Numeric efficiency in dylan (or lisp in general)

[Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>]

I have worked very long and hard with LISP implementations trying to
achieve good numeric performance.  It is a total MYTH that LISP is
doomed to be slower in numeric performance.  I have been able to
achieve in some cases even better performance than C (e.g., a neural
network simulator using the lucid compiler on a sparc).  As simon
spero wrote: ``if there's sufficient type information available at
compile-time, lisp can be as fast as fortran.''  

This statement is all true within a function, the caveat is when a
function calls other functions that take floating-point arguments or
return floating-point results.  The problem is that the representation
of a float usually requires boxing and unboxing the float args/results
upon function call/return and thus allocating the floats on the heap.
Therein lies the rub. A generational GC can recover this garbage and
thus smoothly spread out the overhead, but this overhead pushes the
ratio of LISP to C runtime more towards 2.  There is one brute force
way around this that keeps the performance ratio more towards 1, such
as passing/returning float vectors instead of floats, but this is a
burden on the programmer.  The real problem to date was that there was
no way to avoid the FP call/return overhead incurred when calling the
floating-point library functions (e.g., `exp').  (I ended up calling C
for these functions and passed one-element vectors to avoid the
boxing.)

With regards to this problem (as Rob MacLachlan mentioned), Dylan has
a nice way to turn off run-time function redefinition (by
freezing/sealing a class).  Given this feature, I think that at least
the FP call/returns to/from the FP library (and to frozen user defined
classes) will not need to box/unbox floats and will run just as fast
as any other language.

In conclusion, Dylan is NOT doomed to be slow to crunch numbers, but
there does need to be some careful attention given to this area in
order to get maximal performance (re: earlier letters on
float-vectors, short-floats, and parameterized types).

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784864
bachrach@ircam.fr