Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!agate!shelby!eos!eugene
From: eugene@eos.arc.nasa.gov (Eugene Miya)
Newsgroups: comp.benchmarks
Subject: Re: unbc - A New!, Improved! bc benchmark (nope)
Message-ID: <7710@eos.arc.nasa.gov>
Date: 18 Dec 90 22:38:09 GMT
References: <115440001@hpcuhc.cup.hp.com>
Reply-To: eugene@eos.UUCP (Eugene Miya)
Organization: NASA Ames Research Center, Calif.
Lines: 28

In article <115440001@hpcuhc.cup.hp.com> spuhler@hpcuhc.cup.hp.com
(Tom Spuhler) writes:
>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?

Er, sorry, I must be dense, but where does the "richer instruction mix"(tm)
come in (sounds like coffee, thank god I drink tea).  Seems like more of
the same.  Do you work per change in a marketing department?  Longer running?
Longer is not necessarily better (no sex jokes please).  Seems this could
be optimized as well.  Fortunately (?) I didn't see the beginnings of the 
2^n thread.  

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

Nope.  Beg to disagree.  It can be more damaging.  I think some one is suing
someone else over performance claims, getting nasty.  
Note: in a first post, I cited the APL benchmark (Gaussian sum) where
the adds were all replaced by the simple (n+1)n/2 formula (n was = 256).

It's hard to understand the behavior of some benchmark results, even by
some of the programmer who wrote a given benchmark or compiler.

--e.n. miya, NASA Ames Research Center, eugene@eos.arc.nasa.gov
  {uunet,mailrus,most gateways}!ames!eugene
  AMERICA: CHANGE IT OR LOSE IT.