David LaFrance-Linden <········@hpc.pko.dec.com> writes:
>
> David LaFrance-Linden wrote:
> >
> > Raymond Toy wrote:
> > > Were doubles really catastrophically slower on Symbolics? Or is it
> > > more an issue that the compiler was not smart enough to unbox it? I
> > > might be way off base here because I know nothing about Symbolics
> > > architecture.
> >
> > Both.
> > [...]
>
> I wasn't being completely fair. What do you mean by "catastrophically
> slower"? Stock hardware, in the absense of declarations, for something
I don't know. That's what someone said earlier.
> like (+ a b), has to do a two-way type dispatch, and for double
> arguments it would likely have to unbox, %double_internal, and box, just
> like LispMs. Stock hardware would have to do this all the time in
> macrocode, whereas LispMs would do it in microcode with hardware assist.
Not quite true, if stock hardware means x86, sparcs, etc.. CMUCL has
a compiler that is smart enough not to box and unbox single and double
floats.
Ray
===========================================================================
-----> Raymond Toy ···@rtp.ericsson.se
"I have no problem with their success.... I have a problem with the
fact that they just make really third-rate products. "
Steve Jobs
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> wrote:
>Not quite true, if stock hardware means x86, sparcs, etc.. CMUCL has
>a compiler that is smart enough not to box and unbox single and double
>floats.
CMUCL has one of the better type-inference modules among CL compilers. The
Symbolics compiler, on the other hand, does practically *no* type analysis,
relying heavily on the hardware to do fast type dispatching.
One thing, though: many of the built-in high-level math functions
(e.g. LOG, SQRT, etc.) were hand-coded to use unboxed double floats.
--
Barry Margolin
BBN Corporation, Cambridge, MA
······@bbnplanet.com - Phone (617) 873-3126 - Fax (617) 873-5508
(BBN customers, call (800) 632-7638 option 1, not my direct #, for support)