de5@ornl.gov (Dave Sill) (12/11/90)
Expanded, updated, and revised results for the trivial benchmark:
echo 2^5000/2^5000 | /bin/time bc
Notes: Report corrections/additions to de5@ornl.gov
Some results are vendor-supplied
Disclaimer: These results should not be used to specify minimum
performance requirements in a procurement specification. This
benchmark is best used as a diagnostic tool, e.g., compare successive
runs on on machine or compare similar machines. It can also be used
to determine the rough capabilities of an unknown system when more
thorough and accurate testing isn't feasible.
SYSTEM REAL/USER/SYS REPORTER
------ ------------- --------
AT&T 6386/25 (Coherent) 0.3/0.1/0.1 lih@probe.att.com
IBM 3090 600J (AIX MP) 1.9/1.7/0.0 ken@ab.msc.umn.edu
Fujitsu M780/10 UTS 1.9/1.8/0.0 toyama@ae.keio.ac.jp
IBM RS/6000 Model 540 3.3/2.8/0.0 hh@rhi.hi.is
MIPS RC6280 2.8/2.8/0.0 kmk@tut.fi
MIPS RC6280 2.8/2.8/0.0 mark@mips.COM
IBM RS/6000 Model 530 3.4// mccalpin@perelandra.cms.udel.edu
Alliant FX/2800 3.6/3.5/0.0 turner@sp64.csrd.uiuc.edu
IBM RS/6000 Model 530 3.5/3.5/ xxdon@monet.lerc.nasa.gov
IBM RS/6000 Model 730 3.5/3.5/0.0 tif@doorstop.austin.ibm.com
Amdahl 5870 (UTS) 17.6/4.3/ xxdon@monet.lerc.nasa.gov
IBM RS/6000 320 4.4/4.3/0.0 de5@ornl.gov
Cray Y-MP (6ns) 5.0// elm@sprite.Berkeley.EDU
IBM RS/6000-520 (3.1) 4.5/4.4/0.0 AKayser@et.tudelft.n
DECsystem 5500 (4.1) 5.0/5.0/0.0 doi@jrdmax.enet.dec.com
SGI 4D/380SX 5.2/5.2/0.0 kmk@tut.fi
SGI 320 (2 cpu) 5.2/5.2/ xxdon@monet.lerc.nasa.gov
SGI 340 (4 cpu) 5.2/5.2/ xxdon@monet.lerc.nasa.gov
Motorola 8612 33MHz 88k 5.2// matth@oakhill.sps.mot.com
HP9000 series 870 5.5/5.5/0.0 dvl@hpcupt1.cup.hp.com
HP9000/870 10.7/5.6/0.0 renglish@hplabsz.HPL.HP.COM
Stardent 3000 6.0/5.8/0.1 kmk@tut.fi
Cray Y-MP 4/64 13.9/5.9/ xxdon@monet.lerc.nasa.gov
Cray Y-MP 2/64 /5.9/ dwf@lanl.gov
DECstation 5000/200 6.0/6.0/0.0 de5@ornl.gov
DECstation 5000/200 6.0/6.0/0.0 NEUMANN@awiwuw11.wu-wien.ac.at
DECsystem 5810 6.2/6.0/0.1 de5@ornl.gov
MIPS RC3280 7.0/6.0/0.2 kmk@tut.fi
MIPS M/2000 /6.0/ zdenko@katzo.rice.edu
ALR 486/25 (SCO) /6.2/ jpp@specialix.co.uk
SGI 4D/260 IRIX 3.3.1 7.0// ccsupeh@prism.gatech.edu
Sparcstation 2GX /7.0/ dwf@hope.lanl.gov
Sun 4/490 (-Bstatic) 7.2/7.1/0.0 poole@chx400.switch.ch
DECsystem 5400 (J4.0) 7.6// doi@jrdmax.jrd.dec.com
Sun 4/490 (-O4) 7.7/7.6/0.0 poole@chx400.switch.ch
Cray X-MP 4/8 20.7/7.8/ xxdon@monet.lerc.nasa.gov
DG 88k at 25 Mhz 8.1/8.0/0.0 philip@beeblebrox.dle.dg.com
SGI 4D/25 8.4/8.1/ xxdon@monet.lerc.nasa.gov
Sun 4/470 9.1/8.3/0.0 casper@fwi.uva.nl
Cray X-MP (Unicos) 8.62/8.49/.05 e5@ornl.gov
Cray 2 (4.1ns) 8.8// elm@sprite.Berkeley.EDU
Compaq 486/25 ISC 2.2 11.2/9.1/0.1 suitti@ima.isc.com
Tektronix XD88/30 9.1// tev@pons.uio.no
Convex C220 10.4/9.4/ xxdon@monet.lerc.nasa.gov
DECstation 3100 (4.0) 9.7/9.4/0.1 NEUMANN@awiwuw11.wu-wien.ac.at
HP9000/375, HP-UX 7.0 14.4/9.4/0.1 wunder@orac.HP.COM
DECstation 3100 (3.1) 9.8/9.6/0.1 NEUMANN@awiwuw11.wu-wien.ac.at
HP9000/845 10.0/9.9/0.0 renglish@hplabsz.HPL.HP.COM
MIPS RS2030 /10.0/ zdenko@katzo.rice.edu
SGI 4D/120GTX (3.3.1) 10.0// ccsupeh@prism.gatech.edu
Sun 4/330, SunOS 4.03 11.8// arg@ccvr1.cc.ncsu.edu
VAX 8800 (4.0) 12.1// doi@jrdmax.jrd.dec.com
SPARCstation 1+ (-Bst) 10.8/10.4/0.1 poole@chx400.switch.ch
SPARCstation 1+ (-O4) 11.5/11.1/0.1 poole@chx400.switch.ch
ALR 386/33 (SCO) /11.1/ jpp@specialix.com
Sun 4/370 12.3/11.2/0.3 casper@fwi.uva.nl
SPARCstation 1+ (4.1) 12.2/11.9/0.1 AKayser@et.tudelft.nl
SPARCstation 1+ 12.2/12.0/0.1 de5@ornl.gov
SPARCstation 1+ 12.6/12.0/0.1 casper@fwi.uva.nl
Compaq 386/33 ISC 2.2 12.5/12.1/0.1 suitti@ima.isc.com
DECstation 2100 12.8/12.5/0.1 de5@ornl.gov
VAX 6410 (4.0) 12.8// doi@jrdmax.jrd.dec.com
Mac II(fx) A/UX 2.0 13.4// jim@jagubox.gsfc.nasa.gov
DECstation 2100 13.4/12.6/0.2 meissner@osf.org
DG AViiON AV200 (4.30) 12.6 prc@erbe.se
MicroVAX 3900 (J4.0) 13.5// doi@jrdmax.jrd.dec.com
SGI 4D/20 /13.1/ buck@drax.gsfc.nasa.gov
VAX 6320 (J4.1) 15.1// doi@jrdmax.jrd.dec.com
SPARCstation SLC 15.4/15.1/0.1 juan@burdell.gatech.edu
SPARCstation SLC 15.4/15.1/0.1 casper@fwi.uva.nl
SPARCstation 1 16.0/15.2/0.1 juan@burdell.gatech.edu
Compaq 386/25 ISC 2.2 16.5/16.1/0.1 suitti@ima.isc.com
Harris HCX-7 (3.1) 30.0/16.2/ morgan@engr.uky.edu
HP9000/835 18.0/17.9/0.1 renglish@hplabsz.HPL.HP.COM
HP9000/835 (HP-UX 7.0) 20.6/18.0/0.1 NEUMANN@awiwuw11.wu-wien.ac.at
HP9000-835CHXSE (7.0) 18.2/18.1/0.0 jsadler@misty.boeing.com
NeXT 68030 (Mach 1.0) /18.8/ castor@fizzle.stanford.edu
MicroVAX 3200 /20.5/ crispin@csd.uwo.ca
HP9000-850S (7.0+io) 21.2/20.6/0.3 jsadler@misty.boeing.com
HP9000/825 24.2/23.9/0.1 renglish@hplabsz.HPL.HP.COM
Sequent S27 /26.7/ crispin@csd.uwo.ca
Sun 386i 28.0// leavitt@mordor.hw.stratus.com
Sun 3/80 38.3/28.6/0.6 casper@fwi.uva.nl
Sun 3/60 31.0/29.9/0.4 casper@fwi.uva.nl
IBM PS/2 386-20 (1.2) 36.3// akayser@et.tudelft.nl
HP 9000/840 1 :26.5/37.6/2.2 hh@rhi.hi.is
SGI 3030 39.4/37.8/ xxdon@monet.lerc.nasa.gov
AT&T 3B2/1000-80 3.2.2 33.5/33.1/ morgan@engr.uky.edu
IBM PS/2 386-20 (1.2) 35.7/35.4/0.1 AKayser@et.tudelft.nl
Sun 3/110 /39.3/ crispin@csd.uwo.ca
Sun 3/50 /42.9/ crispin@csd.uwo.ca
SPARCstation SLC 44.5/43.4/0.1 karplus@ararat.ucsc.edu
INTeL 80286 SCO 45.8/45.1/0.2 ethan@thinc.UUCP
Sun 3/50 45.9// zeeff@b-tech.ann-arbor.mi.us
IBM RT 48.8// zeeff@b-tech.ann-arbor.mi.us
IBM RT-6150 (AIX 2.2.1) 49.3// akayser@et.tudelft.nl
IBM RT-6150 (AIX 2.2.1) 51.6/50.1/0.6 AKayser@et.tudelft.nl
VAX 11/780 73.3// lindsay@gandalf.cs.cmu.edu
MicroVAX 2000 (J4.1) 74.1// doi@jrdmax.jrd.dec.com
MicroVAX 2000 74.2/72.4/1.6 de5@ornl.gov
Zenith 386/20 ISC 2.2 86.6/84.6/0.6 suitti@ima.isc.com
VAX 780 90.4// suitti@ima.isc.com
AT&T 3B2/310 (3.1) 1:37.7/1:35.0/ morgan@engr.uky.edu
AT&T 3B20S (2.0) 2:02.3/1:47.9/ morgan@engr.uky.edu
--
Dave Sill (de5@ornl.gov)
Martin Marietta Energy Systems
Workstation Supportstaff@cadlab.sublink.ORG (Alex Martelli) (12/12/90)
de5@ornl.gov (Dave Sill) writes: ... >AT&T 6386/25 (Coherent) 0.3/0.1/0.1 lih@probe.att.com >IBM 3090 600J (AIX MP) 1.9/1.7/0.0 ken@ab.msc.umn.edu >Fujitsu M780/10 UTS 1.9/1.8/0.0 toyama@ae.keio.ac.jp Oh great, what a NIFTY benchmark indeed - finally I now *know* that I can junk all 3090's and Fujitsu's and replace each of them with a PC running the $99 Coherent OS - this will save us a bundle while enhancing performance by 6 times and more. BTW, I hear from a friend who DOES own a Coherent system that it is FAR slower [30+ times] if you compute 2^hugenumber ONCE, instead of doing it twice then dividing - MIGHT it not be that MW's bc IS optimizing...? Naah, this is tantamount to suggesting the utter worthlessness of this benchmark, and who would ever want to be such a spoilsport?-) -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
levisonm@qucis.queensu.CA (Mark Levison) (12/14/90)
To save bandwidth in this group and wading through a dozen extra articles a day could everyone just mail their bc benchmarks to Dave Sill (de5@ornl.gov). followup to one of Dave's comments: Dave if benchmarks are not used for comparison what are the used for? Mark Levison levisonm@qucis.queensu.ca - from a man to cheap to buy a real signature
shri@ncst.ernet.in (H.Shrikumar) (12/14/90)
In article <1990Dec11.145500.6650@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: > echo 2^5000/2^5000 | /bin/time bc >SYSTEM REAL/USER/SYS REPORTER >------ ------------- -------- >Amdahl 5870 (UTS) 17.6/4.3/ xxdon@monet.lerc.nasa.gov >IBM RS/6000 320 4.4/4.3/0.0 de5@ornl.gov Aha, so is the Amdahl fast or slow ? If SPECmarks are multiple numbers, then what are these !! :-) >Cray X-MP 4/8 20.7/7.8/ xxdon@monet.lerc.nasa.gov Now I know why I did not buy a Cray (assuming export clearance :-) my own little 6803 at home would beat that! :-) >Sun 4/370 12.3/11.2/0.3 casper@fwi.uva.nl What does that mean, the Sun is a great OS as it has very little overbyte ? :-) Someone has figures for a Mess-DOS PC ? :-) enuff, this goes into my kill file. -- shrikumar ( shri@ncst.in ) "The slow one now will later be fast, the times they are a-changing!"
de5@ornl.gov (Dave Sill) (12/14/90)
In article <1024@maestro.queensu.CA>, levisonm@qucis.queensu.CA (Mark Levison) writes: > >followup to one of Dave's comments: > Dave if benchmarks are not used for comparison what are the used for? I don't remember saying that. The bc results disclaimer says: >These results should not be used to specify minimum >performance requirements in a procurement specification. This should go without saying, but apparently one can't be too careful. >This benchmark is best used as a diagnostic tool, e.g., compare >successive runs on on machine or compare similar machines. Seems to allow for comparison... >It can also be used to determine the rough capabilities of an unknown >system when more thorough and accurate testing isn't feasible. Of course, one should take the results with a grain of salt. The subsecond timing for the '386 running Coherent should really drive that point home. Use your common sense. -- Dave Sill (de5@ornl.gov) It will be a great day when our schools have Martin Marietta Energy Systems all the money they need and the Air Force Workstation Support has to hold a bake sale to buy a new bomber.
de5@ornl.gov (Dave Sill) (12/14/90)
In article <550@cadlab.sublink.ORG>, staff@cadlab.sublink.ORG (Alex Martelli) writes: > ... >>AT&T 6386/25 (Coherent) 0.3/0.1/0.1 lih@probe.att.com >>IBM 3090 600J (AIX MP) 1.9/1.7/0.0 ken@ab.msc.umn.edu >>Fujitsu M780/10 UTS 1.9/1.8/0.0 toyama@ae.keio.ac.jp > >Oh great, what a NIFTY benchmark indeed - finally I now *know* that >I can junk all 3090's and Fujitsu's and replace each of them with a >PC running the $99 Coherent OS - this will save us a bundle while >enhancing performance by 6 times and more. On the off chance that you just haven't received any of the numerous articles discussing the valid uses of this test and its severe limitations, I'll refrain from requesting that you "get a clue." But did you read the disclaimer in that article? The one that says it's most useful for comparing similar systems and for tracking a system over time? Yes, you're very clever to have realized that the bc test is limited. Luckily there's a ringer like the Coherent number to make it especially obvious. I wonder how many people beside Eugene and myself realize that the kinds of problems the bc test has exist to some degree in *all* benchmarks. The danger isn't trivial benchmarks like this one that are so obviously limited, it's in the more rigorous suites where it's not at all obvious. If you can't see the problems with the bc benchmark, then you're really going to be clueless when it comes to interpreting the SPEC suite, Livermore Loops, x11perf, Linpack, etc. >BTW, I hear from a friend >who DOES own a Coherent system that it is FAR slower [30+ times] if >you compute 2^hugenumber ONCE, instead of doing it twice then >dividing - MIGHT it not be that MW's bc IS optimizing...? How astute. >Naah, this >is tantamount to suggesting the utter worthlessness of this benchmark, >and who would ever want to be such a spoilsport?-) The only thing worse than a zillion bc result postings is hal a zillion mindless bc benchmark-bashing postings. -- Dave Sill (de5@ornl.gov) Martin Marietta Energy Systems Workstation Support
rosenkra@convex.com (William Rosencranz) (12/16/90)
In article <1990Dec14.131722.7878@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >In article <550@cadlab.sublink.ORG>, staff@cadlab.sublink.ORG (Alex Martelli) writes: >> [ talks of dumping 3090 and fujitsu in favor of pc with coherent :-) ] > >On the off chance that you just haven't received any of the numerous >articles discussing the valid uses of this test and its severe >limitations, I'll refrain from requesting that you "get a clue." > >But did you read the disclaimer in that article? The one that says >it's most useful for comparing similar systems and for tracking a >system over time? the problem, dave, is that some people DO NOT READ THE FINE PRINT. you are propagating misinformation if you do not do the test correctly in the first place. that means at least compare the same source code. otherwise, i will rewrite bc to parse the input and see if it is a trivial test. then i will beat any bc on any machine not similarly altered (including, hopefully, a coherent 386 pc :-). this tests my skill, not the system. you'd be benchmarking analysts, not machines, not that this isn't what often happens in real life anyway. you can call people who might rely on this bm naive or irresponsible or whatever, but i think the real guilt lies with the testers, not the interpreters. the only thing each of the tests reported have in common is that they (presumably) all compute the same result. >The only thing worse than a zillion bc result postings is hal a >zillion mindless bc benchmark-bashing postings. sorry to disagree, i think the bashing is what makes this sort of group worthy. otherwise i or you or anybody can post anything and get away with it. and it is not just poor defenseless vendors doing the bashing. why don't you do it right? meaning write a bc and distribute the source with guidlines for running it and reporting results? i suspect some damage has already been done. and i would NOT be suprised if "bc timings" start appearing in some RFPs... -bill rosenkra@convex.com [ as always, just my feelings, not necessarily my employer's ] -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com