I am really, truly, honestly NOT trying to start a religious war here...
But here we are with two major low-cost Common Lisp implementations;
surely someone has done an analysis of their relative strengths and
weaknesses? We use AKCL here, but only because we heard of it before
we had heard of CMU-CL. We are not Serious Lisp users, but may get more
serious soon, and we'd like to start off on the right foot. Are there
major differences between them? In particular, is one or the other
notably faster, more reliable, possessed of a better foreign function
interface, possessed of better ancillary goodies, or otherwise superior?
Your informed opinions solicited...
regards,
--Tom Olson
Tom Olson (·····@virginia.edu) | What's the spring breathing jasmine and rose,
Dept. of Computer Science | What's summer with all its gay train,
University of Virginia | What's the splendor of autumn to those
Charlottesville, VA 22903 | Who barter their freedom for gain?
--
Tom Olson (·····@virginia.edu) | What's the spring breathing jasmine and rose,
Dept. of Computer Science | What's summer with all its gay train,
University of Virginia | What's the splendor of autumn to those
Charlottesville, VA 22903 | Who barter their freedom for gain?
From: Peter Dudey, Order of the Golden Parentheses
Subject: Re: AKCL vs CMU-CL
Date:
Message-ID: <C795rC.8q8@willamette.edu>
In article <··········@murdoch.acc.Virginia.EDU> ·····@uvacs.cs.Virginia.EDU (Thomas J. Olson) writes:
>But here we are with two major low-cost Common Lisp implementations;
>surely someone has done an analysis of their relative strengths and
>weaknesses? We use AKCL here, but only because we heard of it before
>we had heard of CMU-CL. We are not Serious Lisp users, but may get more
>serious soon, and we'd like to start off on the right foot. Are there
>major differences between them? In particular, is one or the other
>notably faster, more reliable, possessed of a better foreign function
>interface, possessed of better ancillary goodies, or otherwise superior?
>Your informed opinions solicited...
One point for AKCL: it has the Common Lisp "step" single-step debugging
feature, and CMUCL does not. If you're using a Sun or a PC, though, CLISP
tops 'em both. The PC version even has graphics!
--
[ Peter Dudey, 11 kyu, Lisp SubGuru and Genetic Programmer Extraordinaire ]
[ "Research continues, at a more furious pace than ever. But it is done in ]
[ secret, and in haste, and for profit." -Michael Crichton, _Jurassic Park_ ]
[ Please mail me plastic spaceships: 257 NE 13th Street, Salem, OR 97301 ]
In article <··········@murdoch.acc.Virginia.EDU>, you write:
|> I am really, truly, honestly NOT trying to start a religious war here...
|>
|> But here we are with two major low-cost Common Lisp implementations;
|> surely someone has done an analysis of their relative strengths and
|> weaknesses? We use AKCL here, but only because we heard of it before
|> we had heard of CMU-CL. We are not Serious Lisp users, but may get more
|> serious soon, and we'd like to start off on the right foot. Are there
|> major differences between them? In particular, is one or the other
|> notably faster, more reliable, possessed of a better foreign function
|> interface, possessed of better ancillary goodies, or otherwise superior?
|> Your informed opinions solicited...
I had been using AKCL for a few years but switched to CMU CL when it
came out for the Sparc/SunOS. There are many reasons, among them,
generally better optimization, better compile-time error detection,
better "environment", better runtime type checking, CLTL/2 support,
etc.
AKCL is still nice because it's smaller, it runs under DOS, and you can
understand the generated C code. For CLTL/1, AKCL may also be a little
more mature, but the difference doesn't seem to be enough to be
important for software development.
A significant problem with CMU CL's foreign function loader is that it
doesn't allow you to reload ".o" files (or, at least, it doesn't seem
to work for me) and seems to rely on some script involving "ld" to load
foreign functions. AKCL's foreign function loader does dynamic linking
in-memory and knows how to re-load files, resolve references, etc.
Furthermore, you can run GDB on an AKCL image with foreign functions
loaded and debug the foreign functions (that may or may not be possible
in CMU CL; I haven't tried yet). On the other hand, CMU CL has a
slightly more convenient Lisp-based mechanism for declaring foreign
functions.
I wouldn't throw out AKCL, but for day-to-day work, CMU CL is probably
the better choice.
Thomas.
In article <··········@murdoch.acc.Virginia.EDU>, you write:
|> But here we are with two major low-cost Common Lisp implementations;
|> surely someone has done an analysis of their relative strengths and
|> weaknesses?
One more thing: adding new low-level optimizations to the AKCL
optimizer is very easy (you specify the Lisp form to be optimized and
conditions under which it may be optimized together with the equivalent
C code). This means you are "less stuck" with AKCL if the optimizer
simply doesn't know about some function that you really need optimized.
On the other hand, CMU CL has better type inference and high-level
optimizations.
As a concrete example, floating point TRUNCATE seems to cons in CMU CL,
and I don't know how to fix it myself. At some point, AKCL didn't know
about optimizing some floating point trig functions, and I could patch
that easily. On the other hand, in order to cajole the AKCL optimizer
to do its thing, you have to sprinkle your Lisp code more than
liberally with "the single-float" and the like, and for some
declarations, being too specific actually hurts you.
Again, I still prefer CMU CL for most of my work, but AKCL is not
without its merits either.
Maybe CMU CL could add something equivalent to the GNU C/C++ "asm"
statement? What about it?
Thomas.
In article <············@life.ai.mit.edu>, ···@arolla.idiap.ch (Thomas M. Breuel) writes:
|> AKCL is still nice because it's smaller, it runs under DOS, and you can
|> understand the generated C code.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What?!
--
..................................................
Len Charest, Jr.
JPL Artificial Intelligence Group
·······@aig.jpl.nasa.gov