[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
floating-point efficiency: Lisp vs. Fortran
- To: Simon Spero <firstname.lastname@example.org>
- Subject: floating-point efficiency: Lisp vs. Fortran
- From: email@example.com
- Date: Wed, 07 Oct 92 07:30:35 +0100
- Cc: firstname.lastname@example.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
4. The Sparc2 with Allegro CL was about as fast as the SE/30 with
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
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
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.
ST Data Analysis Scientist
Space Telescope - European Coordinating Facility
European Southern Observatory
Garching bei Muenchen, FRG