The benchmark is a number crunching physics simulation, it calculates the motion of a few planets orbiting the sun.
I made two versions:
Timing them on my laptop with the Java program as the baseline, this benchmark says that
Clojure 1.2 is not released yet, so any benchmark is preliminary.
All in all, I’m very happy with the 1.2 numeric performance as of today. I’m also happy with the fact that there are far fewer hoops to jump through to get high-performance numerics than in 1.1.
I think Clojure 1.2 as of today supports the Lisp spirit: Implement quickly and/or prettily to the point where it works, and then optimize only the parts where the performance benefits are big enough to make it worthwhile.
There is work in progress on faster numerics for 1.2
These changes were not part of this test. My understanding is that this work will probably not increase the speed attainable by optimized code like the 1.2 benchmark code here, but it might speed up the 1.1 version or allow 1.1-level optimizations with less developer effort.
If you are interested in the details, check out
See the 1.1 call tree profile
(The wiki apparently does not allow me to inline images.)
agetfunction: It converts array indices to int by a cast even when they are numeric literals like ‘0’ and ‘1’, and there is no way to bypass that.
advancefunction into the
mainfunction, but timings got worse.
v_PLUS__BANG_are an artifact of
v+!while Java doesn’t
deftype, Clojure does automatic rewriting in one case but not in the other.
Timings were done on a MacBook Pro with the OS X default Java JVM using flags “-Xms256M -Xmx256M”, the same settings for both Clojure and Java.
The -server flag made little difference, so I left it out. Specifying a larger-than-default amount of memory does make a difference, ~10% in my case.
[pro ~]$ java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)