Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!tektronix!uw-beaver!uw-june!entropy!dataio!bright
From: bright@dataio.UUCP
Newsgroups: comp.arch,comp.sys.misc
Subject: Re: 01/31/87 Dhrystone Results and Source
Message-ID: <1248@dataio.Data-IO.COM>
Date: Tue, 10-Feb-87 11:57:23 EST
Article-I.D.: dataio.1248
Posted: Tue Feb 10 11:57:23 1987
Date-Received: Sat, 14-Feb-87 00:52:08 EST
References: <2348@homxb.UUCP> <15203@onfcanim.UUCP> <293@ames.UUCP> <2366@homxb.UUCP> <112@winchester.mips.UUCP>
Reply-To: bright@dataio.UUCP (Walter Bright)
Organization: Data I/O - FutureNet Corp., Redmond, WA
Lines: 17
Keywords: Benchmark, C, performance measurement
Xref: utgpu comp.arch:315 comp.sys.misc:346

In article <112@winchester.mips.UUCP> mash@winchester.UUCP (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.

Test the results of the computations so that not only do you know
how fast the benchmark ran, but if the correct result was obtained.
For an example of this, in the Feb 87 Computer Language benchmark
program, they test out the compiler's qsort() function. Unfortunately,
the code to the benchmark program had a bug in it which caused the results
to be rather random. It's simple enough to see if qsort() worked.
Computer Language did its readers a disservice by publishing such stuff.
For instance, with sieve, if you don't get 1899 out, your compiler
blew it.