Re: -fprofile-generate and -fprofile-use

[girish vaitheeswaran <girish_vaithees at yahoo dot com>]

Jan,
That's going to be rather difficult given that the app
has over 1000 files. Is there a way I can turn off the
"default" options one at a time ?
Thx
-girish

--- Jan Hubicka <hubicka@ucw.cz> wrote:

> > I have done quite a few experiments with this to
> > narrow down the problem. The performance numbers
> are 
> > slower compared to *No Feedback optimization with
> just
> > -O3* Here are some of them. All the experiments
> were
> > done on a new build-area in order to eliminate
> effects
> > of old feedback files.
> > 
> > 1. I built the app using -O3 and
> -fprofile-generate to
> > generate the feedback data. I then ran the
> workload
> > and then recompiled the app using -O3 and
> > -fprofile-use [app was 20% slower]
> > 
> > 2. I built the app using -O3 and
> -fprofile-generate to
> > generate the feedback data. I then ran the
> workload
> > and then recompiled the app using -O3 and
> > -fprofile-use -fno-vpt -fno-unroll-loops
> > -fno-peel-loops -fno-tracer (Which is turn off all
> the
> > flags used by -fprofile-use) [App was still 20%
> > slower]
> > 
> > 3. I have tried selectively turning of some of the
> > other flags in the above list as well, but the
> > performance regression persists.
> > 
> > 4. I tried with the older flags namely
> -fprofile-arcs
> > and -fbranch-probabilities still no help.
> 
> So it looks like the slowdown is caused by one of
> the profile based
> optimizations that are enabled by default (basic
> block reordering or
> register allocation).  If you are getting such a
> noticable slodown, it
> probably means that your app has pretty small inner
> loop.  Can you just
> look into assembly generated for it with and without
> profiling and try
> to spot what is gong wrong?
> 
> Thanks,
> Honza
> > 
> > Can someone help me out on how to proceed with
> this.
> > 
> > Thanks
> > -girish
> > 
> > 
> > --- Jan Hubicka <hubicka@ucw.cz> wrote:
> > 
> > > > I started with a clean slate in my build
> > > environment
> > > > and did not have any residual files hanging
> > > around.
> > > > Are the steps I have indicated in my earlier
> email
> > > > correct. Is there a way I can break down the
> > > problem
> > > > into a smaller sub-set of flags and eliminate
> the
> > > flag
> > > > causing the performance problem. What I mean
> is
> > > since
> > > > -fprofile-generate and -fprofile-use enable a
> > > bunch of
> > > > flags, would it make sense to avoid profiling
> and
> > > try
> > > > out some of the individual flags on a trial
> and
> > > error
> > > > basis. If so what would be the flags to start
> the
> > > It would be probably better to just turn off the
> > > individual
> > > optimizations with -fprofile-use (for
> optimizations
> > > that are implied by
> > > this flag there should be no need to re-profile
> each
> > > time).
> > > If you can find particular optimization that
> gets
> > > out of control, it
> > > would be lot easier to fix it...
> > > 
> > > Honza
> > > > trials with.
> > > > 
> > > > -girish 
> > > > 
> > > > --- Jan Hubicka <hubicka@ucw.cz> wrote:
> > > > 
> > > > > > On Wed, Jul 20, 2005 at 10:45:01AM -0700,
> > > girish
> > > > > vaitheeswaran wrote:
> > > > > > > > --- Steven Bosscher <stevenb@suse.de>
> > > wrote:
> > > > > > > > 
> > > > > > > > > On Wednesday 20 July 2005 18:53,
> girish
> > > > > vaitheeswaran wrote:
> > > > > > > > > > I am seeing a 20% slowdown with
> > > feedback
> > > > > optimization.
> > > > > > > > > > Does anyone have any thoughts on
> this.
> > > > > > > > > 
> > > > > > > > > My first thought is that you should
> > > probably
> > > > > first
> > > > > > > > > tell what compiler
> > > > > > > > > you are using.
> > > > > > >
> > > > > > > I am using gcc 3.4.3
> > > > > > > -girish
> > > > > > 
> > > > > > Which platform?  I've seen slower code for
> > > > > profile-directed optimizations
> > > > > > on powerpc64-linux with GCC 4.0 and
> mainline. 
> > > > > It's a bug, but I haven't
> > > > > > looked into it enough to provide a small
> test
> > > case
> > > > > for a problem report.
> > > > > 
> > > > > Actually I would be very interested in
> seeing
> > > > > testcases such as those.
> > > > > (and the Girish' slowdown too if possible). 
> In
> > > > > general some slowdowns
> > > > > in side corners are probably unavoidable but
> > > both
> > > > > 3.4.3 and 4.0 seems to
> > > > > have pretty consistent improvements with
> > > profiling
> > > > > at least for SPEC and
> > > > > i386 I am testing pretty regularly.
> > > > > Such slodowns usually indicate problems like
> > > > > incorrectly updated profile
> > > > > or incorrectly readed in profile because of
> > > > > missmatch in CFGs in between
> > > > > profile and feedback run that are rather
> > > dificult to
> > > > > notice and hunt
> > > > > down...
> > > > > 
> > > > > Honza
> > > > > > 
> > > > > > Janis
> > > > > 
> > > 
>