Why is Clojure slower than Java? And, can it be fixed? Is it just the dynamic lookups?
I also want to use Clojure in my work to implement the inner loops, but I was disappointed by a previous discussion looking at the speed of Clojure. As I recall Clojure seems to be about 1/4 the speed of Java at the moment. Until we regularly have 10's of processors, it seems hard to justify that kind of hit for code that has to be fast. So, I use Clojure for scripting and high level code currently. Peter P.S. I also find that C++ and Java are now approximately the same speed. And if exceptions are enabled, Java blows C++ out of the water. cliffc wrote: > Some comments: > > 1- If you think that HotSpot/Java is slower than C++ by any > interesting amount, I'd love to see the test case. Being the > architect of HotSpot "-server" I've a keen interest in where > performance isn't on par with C. Except for a handful of specialized > uses (e.g. high-level interpreters using gnu label vars), I've only > ever seen equivalent code between C/C++ & Java (not so w/asm+C where > the asm calls out specialized ops or makes specialized optimizations). > > 2- As already mentioned, there's no auto-parallelization tools Out > There that are ready for prime-time. (there ARE tools out there that > can *help* parallelize an algorithm but you need annotations, etc to > make them work) > > 3- Making your algorithm parallel is worth an N-times speedup, where N > is limited by the algorithm & available CPUs. Since you can get huge > CPU counts these days, if you can parallelize your algorithm you'll > surely win over almost any other hacking. If you take a 50% slowdown > in the hacking but get to run well on a 4-way box, then your 2x > ahead. I'd love to say that the JVM "will just do it", but hand- > hacking for parallelism is the current state-of-the-art. > > 4- Java/Clojure makes some of this much easier than in C/C++. Having > a memory model is a HUGE help in writing parallel code, as is the Java > concurrency libs, or the above-mentioned Colt libraries. > > 5- The debian shootout results generally badly mis-represent Java. > Most of them have runtimes that are too small (<10sec) to show off the > JIT, and generally don't use any of the features which commonly appear > in large Java programs (heavy use of virtuals, deep class hierarchies, > etc) for which the JIT does a lot of optimization. I give a public > talk on the dangers of microbenchmarks and all the harnesses I've > looked at in the shootout fail basic sanity checks. Example: the > fannkuch benchmark runs 5 secs in Java, somewhat faster in C++. Why > does anybody care about a program which runs 5sec? (there's other > worse problems: e.g. the C++ code gets explicit constant array sizes > hand-optimized via templates; the equivalent Java optimization isn't > done but is trivial (declare 'n' as a *final* static var) and doing so > greatly speeds up Java, etc). > > 6- If you need a zillion integer (not FP) parallel Java cycles, look > at an Azul box. Azul's got more integer cycles in a flat shared- > memory config than anybody else by a long shot. > > Cliff > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
