chow@batcomputer.tn.cornell.edu (Christopher Chow) (03/10/88)
There is a new version (2.0) of the Dhrystone benchmark recently posted to comp.arch. Using Lightspeed C v2.15, I got the following results: Macintosh II, "no registers" 2469.1 dhrystone/sec. Macintosh II, "registers" 2469.1 dhrystone/sec. Can someone with MPW C, A/UX cc, or other C compilers grab the sources off comp.arch and report the results? Note: The Dhrystone benchmarks were posted twice: make sure you grab the second set since the first one was corrupted. Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-253-6699 Address: 7122 N. Campus 7, Ithaca, NY 14853 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
steele@unc.cs.unc.edu (Oliver Steele) (03/10/88)
All right, I'll try this again. Apologies if you see this twice; I
posted it before and it never showed up, so I'll try it again. I
posted the below-the-= to a local group; additions are:
I hope my results differ from Mr. Chow's because he used the LSC time(),
which grains to the second (minute?), while I used Ticks. I assumed
60Ticks/second; if there are instead n, multiply the below numbers by n/60
to get the Truth. I tried these on Macs with nothing unusual on them
except FadeToBlack; I think this runs off of GetNextEvent() so it doesn't
eat any time. I did the 32bit-int tests by changing ints to longs and
constants in arg lists to long constants; there were two of the latter.
======================================================================
To round things out, here are some more department dhries. LSC is
Lightspeed C; MPW is Macintosh Programmer's Workshop C. I didn't bother
much with the MacPlus -- it's too slow -- and I couldn't find an SE. Yes,
fans, it sometimes is faster not to use register variables (probably on
procedure-call-intensive programs, which have to do too much pushing and
popping, but I didn't look at the output code); and -mc68020 really is
faster than -mc68020 -q.
16 or 32 indicates how many bits ints were. Both compilers use 16-bit
ints by default, but this seemed to be comparing...
Machine Dhrystones/sec
Opt. level
No Registers Registers
================= ============ =========
Mac II
LSC16 2698 2925
LSC32 1910 1779
MPW16
no opt 2609 2608
-q 2734 2768
-mc68020 3043 3066
-q -mc68020 2997 3005
MPW32
no opt 2586 2569
-q 2690 2699
-mc68020 2984 2976
-q -mc68020 2921 2945
MacPlus
LSC16 785 715
LSC32 489 525
----------------------------------------------------------------------------
Oliver Steele ...!uunet!mcnc!unc!steele
steele@cs.unc.edu
"A sea urchin is the best way to comb the inside
of a hairy tube." -- Peter Wolfendenchow@batcomputer.tn.cornell.edu (Christopher Chow) (03/11/88)
In article <1634@thorin.cs.unc.edu> steele@unc.UUCP (Oliver Steele) writes: | |I hope my results differ from Mr. Chow's because he used the LSC time(), |which grains to the second (minute?), while I used Ticks. | | No Registers Registers | ================= ============ ========= | | Mac II | LSC16 2698 2925 You may recall that when I did the Dhrystone 2.0 benchmark on my Mac II, I reported a speed of 2469 Dhry/sec. As it turned out, I didn't use the LSC library function time(), but instead TickCount(). After a bit of experimenting, I found the following interesting fact: When I ran my benchmark, I did it on a 2Mb Mac II under MultiFinder. I had VersaTerm resident to I could look up unix man pages, so I decided the have LSC link an actual application for me since there wasn't enough memory left to run Dhrystones under LSC/MultiFinder. When I made my benchmark timming of 2469, I did so under both Finder and Multifinder, so MultiFinder dosen't seem to be the culprit. This morning, I decided to run the Dhrystone program under LSC/Multifinder (i.e, recompile and have LSC launch it into an Multifinder "partition"). Using this method, I got the 2698 Dhrystone/sec figure which Mr. Steele obtained. Unfortunately, for some reason, I still can't match the Mr. Steel's registers benchmark...(mine was still 2698). Does anyone know what's going on here? Why am I getting an 9.3% increase in execution speed when running under LSC/MF over the linked application version? Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-253-6699 Address: 7122 N. Campus 7, Ithaca, NY 14853 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
rs4u+@andrew.cmu.edu (Richard Siegel) (03/15/88)
In response to an original request from Mr. Chow, I ran the Dhrystone
2.0 under LightspeedC. I have a one megabyte Mac Plus, so I wasn't using
MultiFinder. I found that there was absolutely *no* difference in speed between
the version run as a project and the version run as a linked application.
(There was, of course, a speed gain derived from using the register variables.)
It's just speculation, but consider the following: When you compile and
launch an unlinked project into a MultiFinder partition, the project file
doesn't go through the normal launch process. (Actually, it never does, because
it's not an application.) It's very possible that because of the way the
project file is launched, the Finder isn't able to steal as many cycles from
other applications; this would certainly account for increased performance.
Unfortunately, I don't know how the project file is launched, and I
don't know how LightspeedC interacts with MultiFinder. And I'm sure you folks
don't want me to distract Mr. Kahl from his work. :-)
Side issue:
Has anyone noticed what an incredible hog the Finder is when it's
running under MultiFinder? Is there a good excuse for this besides pure
sloppiness and meanness of spirit? :-)
--Rich
===================================================================
Rich Siegel
Confused Undergrad, Carnegie-Mellon University
The opinions stated here do not represent the policies
of Carnegie-Mellon University.
Arpa: rich.siegel@andrew.cmu.edu
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rich.siegel
==================================================================rs4u+@andrew.cmu.edu (Richard Siegel) (03/21/88)
Actually, I was incorrect on one point - the project document does in fact get launched via use of the _Launch trap. I don't know what I was thinking of.... --Rich