[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
different.
Bruno
- Re: [PATCH] New function fstrcmp_if_higher., (continued)
- [PATCH] Implement premature termination of compareseq., Ralf Wildenhues, 2008/09/14
- Message not available
- Re: msgmerge speedup: fstrcmp and diffseq improvements, Ralf Wildenhues, 2008/09/15
- Re: msgmerge speedup: fstrcmp and diffseq improvements, Bruno Haible, 2008/09/15
- Re: msgmerge speedup: fstrcmp and diffseq improvements, Ralf Wildenhues, 2008/09/19
- Re: msgmerge speedup: fstrcmp and diffseq improvements, Bruno Haible, 2008/09/20
- Re: msgmerge speedup: fstrcmp and diffseq improvements, Ralf Wildenhues, 2008/09/20
- Re: msgmerge speedup: fstrcmp and diffseq improvements, Paolo Bonzini, 2008/09/21
- Re: profile-directed optimization,
Bruno Haible <=
- Re: profile-directed optimization, Paolo Bonzini, 2008/09/21
- Re: profile-directed optimizations, Bruno Haible, 2008/09/21
- Re: profile-directed optimizations, Paolo Bonzini, 2008/09/21
- Re: profile-directed optimizations, Bruno Haible, 2008/09/21
- Re: msgmerge speedup: fstrcmp and diffseq improvements, Bruno Haible, 2008/09/22