Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.sys.m88k
Subject: Re: Information wanted on m88000 Risc workstations
Summary: Well, you may have me there...
Keywords: 80386 m88000 Everex Opus UNIX DOS
Message-ID: <665@s5.Morgan.COM>
Date: 11 Jan 90 03:29:42 GMT
References: <641@s5.Morgan.COM> <25A64468.11498@paris.ics.uci.edu> <25AAE835.16940@paris.ics.uci.edu>
Organization: Morgan Stanley & Co. NY, NY
Lines: 65

In article <25AAE835.16940@paris.ics.uci.edu>, rfg@ics.uci.edu (Ron Guilmette) writes:
> In article <648@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes:
> >
> >Yeah, well that DecStation 3100 kind of stomps these 88000 boxes for
> >double precision. And the application benchmarks in that issue show
> >just how nasty the threat is from the 486 (e.g. the Cheetah Gold is
> 
> I don't know where you are getting your numbers.  The 3100 didn't even
> make either of the "Best Performance" or "Best Price/Performance" lists
> in that article, so the numbers for the 3100 were not even shown.
> 
> What was shown however were the single and double precision Whetstone
> numbers for MIPS's own MIPS-based R2030 system (which I would think
> should be quite similar to the DEC product in terms of performance).
> These independently published numbers clearly show that the AViiON
> beats the hell out of MIPS-based systems on single precision Whetstones
> and looses by only about 10% on double precision.  I would hardly call
> that 10% "stomping".  You probably would never even notice the difference
> in practice.
> 

Right you are, and then wrong again. I was looking at the comparison
between the DecStation 3100 and the Opus 8120 and Everex 8825 on page
36, where the  somewhat more powerful Aviion is not present. I see a
consistent 30% victory in the Double precision Linpack and Livermore,
which is what I care about. It would appear that the Aviion is less
vulnerable than the Opus and Everex systems. On the other hand you're
wrong if you think I'd miss that 30% in practice. I have runs planned
for machines which take 50 hours of 3090 CPU and I have to find out
if they can go on workstations. Given that you lose a lot of the
vector and large scale cache advantage, plus the large scale use of hand
coded assembly (ESSL) on the 3090, I'm looking at thousands of hours of
CPU on a workstation class machine. Nearly all of it is double precision
floating point. Even if it's as little as 10%, I think a hundred hours
of CPU is noticable.
> Finally, note that the application benchmark numbers shown in that article
> were possibly somewhat misleading because they were probably done with
> DG/UX 4.10 which came with a horrible implementation of malloc() in libc.a.
> Most good sized C applications rely heavily on a good fast malloc() and can
> suffer dramatically if they are linked with a malloc which has poor
> performance.
> 
> The malloc implementation has been totally replaced in DG/UX 4.20.  It's
> light-years better now.
Well, I wasn't paying much attention to them, but I think the way
they come up with the overall ranking is weird - because the Aviion
beats the 'Best Performers' in all categories but two: Financial
and Dhrystone 2. I think they're putting too much weight on the 
Dhrystone, and this lands the Aviion in 4th place after the MIPS
RS2030. (Go Figure).

Also: you may have the impression that I am primarily concerned with
FORTRAN applications. This is sort of correct, in that you generally
use Linpack and Eispack instead of recoding them - even if your 
application is in C. Here, you end up with algorithms which are
seldom as fast as N log N; often you have N^3 time and N^2 space.
It would have to be the world's dumbest malloc before I would notice
it in scientific computing. Indeed, one of the standard 'jokes' is
to use an N^2 sort routine to order the eigenvalues/singular values
of a matrix, (which has just cost you a fairly large constant times
N^3), the idea being that you'll never be able to do an N big enough
to wear out the N^2 sort. (Being a real puritan, I use shellsort....)

Later,
Andrew Mullhaupt