Call me an optimist, but I’m hopeful that this can do to progressive C++ shops what Clojure did to progressive Java shops. Lots of opportunities for a Lisp to be useful there, and C++ programmers won’t be philosophically opposed to using a huge/complex language.
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.
Let’s hope that a higher performance version will indeed be coming soon :-)
The project direction looks like it will be high performing eventually, as opposed to something like Racket which doesn’t have any plans to be natively compiled and isn’t terribly concerned with being blazing fast. Building on LLVM is a big hint that Clasp is going the opposite direction. That being said, I love Racket! <3
Also, SBCL was what I was thinking of when I said old as hell. ;)
gives me a stack trace I dont understand. The jar does run for me, but still references greet.lisp from the local filesystem, isn’t pulling it as a resource.
Hopefully comments like yours don’t become the norm here.
He’s aware that he needs to do more analysis at the higher levels in his compiler before generating the LLVM IR. Do you have something new to add or that points to a specific issue that he’s going to have that is insurmountable?
LLVM is improving constantly. Look at all of the work by Azul to improve the GC support for example, or the work by Apple to add patch points for doing things like PICs.
We have a prototype LLVM-based backend for Open Dylan and it is doing pretty well so far. (We perform a lot of Dylan-level optimizations prior to generating LLVM IR, much like SBCL does for Common Lisp.)
Edit: And apart from the actual and factual issues with your comment, it was pretty rude and disrespectful of his months / years of work on this project and the actual results that he’s getting.
LLVM has also become a dramatically better foundation on which to build a JIT since that comment was written 3 years ago, and it’s only getting better all the time.
Call me an optimist, but I’m hopeful that this can do to progressive C++ shops what Clojure did to progressive Java shops. Lots of opportunities for a Lisp to be useful there, and C++ programmers won’t be philosophically opposed to using a huge/complex language.
A high performing Lisp that isn’t on the JVM and isn’t old as hell? /me drools
Let’s hope that a higher performance version will indeed be coming soon :-)
The project direction looks like it will be high performing eventually, as opposed to something like Racket which doesn’t have any plans to be natively compiled and isn’t terribly concerned with being blazing fast. Building on LLVM is a big hint that Clasp is going the opposite direction. That being said, I love Racket! <3
Also, SBCL was what I was thinking of when I said old as hell. ;)
What about ABCL and RoboVM?
I don’t know CL or even ABCL but I made a little progress. I followed this blog post on standalone ABCL jars.
But changed
Compile with
robovm -forcelinkclasses org.armedbear.lisp.* -verbose -jar greet.jargives me a stack trace I dont understand. The jar does run for me, but still references greet.lisp from the local filesystem, isn’t pulling it as a resource.
https://gist.github.com/anonymous/5d3a41fac14bd749b44e
It looks like ABCL calls
which RoboVM doesn’t like
https://github.com/robovm/robovm/blob/89c55499db665b8ad6db38e68b893b13c9160db0/rt/libcore/libdvm/src/main/java/java/lang/ClassLoader.java#L242-L244
Rather than load a
.lispfile, one could precompile to .cls[Comment removed by author]
Hopefully comments like yours don’t become the norm here.
He’s aware that he needs to do more analysis at the higher levels in his compiler before generating the LLVM IR. Do you have something new to add or that points to a specific issue that he’s going to have that is insurmountable?
LLVM is improving constantly. Look at all of the work by Azul to improve the GC support for example, or the work by Apple to add patch points for doing things like PICs.
We have a prototype LLVM-based backend for Open Dylan and it is doing pretty well so far. (We perform a lot of Dylan-level optimizations prior to generating LLVM IR, much like SBCL does for Common Lisp.)
Edit: And apart from the actual and factual issues with your comment, it was pretty rude and disrespectful of his months / years of work on this project and the actual results that he’s getting.
I’d further note that without projects like this, the JIT is unlikely to improve.
LLVM has also become a dramatically better foundation on which to build a JIT since that comment was written 3 years ago, and it’s only getting better all the time.