Last week, trying to avoid working on my thesis, I decided to do one of the ITA Software programming puzzles. By the time I got bored with it, my program could find a good (not optimal, but reasonable) solution for all of the example data in a total time of 0.7 seconds on SBCL x86-64 and 0.9 seconds on x86. Then I tried CMUCL 19b, where it took 9 seconds. A factor of 10 was surprising, since I wasn't really doing anything strange or relying on arcane SBCL internals knowledge. Here's how some [*] CL implementations fare on the code:

SBCL CVS   07 seconds
CMUCL 19b    9 seconds
ABCL CVS   150 seconds
CLisp 234 450 seconds
ECL 09g   450 seconds
GCL CVS    900 seconds

[*] No results for Lispworks and Allegro, since the heap limits for their crippled editions are too small. Judging by the tests that Lispworks could handle before bailing out, it would've taken about 100 seconds for the full suite.

I'm not arguing that everyone should be switching to SBCL based on this benchmark. That would be rather sleazy, since I'm not publishing the code for others to verify the results. And of of course there are benchmarks where the other implementations will beat SBCL (I hope not by a factor of 1000). This is more of a reminder about how different the performance characteristics of different Lisp implementations can be, even when they're using the same general implementation strategies.

Just a couple of hours ago a poor #lisp-newbie was told that Lisp is as fast as C, and that porting between different Lisps is just a matter of a few tweaks. From what I've seen, the claims of easy portability can be true, but not when combined about talk of C-like speed. Heroic feats seem to be required for making the same idiomatic Lisp code efficient on multiple Lisps. I certainly have doubts about mere tweaks being sufficient for this program.

P.S. I am impressed about how well ABCL did, considering how young the project is, and that it's targetting a CL-hostile virtual machine.