Oh, and this is all stats for our language, Magik, running a single application, but most of the code is core to many other apps so the results should hold true.
On 21/12/2012 17:40, "MacGregor, Duncan (GE Energy Management)" <[email protected]> wrote: >That's okay, I've implemented the instrumentation and produced some stats >now. :-) > >On average the oldest targets are called significantly more frequently >than later ones, with the average chain position remaining below 1.5 (0 >being the oldest target) up to our standard maximum gwt chain length. > >I then significantly increased the maximum length of our chains un to 20, >and the average chain position remains below 3 up to a chain length of 15, >and only starts going significantly above 3 when we hit a length of 18. >Increasing the chain length to 50 (!) showed that even then the average >chain position was approximately 16, so there's still a fairly strong bias >towards older targets. > >These figures almost certainly do not cover the bootstrap process as I had >to reset the counts as part of call site invalidation, so some bootstrap >processes will have wiped out the earliest stats. > >This suggests that in our case it would be well worth ensuring the oldest >target is always first in the chain, and that chain may be worth keeping >in place even once we've passed our the limit for inlining further >targets. > >It is worth noting that this is all based on a very basic initial cut of >the stats. I'd need to output the raw data and do some number crunching to >check variances etc. on the individual call sites. > >On 21/12/2012 15:37, "Remi Forax" <[email protected]> wrote: > >>On 12/21/2012 04:07 PM, MacGregor, Duncan (GE Energy Management) wrote: >>> Did you ever get a result from this? I haven't got round to >>> instrumentation for our gwt chains that finely, but I'm curious what >>> results you got. >> >>It's still on my TODO list, Java lambda stuff claim most of my time >>devoted to OpenJDK ... >> >>Rémi >> >>> >>> On 30/11/2012 08:12, "Remi Forax" <[email protected]> wrote: >>> >>>> There is a nice article about the JIT that Facebook uses in his HipHop >>>>VM. >>>> >>>>https://www.facebook.com/notes/facebook-engineering/speeding-up-php-bas >>>>e >>>>d- >>>> development-with-hiphop-vm/10151170460698920 >>>> >>>> They have an inline cache with several guards and they found that it >>>>was >>>> better from the perf point of view to link the guard by putting the >>>> older first instead of putting the newer first. I wonder if there is >>>>the >>>> same effect for other languages, I will test with Java + a dedicated >>>> indy logic with week end. >>>> >>>> Rémi >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>>Groups >>>> "JVM Languages" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/jvm-languages?hl=en. >>>> >> >>-- >>You received this message because you are subscribed to the Google Groups >>"JVM Languages" group. >>To post to this group, send email to [email protected]. >>To unsubscribe from this group, send email to >>[email protected]. >>For more options, visit this group at >>http://groups.google.com/group/jvm-languages?hl=en. >> > >-- >You received this message because you are subscribed to the Google Groups >"JVM Languages" group. >To post to this group, send email to [email protected]. >To unsubscribe from this group, send email to >[email protected]. >For more options, visit this group at >http://groups.google.com/group/jvm-languages?hl=en. > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
