Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!emory!utkcs2!de5 From: de5@ornl.gov (Dave Sill) Newsgroups: comp.benchmarks Subject: Re: expanded bc results Message-ID: <1990Dec14.131722.7878@cs.utk.edu> Date: 14 Dec 90 13:17:22 GMT References: <1990Dec11.145500.6650@cs.utk.edu> <550@cadlab.sublink.ORG> Sender: news@cs.utk.edu (USENET News System) Reply-To: Dave Sill Organization: Oak Ridge National Laboratory Lines: 49 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