http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #22 from Teresa Johnson <tejohnson at google dot com> 2013-01-11 18:18:48 UTC --- Hi Honza, I ran a number of experiments at different thresholds, and found that performance starts dropping pretty quickly as the working set threshold is dropped, even to 98.5% (2 working sets lower than the 99.9% threshold). This appears to be due to a reduction in key inlines. If I use your divide by 32 heuristic, the performance is recovered for most of the apps I looked at (with the 98.5% threshold), but is still reduced for others. When I looked at the ratio of the min counter values between the 98.28% bucket (selected when I use the 98.5% threshold) and the 99.9% bucket, I can see that the apps that still degrade with 98.5% + your divide by 32 heuristic are those with the largest ratio (100-300). For the apps that no longer degrade from the 98.5% thresholds when dividing by 32, the ratio is small and often less than 32 (so in effect the resulting min counter is even smaller than with the current 99.9% threshold). What threshold were you thinking of changing it to, based on your experiments? For the google branches, based on the data I collected, we plan to leave it at 99.9%. Thanks, Teresa On Sat, Dec 22, 2012 at 3:20 PM, hubicka at ucw dot cz <gcc-bugzi...@gcc.gnu.org> wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 > > --- Comment #21 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-22 23:20:37 > UTC --- >> I'll give this patch a try and let you know how it affects the >> performance I see. But unrolling shouldn't affect inlining, since all >> unrolling is after inlining, right? > > Well, it is, but we do other transformations that affect profile prior > inlining > + we use hot/cold code all across compilation, not just to drive inlining. > > Honza > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
