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

Reply via email to