On Tuesday, April 26, 2016 at 12:23:48 AM UTC-5, Mars0i wrote: > > On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote: >> >> I was going to say that I'd be surprised if Clojure were as fast as SBCL >> (overall, on average, depends on your application, depends on how you code >> it, ymmv, etc. ...). Then I stopped back to check the little benchmarks on >> the Computer Language Benchmarks Game >> <https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=clojure&lang2=sbcl> >> >> . Whatever it is that those comparisons do, or don't prove, I would no >> longer be surprised. >> > > I forgot how much faster Clojure got in 1.7 and 1.8. I remember Java > wiping the floor with Clojure on most of those benchmarks a couple of years > ago, but now it's just a little bit faster on average > <https://benchmarksgame.alioth.debian.org/u64q/clojure.html> on those > benchmarks. >
I rewrote most of the Alioth programs back in the Clojure 1.6 timeframe to get them in the ballpark of the Java programs. I have timing comparisons across 1.6/1.7/1.8 somewhere but the differences are slight (and not all improvements) - really the subsequent Clojure versions had little effect on the program timings because of the kind of programs they are. Almost all of the Alioth programs are dominated by tight primitive math loops - the bytecode produced by those programs is very similar to the output from Java (or Scala for that matter) and thus there's little advantage left to gain. Most of the perf differences between the Java/Scala and Clojure versions are attributable to Clojure startup time overhead. As the total program timings are mostly in the 5-10 second range, a half second of additional startup time is a big factor, percentage-wise. When I've tested lazy var prototypes, that definitely helps a bit in reducing this overhead. Regarding the idiomatic-ness of these programs, I think it's a fair point that fast primitive math loops do not fit well with the typical sequence (or even transducer) model of data manipulation due to boxing. Rich has done some design work on supporting primitive (long/double) transformation functions and eventually (not 1.9) that will probably surface in the language. When it does, things like primitive vectors will become far more useful than they currently are. I think the compensating factors are that 1) 99% of most typical (your "typical" may vary) programs is not this kind of code 2) it is possible to write most Java primitive/array code in Clojure loop/recurs and see similar performance to Java 3) you can always simply write that hot loop in Java or invoke a native lib when that is necessary -- 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/d/optout.
