🚀 go-pugleaf

In article <15203@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes:
>Does it bother anyone else that the dhrystone benchmark is
>sometimes (if TIME instead of TIMES is used) based on execution
>time of a small number of seconds, measured to the nearest second?
>
>Many of the faster machines execute the benchmark in 10 seconds or less,
>giving a result that may have +- 10% error.  Doesn't it then seem silly
>to quote "dhrystones" as 4-figure numbers?
>
>If TIME is defined, longer execution times (by a factor of 10 at least)
>should be used.
>
>And when TIMES is being used, although much better resolution is
>available, we can't tell this by looking at the fractional part
>of the elapsed time, since it is always truncated to the nearest
>integer.
The trucated elapsed time is printed but the full time is used for the
dhrystones/second calculation.

There is still a problem on fast machines (esp when TIME is used).  Why
not instist that LOOPS be adjusted to force the benchmark to take about
60 seconds to run.  This could even be done automatically by having the
program time a single loop and then decide what LOOPS needs to be.

Another problem is that the variable used to count to LOOPS is declared
as an unsigned int.  This really should be a long so that fast machines
with 16 bit int's (small model 80?86) can have a hope of being able to
run long enough to get accurate times.  The looping time itself is
factored out of the benchmark so changing it shouldn't affect the actual
dhyrstone/sec measurement.
-- 
Jim Prescott	rochester!moscom!jgp