Speed with various Lisps
Waldek Hebisch
Lisp implementations. All timings were on 2.4GHz Core 2 with
2Mb L2 cache and 4GB RAM running Debian stable.
Lisp implementations are:
SBCL 1.0.20
Closure CL (former openmcl) release 1.2
Ecl 0.9l (CVS 2008-06-19 17:09)
gcl "Debian 2.6.7" (which is really very close to 2.6.8pre that
we are using)
Clisp 2.46
I used file times (difference between creatio time and last write to
the file) to estimate run time of particular tests. This means that
there is rounding error (possibly as larg as 2s) in times below.
Most of our test run only for short time and the result would be
meaningless for them, so I included only long running tests.
All times are in seconds.
easter mapleok marcbench r21bugsbig Sum
sbcl 10 30 33 66 139
Closure CL 16 59 146 69 290
ecl 33 69 60 154 316
gcl 29 78 54 208 369
clisp 58 184 134 575 951
Some remarks:
1) ecl starts up quite slowly -- it needs 3-6 seconds before is
can do useful computation. When measuring speed of whole
testsuite the runtime is dominated by startup time on "fast"
tests. Using only long running tests mostly compensates this
problem.
2) sbcl seem to be much faster than other Lisps. Closure CL is
quite fast on general code, but has _very_ slow bigmums. In
particular, Closure CL is worst one on marcbench and the
reason is probably due to bignums.
3) If we ignore issue of startup time ecl seem to have similar
speed to gcl. One notable difference is that gcl has its
own integer GCD routine which is very slow on bignums. ecl
uses GCD provided by GMP which is quite fast for large
numbers (that is one possible explanation for difference
on r21bugsbig).
4) Separate measurement indicates that for very large integeres
gcl provides fastest multiplication, ecl is slower but
it seems that factor is bounded, clisp and sbcl are
significantly slower (it is likely that ratio is unbounded
when numbers grow) and Closure CL is just complete disaster.
AFAIK difference between gcl and ecl is due to memory
management -- gcl has bunch of tricks to make memory allocation
faster. I think that both clisp and sbcl use their own
big integer routines, which seem to be reasonably good,
but slower than GMP. Closure CL seem to have very naive
integer multiplication.
5) One possible conclusion form above data is that there is
no "fastest Lisp". Namely, after looking at sbcl generated
code I am pretty confident that C compilers generate much
faster code for tight loops. In principle Lisp compilers
which go via C code should have similar advantage. If one
add less than optimal speed on bignums in principle one
should be able to get much faster code that current sbcl.
--
Waldek Hebisch
heb...@math.uni.wroc.pl