|Unisoft C Compiler for A/UX -- dhrystone and -O email@example.com (1990-07-06)|
|Re: Unisoft C Compiler for A/UX -- dhrystone and -O mike@hpfcso.HP.COM (1990-07-20)|
|From:||mike@hpfcso.HP.COM (Mike McNelly)|
|Organization:||Hewlett-Packard, Fort Collins, CO, USA|
|Date:||Fri, 20 Jul 90 14:29:26 GMT|
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.
Return to the
Search the comp.compilers archives again.