Rich, I must apologize-- I worded my question *far* too harshly. I knew it as I pushed the send button. I am a huge fan of Clojure, and plan to use it as often as possible. My question was really looking for hints, so that I can use it in more places. You gave me a great one, thanks!
Is there any way to avoid the overhead of dynamic lookups in Clojure? Can I tell the compiler somehow that the types of each argument is constant, and/or that a symbol will always resolve to the same place. I am assuming, and perhaps I am wrong, that dynamic behavior is a significant overhead. P Rich Hickey wrote: > 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 -~----------~----~----~----~------~----~------~--~---
