Integer Multiply/Divide on Sparc
Bo Thide'
irf at kuling.UUCP
Sun Dec 31 03:41:35 AEST 1989
In order to put the discussion on SPARC arithmetics slowness into
some perspective, we ran Plum Hall benchmark on one of our CISC
and two of our RISC machines. The machines we used were:
HP9000/370 MC68030/33 MHz with and without floating point accelerator (fpa)
HP9000/835 HP-PA RISC/15 MHz
Sun SparcStation1 (SS1) SPARC RISC/20 MHz
================================================================================
register auto auto int function auto
int short long multiply call+ret double
HP9000/370 (fpa -O) 0.22 0.26 0.22 1.35 3.96 0.62
HP9000/370 (-O) 0.21 0.26 0.22 1.35 3.08 1.21
HP9000/370 (fpa no -O) 0.26 0.40 0.36 1.44 4.42 1.56
HP9000/370 (no -O) 0.26 0.40 0.37 1.45 3.38 2.72
HP9000/835 (-O) 0.27 0.29 0.27 5.49 0.31 0.27
HP9000/835 (no -O) 0.29 0.53 0.45 5.62 0.31 0.59
Sun SS1 (-O) 0.29 0.33 0.30 19.5 0.49 0.59
Sun SS1 (no -O) 0.38 0.40 0.35 19.7 0.51 0.72
================================================================================
There is no question that Sun SparcStation 1 is *extremely* slow on integer
multiply even for a RISC architecture -- scaling the HP-PA results to the
same clock speed as the SPARC (20 MHz) we see that HP-PA is about 470% faster
than SPARC!! Our results also show that integer arithmetics on CISC (MC68030)
is much faster than on RISC (HP-PA, SPARC).
For those of you not familiar with the Plum-Hall benchmark here is some info:
----------------------------------------------------------------------------
[The following article appeared in "C Users Journal" May 1988.
It describes the purpose and use of the enclosed benchmarks. ]
SIMPLE BENCHMARKS FOR C COMPILERS
by Thomas Plum
Dr.Plum is the author of several books on C, including Efficient C (co-
authored with Jim Brodie). He is Vice-Chair of the ANSI X3J11 Committee,
and Chairman of Plum Hall Inc, which offers introductory and advanced sem-
inars on C.
Copyright (c) 1988, Plum Hall Inc
We are placing into the public domain some simple benchmarks with several
appealing properties:
They are short enough to type while browsing at trade shows.
They are protected against overly-aggressive compiler optimizations.
They reflect empirically-observed operator frequencies in C programs.
They give a C programmer information directly relevant to programming.
In Efficient C, Jim Brodie and I described how useful it can be for a pro-
grammer to have a general idea of how many microseconds it takes to execute
the "average operator" on register int's, on auto short's, on auto
long's, and on double data, as well as the time for an integer multiply,
and the time to call-and-return from a function. These six numbers allow a
programmer to make very good first-order estimates of the CPU time that a
particular algorithm will take.
More information about the Comp.lang.c
mailing list