X-PH: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
From: Chris Baker <[EMAIL PROTECTED]>
Date: 08 Jun 2003 10:06:42 -0700
X-listar-version: Listar v1.0.0
Sender: [EMAIL PROTECTED]
X-original-sender: [EMAIL PROTECTED]
X-list: cmucl-help
X-YaleITSMailFilter: Version 1.0c (attachment(s) not renamed)
Clemens Fischer <[EMAIL PROTECTED]> writes:
> Alexey Dejneka <[EMAIL PROTECTED]>:
>
> > The value of S^2 is boxed before putting into the closure.
>
> what does "... is boxed" mean? the same as "binding" or more like
> "storing"?
It just means it has type information associated with it. Normally,
an arithmetic operation gets boxed arguments. It checks the types,
unboxes the arguments, does the operation, and then boxes up the
result. This is a huge amount of overhead, so if you're doing a bunch
of these in a row, you want the compiler to leave the intermediate
values unboxed.
This answer doesn't make it clear that boxing means allocating some
bytes somewhere for the actual number, then creating a pointer to it.
Unboxing means following the pointer to get the number. This is
indeed a huge amount of overhead, especially for the garbage
collection required to reclaim all those "boxes." To optimize a
numerical calculation it's necessary to persuade Lisp to avoid boxing
wherever possible, and just represent numbers as four- (or eight-)
byte quantities manipulated directly in registers, stored in
arrays, etc.
The reason for boxing is to maintain the constraint that all Lisp
objects are represented as pointers to something (and hence all
require the same number of bytes to represent). There are a couple of
exceptions, notably small integers (called "fixnums"), which are
usually represented as bit strings that are illegal pointers.
It is surprisingly difficult to avoid all boxing. Two cases to watch
out for:
1. A list of numbers must always be represented as a list of boxed
numbers, because cons cells can contain only pointers.
2. A function that returns a number must always return it boxed,
because there is no way to know who is going to call that function.
The second problem is really annoying. Some compilers (including
cmucl, I believe) can solve it by doing some sort of "block
compilation," in which a group of functions is compiled together, with
declarations of exactly which in the group might be called outside the
group. If F1 calls F2, and no one else does, then F2 can return an
unboxed number, and F1 will expect to get a number, not a pointer,
when F2 returns.
If you don't want to do block compilation, the alternative is to
change the calling sequence so that F1 passes an array of numbers to
F2, and F2 stores its result in it. That is, you can emulate C in
Lisp, which is pretty disgusting. On the other hand, there's probably
a clever way to use macros to cover up the ugliness.
--
-- Drew McDermott
