nfs@notecnirp.Princeton.EDU (Norbert Schlenker) (10/04/89)
In article <3461@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >... >While I was at it, I ran dhrystone. I'll post my version in the next message. >I think it might be interesting if the compatibility list had a column for >dhrystone. Does that sound like a good idea (Alan)? > >Results of my tests: > >Machine Vers. OK? Who? Date Dhry. >Zenith Z248 1.4a Y ast@cs.vu.nl 02 Oct 89 1086 >Tandon 386/16 1.4a Y ast@cs.vu.nl 02 Oct 89 1851 >Wyse 386/16 1.4a Y ast@cs.vu.nl 02 Oct 89 2173 >Epson AX3 1.4a Y ast@cs.vu.nl 02 Oct 89 2500 HD failed >Laser 386/20 1.4a Y ast@cs.vu.nl 02 Oct 89 3125 >Tulip 386/25 1.4a Y ast@cs.vu.nl 02 Oct 89 3846 >Laser 386/25 1.4a Y ast@cs.vu.nl 02 Oct 89 4166 >Commodore PC-60 1.4a Y ast@cs.vu.nl 02 Oct 89 4545 >... >Andy Tanenbaum (ast@cs.vu.nl) Here are my results on a Toshiba 5100, a portable with a 16MHz 80386. I am running Minix 1.4a with Bruce Evans' protected mode. ACK 1.3 ACK 1.3 Microsoft C 5.1 Test Spencer Mine MS/DOS 3.3 ------ ------- ------- --------------- ~R/~SA 2100 2531 3300 ~R/ SA 2657 3397 4160 R/~SA 2091 2514 2860 R/ SA 2647 3382 3570 4760 (maximum optimization) Notes: "Spencer" is the 1.3 library with Henry Spencer's string routines "Mine" is a library with recoded string routines R means register variables are defined, ~R not. SA means structure assignment was used, ~SA not. Lessons to learn: 1. Let your compiler do the work! Notice how the definition of register variables helps not at all (and see how it hurts MSC). 2. Let your compiler do the work! Notice the speedup when you let the compiler move structures around. 3. Find your bottlenecks and recode them. I use a lot of code that shoves strings and/or memory around. The performance penalty (compared to MS/DOS) was just too large when using the standard library, so I recoded the routines. There is still a penalty, but the difference (now 10-20% instead of 30-40%, depending on application) is small enough for me not to be concerned. 4. Bug your vendor (this means you, Andy!) to improve the compiler. Look at the difference between the upper left entry and the bottom right one - there is obviously big room for improvement. (To be fair, the real difference is between 2657 and 4760.) For me, the gap is between 3397 (ACK 1.3, my library) and 4760 (MSC 5.1, no fiddling required), which I consider rather large still (but not large enough to make me use DOS). Norbert
CS497JFA%ROSEVC.Rose-Hulman.Edu@uicvm.uic.edu (V30 CUSTOM MINIX PROJECT) (10/05/89)
From: ROSEVC::CS497JFA "V30 CUSTOM MINIX PROJECT" 4-OCT-1989 17:12:37.14
To: IN%"ihnp4!castor!pcrat!rick"
CC: CS497JFA
Subj: DHRYSTONE on VAX 6320
Our VAX 6320 benchmarked at 2367 DHRYSTONES using your code. I am
currently running the benchmark on a variety of PCs with Turbo C using all
memory models. I will also have results for an Amiga (68000 based) soon.
-John Allen
Rose Hulman Inst. of Technologyroot@cca.ucsf.edu (Systems Staff) (10/05/89)
In article <24988@louie.udel.EDU>, CS497JFA%ROSEVC.Rose-Hulman.Edu@uicvm.uic.edu (V30 CUSTOM MINIX PROJECT) writes: > > Our VAX 6320 benchmarked at 2367 DHRYSTONES using your code. I am > currently running the benchmark on a variety of PCs with Turbo C using all > memory models. I will also have results for an Amiga (68000 based) soon. Why is all this effort being spent running an obsolete version of the Drhystone bencmark? This is 1.1; 2.1 was distributed over a year ago. Version 2.x is designed to avoid certain distortions which gave misleading results with compiler optimizers in the earlier versions. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
ast@cs.vu.nl (Andy Tanenbaum) (10/06/89)
In article <2457@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: >Why is all this effort being spent running an obsolete version of the >Drhystone bencmark? Probably because it is the only one I have. If you have a newer one, please post it. Andy Tanenbaum (ast@cs.vu.nl)
root@cca.ucsf.edu (Systems Staff) (10/07/89)
In article <3545@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <2457@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Thos Sumner) writes: > >Why is all this effort being spent running an obsolete version of the > >Drhystone bencmark? > > Probably because it is the only one I have. If you have a newer one, please > post it. I have version 2.1 here and am preparing it for posting to comp.os.minix per Andy's request. This is the current version and I have just talked to the coordinator and he is prepared to accept new results for inclusion in his next report (which is normally posted to comp.arch). Please discontinue posting results from version 1.1 as it is known to be flawed. In particular, certain "optimizing" compilers give exaggerated results because they eliminate code which is a part of the timing process. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>