floating-point efficiency: Lisp vs. Fortran

[hmadorf@eso.org]

Lisp's floating point efficiency
--------------------------------
Simon Spero writes:
>If there's sufficient type information available at compile-time, lisp
>is as fast as fortran. It's only when the types are unknown and you have to
>dispatch at run-time that things really start to slow down.

This does not at all agree with my recent observations. I carried
out the following simple floating-point benchmark: I coded the 
log-factorial function in Fortran-77 and in Lisp (using a simple 
do-loop). The algorithm simply sums up all the log-terms. (The code
is available on request.) I executed the code using

MacTran    & Mac SE/30
MCL        & Mac SE/30
f77	     & Sun Sparc2
Allegro CL & Sun Sparc2

Two versions of the CL code were tested, one without declarations,
the other fully spiced with declarations. The CL-code was compiled
with (speed 3) optimization. The Fortran code was not particularly
optimized. My observations:

1. Declarations had little influence on CL-execution efficiency.
2. The availability of the FP-coprocessor in the SE/30 (as opposed
   to the SE) made a big difference.
3. The Fortran code ran consistently 5 times faster on both hardware
   platforms.
4. The Sparc2 with Allegro CL was about as fast as the SE/30 with
   MacTran.

The most striking thing is the consistency across the compilers and
hardware platforms, almost ruling out any trivial explanation
(such as "the log function is particularly inefficiently implemented
in MCL" or things alike).

I am quite prepared to carry the comparison further, but (despite
the fact that I love Lisp and do all work possible in it) my 
conclusion for the moment is: I cannot recommend Lisp for number
crunching when a simple algorithm is executed for utmost speed.

I recently brought up the Lisp vs. Fortran efficiency issue on the 
info-mcl network. Someon called the comparison foolish, but I do not
think it is. In any case have not received code or immediate hints that
would invalidate my conclusions above. (I still have to check out 
the optimization document in the /contrib directory in the Apple 
archive.)

Two wishes:

1. I would like to see others report their experience on
FP-efficiency in order to see whether a consensus emerges.

2. I would also like to have the MCL developers pay attention to the
"floating point efficiency issue" as *the* selling/repelling argument 
for many scientists. Advocating all the other nice features (we all
appreciate) that Lisp possesses will not make them turn away from their
beloved, primitive, but veeeeeery fast Fortran, I'm afraid. 


Lisp for scientific computing
-----------------------------
I am delighted about the discussion on Lisp for scientific
computation (which is almost invariably taken to be numeric). Right
now the discussion centres on whether Dylan should incorporate
enough to make it an interesting language to those engaged in 
scientific computing (as I am).

I am currently trying to influence the attitude of my colleagues 
(working mainly in astronomy), and make them aware of the advantages 
of Lisp vs. Fortran or even C, but I need convincing arguments not
strong convictions!

One argument that I have in my pockets is that Lisp is easy to
vectorize. (I have vectorized the whole Lisp language with a few 
macros and the help of CLOS.) The four fundamental arithmetic 
oprators +, -, * and / and all single argument functions operate on 
scalars, lists, vectors and arrays and even on some mixtures of these.
(Is that what some guys call "threading"?)

I am planning to interface this nice language to the Intel i860
vector processor in the backplane of my Sun in order to get the
FP-performance that I cannot squeeze out of Lisp otherwise. (I have
a statistical classifier that is supposed to operate on large data 
sets and that is an ideal algorithm for this kind of vectorization.)

If anyone is interested in the topics above, please contact me in
order to foster exchange of views and experience.

Hans-Martin Adorf

ST Data Analysis Scientist
Space Telescope - European Coordinating Facility
European Southern Observatory
Garching bei Muenchen, FRG

Internet: adorf@eso.org