UH2@PSUVM.BITNET (Lee Sailer) (06/06/89)
Has anyone benchmarked the floating point speed on the NeXT. It comes with a 68881 or 68882, doesn't it, so unless it is crippled in some way it shouldn't be too bad. I ask because an aquaintence says that the NeXT is not known for its floating point speed, which implies that it is slower than it should be, assuming that we know it isn't a Cray.
fellman@celece.ucsd.edu (Ronald Fellman) (06/12/89)
In article <89157.122728UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >Has anyone benchmarked the floating point speed on the NeXT. It >comes with a 68881 or 68882, doesn't it, so unless it is crippled >in some way it shouldn't be too bad. > >I ask because an aquaintence says that the NeXT is not known for >its floating point speed, which implies that it is slower than it >should be, assuming that we know it isn't a Cray. I have compared a MacII, a NeXT, a Sun 4/280, and a DecStation3100 running the CD3040 opamp in Berkeley spice3b1. (I don't have the graphics part running on the NeXT but that didn't matter for this benchmark.) Here's the results: MacII: 59 sec., NeXT: 21 sec., Sun 4/280: 8.7 sec., DecStation 3100:4.0sec. Although I haven't tried it against a Sun 3/60, I'd guess that the NeXT would be about 25% faster. -ron fellman (rfellman@ucsd.edu)
edwardm@hpcuhc.HP.COM (Edward McClanahan) (06/13/89)
> I have compared a MacII, a NeXT, a Sun 4/280, and a DecStation3100 > running the CD3040 opamp in Berkeley spice3b1. (I don't have the > graphics part running on the NeXT but that didn't matter for this > benchmark.) > Here's the results: > MacII: 59 sec., NeXT: 21 sec., Sun 4/280: 8.7 sec., DecStation 3100:4.0sec. Did this application take advantage of the Motorola 56001 DSP chip in the NeXT? Is it reasonable for users to expect applications developed for multiple machines (MacII,NeXT,Sun4,DecStation3100,Sun3,etc...) to take advantage of such "product differentiators" as this? And, if we are only comparing the CPU(and memory systems, e.g. cache, main, secondary), why was the NeXT (at 25MHz) so much faster than the MacII (at 15.67MHz)? Ed "enquiring minds want to know" McClanahan
mcdonald@uxe.cso.uiuc.edu (06/14/89)
> >I ask because an aquaintence says that the NeXT is not known for >its floating point speed, which implies that it is slower than it >should be, assuming that we know it isn't a Cray. I compared a Next and a Mac II with my Dell 310 (with 387) on a large variety of floating point code. The Dell was about 30% to 60% faster than the NeXt which was much faster than the MacII. If you want floating speed buy, in descending order of speed: Cray Y-MP Cray X-MP top Amdahl mainframe Mips 3000 or Sun4 Top of the line 386 PC with a real 32 bit compiler(*) and Weitek 1167/3167 The following two are tied: Top of the line 386 PC with a real 32 bit compiler(*) and 387 Top 68030 workstation from HP. Presumably Sun and other 68030 folks will tie this very soon. NeXt Mac II Whatever you do, don't buy a Vax. *MicroWay C or Fortran for DOS / Gnu cc or better for Unix Doug McDonald
jmunkki@kampi.hut.fi (Juri Munkki) (06/14/89)
In article <680008@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: >> MacII: 59 sec., NeXT: 21 sec., Sun 4/280: 8.7 sec., DecStation 3100:4.0sec. > >why was the NeXT (at 25MHz) so much faster than the MacII (at 15.67MHz)? Reason #1: The Mac II has two wait states. Reason #2: The Mac II has a 68020, the NeXT has a 68030. Reason #3: The Mac II has a 68881, the NeXT has a 68882. I assume this was a floating point benchmark. Reason #4: Most benchmarks are run directly after they have been ported. This means that the machine has all sorts of low level debuggers installed. As strange as it may seem, at least some versions of the MacsBug debugger reduce FPU performance by 50%. TMON does something similar, but not quite (try running Moire and see the difference) Most people do not seem to be aware of #4, but even the first three reasons should be enough to explain the difference under certain conditions. If you reply and your followup has nothing to do with NeXT, please followup to comp.sys.mac.programmer... _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
fellman@celece.ucsd.edu (Ronald Fellman) (06/14/89)
In article <680008@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: >> I have compared a MacII, a NeXT, a Sun 4/280, and a DecStation3100 >> running the CD3040 opamp in Berkeley spice3b1. (I don't have the >> graphics part running on the NeXT but that didn't matter for this >> benchmark.) > >> Here's the results: >> MacII: 59 sec., NeXT: 21 sec., Sun 4/280: 8.7 sec., DecStation 3100:4.0sec. > >Did this application take advantage of the Motorola 56001 DSP chip >in the NeXT? Is it reasonable for users to expect applications developed >for multiple machines (MacII,NeXT,Sun4,DecStation3100,Sun3,etc...) to >take advantage of such "product differentiators" as this? And, if we >are only comparing the CPU(and memory systems, e.g. cache, main, secondary), >why was the NeXT (at 25MHz) so much faster than the MacII (at 15.67MHz)? > >Ed "enquiring minds want to know" McClanahan That didn't use the DSP chip in the NeXT. In fact, a 56001 uses 24 bit fixed-point multiplication, NOT double-precision floating point. As for the speed difference between the NeXT and the MacII: the NeXT uses a 68030/68882 combination. The Mac II I had used a 68020/68882 combination. The 68030 has a data cache on-chip which must have made most of the difference. Spice probably had a high hit rate in some of its inner loops. As for the 68882 on my MacII, I just stuck it there without telling Lightspeed C 3.0 about it (in fact it doesn't know how to optimize code for a 68882.) Simply plugging a 68882 into a MacII just helps by about 10%. Apparently, if your compilers know how to reorder instructions properly, one could get more leverage out of the '882s pipelining. I don't know if the NeXT C compiler does this or not. -ron fellman (rfellman@ucsd.edu)