baskett@decwrl.UUCP (Forest Baskett) (11/04/83)
I thought some of you might be interested in some comparative numbers on
the latest microcomputer on the block. The Pascal referenced is the new
VAXElan Pascal. The Unisoft C compiler has the reputation locally of
being usually better than other commonly used C compilers on 68000's.
(I'm not sure of this last statement but that's what I keep hearing.)
MicroVax I 68000, 10MHz, no wait states, floating point subroutines
Pascal Unisoft C
perm 6.6 2.8 all permutations of n things, very recursive (n=7)
towers 7.1 3.4 towers of hanoi, very recursive
queens 1.9 1.9 Wirth's 8 queens program, 50 times
intmm 3.1 8.4 multiply two 100 square integer arrays
mm 4.4 32.2 multiply two 100 square real arrays
puzzle 17.4 20.7 Baskett's famous puzzle program
quick 2.1 3.2 Quicksort 50,000 random numbers
bubble 3.3 4.8 Bubblesort 5,000 random numbers
tree 9.1 7.4 Insert 50,000 random numbers in an ordered binary tree
fft 5.7 59.9 FFT of 256 real numbers
Both versions of these programs are nearly identical syntactically and
semantically. All are sensible but straightforward programs. There are no
C hacks such as *p++ instead of p[i] or register int i instead of int i.
Thus there is the potential for hand tuning the C versions if you like to
do that sort of thing. Similarly, the VAXElan Pascal system has an INLINE
facility which has not been exercised here. The Pascal integers are 32 bits;
the C ints are 16 bits. The Pascal real is treated differently from the C
float in the usual way but this difference is clearly dominated by the lack
of floating point hardware or microcode on the 68000. John Hennessy at
Stanford is responsible for putting together this suite of benchmarks.
These are pure CPU comparisons and may imply nothing about the performance
of the "systems" such CPU's might be in. All numbers are seconds.
Forest Baskett
Western Research Lab
Digital Equipment Corporationbaskett@decwrl.UUCP (Forest Baskett) (11/08/83)
Oops, I seem to have goofed. Int's on the 68000 C were 32 bits! However, the only place where "jsr lmul"'s appeared were in some low frequency initialization routines because of the random number generator, in the integer matrix multiply routine were the semantics of the program explicitly specified a long integer multiply, and in the cosine subroutine of the fast fourier transform, again for initialization. So perhaps the comparison was more fair than I had originally imagined. The programs are available. (John Leon, thanks for the correction.) Again not trying to hide my lack of independence (but trying to be fair and honest), Forest Baskett Western Research Lab Digital Equipment Corporation