Clementson's Blog

CL Implementations

Friday, December 3, 2004

On c.l.l. Rainer Joswig posted a good summary of the different CL implementations that are available, grouping them under different categories. I've taken his summary, added links and made some edits/additions:

1. Lisps that have extensive development environments, large libraries, lots of extensions to ANSI CL. These tend to provide rich options for delivery. Compilation is native. Fully configured, the Lisps can become large (compared to other lisps and these lisps with the more basic options installed). Lots of bells and whistles. Can generate code with good performance. Commercial.
   
   Allegro CL, LispWorks
   
   
2. Lisps that don't have that good performance, but small footprint. They either use byte-codes or compile to (often not that efficient) compact code.
   
   OpenMCL, MCL, CLISP, Corman CL, ABCL
   
   
3. Special purpose Lisps for embedding and/or delivery. Means you can develop with them, but it might be useful to have another Lisp for development.
   
   CLICC (dead), WCL (dead), ECL, ThinLisp, CLISP, Allegro CL
   
   
4. Native compiling Lisps with often excellent performance
   
   Allegro CL, LispWorks, CMUCL, SBCL
   
   
5. Lisps for the Windows platform with special support
   
   Corman CL, Golden Common Lisp, Allegro CL for Windows, LispWorks for Windows
   
   
6. Lisps for the Mac OS X platform with special support
   
   MCL, OpenMCL, LispWorks for Macintosh
   
   
7. Cross-platform Lisps
   
   CLISP, GCL, CMUCL, SBCL, Allegro CL, LispWorks, ECL
   
   
8. Lisps for multiprocessor machines
   
   Scieneer Common Lisp, OpenMCL, Corman CL (?)
   
   
9. 64bit Lisps
   
   Scieneer Common Lisp, Allegro CL, CLISP (soon), SBCL (soon), ECL
   
   
10. Lisps on top of a Lisp operating system
    
    Xerox Common Lisp, Symbolics Common Lisp, TI Common Lisp, Movitz

• ECL can be embedded as shared library in any C/C++ program, so it fits on 3.
• ECL is compiled natively under Windows using either MingW32 or Microsoft Visual C++, so it would fit on 5.
• ECL is cross-platform (point 7), since it works under Solaris, Digital Unix, FreeBSD, NetBSD, Linux, Windows and Mac OSX 10.2, at least, and can be ported to any operating system with minimal support for POSIX, and also to any processor (see below).
• ECL is 64bit lisp (point 9). Actually ECL is independent of the size of the words in any system: it detects the size automatically during configuration time and updates the code to support it. ECL is actively supported under SPARC and Alpha, and has been succesfully cross-compiled to ARM.

• First, the easy one:
  
  Allegro CL can be embedded as a shared-library, so it belongs in item 3.
  
  
• Second, I have trouble with the apparent dichotomy of #1 and #2. These two items seem to lump the lisps into categories that are have a rich ide but are (implied as) mostly large with large code generation, or else a small lisp footprint with slow generated code. I believe that this is much too broad a brush to paint these lisps, and it is unfair to the versatility of Allegro CL to its environment.
  
  For example, on freebsd a "ps ux" command at the start of a running of several lisps ready-to-run - Allegro CL (alisp-7.0), cmucl, sbcl, clisp - places Allegro CL closer to the small end of the scale; the "RSS" (resident set size) is comparable to cmucl, and twice as small as sbcl. Clisp of course wins in the Virtual Size area, consuming about 1/5 the swap of Allego CL. But Allegro CL consumes less than 1/50 of the swap of cmucl, and 1/60 of the swap of sbcl. So even out of the box comparisons don't bear the footprint statements of point #1 out, compared to all of the other Common Lisps.
  
  As for the completeness of the development environments, I guess I would say that our philosophy on memory footprints is that it should be a "get what you pay for" style; if you don't use a particular feature in a lisp, then you shouldn't have to pay the cost in memory usage for that feature. As you use more features, the lisp uses more memory.
  
  Getting back to the #1/#2 dichotomy: I can see the point with #2, where the lisps in that category have chosen space efficiency at the expense of speed. Allegro CL certainly doesn't fit into that category; we certainly don't sacrifice speed for space efficiency. However, juxtaposed with category #2, category #1 makes these lisps look monolithic, as if the development environment (and other modules) can't be left out of the lisp.
  
  I think that a simple way to fix this problem is to modify two statements within #1 slightly:
  1. "The Lisps tend to be not really small."
     
     should be changed to something like
     
     "Fully configured, the Lisps can become large (compared to other lisps and these lisps with the more basic options installed)."
  2. "Generated code might be largish."
     
     I really don't know what Rainer was intending with this statement. If he was making a distinction between native compiled code and byte code, then it is a more general statement and doen't belong in this category (contrast this to #2, where he describes compiled code that is compact). Perhaps he means instead that since minimal compilation has occurred, more code is generated than the original source had specified. Either way, the statement is not specific to lisps in category #1, and should be removed.