aburto@marlin.NOSC.MIL (Alfred A. Aburto) (08/19/88)
------------------
In the June BYTE benchmark article 'Problems and Pitfalls' I showed some
Sieve benchmark results for various array sizes. The sieve program I used
wasn't Gilbreath's original program but a version modified for register
long variables and large arrays (via 'malloc()'). I also put in a loop
counter within the outer ('iter') loop to hopefully prevent optimizing
compilers from deleting this loop altogether. I called this version
'nsieve'. I would be happy to post nsieve.c if anyone is interested. It
includes timing routines for UNIX (I tested it on the SUN and VAX), Amiga,
and the IBM PC systems using TURBO C. My mail address:
aburto@marlin.nosc.mil.UUCP .
These are some NSIEVE Results for various array sizes (10 Iterations):
Array Size --------------------- BenchTime (sec) -----------------------
(Bytes) SUN 3/280 VAX 8600 Turbo-Amiga Amiga
(68020 @25MHz) (68020 @14.32MHz) (68000 @ 7.16 MHz)
8191 0.250 0.250 0.461 (0.264) 2.280
10000 0.317 0.333 0.578 (0.331) 2.820
20000 0.667 0.800 1.195 (0.684) 5.700
40000 1.333 1.817 2.383 (1.365) 11.560
80000 2.967 3.700 4.820 (2.761) 23.340
160000 7.933 8.133 9.758 (5.589) 47.200
320000 17.533 18.100 ------ ^ ------
|
|
Scaled to 25 MHz SUN clock speed ----------+
Average Run Time (sec) relative to 10 Iterations and the 8191 array size:
8191 0.316 0.354 0.484 (0.277) 2.350
(1) SUN 3/280, 25 MHz 68020 CPU. SUN UNIX 4.2 Release 3.4.
compiled using 'cc -O'.
(2) VAX 8600, ?? MHz ????? CPU. UNIX 4.3 BSD. compiled using 'cc -O'.
(3) Turbo-Amiga, 14.32 MHz 68020 CPU. Compiled using Manx Aztec C V3.4B
and 'cc +2 +L +ff' (no 'optimize' option available).
(4) Amiga, 7.16 MHz 68000 CPU. Compiled using Manx Aztec C V3.4B and
'cc +L +ff' (no 'optimize' option available).
The VAX 8600 results are different from those that appeared in the
Jun Byte Article because I thought I could not define 'register'
variables at all, but I was in error. 'register long' variables
seem to work fine on our VAX 8600 UNIX 4.3 C compiler. It is the
register 'short' types that (apparently) cause problems.
The VAX and SUN run times show a slight non-linear trend as the array
size increases. This is due I suspect to an increasing number of 'page
faults' with increasing array size. I suspect this because the Turbo-Amiga
has no memory management while the UNIX systems do and the Turbo-Amiga run
times are very linear (almost) with respect to increasing array size.
It is very interesting to me that the Turbo-Amiga results (for small arrays)
scaled to 25 MHz are in very close agreement to the SUN 3/280 results.
This indicates to me that the Turbo-Amiga non-optimizing Manx Aztec C
compiler was generating just as efficient nsieve code as the optimizing
SUN 3/280 C compiler. This also indicates that nsieve is probably not
very susceptable to optimization. I know, these results could mean other
things, but I'm assuming the SUN 3/280 does indeed do some optimizations
that Manx Aztec C doesn't do (Aztec C doesn't claim to do any optimizations
at all).
NSIEVE is, I think, a farely reasonable test program. The ratio of NSIEVE
performance between the SUN 3/280 and the Turbo-Amiga for example is not
too much different than the ratio of Dhrystone performance. The Turbo-Amiga
with Manx Aztec C does about 3000 Dhrystones/sec and on a SUN 3/280 I would
expect this compiler to give me 3000 * 0.461 / 0.267 = 5180 Dhrystones/sec
or so based upon the NSIEVE results.
Al Aburto
aburto@marlin.nosc.mil.UUCP