Did you know that SBCL is now faster than Java, as fast as Ocaml, and getting better?! What does this mean for you? Most likely, nothing.
They have various benchmarks that are used to measure the speed of a language implementation; and I think it’s a good thing – it keeps the implementers honest, and I’m not crazy about wasting CPU cycles just because they’re there.
However, these numbers remind me very strongly of the local CompuMart selling the 2.4GHz machine for 1.5x the price of the 2.0GHz machine and relying on the fact that customers have no idea that this will make exactly zero difference for most uses.
Why? Because pretty much all programs nowadays depend on more than just the CPU. They’re competing for RAM, disk access and maybe even network. None of those are nearly as fast as the CPU, hence most often create a bottleneck.
Aside from this, it’s very likely that the code you’re writing will be more dramatically improved by tweaking your algorithms than it would by changing the language.
Couple that with the unfortunate fact that most jobs won’t allow you to just grab SBCL or OCaml because it happens to be at the top of the list today, and you’re left with a measurement that has little real-world value.
What these measurements are good for is preventing those who write the language implementations from getting too lazy. While I think that application programmers should generally be spending CPU cycles to save lines of code, I don’t necessarily believe the same for platform/language programmers.
Just don’t look at this list and get too disheartened about your choice of language. Even if it is Ruby 😉