Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!boulder!pikes!aspen.craycos.com!jrbd From: jrbd@craycos.com (James Davies) Newsgroups: comp.benchmarks Subject: Re: Don't use bc (was: More issues of benchmarking) Message-ID: <1990Dec6.213651.1724@craycos.com> Date: 6 Dec 90 21:36:51 GMT References: <5042@taux01.nsc.com> Organization: Cray Computer Corporation Lines: 26 In article dale@convex.com (Dale Lancaster) writes: > >For this reason it makes a good a benchmark as any. I suspect that most Unix >based bc's/dc's work the same. This is a typical dusty-deck, no optimization >piece of code that shows the performance of the machine from not just the >hardware side but the software (compiler) side as well. I suspect it would take only a few hours of work on bc to add the peephole optimization X/X ==> 1. This would be totally pointless in practical terms, but it might sell machines if everyone keeps taking this "benchmark" so seriously :-) >Today you have to benchmark the compiler as much as the hardware. Unfortunately, this benchmark is too easy to cheat on (the above change relies on neither the compiler nor the hardware, just bc itself). >But of course the only true measure of performance is my own application :-) That's the rationale for benchmarks using more realistic programs, like SPEC and the Perfect Club. I think the bc "benchmark" points up a major reason that people like SPEC more than Perfect: it sums up a machine's performance in a single number. If the Perfect people started computing a "PerfectMark" by averaging their times, they might get more press coverage, but it wouldn't necessarily mean they were measuring anything more useful. People like easy answers to hard questions, I guess. Brought to you by Super Global Mega Corp .com