Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-spam!ames!pioneer!eugene
From: eugene@pioneer.UUCP
Newsgroups: comp.arch,comp.sys.misc
Subject: Re: 01/31/87 Dhrystone Results and Source
Message-ID: <319@ames.UUCP>
Date: Fri, 13-Feb-87 01:47:30 EST
Article-I.D.: ames.319
Posted: Fri Feb 13 01:47:30 1987
Date-Received: Sat, 14-Feb-87 01:40:39 EST
References: <2348@homxb.UUCP> <15203@onfcanim.UUCP> <293@ames.UUCP> <2366@homxb.UUCP> <112@winchester.mips.UUCP> <1248@dataio.Data-IO.COM>
Sender: usenet@ames.UUCP
Reply-To: eugene@pioneer.UUCP (Eugene Miya N.)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 46
Keywords: Benchmark, C, performance measurement
Xref: utgpu comp.arch:316 comp.sys.misc:347

Walter Bright says

>(John Mashey) writes:
>>4) How about some suggestions for ways to improve Dhrystone?
>Make the computations 'do something', so that an optimizing compiler
>won't simply delete them. The Datalight optimizing C compiler deletes
>(correctly) much of Dhrystone, because it determines that many of the
>statements cannot serve any useful purpose.

Do something?  Sure
This is called EXPERIMENT CONTROL.  It's really lacking in computer
science (some say sic).  You need to learn about (as well as Weicker,
author of DSTONES), what's called the "Pre-test Condition," the
"Post-Test" Condition, and also during the test.  You want to set
something up called a CONTROL or CONTROL condition for comparison
purposes.  Pre-test conditions include flushing caches or page tables
before hand.  During test: avoid repetition, especially on machines
which page.  Repeating a section of code just because the clock is poor
is not representative of the true running time of a machine, after the
first repetition, your page tables are pre-filled and are not
representative of the real running conditions of the machine.

Another thing: take a chuck of code (we can control it later), throw the
test section inside this chunk compare the two conditions.

>QSORT example.

Good example but consider how pattern of data access can effect the
performance of a sort.  My suggestion is perform at least three cases
(if not more) in data sorting. 1) Random case, 2) case of already sorted
arrays [minimum comparison and fetching], and 3) inversely ordered
arrays.  You might also have separate worst case data patterns depending
on algorithm type (QSORT in this case).  Don't be surpised at what you get.

I have references to some good simple books on experiment control (not
computer science texts] as well as several papers [surprise: some of
the best are from IBM].

From the Rock of Ages Home for Retired Hackers:

--eugene miya
  NASA Ames Research Center
  eugene@ames-aurora.ARPA
  "You trust the `reply' command with all those different mailers out there?"
  "Send mail, avoid follow-ups.  If enough, I'll summarize."
  {hplabs,hao,nike,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene