Path: utzoo!attcan!uunet!snorkelwacker!spdcc!esegue!compilers-sender
From: mike@hpfcso.HP.COM (Mike McNelly)
Newsgroups: comp.compilers
Subject: Re: Unisoft C Compiler for A/UX -- dhrystone and -O
Keywords: benchmarks
Message-ID: <1990Jul20.142926.5776@esegue.segue.boston.ma.us>
Date: 20 Jul 90 14:29:26 GMT
References: <2707@dftsrv.gsfc.nasa.gov>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: mike@hpfcso.HP.COM (Mike McNelly)
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 21
Approved: compilers@esegue.segue.boston.ma.us

If I remember correctly, the original Dhrystone benchmark timed a null
loop to determine loop overhead and then a similar useful loop.  Timing
was at least in part reported as a ratio between the two.

Now if the optimizing compiler is smart enough to see that the original
timing loop is completely useless it may reduce the loop or even
eliminate it entirely but not eliminate the same parts from the other
one that does useful things.  Voila, you have a bogus ratio.

Check to see if this is the case in the source code.  If it is, then a
better way to see if the optimizer is actually improving code is to time
the whole benchmark externally via a time() call from the shell or
something like that.

Several benchmarks I've seen demonstrate this phenomena.

Mike McNelly
mike@hpfcla
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.