Re: Just how fast is LISP? (Gene Ressler)
Thu, 21 Nov 1991 01:31:36 GMT

          From comp.compilers

Related articles
Re: Current work in compiler/language design. (1991-11-19)
Just how fast is LISP? (1991-11-20)
Re: Just how fast is LISP? (1991-11-20)
Re: Just how fast is LISP? (1991-11-21)
Re: Just how fast is LISP? (1991-11-21)
Re: Just how fast is LISP? (1991-11-21)
Re: Just how fast is LISP? (Raul Deluth Miller-Rockwell) (1991-11-21)
Re: Just how fast is LISP? (1991-11-21)
Re: Just how fast is LISP? (Simon Marlow) (1991-11-21)
Re: Just how fast is LISP? (1991-11-21)
Re: Just how fast is LISP? (1991-11-23)
[1 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Gene Ressler)
Keywords: design, Lisp, performance
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
References: 91-11-072 91-11-080
Date: Thu, 21 Nov 1991 01:31:36 GMT (Perry Schmidt) writes:
>Comment: I will agree LISP is MUCH faster than it use to be. And for many
>applications LISP can now be used where before it "couldn't" because it
>was still too slow. But I do not agree that LISP is as fast as Opt. C
>compilers of today.
>Perry Schmidt

Agree, and would like to see more discussion on this. I have various
experience with Lucid Common Lisp and also some with KCL, having written
image processing algorithms, compiler, theorem prover, graphical editor
(in CLX), and geometric algorithms for robot motion planning therein.
I've also written more C than I care to think about. Gut reaction: It
usually takes 1/3 the time to get a CL program up and running compared to
the same program in C. Most of the difference seems to be in planning
memory management and/or building/finding libraries to duplicate built-in
CL features (e.g. rational arithmetic) that C doesn't have.

On the other hand, if speed is a concern, it often takes again as long as
writing the program in CL to apply declarations, inlining, tricks, etc to
get back to within a factor of 3 of the speed of a C program. This is a
really annoying process. I've intentionally written fairly substantial
algorithms in both C and Lisp with coding styles as close as possible the
same (e.g. I implemented cons, car, and cdr in C, but also called malloc
and free), and the fastest LCL has ever done relative to gcc is a factor
of 2, often much worse. This is on Sun SparcStation 2s with huge amounts
of physical memory. On less robust machines, the sheer bulk of the LCL
image seems to intimidate Unix and run time deteriorates badly.

This is hard to understand. If a Lisp program doesn't cons, use closures
or any other fancy Lispisms, but just munges pointers and (heavily
declared) fixnums with setq, what causes the degradation? I've compared
LCL code from (disassemble 'foo) and gcc -S, and the answer seems to be
mainly that the function call overhead of Lisp is terrible, and of course
_everything_ in Lisp is a function call. I'm guessing the reasons have to
do with keyword and &rest parameters, garbage collection, symbol-function
indirection, special bindings, etc.

Lisp implementers please comment: What are really the key performance issues?


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.