A study in code optimization in C

Tom Tkacik tkacik at kyzyl.mi.org
Mon Jul 30 00:38:27 AEST 1990


In article <134 at smds.UUCP>, rh at smds.UUCP (Richard Harter) writes:
> In article <1990Jul26.144134.16053 at ux1.cso.uiuc.edu>, mcdonald at aries.scs.uiuc.edu (Doug McDonald) writes:
> > In article <133 at smds.UUCP> rh at smds.UUCP (Richard Harter) writes:
 
> > >The macro shown below is an optimized memory to memory copy macro.
> > >It is probably faster than memcopy on your machine -- I have checked
> > >it on several machines and have always found it to be faster.
> >                                  !!!!!!
 
> > Oh My!.
 
> 	[Superior timings for a 20KB move on a 386 by memmove given]
 
> Ouch.  I should have phrased that more carefully.  Yes, the gentleman
> is quite right.  As to be expected, a hardware bulk move is always
> going to beat code that uses item by item move instructions.  Furthermore,
 
> In defense I have to point out that the quoted remark is accurate;
> timings were made on 680x0 boxes, vaxes (!), and some risc boxes,
> but not, obviously, on any 386 boxes.
 
Oh My!.

I also tried this using 1000 copies of 20K blocks.
This was performed on an AT&T UnixPC (68010 @ 10MHz).
Here are my times:
			gencopy			memcpy
     GCC  (char)20000	31.3sec			12.0
	  (int)  5000	12.2			12.0

     CC	  (char)20000	31.3sec			12.0
	  (int)  5000   12.3			12.0

Both CC and GCC used the library version of memcpy, so there is little
suprise that they both used the same time.
 
>                                        Small comfort for the chap
> who took my posting blindly and put it on his 386.  Apologies.

Small comfort for the chap who blindly puts it on a 680x0.
I think I will stick to the library version.:-)

-- 
Tom Tkacik		tkacik at kyzyl.mi.org
Speaking only for myself here in Royal Oak.



More information about the Comp.lang.c mailing list