Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!isc-br!tau-ceti!cims2!proto!joe From: joe@proto.COM (Joe Huffman) Newsgroups: comp.lang.c Subject: Re: A study in code optimization in C Summary: More comparisions... Keywords: memcopy Message-ID: <1349@proto.COM> Date: 28 Jul 90 00:05:14 GMT References: <133@smds.UUCP> <1990Jul26.144134.16053@ux1.cso.uiuc.edu> Organization: Prototronics; Sandpoint, Idaho Lines: 50 In article <1990Jul26.144134.16053@ux1.cso.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > In article <133@smds.UUCP> rh@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!. > > Time on my computer, in seconds, for 1000 copies of a 20 kilobyte array: > > His code library memcpy > Compiler 1: > (chars) 12.6 2.7 > (ints) 6.9 2.7 > > > Compiler 2: > (chars) 23.6 1.3 > (ints) 6.9 1.3 > [Stuff deleted... compilers were Microsoft and Microway NDPC, machine was 20 MHz 386] I just ran it on a 20 MHz 386 running SCO UNIX. The timing were done with 5000 copies but then divided by 5 to make the numbers comparable. His code library memcpy SCO supplied MSC 5.1 (chars) 14.0 2.05 Zortech 386 code generator not available 1.80 The reason why the macro is so much slower is (as Doug alluded to and I deleted) is that the library routines were written in assembly language and tweaked for near optimum speed and/or size. Not something you usually should do if you are trying to write portable code. Hence let the compiler writers do it -- usually they can be trusted to squeeze the most performance out of the machine. Especially in a competitive marketplace. --- Zortech is my major source of income. Statements about them or their competitors cannot be totally without bias. -- joe@proto.com uunet!proto!joe FAX: 208-263-8772