I you attempt to mimic Java or C in some narrow linear
compute bound algorithm, I agree that the resulting code is quite ugly, not 
idiomatic
on top of having performance issues.

Lucky for us not all the problems are bounded like this.

I have been following this thread from the beginning and I cannot understand
why people are hammering at performance issues we were tackling using 
machine code directly in the 80s or by carefully inspecting compiler generated
code (by Fortran, C, ...) to avoid costly instructions. We would thunk down
to machine code when required.

There are no wins on all fronts at the same time. We are happy here to get
wall clock performance boosts without added complexity
because the nature of our business domain allows us to parallelize processing.

Why insist on getting Clojure to be at par with languages that may offer a 
performance
boost on narrow problems at the expense of making parallel processing and code
in general more complex everywhere else ?

I do not say that these benchmarks are futile, write idiomatic code, use 
available 
optimizations (type hints and cie) and start the baseline from there to improve 
the
compiler.

Improvements to the compiler will benefit everyone. Improvements to reach
similar perf levels with these benchmarks by twisting the code are pretty 
narrow goals
and not many can benefit from it.

100% cpu usage in the whole lifetime of your app ?
Without db or file persistence ? Without network I/O s ? All of which induce 
latencies ?

It's similar to me to weater simulations. These days they have enough data to
predict weather with a great accuracy... three days after the fact.
Why ? They have a compute bound problem that they cannot address other than 
sequentialy in some critical steps and too much data to process if they want to 
improve
the accuracy of their simulations.

Using Clojure in these critical steps would be futile until new parallel 
algorithms
appear. Parallel algorithms to some of their performance problems do not exist
yet. The maths to do so have not been invented yet. Oups...

If anyone uses these benchmarks as their main criteria to choose a language
without considering first their problem domain, well they need to get their 
brain fixed.

I considered my domain problem before embracing Clojure and pushed back the 
performance issues later because I knew I could always cheat with parallel 
processing
and lower the source code burden by getting more expressivenes.

The gains are in the sum of all parts not in a single narrowly defined one.


Luc P.

> I see; didn't notice that one. Again, only the fastest entries are shown. 
> It appears that the same is the case with Marceau's graphs; he just didn't 
> state that explicitly.
> 
> Things don't look very rosy for Clojure: it turns out to be about as 
> verbose as Java and significantly slower (this confirms my experience; 
> slightly slower than *regular* Java code, significantly slower than highly 
> optimized Java). If idiomatic Clojure was used, it would move it to the 
> left and upwards; Clojure would hang out with JRuby.
> 
> Anyway, it would be really great to see such a comparison chart, but only 
> with idiomatic code involved. This way I don't have a clue what to make of 
> Haskell, for example.
> 
> 
> On Tuesday, February 26, 2013 6:30:55 PM UTC+1, Ben Mabey wrote:
> >
> >  As Issac pointed out, here are some very recent graphs (including 
> > Clojure):
> >
> > http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
> >
> > On 2/26/13 2:35 AM, Marko Topolnik wrote:
> >  
> > This is a great analysis, thanks for the link; shame it's so old.
> >
> > On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote: 
> >>
> >>  
> >>  Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely 
> >> tuned submissions.  That would allow you to get some sort of an idea how 
> >> performant the dominant idiom is.  Along those lines this older post did 
> >> an 
> >> interesting analysis on the benchmark solutions where it explored the 
> >> tension that exists between expressiveness and performance across the 
> >> various languages:
> >>
> >> http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html
> >>
> >>
> >>
> >>  -- 
> > -- 
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com <javascript:>
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com <javascript:>
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > --- 
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+u...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >  
> >  
> >
> >
> >  
> 
> -- 
> -- 
> 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
> Note that posts from new members are moderated - please be patient with your 
> first post.
> 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
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
--
Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!

-- 
-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to