Of course it is faster than Java in some specific micro benchmark. That's what micro benchmarks are for!
Now try building something really big on SBCL that takes advantage of that quad core box. Huh. What do you mean half the Common Lisp libraries are not thread safe? :-)
Threads are not the only mechanism for parallelizing your code. You could just start 4 processes (which I actually recommended against here yesterday ;), or you can use something like STM. SBCL has an STM library:
The only reason for recommending spawning processes is if you live in a non-threaded environment like Python, Ruby, Perl or Common Lisp. In a C/C++/Java world it is the normal thing to do and it generally makes communication between those threaded tasks 10x simpler.
Don't get me wrong, I love languages like Python or Ruby and I hack stuff with it daily. I would just never do high performance stuff with them.
It's my observation that the 'threads are evil' mantra only seems to be sung by people who have never really experienced working with a really thread safe environment. It's like being stuck in the early Linux/BSD days.
We live in the multi-core era. Today 8 cores are not unusual, many-more-cores are coming. I seriously think that we're going to see some fallout with regards to programming environments that can't keep up.
I find that the results of the GCLS are so specialcased and gamed and compiler-optimized at this point that they basically don't reflect anything even remotely near reality.
For example, Ocaml still seems to be the language I can go to for the best performance with high level code. C++ still seems to be somewhat slower.
It's one thing to implement an ackerman function in C++ and another entirely to make a real working application.
I see your point but would argue the foundations of a language should be simple enough to test in a fashion like this. Perhaps this particular test isn't good because numbers are skewed from optimizations that don't reflect the languages abilities. A full application will have many, probably more, design decisions made that aren't necessarily a reflection of the language too.
How can "C++ still seems to be slower" if C (or C++) is essentially a macro-assembler, i.e. you're free to hand-optimize any particular bottleneck.
Every time I hear someone say (or show a benchmark) where "C++ is slower than C" it always comes down to some STL usage instead of flat arrays or something (which is still valid C++)
Sure, but the whole point of using a higher level language is to use some of those higher level features. It seems somewhat... unfair to argue that C++ "can be fast" so long as you basically restrict it to its C subsets.
I want the code to be both high level and fast. A language is of no use to me as a performance target if in order to get performance with it you have to use a tony subset of it.
Sure, every language has fast and slow ways of doing things
It's a tiny bit dishonest... SBCL is faster than Java 1.4, but slower than Java 1.6. (And using the logic used for comparing OCaml, it's as fast as Java 1.4).
Now try building something really big on SBCL that takes advantage of that quad core box. Huh. What do you mean half the Common Lisp libraries are not thread safe? :-)