Larry Hunter wrote in message ...
>Judging by a quick look at the code (not to mention the huge amount of
>boxing indicated above), there is a lot of optimizing that could be done.
I
>don't have time to do it, but if someone else takes a crack, I'll test the
>resulting code on the ACL/SGI implementation.
Yup, boxing floats is the main thing that seems to slow down LISP FP
computation (and from looking at this code, I'd imagine that it would cons a
bit, being written for clarity rather than speed). I was wondering if
anyone had done an implementation that used tag bits in the lower end of the
word to differentiate between primitive types (e.g., smallInt / pointer /
singleFloat / constant) and just burned the last few bits of IEEE
compatibility. It seems that you could get single float performance to
within a small amount of "C"-speed with only a small penalty in accuracy. I
know that most compilers can do a good job of not boxing floats once they
get into the stack frame, but whenever they're returned or stored to memory,
most implementations seem to have to box them. So has anyone tried this
approach?
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
From: Bulent Murtezaoglu
Subject: Re: Floating Point speed in Common Lisp
Date:
Message-ID: <87en097zfs.fsf@isttest.bogus>
>>>>> "FAA" == Frank A Adrian <············@firstdatabank.com> writes:
FAA> ... I know that
FAA> most compilers can do a good job of not boxing floats once
FAA> they get into the stack frame, but whenever they're returned
FAA> or stored to memory, most implementations seem to have to box
FAA> them. So has anyone tried this approach?
It appears that CMUCL block-compile extension should be able to do this
without undue decleration noise. It enables you to declare a bunch of
functions in " a block" as being only called from others in the same block
with the exception of ones you declare as entry points (ie called from
elsewhere). Excellent idea, as then just like as in inlining, all kinds
of optimizations become feasible without the programmer having to spell
everything out in declares. That should as far as I can see take care of
the above. Of course I was unable to test it since I couldn't yet coerce
the experimental version of CMUCL I have to do block compiles, but I think
the idea is an elegant and feasible one. The inconvenience of not being
able to redefine functions and such is a small trade off for finished code.
BM