Benefits of moving from Python to Common Lisp?
Pierre R. Mai
pmai at acm.org
Fri Nov 16 16:28:23 CET 2001
Raymond Toy <toy at rtp.ericsson.se> writes:
> >>>>> "Daniel" == Daniel Lakeland <dlakelan at sil-no.spam-con.com> writes:
> >> CMUCL uses different GC's on different platforms? Or do you mean you
> >> were using CMUCL on one box and a different CL on the other?
> Daniel> Yes CMUCL uses (or used in Feb 2000) different GC's on different
> Daniel> platforms.
> That is still true today and for the foreseeable future as well.
To give slightly more details for the reasons:
CMU CL (nee Spice Lisp) was originally developed on (RISC)
workstations. In order to allow the direct operation on
unboxed/untagged data, it partitions the register set of the
underlying processor into tagged and untagged register subsets (and
corresponding stacks), so that garbage collection can occur at
(nearly) any point in time, without having to worry about untagged
values being mistaken for lisp pointers, etc.
When CMU CL was ported to x86 in the 90s, keeping up this partitioning
scheme would have resulted in very bad performance, given the relative
scarcity of general purpose registers on x86 machines, and the
resulting register pressure. For that reason CMU CL on x86 needed a
conservative GC, that could deal with unboxed/untagged values in
normal registers and the stack. That is where the divergence started.
Since most development on certain areas of CMU CL happened on x86
during the 90s, CMU CL on x86 currently has a number of features that
haven't been (fully) ported to the other platforms, like e.g.
multi-processing and the generational aspects of the conservative GC
F'up to comp.lang.lisp set, since I don't think that further
discussion is that interesting to those that use Python the language
(and not Python the CMU CL compiler). Feel free to ignore it, if I'm
Pierre R. Mai <pmai at acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
More information about the Python-list