Re: Just how fast is LISP?

In article 91-11-085 ressler@cs.cornell.edu (Gene Ressler) writes:
>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.


Most of these things only have overhead when they're used.


If the function you're calling doesn't have any keyword or &rest
parameters there should be no overhead for that. I don't know of any
special garbage collection overhead in function calls. There is no
indirection through symbol-function at runtime (in most Lisps, the linking
is done when you load the binary file or when you compile to memory --
back pointers are maintained for updating when the function is redefined);
the indirection is usually through a function pointer stored in the
caller's constant vector. Special bindings do usually have overhead, but
only when they're used.


When you did your comparison, did you disable number of arguments checking
(in most Common Lisps, (proclaim '(optimize (safety 0))) will disable
argument number and type checking)? If not, then there's overhead in the
called function as it checks the arguments (argument count checking only
takes two instructions in LCL/SPARC -- it's a comparison of a register to
a constant followed by a conditional branch).
--
Barry Margolin, Thinking Machines Corp.


barmar@think.com
{uunet,harvard}!think!barmar
--

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