Path: utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!ogicse!decwrl!shelby!neon!Kermit.Stanford.EDU!philip
From: philip@Kermit.Stanford.EDU (Philip Machanick)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Reforming Mac Programming (longish, ~60 lines)
Message-ID: <1990Mar26.180116.8814@Neon.Stanford.EDU>
Date: 26 Mar 90 18:01:16 GMT
References: <2346@husc6.harvard.edu> <13828@eagle.wesleyan.edu>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 39

In article <2346@husc6.harvard.edu>, siegel@endor.harvard.edu (Rich
Siegel) writes:
> In article <13828@eagle.wesleyan.edu> bparsia@eagle.wesleyan.edu writes:
> 
> >For example, numeric coprocessors. THINK Pascal (along with most
other packages
> >I hope) has a 68881 compile option which generates optimized code for the
> >coprocessor if you check it off. Now, why doesn't Apple just set up a
standard
> >numeric enviroment (i.e. SANE), included in the system or the ROM,
written in
> >blazingly fast and clever assembly language, and tailored to each
machine. Thus
> >the SANE in the SE ROM would just use the 68K to do the work, while
the SANE in
> >the II series would be optimized for the coprocessor. The upshot is:
both have
> 
> 	In fact, that's exactly the way it's done. SANE on the Mac II is
> faster than SANE on a Portable (for example). However, SANE is tailored to
> conform to the IEEE P784 spec for accuracy, and not so much for performance;
> you do pay a little overhead for the trap dispatch, for the fact that
> SANE only takes arguments by address on the stack, and for that extra
> accuracy. Direct '881 calls are much faster than going through SANE, but
> are occasionally less accurate.
> 
I benchmarked the cost of going through SANE on a Mac II a while back, using
a program to draw a nice Mandelbrot set picture on a 19" screen. The direct
calls were about 18 times faster than going through SANE (using Think
Pascal 2).
Is this the cost of trap dispatching? It might be interesting to do the
benchmark again, doing direct calls to ROM - should not be worse than 4-5 times
slower than going direct to the 68881. Of course, the vast majority of Mac
aps are not this FP-intensive, but the point is that the cost of the standard
mechanism is too high for some applications - hence the appearance of
model-specific software (e.g., Mathematica).

Philip Machanick
philip@pescadero.stanford.edu