This is Number-Crunching-on-the-Cube? in view mode; [Up]
Date: Sun 27-Jul-1989 23:31:40 From: Unknown Subject: Number Crunching on the Cube? _ _ How good is the Cube at pure number crunching? Does anyone have some benchmarks comparing it to, say, some flavor of Sun? Please post them if you do. If you have a Cube handy, try this trivial benchmark: Write a program that multiplies 1.000001 (double precision) against itself 10^6 times, and time it with the unix "time" command. Try it with and without the floating point chip. For comparison, here are the elapsed cpu times for some of our local Suns, and the inferred MFLOPage: [Notes: 68881 denotes the Motorola MC68881 floating point coprocessor; all runs were compiled with the -O optimization option on the f77 compiler, which makes about a factor of 4 improvement when using the MC68881.] ------------------------------------------------------------------ Machine (options) cpu time/sec MFLOPs Comments ------------------ ------------ ------ -------- Sun 3/50 101.4 0.01 Sun 3/50 (68881) 4.3 0.23 20x speedup Sun 3/60 66.1 0.015 Sun 3/60 (68881) 3.7 0.27 18x speedup Sun 3 Server 47.8 0.02 Sun 3 Server (68881) 3.5 0.29 14x speedup and, just for fun, our local throwback to the centralized computing era ELXSI 6400 2.1 0.48 cost > $200K NeXT Cube ??? ???? ??????????? ------------------------------------------------------------ Any info on Cube processing speeds (and the speed of the optical drive---measured in units of user pain) is appreciated. -thanks Barry Merriman University of Chicago, Dept of math >From: barry@zaphod.uchicago.edu (Barry Merriman)
Date: Sun 28-Jul-1989 07:38:24 From: Unknown Subject: Re: Number Crunching on the Cube? 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 >From: glc@frame.UUCP (Greg Cockroft)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.