Good news, bad news

[Charles Oliver Nutter]

On Thu, May 26, 2011 at 3:42 AM, Christian Thalinger
<christian.thalinger at oracle.com> wrote:
> I also did some performance testing.  I used a recent HS repository, applied Tom's patch, used a recent meth.jar provided by John and this is what I got:

Somehow I stumbled past this reply...comments inline below.

> intelsdv07:~/mlvm/jruby$ bin/jruby.sh -J-Xbootclasspath/p:meth.jar --server -Xcompile.invokedynamic=false bench/bench_fib_recursive.rb 10 35
...
>  0.979000   0.000000   0.979000 (  0.979000)
>
> intelsdv07:~/mlvm/jruby$ bin/jruby.sh -J-Xbootclasspath/p:meth.jar --server -Xcompile.invokedynamic=false -Xcompile.dynopt=true bench/bench_fib_recursive.rb 10 35
...
>  0.762000   0.000000   0.762000 (  0.762000)
>
> intelsdv07:~/mlvm/jruby$ bin/jruby.sh -J-Xbootclasspath/p:meth.jar --server -Xcompile.invokedynamic=true bench/bench_fib_recursive.rb 10 35
...
>  0.920000   0.000000   0.920000 (  0.920000)
>
> Here are the numbers from April 28 on the same machine:
>
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002873.html
>
> Although I can't remember if the invokedynamic numbers were with or without the guard-removal-hack I tried at that time (I think without, because with the hack the numbers should be very similar to dynopt, see: http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002869.html).

My numbers from that time period (or slightly after, in macosx port)
match yours and were based only on code that got into MLVM patchset or
into OpenJDK mainline (via macosx port for me), so I don't think they
were with the hack.

Something definitely degraded between then and now, since *current*
JRuby logic is almost always faster on the old builds than on the new
ones. I'm not sure yet what it is, but the GWT optimization
"opportunity" was obviously part of the original degradation. There
are likely other niblets in there somewhere.

> Using Tom's new code doesn't make a difference since I think the meth.jar from John includes the reverted GWT code.

I'm rebuilding current MLVM now to run some new tests with the "real"
code from Tom, but it worries me that even the reverted GWT code shows
degradation compared to late April indy logic.

Perhaps Tom is right about the impact of removing your inlining
threshold increases? That is in my mind a strong candidate for
explaining why perf on these small benchmarks has degraded so much.

At the end of the day, I think it's reasonable to have dynopt perf as
an "ideal" goal for indy...so I'm proceeding from that point.

> A quick check on bench_string_ops.rb shows that a couple of numbers are better but some are worse, especially string == comparison (compare with http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002887.html):

I will have a look at these in more detail as time permits...

- Charlie