From: ···@sef-pmax.slisp.cs.cmu.edu
Subject: Re: Floating Point
Date:
Message-ID: <CMC3wu.6Bz.3@cs.cmu.edu>
From: ········@wheaton.bbn.com (Ken Anderson)
Also, can anybody point me to a source that gives examples of LISP
code that is optimized for speed? Do I have a chance to make a LISP
program run half as fast as the comparable C code?
1. A good example of how to write fast math in Lisp, is Scott Fahlman's
Cascade Correlation Here are some ftp sources:
This code does indeed run very well under CMU CL -- I think that the guy
who wrote it knows someone in the CMU CL implementation group and maybe got
special treatment and advice. :-)
I would point out, however, that the Cascade-Correlation code was written
when CMU CL's Python compiler was not as good at type inference as it is
today, so this code has a lot more type declarations than are necessary for
good performance.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:33 N
5000 Forbes Avenue Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================
CMU CL is very good at floating point. I wrote a software-only speech
synthesizer in Lisp, and it ran faster in optimized Lisp (CMU CL or
Lucid) than the equivalent program in optimized GNU C. Moreover, it
was faster than a similar commercial program. Lucid's performance was
actually quite close to CMUCL. (At the time Allegro didn't have
certain optimizations; I haven't redone the timing tests, but I
believe Allegro 4.2 will have similar performance to Lucid.)
Speech synthesis is heavily dependent on floating point.
--mark
CMU CL is very good at floating point. I wrote a software-only speech
synthesizer in Lisp, and it ran faster in optimized Lisp (CMU CL or
Lucid) than the equivalent program in optimized GNU C. Moreover, it
was faster than a similar commercial program. Lucid's performance was
actually quite close to CMUCL. (At the time Allegro didn't have
certain optimizations; I haven't redone the timing tests, but I
believe Allegro 4.2 will have similar performance to Lucid.)
Speech synthesis is heavily dependent on floating point.
I can vouch for cmucl.
I did a simple neural net benchmark and cmucl beat the sun c compiler,
and was just beaten by gcc with full opt. The code used arrays, but
not complex function calls or method dispatching. (cmucl knows how to
compile a group of functions as a block, and thus do certain cross
function optimizations.) cmucl beat gcc for a simple integer
benchmark, but I'd say that they are actually similar.
I suggest that you write a test for the guts of what you are trying to
do in C and lisp, and find out for yourself. The lisp code will need
declarations, make sure that you know how to use them.
Making claims on the basis of experiments like these is ludicrous since I have
no idea of your talent as a Lisp programmer, as a C programmer, or your
relative talents in Lisp versus C. I also don't know how much effort you put
into each alternative and how close your Lisp or C code is to the best
possible Lisp or C code for the task and for the given compilers. Also, this
is one data point and says nothing about the average or the distribution
across programs for tasks in a given class.
Here are several different kinds of experiments one could perform that would
shed more light on the matter.
A. Have the same programmer or team implement both a C version and a Lisp
version for some task and compare the results. The programmers would need to
be equally competent (how one would measure that I don't know) in both C
and Lisp and would have to spend equal amounts of time and effort on both the
C and Lisp versions.
B. Same as A except have different teams. The teams would be equally
proficient at the task domain while each team would be maximally proficient at
the language/compiler that they were using.
C. Same as B except that the teams would just have average proficiency at the
language/compiler that they were using (however that would be measured).
D. Same as B except that each time could spend as much time as they wanted on
the task to achieve as best performance as they could.
You would then have to quantify this experiment over a space of tasks crossed
with a space of compilers crossed with a space of programmers/teams.
Another question one could ask is:
E. Take the maximal subset of Lisp which is semantically in the intersection
with Fortran or C. Take a set of Fortran or C programs in that intersection
and mechanically translate them to Lisp syntax (either by hand or by machine),
compile them and compare the results. This won't tell you anything about how
good a Lisp compiler is at compiling Lisp-style code but it will at least tell
you something about the raw code-generator.
Also, I would like to deflate the mistaken image of CMUCL as an efficient
compiler. It may produce good floating point code but it is horrible at
symbolic code. One some of my examples, it runs 5 to 7 times slower than
Lucid, possibly due to abyssmal GC. So if you are in the unfortunate situation
of having to integrate numeric and symbolic processing you lose.
Jeff
|CMU CL is very good at floating point. I wrote a software-only speech
|synthesizer in Lisp, and it ran faster in optimized Lisp (CMU CL or
|Lucid) than the equivalent program in optimized GNU C. Moreover, it
|was faster than a similar commercial program. Lucid's performance was
|actually quite close to CMUCL. [...]
|Speech synthesis is heavily dependent on floating point.
Yes, you can get good floating point performance out of CMU CL or even
AKCL. There are still two major problems:
(1) The set of things I need to do in order to get good performance
in each implementation is haphazard. For example, last I tried,
calling FLOOR in CMU CL caused floating point consing, without even
any hint from optimization notes for what was going on. In
Lucid, at one point, (THE SINGLE-FLOAT (THE SINGLE-FLOAT (+ X
Y))) was slower than (THE SINGLE-FLOAT (+ X Y)). And the AKCL
optimizer fails when you specify the rank of an array; so
(SIMPLE-ARRAY SINGLE-FLOAT *) is much faster than (SIMPLE-ARRAY
SINGLE-FLOAT (* *)).
(2) None of the Lisps I have tried has solved satisfactorily the
problem of avoiding consing for floating point functions compiled
in different compilation units.
Whenever I have tried to use anything like data structures or
functions in numerical CommonLisp programs, I have tripped in one way
or another over (1) or (2) and had to spend hours trying to find all
the places where the optimzer failed. If I can't use even basic
facilities of a high level language without tearing my hair out, what's
the point of using CommonLisp for numerical applications? Pointer
errors notwithstaning, writing my code in C is more pleasant than
pouring over disassembled compiled Lisp code to figure out what went
wrong with the optimizer.
Now, both problems are fixable. In fact, CMU CL does a whole lot
better at (1) than other implementations of CommonLisp. But frankly,
at this point, I don't think it matters anymore.
Five years ago, CommonLisp vendors said they didn't want to bother
with improving floating point performance because they didn't think
there was a market for CLs with high performance floating point. They
were wrong then. But, by now, most people who were at one point
interested in numerical CL seem to have given up and switched to C or
other languages.
Thomas.
In article <·················@arolla.idiap.ch> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
Whenever I have tried to use anything like data structures or
functions in numerical CommonLisp programs, I have tripped in one way
or another over (1) or (2) and had to spend hours trying to find all
the places where the optimzer failed. If I can't use even basic
facilities of a high level language without tearing my hair out, what's
the point of using CommonLisp for numerical applications? Pointer
errors notwithstaning, writing my code in C is more pleasant than
pouring over disassembled compiled Lisp code to figure out what went
wrong with the optimizer.
For once I agree totally with what tmb says :-)
Let me add a third really absurd aspect of the CommonLisp type system.
(3) In most implementations, when you make an unsound type declaration
you get no compile-time or run-time assitance in discovering that
unsoundness. Often you crash your Lisp image.
Now for a language that prides itself on its forward thinking programming
environment and its dynamic aspects this is downright reactionary. I prefer
not having to put in declarations in my code in the first place. That is one
reason I prefer Lisp to C. But if I'm going to put in the effort to decorate
my program with types, I would expect the compiler to do at least as good as
what compilers for statically typed languages like FORTRAN have done for 35
years and tell me when my types don't jive.
I don't want vendors to interpret this as my first choice suggestion. I would
prefer that you did much more extensive and sophisticated automatic type
inference under closed-world assumptions inference so I didn't have to put in
declarations in the first place. But if you don't get arround to doing that,
then the above is in my mind a necessary alternative.
Jeff
In article <··················@qobi.ai.toronto.edu> ····@qobi.ai.toronto.edu (Jeffrey Mark Siskind) writes:
Let me add a third really absurd aspect of the CommonLisp type system.
(3) In most implementations, when you make an unsound type declaration
you get no compile-time or run-time assitance in discovering that
unsoundness. Often you crash your Lisp image.
Now for a language that prides itself on its forward thinking programming
environment and its dynamic aspects this is downright reactionary. I prefer
not having to put in declarations in my code in the first place.
It really sounds like you should try out Python (CMU Common Lisp).
--
Rick Busdiecker <···@lehman.com> and <···@cmu.edu>
Lehman Brothers
388 Greenwich Street ``A great many people think they are thinking when
New York, NY 10013 they are merely rearranging their prejudices.''
(212) 464-4750 - William James