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