Odd 1.6.5 microbenchmarks

While working on another issue, I get these results
https://gist.github.com/1346345 in which it appears the JRuby
1.6.5/Oracle Java (client mode) 1.7.0_01 combo is slower than JRuby
1.6.3/1.6.0_26 when doing (3) reads on a 500,000 LF delimited test file.

On Win7 I see 6.24s (user+system) vs 2.025s when doing binary reads, and
7.769s vs. 3.102s when doing text reads.

Results also provided for JRuby 1.6.5/1.7.0_01 on Arch Linux running in
a VirtualBox VM on Win7. The results are similar to the Windows results.
Sadly I did not run JRuby 1.6.3/1.6.0_26 on Arch back in July.

I’m focused on the other issue, but am interested in what others are
seeing with the JRuby 1.6.5/1.7.0_01 combination as well as whether the
microbenchmarks are flawed for what they’re trying to measure.

Jon


http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

(2011/11/08 7:26), Jon wrote:

running in a VirtualBox VM on Win7. The results are similar to the
Windows results. Sadly I did not run JRuby 1.6.3/1.6.0_26 on Arch
back in July.

I’m focused on the other issue, but am interested in what others
are seeing with the JRuby 1.6.5/1.7.0_01 combination as well as
whether the microbenchmarks are flawed for what they’re trying to
measure.

Try -Xinvokedynamic.invocation.switchpoint=false for Java SE 7GA or
7u1. I heard from Charles that there’s a known degradation about
method invocation optimization. ‘Degradation in GA’ may sound funny
though :slight_smile:

Here’s my result with/without switchpoint.
https://docs.google.com/spreadsheet/ccc?key=0AiZsKd8d4hSJdGl3ajhSR1FYeGtBWGs5YVQ5cW4yR3c#gid=0

// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)

iQEcBAEBAgAGBQJOuGPMAAoJEC7N6P3yLbI24KAIAKNOnVW+4wXb2fjFf0W4LtXB
GTCpSWbJFG/9fk7PzILrRoEE4L+KhcjS4+GZX29nejFDBjQpzTuPaNiQSx2UXqDE
7KYcxaHXaVSQppe7f0OfFymD2dRcGonAzKsNY530k1O302mI6dD2UABNB2maMYCx
5m1Amn0w991PfqouuH9QC7wLnUsDEiad5m6GsnySTxerOJyGAWnCbrubpNUtVLCK
hcjgXtgpsgqBLHdc6Vl8yYyO610ADuSC3PwgAviLYVUl5uvZRqvKdlEj7ccLrNYF
1DzfyCADgo1lGCQoSGjBCy4Rtuc6fZrQVfYmWsooijKykGp1obiQmgWfserG1eM=
=yH7h
-----END PGP SIGNATURE-----

On Mon, Nov 7, 2011 at 10:26 PM, Jon [email protected] wrote:

While working on another issue, I get these results
https://gist.github.com/1346345 in which it appears the JRuby 1.6.5/Oracle Java
(client mode) 1.7.0_01 combo is slower than JRuby 1.6.3/1.6.0_26 when doing (3)
reads on a 500,000 LF delimited test file.

On Win7 I see 6.24s (user+system) vs 2.025s when doing binary reads, and 7.769s
vs. 3.102s when doing text reads.

Results also provided for JRuby 1.6.5/1.7.0_01 on Arch Linux running in a
VirtualBox VM on Win7. The results are similar to the Windows results. Sadly I did
not run JRuby 1.6.3/1.6.0_26 on Arch back in July.

I’m focused on the other issue, but am interested in what others are seeing with
the JRuby 1.6.5/1.7.0_01 combination as well as whether the microbenchmarks are
flawed for what they’re trying to measure.

Hmm, that’s an interesting finding. I would normally be more inclined
to suspect a regression in JRuby rather than in the JDK. Are you able
to run 1.6.3 on Java 1.7.0_01? (your results only seem to show JRuby
1.6.5 on Java 1.7.0_01).

If it also happens with JRuby 1.6.3, then we could look into what
might have regressed in the JDK itself to slow down IO. If it’s JRuby,
we can look there.

WRT Nahi’s suggestion about invokedynamic…that doesn’t come into
play here JRuby 1.6.x does not use invokedynamic at all. You aren’t
running JRuby master/1.7, right?

  • Charlie

to run 1.6.3 on Java 1.7.0_01? (your results only seem to show JRuby
1.6.5 on Java 1.7.0_01).

If it also happens with JRuby 1.6.3, then we could look into what
might have regressed in the JDK itself to slow down IO. If it’s JRuby,
we can look there.

I’ll swing back, install 1.6.3 and update the gist.

Updates at https://gist.github.com/1346345#file_results_1.txt and it
appears to be a 1.6.5 perf regression as 1.6.3 (Win7) on 1.7.0_01
appears similar (maybe a scooch faster?) to 1.6.3 on 1.6.0_26.

Will look later with JRuby master and Arch.

Jon


Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

to run 1.6.3 on Java 1.7.0_01? (your results only seem to show JRuby
1.6.5 on Java 1.7.0_01).

If it also happens with JRuby 1.6.3, then we could look into what
might have regressed in the JDK itself to slow down IO. If it’s JRuby,
we can look there.

I’ll swing back, install 1.6.3 and update the gist.

WRT Nahi’s suggestion about invokedynamic…that doesn’t come into
play here JRuby 1.6.x does not use invokedynamic at all. You aren’t
running JRuby master/1.7, right?

I’ll build JRuby master on Windows and post thost results too. Assuming
I have ant and javac on PATH, its rvm install jruby-head on Linux,
right?

Jon


Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

Excellent! I prefer for such things to be our fault, since we can fix
them
:slight_smile:

Please file a bug, and if you really want to help you could bisect
revisions between 1.6.3 and 1.6.5 to locate the problem revision. Thank
you!

  • Charlie (mobile)

http://jira.codehaus.org/browse/JRUBY-6201

https://gist.github.com/1346345 in which it appears the JRuby

I’m focused on the other issue, but am interested in what others are
we can look there.
Jon

Jon


Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs