Re: How to make Lisp go faster than C

Ditto, what Waldek is saying about SBCL (and other Lisp Compilers).

For example one thing that bothers me, is that depending on the memory address where the function was compiled it can run slower of faster. Simple explnatation: any loop (jmp, jne, etc. function) that does not go to a 16-th aligned boundary is going to get slower. So depending on where the function compiled (1/4 times) it would get significantly faster. (Wonder how they get proper boinkor results everytime).

But then again it's one of the best compilers I've seen for such a dynamic language.

Waldek Hebisch wrote:
Didier Verna <didier@xxxxxxxxxxxxx> wrote:
Francogrex <franco@xxxxxxxx> wrote:

Read the Research and Development article by Didier Verna:
http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf
FWIW, try s/imecs/ecoop/. It's the director's cut version. Also, note
that I'm going to present the sequel at ILC.


I appreciate information about optimizing Lisp code contained
in this article. However I consider the claim "Beating C in Scientific
Computing Applications" to be misleading. My personal experience
using both SBCL and C (gcc) is that SBCL generates significantly worse
code than gcc:

1) SBCL in many cases generates shifts/masks due to tags in Lisp
integers. Declaring integers as (unsigned byte 64) (or 32 on
32-bit machines) helps in some cases, but other remain.
2) SBCL frequently generetes "useless" instructions: extra copies,
recomputes sub-expressions which did not change, can not exploit
addressiong modes etc. In other words, SBCL code generator is much
less sophisticated than gcc one.

I would say that in compute-bound code it is hard to get within
factor of 2 using SBCL compared to gcc. Real code is frequenty
memory-bound and this tends to significantly decrease performance
gap. However, in many important cases it is possible to
design algorithms so that data is available in L1 cache -- such
algorithms get full benefit from better code generation. And
on code which is doing many memory accesses gcc will still
have advantage of smaller number of non-memory operations.

Extra remark about the paper:

- C code for add in Listing 1 is pretty inefficient. One thing
is mixing of integer and floating point operations. Another,
probably more important, is use of double indirection, which
forces 4 memory accesses in inner loop.

So kudos for serious work on improving Lisp performace. And
kudos to CMU CL and SBCL developers for good compilers. But
guys, get real, there is long way before for Lisp technology can
match C.

.

Relevant Pages

  • Re: SBCL performance on OS X
    ... > than C at allocating memory. ... > OpenMCL on the powerbook is an order of magnitude slower than SBCL ... comparison with the lisp implementation of your experiment terribly ... allocate an extra two-word structure to store it in, ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... Few, if any, compilers offer completely safe modes. ... Lisp programming is much more visual. ... >> objects around to make manual memory management manageable. ... Few programmers use the auto keyword in declarations because all ...
    (comp.lang.cpp)
  • Re: C++ sucks for games
    ... Few, if any, compilers offer completely safe modes. ... Lisp programming is much more visual. ... >> objects around to make manual memory management manageable. ... Few programmers use the auto keyword in declarations because all ...
    (comp.lang.lisp)
  • Re: lisp implementations and scaling requirements
    ... In SBCL this is not really possible. ... library and dynamically linked into a Lisp process. ... different SBCL processes. ... have its own copy in memory of such libraries in order to function. ...
    (comp.lang.lisp)
  • Re: multicore lisp?
    ... web page that SBCL does not care about thread safety, ... I object to the claim "as of December 2007 they have big locks around ... You're using a definition of thread safe here that I can't agree with. ... support for basic lisp operations in sbcl. ...
    (comp.lang.lisp)