[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: profile-directed optimization

From: Bruno Haible
Subject: Re: profile-directed optimization
Date: Sun, 21 Sep 2008 12:58:57 +0200
User-agent: KMail/1.5.4

Paolo Bonzini wrote:
> > But the compiler does not know that fstrcmp is called millions of time and
> > that this piece of code needs to be optimized for speed rather than for 
> > space.
> If doing profile-directed optimization, it does know.

However, it is impractical: I never used profile-directed optimization with
GCC so far, because the steps to put it in place are prohibitive. In a
just-in-time compiler, such as in Java or C# virtual machines, it can be
implemented transparently. But in a C compiler, it requires the following
steps (taken from the GCC manual):

        * Compile the source files with `-fprofile-arcs' plus
          optimization and code generation options.
        * Link your object files with `-lgcov' or `-fprofile-arcs' (the
          latter implies the former).
        * Run the program on a representative workload to generate the
          arc profile information.
        * Compile the source files again with the same optimization and
          code generation options plus `-fbranch-probabilities'

How can these steps easily be implemented in a package which has its source
in one subdirectory and its tests in another subdirectory? In a typical
autoconf/automake based setup, "make" recurses first into the sources directory
and then into the tests directory - and never into the sources directory again.

The emphasis is on "easily". With enough hacks to the build infrastructure of
a package, I can achieve anything. But I won't make my Makefile.ams
unmaintainable for the gain of just a few percent of performance. If automake
would offer an option that keeps the Makefile.ams simple, things would be


reply via email to

[Prev in Thread] Current Thread [Next in Thread]