SBCL is really amazing. Even though it's "bog standard" 1970's and 1980's technology, it still puts up a great showing against state of the art compilers: http://benchmarksgame.alioth.debian.org/u64/lisp.php.
It's also a great example of the power of macros. If you look at the backend, things like define-vop and the like, it does a lot of things using macros that e.g. LLVM uses an external code generation tool (tblgen) to accomplish.
No offense, but I'm not sure that the Language Shootout is the best showcase, the SBCL code submitted there could hardly be called idiomatic Common Lisp. Mandelbrot is one of the most egrerious offenders in that regard [1], compare that with the Java submission [2] which is both cleaner and faster...
The links which you have given above, are for 2 different simulations - the SBCL one is computing the mandelbrot set, and the Java one is doing an n-body simulation.
That said, I agree with your point ... is seems to me pointless to effectively program in assembly in another language and then claim that the wraper language is faster/better ... given enough determination, you can do the same with most other languages and it proves nothing.
I find it interesting how particularly readable the Go code on there is compared to Lisp. And I'm not talking syntactical fluff, I'm talking semantics - the Lisp dances around doing macros, toggling compiler switches (including nonstandard ones that are specific to SBCL), redefining things... the Go just says "do this then do that". And its speed is roughly comparable.
Indeed, the Java code is readable to someone who's just picked up a Java book/tutorial, while that CL code is like an "obsfucated mandarind local dialect" to someone just starting to learn CL (even to someone pre-exposed to SICP Scheme or other lisp-family languages)! I think it's closer to someone writing Python code specifically tailored to the way PyPy does JIT or smth like that, but that wouldn't be idiomatic Python in a thousand years, or even "comprehensible by the average Python coder".
> the SBCL code submitted there could hardly be called idiomatic Common Lisp
That's the point of Common Lisp: It gives you enough rope. Some people use it to hang themselves, others use it to selectively optimize the parts that need it, still others use it to optimize the whole thing.
All languages have "layers/levels" at which one uses them. Isn't the whole point of a language shootout to compare "default levels", that is levels at which the "average programs" are written, and not the kilometers of rope stored in the levels below? (or is it really true that there isn't a "default level" for CL?)
I think you are right that there is no "default level" for CL. I find this an interesting point of programming language culture - what do people do when they want to optimize.
In Erlang the culture is to write your code in a straightforward way and you accept the performance you get. "Inner loop" code looks much like any code. It's a point of pride that you stick with the same style throughout and don't burn brain cycles looking for tricks.
In Common Lisp the culture is to write performance-critical inner loops in a very different way to other code. So although the code on the shootout page looks weird compared to most Common Lisp code, it does look like code that a Lisp programmer would write when they are in deep optimization mode.
Seriously asking, for this code example (I don't have enough CL experience to tell from this sample): are these optimizations at least generally CL specific, or are they tailored to SBCL specifically? would the same performance benefits apply to Clozure CL or to a bytecode compiled variant like CLISP?
I've been coding with SBCL and Common Lisp for years, and the general optimization strategy is great. With compiler hints (standard in Common Lisp), you can really help the optimizer, and locally vary the speed/safety trade-offs (eg. bound checking).
I don't think I would ever write something like the code linked above. Half of it is not standard Common Lisp, and not even part of SBCL's official extensions. At that level, you could write custom assembly, which kinda defeats the point of having a language shout-out IMO.
yeah, and the performance is still on par with the Java code, so whoever submitted that SBCL optimized code to be showed alongside the Java and Scala examples ended up proving how well engineered the JVM is, compared to state of the art CL compilers, or maybe how efficent JIT can be in general :) ...though I'd love to see an ABCL example for comparison
I get your point, but when the performance requirement is put on the table (hence a need for optimizations), in the first place I wouldn't choose Lisp.
Funny. Chance has it that I am right now working my way through "Practical Common Lisp" and rather enjoying Common Lisps bag of tricks. We'll see if I will dive deep enough to start hacking on the compiler itself. Once I go there, this post will be an awesome resource though.
I already read PCL and imho it's a really great book. In case, however, you have further questions (like I did) have a look at #lisp on irc.freenode.org - the guys there are really nice and helpful.
It's also a great example of the power of macros. If you look at the backend, things like define-vop and the like, it does a lot of things using macros that e.g. LLVM uses an external code generation tool (tblgen) to accomplish.