Xref: utzoo comp.lang.c:12321 comp.arch:6228 Path: utzoo!attcan!uunet!pcrat!rick From: rick@pcrat.UUCP (Rick Richardson) Newsgroups: comp.lang.c,comp.arch Subject: Re: Explanation, please! Message-ID: <566@pcrat.UUCP> Date: 1 Sep 88 22:37:23 GMT References: <638@paris.ics.uci.edu> <189@bales.UUCP> Reply-To: rick@pcrat.UUCP (Rick Richardson) Organization: PC Research, Inc., Tinton Falls, NJ Lines: 31 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@uunet.uu.net (INTERNET) uunet!pcrat!rick (UUCP, Personal Mail) ..!pcrat!jetroff (JetRoff Info) ..!pcrat!dry2 (Dhrystone Submissions)