
SBCL is now faster than Java, as fast as Ocaml, and getting better - nickb
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/25fb220a1da975fb#
======
st3fan
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? :-)

~~~
jrockway
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:

<http://common-lisp.net/project/cl-stm/>

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

~~~
jrockway
_I seriously think that we're going to see some fallout with regards to
programming environments that can't keep up._

Probably not. People are creatures of habit and will continue doing whatever
they were doing before. That doesn't mean we need to care though.

But anyway, threads aren't the solution. They are way too low-level and too
easy to screw up. That's why I recommended STM previously.

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

~~~
tx
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++)

~~~
KirinDave
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

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

------
tx
Oh no! This post just taught me that Opera 9.5 still won't work with Google
Groups... Dammit.

