[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CMUCL Native CLOS
Rob, comments on comments on comments...
Hmmn. I'll ponder this. My first reaction is that it might be better to
have the class be a generally-reasonably-small integer class ID, with an
indirection through a class table to find the object. This would
potentially allow the class ID to be compiled as an immediate constant, and
would work somewhat better for caching schemes, since class IDs would be
more dense than class pointers.
The problem with having class ID's is that the dispatching code must
test to see whether the object is a builtin or a regular CLOS object.
If the object is a builtin then use the class ID else use the class
pointer. If the representation is uniform (with all objects having
class pointers), then no such test is necessary. This seems crucial
to me for efficient CLOS, because the class is accessed so often.
Now if you're suggesting having all classes have class ID's, then this
is another thing entirely. It appears that this is inefficient as
well, because you always need that extra indirection.
Also, when true 64bit machines come, you will want to put the whole
descriptor on one word, but probably won't want to be confined to a measly
32bit heap. If the class ID is more densely encoded, then you can grab a
high chunk of say 20 bits to hold it.
Personally, I'm not so concerned with a measely 32bit heap. I would
rather penalize people for using >32bit addresses than penalize
everyone for all accesses to objects. Furthermore, I'm confident that
accessing the upper 32bits of a 64bit word will be much faster than
accessing the upper 20bits.
A key question here is which (declare (fixnum i)) would be equivalent to.
It would presumably be the former, which would make existing programs
reasonably efficient, but would also make them non-generic.
Actually, I think that (declare (type fixnum i)) should be equivalent
to (declare (subclass fixnum i)) because this is consistent with
CommonLisp typing. But going along the lines of what you are
suggesting about not having fixnum subclassable would guarantee that
this would be implemented efficiently. I'm not exactly sure what your
worries were about non-generic arithmetic.
Defining hash-tables as classes makes a great deal of sense, since even as
a CL primitive, the functions are "generic" due to different kinds of
hash-tables. As for lists, the Lisp implementation is over-constrained.
You don't really have lists, you have conses. If you wanted a general list
class, you would be better off making a totally new one, and making the
generic sequence functions work on it. If vector operations were generic,
that would be easy.
I agree with you here.
I am incredibly excited about your ideas on the SELF optimization
techniques. This sounds like an amazing idea. I'm going to read the
SELF papers more carefully.
I have a few questions for you.
Are their any immediate plans for implementing the
dynamic-extent declaration for declaring &rest args on the stack as
well as other local variables?
Are there any immediate plans to implement a multiprocessing facility
that would allow multiple threads within one lisp process?
Finally, are there any immediate plans to port CMUCL to the new $5000
34-SPEC-Mark HP snake machine?