Re: Just how fast is LISP? (Barry Margolin)
21 Nov 91 21:36:33 GMT

          From comp.compilers

Related articles
[3 earlier articles]
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)
Re: Just how fast is LISP? varghese@cs.MENTORG.COM (1991-11-25)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Barry Margolin)
Keywords: Lisp, performance
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: 91-11-072 91-11-085
Date: 21 Nov 91 21:36:33 GMT

In article 91-11-085 (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.

Post a followup to this message

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