Alioth benchmarks are out of date as far as Clojure is concerned. These days it's not much work to get Clojure to deliver identical to Java performance. Better versions of the same benchmarks here that show the same performance as Java that you verify yourself - http://github.com/clojure/test.benchmark

>>out of date as far as Clojure is concerned<< What a pity that Clojure programs, written months ago to do benchmarks game tasks, have not been contributed to the benchmarks game for all to see!

All in good time Isaac :)

Let's hope the benchmarks game website is still being updated when that time arrives ;)

What are you two plotting?!

Programming language benchmark data.

"The Computer Language Benchmarks Game" has never been a valid benchmark for any language or implementation.

Why?

Among others: because of completely arbitrary and I'd dare to say weird rules. Programs are not meant to be written in idiomatic language. They are meant to resemble the C implementation. In many cases you can see that the program representing the language in the comparison is neither the fastest nor the simplest of the submissions.

You've made a bunch of claims without showing any evidence to support them. Please point to specific examples we can all look at on the website which show -- "Programs are not meant to be..." -- which show -- "They are meant to resemble the C implementation." etc

I'm not going to back up these claims in any other way than pointing the "interesting alternative" programs that appear in some comparisons, which tend to be faster than the chosen versions. For example here: http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa... Both Lisp and Java alternatives are faster than the "fastest" solution (written in Fortran). Finding any more support for the years-old opinion I voiced seems too much work to be worth it.

Yes, you can. Just one last mention: my opinion was formed in the times I used Perl and looked around the actual implementations of these. But that was years ago. It was reinforced quite recently by someone whining (probably on HN) about the same things. Apart from these anecdotes, I have no basis for these words.

> But that was years ago.

It's a sad nuisance when people opine without checking what's actually shown on a public website.

It's sad to see fact based comments being down voted on HN.

> It's a sad nuisance when people opine without checking what's actually shown on a public website.

Well, I could simply ignore the question. Or give the answer I got a few years ago, what I did...

> It's sad to see fact based comments being down voted on HN.

Fact based? More like facts querying. Which is the reason I upvoted every single of your comments...

> Which is the reason I upvoted every single of your comments.

And yet people have down voted.

"... we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result."

(Except for meteor-contest.)

I'm sure you wish to make a point -- please don't make everyone guess what you mean, just spell it out.

An algorithm that's idiomatic in one language might be terribly unidiomatic in another. (I'm sure you know this, but) Haskell's pervasive laziness makes some algorithms tractable while requiring a lot of space/time complexity for other algorithms.

The benchmarks game URL was posted by someone who has put a lot of energy into promoting Haskell - dons makes the best of the opportunity that the benchmarks game provides to promote Haskell.

>>pervasive laziness... requiring a lot of space/time complexity for other algorithms<<

And GHC provides strictness analysis and explicit strictness to avoid reducing performance.

http://www.haskell.org/haskellwiki/Performance/Strictness

>>I need some sort of shock collar to teach me not to argue about the worth of the Computer Language Benchmarks Game.<<

Do argue - but argue better.

Unfortunately, to argue better does require learning what the website says about the benchmarks game - and for most that's far too much effort.

Unfortunately the cost of developing this solution in C++ would be forbidding for us.

In our case on the pretty much same loop the difference between Ruby and Clojure was 20-30 times. Please note that using Clojure allowed us direct access to Java libraries, so essentially this is Java performance that we've been able to tap into using Clojure.

did you try doing the same using jruby?

Nope. Although JRuby is not very efficient in calling Java code, at least it's not as efficient as Clojure is from what I've read.

Another plus for Clojure is that it allows us to easily have a multi-threaded implementation. JRuby allows native threads too, but Clojure make concurrency really easy, while JRuby just wraps Java threads with nothing more, so I would have to use regular locking and stuff.