> 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.
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.