← Back to context

Comment by phkahler

11 years ago

Sounded good until I saw this:

A faster Clasp compiler is coming soon – the current Clasp compiler generates slow native code that is about 100x slower than highly tuned Common Lisp compilers like Steel Bank Common Lisp.

No mention of the expected speedup, but 100x is a huge performance problem.

26 comments

phkahler

Reply
drmeister  11 years ago

The reason is that Clasp doesn't do Lisp language level optimizations like escape analysis yet. All bindings are stored on the heap and the stack/registers are underutilized. LLVM is a great library for implementing C and C++ but more work needs to be done to support Lisp features like closures and first-class functions. We are working on that now. The goal was first to "make it correct" and now we will "make it fast". Once we have a faster compiler (give us a couple of months) I don't see why it couldn't approach the speed of SBCL (a tall order).

  • phkahler  11 years ago

    Glad to hear it. I've been wondering when new languages would be developed on top of LLVM and it's starting to happen (Julia, now this). C++ is getting a lot of more advanced features, but the syntax is so clunky compared to something like Python for example. I also like the notion of easy C++ library use for things like QT.

krig  11 years ago

Considering that SBCL is among the fastest programming language implementations there is, 100x is actually not terrible for a first version.

  • sigil  11 years ago

    > Considering that SBCL is among the fastest programming language implementations there is...

    Source for this? I'd love to find a really fast lisp or scheme. Hadn't heard SBCL was particularly fast, and the alioth benchmarks don't show anything special there.

    http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

    Edit: actually SBCL stacks up alright against languages like Go or Rust in the alioth benchmarks, so maybe that's what you had in mind.

    • krig  11 years ago

      I'd say those numbers you link to are pretty amazing for a garbage collected language. Compared to Java, SBCL is roughly on par, with some benchmarks 2-3x slower and some 2-3x faster.

      edit: To clarify, I'm not saying SBCL makes Common Lisp the fastest language (I don't even think that's a meaningful statement). But to be within 2-3x of the JVM or C (and even outperforming C in some scenarios) certainly puts SBCL among the fastest language implementations. All the other ones you mention (C, C++, Go, Java..) are indeed also among the fastest. :)

      1 reply →

aidenn0  11 years ago

I'm not too worried, since a) that makes it about as fast as cpython and b) there is a lot of low-hanging fruit. There is work being done on integrating the Cleavir compiler which does a number of tricks. In particular escape analysis and lambda lifting should both help a lot on certain types of code.

eudox  11 years ago

http://log.irc.tymoon.eu/freenode/lisp?around=2014-09-25T18:...

Essentially, LLVM does tons of low-level optimizations but Clasp does few high-level, CL-specific ones. SBCL, on the other hand, mostly does CL-level optimizations and few low-level ones.

  • drmeister  11 years ago

    Yes, LLVM is awesome. Clasp uses the inlining LLVM provides to inline C++ code within Common Lisp code by generating LLVM-IR bitcode files from C++ source and linking them with Clasp generated bitcode files and then running them through LLVM module and function optimization passes. I'm really excited about combining the CL specific optimizations with the ones that LLVM provides - stay tuned.