Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!watnot!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP
Newsgroups: comp.arch,comp.sys.misc
Subject: Re: 01/31/87 Dhrystone Results and Source
Message-ID: <15203@onfcanim.UUCP>
Date: Thu, 5-Feb-87 15:17:31 EST
Article-I.D.: onfcanim.15203
Posted: Thu Feb  5 15:17:31 1987
Date-Received: Fri, 6-Feb-87 01:37:10 EST
References: <2348@homxb.UUCP>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 28
Keywords: Benchmark, C
Xref: watmath comp.arch:293 comp.sys.misc:305

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.  How about changing the code:

	printf("Dhrystone(%s) time for %ld passes = %ld\n",
		Version,
		(long) LOOPS, benchtime/HZ);

to:

	long hundredths;

	hundredths = (benchtime*100 + HZ/2)/HZ;
	printf("Dhrystone(%s) time for %ld passes = %ld.%02ld\n",
		Version,
		(long) LOOPS, hundredths/100, hundredths%100);