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

Reply via email to