On 04/30/2011 11:13 PM, Charles Oliver Nutter wrote: > Well it seems like the GWT-based PIC could be a *great* success, at > least compared to falling back on a single-entry IC. I will shortly > commit another patch to JRuby master that provides a configurable GWT > chain size before giving up and going to a simple IC, and the results > are spectacular. > > First, recall that my little bimorphic bench took 9s to run when > constantly rebinding. GWT construction is expensive, CallSite > rebinding is expensive...we've clearly established that. > > JRuby with an immediate failover to a simple IC performs roughly like > JRuby, with each million-cycle iteration taking about 0.13s, a massive > improvement over rebinding. No real surprise there, since it's > essentially just giving up and doing the same thing as JRuby's > CachingCallSite. > > Now for the surprise. With a 2-deep GWT chain simulating a PIC, the > bimorphic benchmark performs almost *identically* to one that's > monomorphic. The iterations take roughly 0.054s when monomorphic and > 0.056s when bimorphic.
I remember seeing a patch from John to group a cascade of typechecks on the same object into one check. > If it goes trimorphic, the hard failure kicks > in and it drops back to IC performance again. > > Naturally I'm quite pleased by this result. > > For those of you following along at home, the commit is 9890000 and > the property to configure is jruby.invokedynamic.maxfail, which should > equal the number of GWT it will attempt to chain before failing over > to simple IC. > > Awesome stuff. Also, instead of using IC has a fallback, you can use a hashmap to handle megamorphic calls that are not mega-megamorphic. > - Charlie cheers, Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
