Interesting. On Groovy's side, doing this doesn't change anything, I get more or less the same results.
Anyhow, the problem of all those micro-benchmarks is that you need to know the various languages well to give an accurate comparison (ie not apples and oranges). But not focusing on the comparison per se (which is always great for FUD, inflamatory emails, and usual pissing games) and seeing where our implementation is lacking is more interesting. On Tue, May 25, 2010 at 13:08, Charles Oliver Nutter <[email protected]> wrote: > It's probably also worth mentioning that because of how Float objects > work in Ruby, every float in the body of the loop (and even in the > conditional) are created new each time they're encountered. That would > probably be a simple way to reduce the overhead of this benchmark and > put it probably where Groovy is. > > On Tue, May 25, 2010 at 6:06 AM, Charles Oliver Nutter > <[email protected]> wrote: >> I profiled the benchmark in JRuby, running with --fast (for all >> optimizations in JRuby), and found some interesting things: >> >> * Doing a sampling profile, these two methods gathered the most >> samples; JRuby itself barely registered. >> >> Stub + native Method >> 54.8% 0 + 2633 java.lang.StrictMath.pow >> 40.3% 0 + 1934 java.lang.StrictMath.exp >> >> * A memory profile shows allocations almost completely dominated by >> RubyFloat instances: >> percent live alloc'ed stack class >> rank self accum bytes objs bytes objs trace name >> 1 90.41% 90.41% 24433056 763533 235295808 7352994 301908 >> org.jruby.RubyFloat >> >> Using this measurement, you can see that RubyFloat instances are 32 >> bytes large for JRuby (64-bit double + 32-bit flags + 32-bit reference >> to metaclass + the object itself). Reducing the number of RubyFloat >> objects would probably do the most to improve this benchmark (or >> getting the JVM to do a better job of eliminating those objects; >> DoEscapeAnalysis doesn't appear to help this benchmark at all). >> >> Reducing the size of RubyFloat objects would also help. A normal >> java.lang.Double would be 8 bytes smaller (no flags or metaclass). So >> this benchmark appears to either bottleneck on the Math methods (seems >> a bit unlikely) or on RubyFloat allocations (more likely). Optimizing >> to lift RubyFloat objects to actual double primitives wouldn't be >> hard...we just haven't done it yet. >> >> It would certainly be nice if the JVM eliminate those RubyFloat >> objects, since it appears that almost everything here inlines. Perhaps >> there's something missing that would allow escape analysis to >> eliminate the objects? >> >> - Charlie >> >> On Tue, May 25, 2010 at 4:29 AM, Rémi Forax <[email protected]> wrote: >>> It's not FUD. >>> I was not aware (I think I am not the only one) that groovy default for real >>> number is BigDecimal. >>> >>> Rémi >>> >>> Le 25/05/2010 08:44, Guillaume Laforge a écrit : >>>> >>>> The article is great and interesting... >>>> >>>> But I'll react on the FUD aspect :-) >>>> (otherwise, it *is* really interesting minus the apple/orange comparison >>>> part) >>>> >>>> But your Groovy sample is really not reflecting reality, and makes >>>> apples and oranges comparisons. >>>> By default Groovy uses BigDecimal for it's decimal numbers, which >>>> means you're doing a mix of double and BigD arithmetics, which slows >>>> down Groovy terribly, compared to the other languages which use >>>> doubles by default. >>>> So this is a bit misleading. >>>> Add a 'd' suffix to the numbers, and you'll have a more fair >>>> comparison! (ie. 3.4d, 4d, etc) >>>> >>>> Guillaume >>>> >>>> On Tue, May 25, 2010 at 02:29, Rémi Forax<[email protected]> wrote: >>>> >>>>> >>>>> Hum, nobody answer ? >>>>> >>>>> I have written a blog with a small benchmark that can be instructive: >>>>> >>>>> http://weblogs.java.net/blog/forax/archive/2010/05/24/jvm-language-developpers-your-house-burning >>>>> >>>>> Rémi >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "JVM Languages" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/jvm-languages?hl=en. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "JVM Languages" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/jvm-languages?hl=en. >>> >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
