Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!seibel
From: seibel@cgl.ucsf.edu (George Seibel)
Newsgroups: comp.sys.next
Subject: Re: Number Crunching on the Cube?
Keywords: number crunch
Message-ID: <11725@cgl.ucsf.EDU>
Date: 28 Jul 89 07:38:24 GMT
References: <4696@tank.uchicago.edu>
Sender: daemon@cgl.ucsf.edu
Reply-To: seibel@cgl.ucsf.edu (George Seibel)
Distribution: usa
Organization: Dept. of Pharmaceutical Chemistry, UCSF
Lines: 40

In article <4696@tank.uchicago.edu> barry@zaphod.uchicago.edu (Barry Merriman) writes:


>How good is the Cube at pure number crunching? Does anyone
>have some benchmarks comparing it to, say, some flavor of Sun?

  I've run a floating pt intensive benchmark on a number of systems.
This is a real application, not a synthetic benchmark.  It's an energy
minimization of a DNA pentamer/drug complex.  Data arrays occupied about
600 kbytes.  There were not a significant number of sqrts or trig functions
in this benchmark, just a lot of floating pt math.  All compilations were
done using optimization.  The NeXT benchmark was run using a Sun 3 binary,
compiled f77 -O -f68881.  (This really worked, but might not in the future)
The benchmark was run in both double and single precision on various machines.

  Machine             Double prec.       Single prec.
-----------------------------------------------------
Cray XMP4/8               11 sec    (cray native word=64bits)
Convex C1                103                70 sec.
DecStation 3100          203
IRIS 4D/70               243               166
NeXT                                      1885
Sun 3/280 68881                           2945
Sun 3/160 fpa           4486              3681

  There's no reason that I could not have run double precision on the
NeXT, I would expect about a 30% slowdown in this particular application.
The cube can certainly be used for real number crunching; I find its
floating point behavior to be excellent.   Crunching is not the cube's
strong point, however, in comparison to the hot RISC boxes.  Although,
to put it in perspective, it's on par with a Vax 11/780.   This code
is highly vectorized, and the vector lengths in the problem are long
enough to make a fair comparison to the Convex and Cray.   I'm still
hoping that a vector library will appear that uses the DSP chip, although
I am not sure how fast this might be.  Absoft has a fortran compiler for
the cube, with Object-Oriented extensions.  I've used their compiler
on the Mac and liked it, and understand that their NeXT compiler is much
better.
 
George Seibel, UCSF