How to write fast Numerical Analysis code in CLISP?

[gadbois@cs.utexas.edu (David Gadbois)]

   Date: Thu, 28 Apr 1994 10:19 CDT
   From: Matthias Lindner <matthias@intellektik.informatik.th-darmstadt.de>

   To complete my "mini-benchmark":

	    +------------+--------+-------------+-------------+
	    |Lisp        | Memory | Interpreted |  Compiled   |
	    +------------+--------+-------------+-------------+
	    |clisp       |  1.5MB |     51 sec  |     10 sec  |
	    |Xakcl       |  5.0MB |    116 sec  |     52 sec  |
	    |Allegro 4.0 | 16.0MB |    142 sec  |     12 sec  |
	    |Lucid 4.0   | 39.0MB |     65 sec  |      7 sec  |
	    +------------+--------+-------------+-------------+

Clisp and AKCL have radically different performance profiles than
Allegro and Lucid.  Clisp is a byte compiled-implementation with a
number of critical functions written in C.  AKCL "compiles" to C code,
which in turn is compiled to native code.  Thus, one can expect
compiled code in Clisp to usually (but not always!) do worse than
AKCL.

Note that since AKCL has to format the compiled Lisp code into C
source files and send them through the C preprocesor, parser, backend,
assembler, and linker, compilation in AKCL is ungodly slow.  If your
benchmarks do any kind of on-the-fly compilation, AKCL will lose big
time.

AKCL in turn is limited by how good the C compiler is, and furthermore
gives up some performance relative to native compilers like Lucid and
Allegro due to portability concerns and trying to cram the round Lisp
peg into the square C hole.

Even within compilers there is considerable variations.  Lucid
actually has two compilers in it, the production and development
compilers.  SAFETY settings can also alter performance in a big way.
In general, there are a zillion ways to compile Lisp and just as many
ways for the compiler writer to spend time optimizing things.  No one
compiler is going to do the best thing in all cases.

So, there is a continuum of choices here.  From Clisp, which is free,
has a small footprint, and runs on just about any machine albeit more
slowly, up to Lucid, which is expensive, big, and runs on a limited
number of workstation-class machines but is generally quick and
featureful.  Single benchmarks are not going to tell much here, since
there is so much variation between the implementations, and there are
quite a few factors to consider (cost, portability, development
environment, support, quality, language extensions, etc.) besides just
raw performance.

--David Gadbois