Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcuhc!spuhler
From: spuhler@hpcuhc.cup.hp.com (Tom Spuhler)
Newsgroups: comp.benchmarks
Subject: nbc - A New!, Improved! bc benchmark
Message-ID: <115440001@hpcuhc.cup.hp.com>
Date: 17 Dec 90 22:29:00 GMT
Organization: Hewlett Packard, Cupertino
Lines: 51

Concerned that your 'bc' benchmark results may be skewed by vendor
optimization of the trivial case?  Looking for a longer running version
for your faster CPU's?  Does management want a richer instruction mix to
be tested?

For YOU, we proudly present:

nbc - a better bc benchmark.

It's easy, it's fun.  Just type the following line on a system of your
choice under the SAME (or as close as possible) conditions in which the
system will normaly be used.

      echo '2^9999/3^6308' |/bin/time bc

<Output is> 2

Record and report the values returned by /bin/time along with the system
configuration.  Elapsed time is most important.  Make sure that the
time command on the system under test is working correctly.  

What you will learn:  How fast bc will solve 2^9999/3^6308 on the tested
machine under the conditions specified.  Of course, this may be somewhat
indicative of the performance of that machine running your application,
under the specified conditions.  Don't count on it, but hey, the other
mistake is the other extreme (don't ignore  it just because it's
simple).  
---
My philosophy on benchmarks is something along  the lines of:

	Any correctly run and reported benchamrk is a datapoint that can
	be used to gain a better understanding of a system's
	performance characteristics..  

and,

	All accurate performance data is interesting and useful, but not
	necessarly indicative (of the performance of that machine
	running your application).

	Some performane data is more indicative then others.  The most
	indicative is that which most accurately matches your target
	workload.  Probably also, the most expensive to obtain.

and finally,

	It is better to have some data, no matter how limited, as long
	as you understand it, then no data at all.

Happy benchmarking
-Tom Spuhler