On Sep 15, 2012, at 3:15 PM, Charles Oliver Nutter wrote:
> Things like this worry me a bit too, but there's only a couple of them :)
We need to find out why these guys deoptimize. Either add
-XX:+TraceDeoptimization or -XX:+LogCompilation (for the latter the output is
then in hotspot.log).
After reading Charles' blog on 'fast' ruby I decided to look at how Rtalk
was
comparing. At the same time I loaded the latest JDK8 just to compare.
First jdk 8 runs (excellent) with some things faster but most slower. But
to
my chagrin Rtalk running FIB(35) is much slower than Charles' effort.
Your output is a little hard to parse, but I think I followed it.
First off, it is currently expected that jdk8 is not optimizing as
well as the jdk7 indy logic. I have seen very few benchmarks that are
faster, and my reading of the inlining logs tells me it's just not
inlining everything the jdk7
Oh, and to reiterate the point about jdk8...
On JRuby fib, it's around 0.44s for fib(35) versus jdk7's 0.33 and
fastruby's 0.19. So that's easily 2x slower, which isn't far off from
what you're seeing..right?
- Charlie
On Mon, Sep 17, 2012 at 7:57 PM, Charles Oliver Nutter
wrote:
> Your output
An aside...can you post your RTALK and Java Hanoi impls? I'm always
looking for another benchmark to add to my suite.
- Charlie
On Mon, Sep 17, 2012 at 8:00 PM, Charles Oliver Nutter
wrote:
> Oh, and to reiterate the point about jdk8...
>
> On JRuby fib, it's around 0.44s for fib(35) versus jdk7
On JRuby fib, it's around 0.44s for fib(35) versus jdk7's 0.33 and
fastruby's 0.19. So that's easily 2x slower, which isn't far off
from
what you're seeing..right?
So for Rtalk ( Hanoi which is the one I have all three for) its
294/629/754 java Static/ JDK7 / JDK
An aside...can you post your RTALK and Java Hanoi impls? I'm
always
looking for another benchmark to add to my suite.
Not much but here, in order, would be Hanoi in Smalltalk, several integer
types of Java and the
version is java which matches the Rtalk implementation not using
>From Charles
then could it simply be that your
indy guard logic and arbitrary precision logic adding all that
overhead? It seems like a lot indeed.
I had not thought about this in a while so perhaps my call site handling
is an issue. I went
for simple in that I use a var
