For those interested in numeric performance, Clojure lets you use arrays of primitives, has primitive math support, primitive local support, and has higher-level macros for dealing with them (amap, areduce) which can also serve as models for your own. You can also use :inline to wrap arithmetic primitives implemented as Java static methods, as Clojure itself does for +/* etc, which HotSpot inlines quite nicely.
If people are not exploring and using these things, and are concerned about performance not being the same as Java's, I can't help them. That's how you get numeric performance the same as Java's in Clojure. Cliff Click has already spoken about the performance of Java vs/ C++, and I concur. Where Clojure currently has an unavoidable overhead vs Java is Clojure- >Clojure calls involving numbers. Since the fn call/return signature is Object based, those numbers need to be boxed, at least until we get something like tagged numbers on the JVM. That means naive fib microbenchmarks suffer (boxing in a tight loop), but most real performance-critical numeric code is not like naive fib. Most of it is inner loops on vectors/matrices, or local iterative calculations involving primitives, which, if implemented using the above constructs, is as fast as Java. So, getting the fastest numerics means working with primitive types, and lower-level constructs. It's not something you'll want to do anywhere other than where it really matters. When you do, you'll find Clojure's macros let you write higher-level code than the for loops of Java. amap and areduce just hint at the possibilities of a high- performance, macro-based math library, and I expect similar macros to come from people actually doing number crunching with Clojure. Rich On Jan 13, 2:53 pm, Peter Wolf <opus...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
