ths@eyelab.UUCP (Tom Speeter) (01/24/86)
One of the assumptions I made before purchasing the Mac
was that the 68000 could whiz through numerical calculations
and impress my friends with its speed. Even pardoning
the disk drives' lethargy, I'm a little disappointed by
its CPU intensive operations as well. I've downloaded some 'C'
programs from a PDP 11/44 and observed the differences in
processing speed. What a difference!!
The programs are primarily matrix manipulations using
double precision arrays. The PDP runs a representitive
program in 75 seconds, the Mac takes 4000 seconds (thats over
an hour!!). I used Aztec C's 1.00D compiler, purportedly one
of the faster version of 'C' for the Mac (I'd hate to use a
slower one). At least the code was portable, didn't have to
change a line!
Now I realize that the 11/44 has floating point hardware
and is in an entirely different class, but a 50 fold decrease in
speed is a little hard to believe. With the recent revelation
of the Mac+ and its orientation toward increased size and not
speed I think Apple may be forgetting those of us who want to
crunch, not expand.
Any comments about this, or suggestions for speeding
things up? I see an occasional posting about the faster 68???
chip and boards from outside vendors, but whats Apple doing
for people (I know you're out there) who want floating point
speed, and not room for the entire collection of 1985 tax forms?
Tom Speeter
(cwruecmp!eyelab!ths)breuel@h-sc1.UUCP (thomas breuel) (01/29/86)
| One of the assumptions I made before purchasing the Mac |was that the 68000 could whiz through numerical calculations |and impress my friends with its speed. Even pardoning [...] | The programs are primarily matrix manipulations using |double precision arrays. The PDP runs a representitive |program in 75 seconds, the Mac takes 4000 seconds (thats over |an hour!!). I used Aztec C's 1.00D compiler, purportedly one |of the faster version of 'C' for the Mac (I'd hate to use a |slower one). At least the code was portable, didn't have to |change a line! | Now I realize that the 11/44 has floating point hardware |and is in an entirely different class, but a 50 fold decrease in |speed is a little hard to believe. With the recent revelation First of all, for certain applications, a PDP-11/44 seems to be comparable to a VAX 11/750. The problem with the PDP series is not speed (it seems), but rather the limited address space. I do not see why you are not willing to accept that FP hardware can give you a 50 fold performance increase over software floating point. The easiest way to answer your question about relative performance might be to use software floating point on your PDP as well, or to compare the two machines in integer math. They'll probably perform about equally well. Also note that Aztec 'C' *might* be using 80 bit FP ('SANE') everywhere (as compared to 32bit floats and 64bit doubles on the PDP). I don't know; that is something you should check before comparing the two. Finally, your compiler for the PDP might be vastly superior to the Aztec compiler. The Aztec compiler is a decent product from what I hear, but the UN*X PDP-11 'cc' (and probably the DEC 'C' compiler, judging from the quality of they VAX-11 'C' compiler) is quite good at optimisation. Now, since your primary concern is obviously to get your calculations done and not to make the Mac look bad, there are several possible solutions: (1) use integer math (yes, I know that it takes more thought and work, but it runs soooo much faster), (2) get an FP co-processor for the Mac, (3) get a different machine. Personally, I try to do any numerical calculations that I have to do (even DEQ's &c.) with integer math. I care much more about lots of memory than about FP speed... Thomas.
gus@Shasta.ARPA (01/30/86)
> Now I realize that the 11/44 has floating point hardware > and is in an entirely different class, but a 50 fold decrease in > speed is a little hard to believe. With the recent revelation > of the Mac+ and its orientation toward increased size and not > speed I think Apple may be forgetting those of us who want to > crunch, not expand. This is not at all unreasonable considering the double overhead of software floating point and a trap interface vs direct fp hardware calls inline. I hear that Levco's Monster Mac has a 68881 buit-in and that Consulair is writing a compiler that will directly support it. Do your benchmarks on that puppy! Actually, a much better comparison might be to use a 16 or 32 bit integer problem. In this case, the Mac should do a lot better. Also, you might want to compare the accuracy you got with the PDP11 vs that of the Mac. Nobody claimed that SANE or any other software floating point was fast, but Apple does boast its accuracy.
sjl@amdahl.UUCP (Steve Langdon) (02/01/86)
In article <106@eyelab.UUCP> ths@eyelab.UUCP (Tom Speeter) writes: > > One of the assumptions I made before purchasing the Mac > was that the 68000 could whiz through numerical calculations > and impress my friends with its speed. Then he quotes figures showing that the Mac ran some floating point programs 50 times slower than a PDP 11/44. One answer is Mac C from Consulair customized for the Quesse Maccelerator. The Maccelerator is an add on board based on a National 32081 Floating point chip running at 10 Mhz. It uses the clip style connector so no surgery to the Mac is required (an installation kit is included with the board). The customized version of Mac C generates all the necessary code to interface with the Maccelerator (replacing the normal calls to SANE). The Mac C/Maccelerator package is $995. The board plus a function library and some assembler macros can be purchased without the compiler for $665. A couple of performance comparisons are: 70K Whetsones (5K for SANE) 1024 point DP complex FFT 5.6 seconds (88 seconds using SANE) Consulair can be reached at (415)851-3272 Quesse Computer Company reached at (206)392-7701 I have no connection with either company other than being a satisfied customer of Consulair (who also have versions of Mac C that use the floating point on the Hyperdrive 2000 and the Levco 68020/68881 boards). -- Stephen J. Langdon ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl [ The article above is not an official statement from any organization in the known universe. ]