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