Sun 3 vs uVAXII floating point speed....
Stephen R. Walton
acphssrw at csuna.UUCP
Sat Jul 16 03:22:16 AEST 1988
In article <4953 at husc6.harvard.edu> reiter at harvard.UUCP (Ehud Reiter) writes:
>The following data is from J. Dongarra, "Performance of Various Computers
>Using Standard Linear Equation Software in a Fortran Environment", COMPUTER
>ARCHITECTURE NEWS, vol16, no 1 (March 1988):
>
>[table omitted].
>IBM PC/AT with 80287 .012 (using PROFORT 1.0 compiler)
For what it's worth, I get 0.020 with Microsoft Fortran V5.1 on an 8 MHz AT.
>Readers can draw their own interpretations. Note that while I think
>Dongarra's LINPACK is one of the most honest benchmarks around (and far
>better than, say, Dhrystone), it, like all benchmarks, still needs to
>be taken with a very large grain of salt.
Which brings up something I've been meaning to throw out to the net.
The deleted lines from Ehud's posting show a Sun 3/160 to be about
half the speed of the VAX 11/780. This is true but incomplete. On the
Savage benchmark, the Sun comes up 5 times FASTER than Vax. What's
happening? Well, the Linpack benchmark does matrix manipulation and
therefore its real work is all * and /. The Savage benchmark consists
entirely of transcendental functions, which are microcoded on the
68881 chip on the Sun but done in software on the Vax. To put it
another way, SQRT on the Vax takes about the same time as 10
multiplications; this number is 3 on the Sun.
I think what this REALLY means is that previous rules of thumb of
the past about the tradeoff between transcendentals and
multiplications doesn't apply to the 68881, 80n87, and similar FPU's.
On these advanced chips, if you can get rid of 5 or 6 multiplications
in favor of one transcendal, it is worth doing. I think a lot of old
code could run faster if this was taken into account.
PS. Ehud, did you mean "Whetstone" instead of "Dhrystone" above?
The latter does only integer and address arithmetic and is in C, not
Fortran. The former is a weighted mix of various operations which is
supposedly "typical" of scientific code.
Stephen Walton, representing myself swalton at solar.stanford.edu
Cal State, Northridge rckg01m at calstate.BITNET
More information about the Comp.unix.questions
mailing list