CL Implementations for Mac OS X
Sunday, March 27, 2005
I've posted about my use of CL on Mac OS X previously (see here and here). Well, my old Win32 box finally died so I am a 100% Mac OS X user now! I actually have 3 Macs in the house: A 17 inch iMac G4, a 21 inch iMac G5 and my latest addition, a 17 inch PowerBook laptop. I've been doing remote consulting work on the PowerBook and am really pleased with it. I'm still catching up on what's been happening in the Lisp world since I was away in the UK (I didn't have Internet access outside of work hours and was too busy during work hours to keep up with things), but it looks like there are more and more people who are moving over to Mac OS X as their Lisp platform of choice. On c.l.l., there were a number of Mac OS X threads while I was away, including the following:
- Common LISP Implementations for Mac OS X?
- MCL for OS X worth the price?
- What Lisp for Mac OS X with these requirements?
- Graphics in MCL or LispWorks? (OS X)
"I run now, or have run, just about every common lisp that runs on Mac OS X. These include, in no particular order:This thread included a series of exchanges (primarily between Alexander Repenning and Rainer Joswig) on the relative merits of MCL and LispWorks for Mac OS X development as well as the relative merits of Carbon/Cocoa for Mac development. I won't repeat their exchange here; however, if you are tossing up whether to use MCL/OpenMCL/LispWorks/Allegro on the Mac, it would be worthwhile to read their comments in this thread.
Armed Bear Common Lisp
Allegro Common Lisp (trial version)
MCL
OpenMCL
LispWorks (4.4)
CLISP
CMUCL
SBCL
I'll rate these on the categories that would matter to most Mac OS X programmers - Carbon, Cocoa, speed (of compiled code), compiler, issues (i.e., problems), and unusual features.
ABCL
Carbon: via Java
Cocoa: via Java
Speed: slow
Compiler: slow
Issues: not fully ANSI compliant yet
Features: Java based, so access to Java libraries.
Allegro
Carbon: via FFI?
Cocoa: no
Speed: moderate to fast. (Note: This is a surprising ranking by Raffael and doesn't correspond with some other people's tests nor my own impressions as I've found Allegro to be very fast on the Mac. Raffael was using the trial version of Allegro and this is not really a fair basis for a speed comparison. Also, with regards to benchmarking CL implementations, see my comments at the end of this posting)
Compiler: fast
Issues: No IDE on Mac OS X. Trial couldn't load vendor supplied patch. Expensive. Royalties on delivered apps. (i.e., IMHO not ready for prime time on Mac OS X, especially if you're interested in GUI apps).
Features: runs on Windows and unix/linux, so should be very portable. Large user community. Excellent and abundant contributed code. Java access.
MCL
Carbon: excellent Carbon support - best of any lisp.
Cocoa: no (i.e., only via Carbon).
Speed: moderate to fast, slow floating point and arrays.
Compiler: blazingly fast.
Issues: Digitool chose the Carbon route to port from Mac OS Classic to Mac OS X. As a consequence, MCL's Cocoa support is lacking. In addition, MCL itself, as well as delivered applications are *not* Mac OS X bundles - they are single files with a resource fork. This is a problem as unix tools can unwittingly strip the resource fork of MCL apps.
Features: Unsurpassed Carbon support. Nice IDE. Friendly user community. Lots of contributed code. Royalty free app delivery with deployment license. MCL has an ephemeral garbage collector (essential for continuously animated stuff).
OpenMCL
Carbon: excellent Carbon support.
Cocoa: very good Cocoa support.
Speed: moderate to fast, slow floating point and arrays.
Compiler: blazingly fast.
Issues: As of this writing, app bundles and the alpha IDE need to be recompiled for every point update of Mac OS X. This effectively prevents distribution of finished apps (i.e., users would have to download a new version every time they used Software Update and went from Mac OS X 10.3.7 to 10.3.8 for example.) IDE is primitive.
Features: Friendly user community. Native thread support. Free as in beer and speech (LLGPL) - no redistribution issues unlike GPL because of the preamble of the LLGPL. Cocoa bridge.
LispWorks
Carbon: via FFI, but Cocoa is the expected GUI framework with LispWorks.
Cocoa: excellent Cocoa support.
Speed: fast to blazingly fast (especially CLOS)
Compiler: moderately fast
Issues: CAPI, LispWorks cross platform GUI API, is not fully HIG compliant. Mac OS X GUI is not multi-threaded unlike Windows version.
Features: Excellent IDE. Friendly user community. Good, abundant contributed code. CAPI allows easy cross platform development to Windows and Linux. Royalty free application delivery. Best lisp for Cocoa GUI development, especially if you want an IDE. LispWorks uses native threads for its multiprocessing, but, unfortunately, the LispWorks CAPI GUI on Mac OS X puts all GUI interaction in a single thread (possibly because this is easier - portions of the AppKit are not thread safe).
CLISP
Carbon: via FFI? (don't know if callbacks are possible)
Cocoa: not that I'm aware of.
Speed: generally slow to moderate, but fast bignums.
Compiler: moderately fast
Issues: No IDE. Not native compiled (bytecode). GPL (so should be aware of license issues if redistributing).
Features: very widely cross platform - Windows, Linux, unix, Mac, FreeBSD, etc. Free as in speech and beer - GPL.
CMUCL
Carbon: via FFI and callbacks
Cocoa: not that I'm aware of.
Speed: blazingly fast.
Compiler: slowish (see SBCL for comments).
Issues: Not as widely used or developed/maintained on Mac OS X as its fork, SBCL.
Features: optimizing native compiler, callbacks. .
SBCL
Carbon: via callback system.
Cocoa: not yet.
Speed: blazingly fast - fastest generated native code all around of any Common Lisp (with LispWorks close behind).
Compiler: slow, but then, it does a lot of optimizing and generates a lot of notes to aid programmer in optimizing source.
Issues: Not really ready for prime time for GUI app delivery - Carbon callbacks are still a new feature and there is no IDE.
Features: very widely cross platform, and generated code is unexcelled among Mac OS X common lisps.
Since I'm interested in Cocoa GUI apps, I use LispWorks. I'd use OpenMCL if one didn't need to recompile and redeliver apps for each OS point update, but OpenMCL is not quite ready for prime time for GUI app delivery. MCL is nice, but too slow for float and/or array intensive code, and I don't want to deliver apps that have resource forks, and I'd rather use Cocoa than Carbon.
I'd go with LispWorks. It isn't perfect (CAPI HIG issues), but it's the best Common Lisp all around for Mac OS X right now."
I should also point out that Rainer Joswig gave an excellent presentation on CL implementations for the Mac at the ILC2003 conference and that Alexander Repenning has made available much of the MCL code that he uses to fix various issues with MCL.
A final point to make is that the rating for "speed" for each of these implementations should be taken with a grain of salt. One's perception of the speed of a Lisp implementation may differ quite substantially based on the type of application that is being run. In order to measure comparative performance for different implementations, you really should run your own tests on your own hardware using your own software. As an alternative (although a poor one), you can look at other people's benchmark results and attempt to extrapolate those results to your own application's requirements although their results may not be a true indication for your own application. Having published some benchmark results for CL implementations on Win32 in the past (see here and here), I know that this is a very, uhmm, "contentious" area. However, having made that caveat, I'd like to point out that Rainer Joswig published a set of CL implementation benchmarks on OS X a while back and there are some more CL OS X benchmarks at the bottom of this CLiki page. These might be helpful in showing specific areas where different CL implementations might be strong or weak.
