From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7444 invoked by alias); 11 Jan 2013 18:19:20 -0000 Received: (qmail 7383 invoked by uid 55); 11 Jan 2013 18:18:50 -0000 From: "tejohnson at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747 Date: Fri, 11 Jan 2013 18:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: gcov-profile X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tejohnson at google dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg01053.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #22 from Teresa Johnson 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 wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 > > --- Comment #21 from Jan Hubicka 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.