Re: Just how fast is LISP?

pschmidt@convex.com (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?


Thanks,
Gene
--

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