Explanation, please!

Rick Richardson rick at pcrat.UUCP
Fri Sep 2 08:37:23 AEST 1988


I did a quick comparison of the times for "memcpy(,,n*4)", Duff's
device, Nathaniel's "nat", and Hank's versions.  Here's the results:

TEST	MACHINE				ATT cc	VENIXcc	GNU1.26
memcpy	8Mhz 286, Venix SVR2		 3.35	11.15	-
duff	8Mhz 286, Venix SVR2		16.58	 4.56	-
nat	8Mhz 286, Venix SVR2		16.73	 5.11	-
hank	8Mhz 286, Venix SVR2		 1.83	 ccbarf	-
memcpy	16Mhz 386, 386/ix 1.0.4		  .82	  -	 .82
duff	16Mhz 386, 386/ix 1.0.4		 2.01	  -	2.26
nat	16Mhz 386, 386/ix 1.0.4		 1.95	  -	2.21
hank	16Mhz 386, 386/ix 1.0.4		  .86	  -	 .89

		* Everything was compiled with -O
		* test moved 2000,1999,...,2,1 int's

I learned this: Venix obviously doesn't have a good memcpy, and
Duff, or nat make a good replacement.  AT&T uses the block move
in memcpy, and it is a definite win on both machines. The AT&T
286 C compiler is terrible for these program on the 286.  AT&T
still has a slight edge over gcc *for these programs*. Hanks
version, while not portable, is a clear win on the 286 (disassemble
memcpy and hank's to see why), and virtually as good as memcpy on 386.

Conclusion: you can't make any.  It all depends on your computer
and compiler.
-- 
		Rick Richardson, PC Research, Inc.
		rick%pcrat.uucp at uunet.uu.net (INTERNET)
		   uunet!pcrat!rick (UUCP, Personal Mail)
..!pcrat!jetroff (JetRoff Info)		..!pcrat!dry2 (Dhrystone Submissions)



More information about the Comp.lang.c mailing list