On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote: > Hello friends! After months on "vacation" from indy, I managed to > spend some time this weekend updating JRuby's indy support. But this > email is to ask about the inlining flag tweaks that still seem to be > required. > > First, the good news: using a fastdebug build of MLVM from Stephen B > (FYI, Stephen, your 1/11 build is fastdebug, not product), running > JRuby with invokedynamic enabled is better than 30% faster than simple > inline caching (measured on the same JVM with indy turned off). That's > excellent! This marks the first time there's been a clear improvement > over our usual execution mode! You're finally beating* JRuby by a > comfortable margin! :) > > The bad news is that I still had to tweak inlining flags way up. > Specifically, MaxInlineSize=150 and InlineSmallCode=2000 or higher > (stopped improving somewhere around 10000). > > Obviously we can't force people to set these flags when running JRuby > on Java 7, so I'm writing to get confirmation that this is still going > to get worked out. I'd not be surprised at all to hear things are > still being tuned and tweaked, and so adjusting inlining budgets at > this point would be premature. Just tell me so :)
We are currently not tweaking these knobs since we still have a couple of bugs to fix. But eventually we will get there. -- Christian > > Also, the bar has moved for beating JRuby performance when comparing > to our "dynopt" mode. Dynopt uses the most recently called method at > each interpreted call site to insert a guard plus direct static-typed > call in the emitted JRuby bytecode. That still performs around 2x > invokedynamic. HOWEVER...it's not really a fair test yet, since dynopt > also avoids using Fixnum objects in more cases and also inserts a > direct call for recursion. Those two combined with EA still being > active could make all the difference. > > I'll continue widening the use of indy and report back. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
