I've heard it said that maclisp used to produce numeric code as good
as an optimizing FORTRAN compiler. To what extent can LISPs do this
today? Which LISPs are best at it? Which are worst? What types of
computations get closest to optimized FORTRAN speed, & which are
slowest in comparison? How do the freely available LISPs compare?
What about the freely available SCHEMEs? Does the fastest free SCHEME
do better or worse than the fastest free LISP? What does the user
need to know to produce optimal code? Are there afew simple rules of
thumb, or many complex factors involved?
In general, what do I need to know to produce efficient LISP code?
What documents are available on the subject?
Thanks,
--
Harvey J. Stein
Berger Financial Research
·······@math.huji.ac.il
In article <·····················@sunset.huji.ac.il> ·······@sunset.huji.ac.il (Harvey J. Stein) writes:
I've heard it said that maclisp used to produce numeric code as good
as an optimizing FORTRAN compiler. To what extent can LISPs do this
today? Which LISPs are best at it? Which are worst? What types of
computations get closest to optimized FORTRAN speed, & which are
slowest in comparison? How do the freely available LISPs compare?
What about the freely available SCHEMEs? Does the fastest free SCHEME
do better or worse than the fastest free LISP? What does the user
need to know to produce optimal code? Are there afew simple rules of
thumb, or many complex factors involved?
In general, what do I need to know to produce efficient LISP code?
What documents are available on the subject?
That's a lot of questions for one post. :-)
For numerical code, CMU Common Lisp is probably your best bet if it
runs on the machine/os that you care about. I don't know of any free
scheme that comes close for floating-point. The CMU CL documentation
talks a bit about how to produce efficient code, and the compiler
produces efficiency notes if you want them.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576 (new!)
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU
(Scott Fahlman) writes:
In article <·····················@sunset.huji.ac.il>
·······@sunset.huji.ac.il (Harvey J. Stein) writes:
I've heard it said that maclisp used to produce numeric code as good
as an optimizing FORTRAN compiler. To what extent can LISPs do this
today? Which LISPs are best at it? Which are worst? What types of
computations get closest to optimized FORTRAN speed, & which are
slowest in comparison? How do the freely available LISPs compare?
What about the freely available SCHEMEs? Does the fastest free SCHEME
do better or worse than the fastest free LISP? What does the user
need to know to produce optimal code? Are there afew simple rules of
thumb, or many complex factors involved?
In general, what do I need to know to produce efficient LISP code?
What documents are available on the subject?
That's a lot of questions for one post. :-)
For numerical code, CMU Common Lisp is probably your best bet if it
runs on the machine/os that you care about. I don't know of any free
scheme that comes close for floating-point. The CMU CL documentation
talks a bit about how to produce efficient code, and the compiler
produces efficiency notes if you want them.
I'm afraid that I only have access to 486s running Linux, so as much
as I'd like to use it, CMU CL is out of the question. But, in that
CMU CL is considered to be so hot, I'd like to know what sort of
penalty is involved in using another lisp instead. For example, as a
general, rough rule of thumb, would GCL code take 1.5 times as long to
run, or 3 times as long, or what. What sort of magnitutes are we
talking about? If CMU CL will generally have about 1.2 to 1.5 times
the runtime of Fortran code, and GCL will generally have about 1.5 to
2 times the run time of Fortran, then I wouldn't be so worried about
using GCL.
Thanks,
--
Harvey J. Stein
Berger Financial Research
·······@math.huji.ac.il
In article <·····················@sunset.huji.ac.il> ·······@sunset.huji.ac.il (Harvey J. Stein) writes:
... But, in that
CMU CL is considered to be so hot, I'd like to know what sort of
penalty is involved in using another lisp instead. For example, as a
general, rough rule of thumb, would GCL code take 1.5 times as long to
run, or 3 times as long, or what.
I think it's probably more than that for well-tuned single-float
code. When our Python compiler first came up on the MIPS-based
Descstations, I tested a float-intensive neural-net simulator on it.
This was well-tuned code, though Ken Anderson has recently been able
to tweak it even further. Anyway, the speed in CMU CL was very close
to the performance of the same program translated into C by one of our
grad students. It was 5-6 times faster than the Allegro of the day,
which I think was considerably faster (maybe 2x) than AKCL (now GCL).
I think Allegro's floating-point performance has improved some since
then. I don't know about GCL. We didn't try Fortran, but the C
compiler on that machine was said to a be good one in terms of
optimization.
Ken Anderson has run some more recent tests, and posted a pointer in
this newsgroup not long ago.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576 (new!)
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU (Scott Fahlman) writes:
>
>In article <·····················@sunset.huji.ac.il> ·······@sunset.huji.ac.il (Harvey J. Stein) writes:
>
> ... But, in that
> CMU CL is considered to be so hot, I'd like to know what sort of
> penalty is involved in using another lisp instead. For example, as a
> general, rough rule of thumb, would GCL code take 1.5 times as long to
> run, or 3 times as long, or what.
>
>I think it's probably more than that for well-tuned single-float
>code. When our Python compiler first came up on the MIPS-based
>Descstations, I tested a float-intensive neural-net simulator on it.
>This was well-tuned code, though Ken Anderson has recently been able
>to tweak it even further. Anyway, the speed in CMU CL was very close
>to the performance of the same program translated into C by one of our
>grad students. It was 5-6 times faster than the Allegro of the day,
>which I think was considerably faster (maybe 2x) than AKCL (now GCL).
Ah, but faster at what? I don't know about floating point, but
for some things AKCL is not particularly slow.
-- jeff
In article <·····················@sunset.huji.ac.il>,
Harvey J. Stein <·······@sunset.huji.ac.il> wrote:
>>In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU
>(Scott Fahlman) writes:
>But, in that
>CMU CL is considered so hot, I'd like to know what sort of
>penalty is involved in using another lisp instead. For example, as a
>general, rough rule of thumb, would GCL code take 1.5 times as long to
>run, or 3 times as long, or what.
It's not as simple as a constant factor. I haven't done much benchmarking
recently, and the other Lisps have continued to improve, but:
-- If an application is written just right, other implementations may be
faster. GCL does have the advantage of the gcc backend, which does much
more low-level optimization than CMU CL.
-- If the application is written significantly wrong, the slowdown may be 30x
or more.
Broadly speaking, an application is "written wrong" if the implementation feels
a need to heap-allocate floats. CMU CL has two major advantages:
1] Heap allocation is avoided in many situations where Lisp implementations
have often done heap allocation:
- inline or block-compiled function calls,
- structure slots,
- inadequate type declarations.
2] Comprehensive and relatively comprehensible efficiency notes describe
situations where generic arithmetic or number consing occur, and why
open-coding was impossible.
Point [1] allows programs to be written in a more natural and readable way,
since inner loops can be split into multiple functions and non-array data
structures can be used.
Even with an existing program tuned for less clever implementations, point [2]
often results in significant performance improvement. This is because even if
a programmer knows the "efficient style" of declarations, etc., he will mess up
occasionally.
Although it presumably isn't the sort of numeric code you're talking about, CMU
CL also excels at bignum arithmetic, and supports user-level full-word integer
arithmetic.
Rob
In article <·····················@sunset.huji.ac.il> ·······@sunset.huji.ac.il (Harvey J. Stein) writes:
In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU
(Scott Fahlman) writes:
In article <·····················@sunset.huji.ac.il>
·······@sunset.huji.ac.il (Harvey J. Stein) writes:
I've heard it said that maclisp used to produce numeric code as good
as an optimizing FORTRAN compiler. To what extent can LISPs do this
today? Which LISPs are best at it? Which are worst?
<deletia>
That's a lot of questions for one post. :-)
For numerical code, CMU Common Lisp is probably your best bet if it
runs on the machine/os that you care about.
<deletia>
I'm afraid that I only have access to 486s running Linux, so as much
as I'd like to use it, CMU CL is out of the question.
Hr'hhm. I suspect that, in the near future at least, a lot of serious
computer science students (and many professionals at home) will
'...only have access to 486s running Linux...'. Linux is a very good
system, and cheap :-} The feeling that CMU is the best non-commercial
CL around seems widespread, too.
Has anybody enough knowledge of the CMU source to have a feel of how
difficult this would be to port to Linux? Is this something that,
perhaps, a group of us could get together on over the net? It seems to
me that the goal might well be worth achieveing. If enough people mail
me on this I shall work out what it takes to set up a mailing list.
--
··············@rheged.dircon.co.uk
In article <··········@cantaloupe.srv.cs.cmu.edu> ···@CS.CMU.EDU (Scott Fahlman) writes:
...
As a guess, figure a person-year for someone really good who already
knows his way around Linux. We would like to see such a port, and
would offer advice and encouragement, but my people can spare very
little time for this.
I wonder if a Linux port would be more useful to the world than a
Windows NT port. Linux probably would be a good deal easier.
Like it or not, a port to Windows NT would make more sense. Still it
would seem that the first step of porting the instruction set code to
the 80x86/Pentium architecture could be a very good first step.
Unfortunately, I don't have the time to do that. :(
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
| I wonder if a Linux port would be more useful to the world than a
| Windows NT port. Linux probably would be a good deal easier.
|
|Like it or not, a port to Windows NT would make more sense. Still it
|would seem that the first step of porting the instruction set code to
|the 80x86/Pentium architecture could be a very good first step.
Windows NT costs lots of $$$ (in a useful configuration) and consumes
lots of resources compared to Linux. It would also be much harder to
port to. And, I suspect that the number of NT installations (in
particular those interested in running Lisp) is small compared to the
number of Linux installations. I doubt that a Windows NT port "would
make more sense".
Thomas.
From: Simon Brooke
Subject: Port of CMU Common LISP to Linux (was: Re: Squeezing more speed out of LISP.)
Date:
Message-ID: <Cy4B02.4ME@rheged.dircon.co.uk>
NOTE: This article is cross posted to comp.lang.lisp and
comp.os.linux.misc, but follows discussion which has taken place in
comp.lang.lisp only. Please follow-up by mail to me, and I'll repost
-- I don't know what the volume of interest will be, and don't want to
swamp the newsgroups.
SUMMARY: In comp.lang.lisp we've been discussing the efficiency of
Common LISP implementations, and there appears to be a strong feeling
that Carnegie Mellon University's CMU CL is the fastest non-commercial
version presently available. However, it is available only for some
RISC based architectures. I wondered how many people would be
interested in a port to Linux, and what would be involved.
ACTION: If you would be seriously interested in using CMU CL on Linux,
please mail me with the subject line 'CMU CL: Interest'
If you believe you have skills relevent to the porting effort, and
would like to be involved, please mail me with the subject line
'CMU CL: Volunteer', and detail in the message what skills you can
offer, and how much time you could make available.
I will collate responses, and if I feel that there is enough interest,
will set up a mailing list. I shall in any case repost a summarry of
the responses I receive.
BACKGROUND:
In article <··········@cantaloupe.srv.cs.cmu.edu>,
Scott Fahlman <···@CS.CMU.EDU> wrote:
>
>In article <··········@rheged.dircon.co.uk> ·····@rheged.dircon.co.uk
>(Simon Brooke) writes:
>
> Hr'hhm. I suspect that, in the near future at least, a lot of serious
> computer science students (and many professionals at home) will
> '...only have access to 486s running Linux...'. Linux is a very good
> system, and cheap :-} The feeling that CMU is the best non-commercial
> CL around seems widespread, too.
>
> Has anybody enough knowledge of the CMU source to have a feel of how
> difficult this would be to port to Linux? Is this something that,
> perhaps, a group of us could get together on over the net? It seems to
> me that the goal might well be worth achieveing. If enough people mail
> me on this I shall work out what it takes to set up a mailing list.
>
>Porting to Linux is not the whole story. CMU CL is a native-code
>compiler, so you have to port to a specific instruction set as well as
>to a specific OS. You don't just change the system calls and
>recompile the C.
>
>If porting to the 486 under Linux is the goal, you first have to port
>to the 486 instructions set. Since this is a CISC instruction set
>with fewer registers than CMU CL uses on the typical RISC machine,
>there are some tricky aspects to the port. We did some bits of the
>design at one point, when we were thinking about porting to 486/Mach,
>but I'm not sure if this is far enough along to be useful.
>
>I have no idea how much Linux differs from Mach or SunOS in things
>like signals and the mapping of disk files into particular addresses
>in virtual memory.
>
>As a guess, figure a person-year for someone really good who already
>knows his way around Linux. We would like to see such a port, and
>would offer advice and encouragement, but my people can spare very
>little time for this.
>
>I wonder if a Linux port would be more useful to the world than a
>Windows NT port. Linux probably would be a good deal easier.
>
>-- Scott
>
>===========================================================================
>Scott E. Fahlman Internet: ····@cs.cmu.edu
>Principal Research Scientist Phone: 412 268-2575
>School of Computer Science Fax: 412 268-5576 (new!)
>Carnegie Mellon University Latitude: 40:26:46 N
>5000 Forbes Avenue Longitude: 79:56:55 W
>Pittsburgh, PA 15213 Mood: :-)
>===========================================================================
>
--
··············@rheged.dircon.co.uk
In article <··········@rheged.dircon.co.uk>
·····@rheged.dircon.co.uk "Simon Brooke" writes:
> Hr'hhm. I suspect that, in the near future at least, a lot of serious
> computer science students (and many professionals at home) will
> '...only have access to 486s running Linux...'. Linux is a very good
> system, and cheap :-} The feeling that CMU is the best non-commercial
> CL around seems widespread, too.
Does this suggest that porting CMU CL to Linux on the x86 would
be a good move? It sounds like it to me, but then, here I am stuck
with a 386 for the next few years! So I would say that, wouldn't I?
> Has anybody enough knowledge of the CMU source to have a feel of how
> difficult this would be to port to Linux? Is this something that,
> perhaps, a group of us could get together on over the net? It seems to
> me that the goal might well be worth achieveing. If enough people mail
> me on this I shall work out what it takes to set up a mailing list.
If I were running Linux right now, I'd volenteer, even tho I've no
experience with CMU CL at all. That's how keen I am. ;-) At the very
least, I'd want to be a beta tester. Perhaps in a year?
Martin Rodgers
--
"Internet? What's that?" -- Simon "CompuServe" Bates
http://cyber.sfgate.com/examiner/people/surfer.html
From: Simon Brooke
Subject: Port CMU CL -> Linux (was Re: Squeezing more speed out of LISP)
Date:
Message-ID: <CyAvuz.6zL@rheged.dircon.co.uk>
In article <·················@scott.cogsci.ed.ac.uk>,
Tim Bradshaw <···@cogsci.ed.ac.uk> wrote:
>* Marco Antoniotti wrote:
>> (Jeff Dalton) writes:
>> Like it or not, a port to FreeBSD, NetBSD, 386BSD, or Linux
>> would be vastly more useful to me and many like me.
>
>> Note that I don't necessarily like the WindowsNT option.
>
>Am I right in thinking that retargeting the compiler to produce 386
>code is a lot more work than making things run on a new OS? If this
>is true it should be possible to have linux/windows/BSD versions quite
>easily once one can get 386 code at all.
>
It's my understanding, at a preliminary stage and having only just
begun working with the documentation, that retargeting the compiler
and possibly optimising the garbage collector for Intel 32 bit will be
the big challenge, and that if that is successful, retargeting to other
OSs with the same processor architecture should then be less of a
challenge (tho' not necessarily 'quite easily' :-}).
However, this is an early stage... if you wish to assist, please sign up!
--
·············@rheged.dircon.co.uk
(cond ((think you (oddp (my 'car)))
(should (see you (my 'cdr)))))
In article <·····················@sunset.huji.ac.il> ·······@sunset.huji.ac.il (Harvey J. Stein) writes:
>
>I've heard it said that maclisp used to produce numeric code as good
>as an optimizing FORTRAN compiler. To what extent can LISPs do this
>today? Which LISPs are best at it? Which are worst? What types of
>computations get closest to optimized FORTRAN speed, & which are
>slowest in comparison? How do the freely available LISPs compare?
>What about the freely available SCHEMEs? Does the fastest free SCHEME
>do better or worse than the fastest free LISP? What does the user
>need to know to produce optimal code? Are there afew simple rules of
>thumb, or many complex factors involved?
It would be very unlikely for today's Lisp compilers to produce code
as efficient as today's Fortran compilers. For one thing, the arrays
would have to be statically allocated and have constant dimensions.
For another thing, the array indices would have to be declared in such
a way to map directly to the HW arithmetic. The interfaces to most of
the math libraries would have to be changed to be more amenable to
static analysis. The compiler would have to specially recognize that
the Lisp programmer didn't inadvertently take advantage of certain
control constructs in peculiar ways. Etc., etc.
Rather than re-invent all of the clever Fortranish optimizations, it
would be far simpler and more productive to recognize and compile
certain functions into Fortran (perhaps even dynamically) and have the
Fortran compiler do its thing. Of course, there are some hard issues
regarding interfacing Lisp to Fortran code......
Henry Baker
Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.
Ken Anderson recently wrote of his experiences in benchmarking numerical
code. You may still have the article available on your site (the
title is "Fannkuch revisited or Benchmarking is hard"). I can send
it to you if you don't have it.
Richard Fateman (·······@cs.berkeley.edu) wrote the paper claiming Fortran
speed for Maclisp back in the 70's. Fortran was simpler back then
(recursion was illegal). Lisp was also simpler. I'm not sure how Fortran has
evolved but Lisp is certainly more complex today. Compiler writers love
simple languages, it makes their job a lot easier. So Fortran will probably
always compile numeric code faster than Lisp. However if you confine your
Lisp code to the subset of Lisp where the Lisp compiler writer has concentrated
his numerical optimizations then you'll find that Lisp can give you very
good performance. Specifically
1. store only one type of lisp object in a variable and declare that
variable's type.
2. use only simple arrays and declare their types (including their dimensions).
3. avoid operations which would force the compiler to heap allocate
intermediate results.
[don't forget: see Ken Anderson's article for other suggestions]
If this doesn't give you enough speed and speed is critical because
this numeric code will take hours and hours to run, then do as Henry Baker
suggests. Write it in Fortran and have your Lisp program call it.
-john foderaro
franz inc.
In article <·················@frisky.Franz.com> ···@Franz.com (Sean Foderaro) writes:
For a more upto date comparison with Fortran see:
R.J. Fateman, K.A. Broughan, D.K. Willcock, and Duane Rettig, "Fast
floating-point processing in Common Lisp"
ftp peoplesparc.berkeley.edu:~ftp/pub/papers/fastlisp.ps.Z
Besides the analysis of the FANNKUCH benchmark, see also my LUV '94 paper:
ftp wheaton.bbn.com: pub/faster94/faster94/postscript profile.ps
for a comparison of Lisp and C. There is other performance related stuff
in that directory.
k
--
Ken Anderson
Internet: ·········@bbn.com
BBN ST Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4a FAX: 617-873-2794
Cambridge MA 02138
USA