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.
