On Fri, 2010-07-09 at 00:00 -0700, Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/08/2010 06:44 PM, Dave Airlie wrote:
> So I'd package up stuff, do a koji build, download it, run my
> representative test suite, upload the result and do another build.
As Roland wrote, if you cannot provide a self-contained RPM build
process it'll be tricky setting up the environment and then collection
the files. And then you also have to be sure you're using *exactly* the
same build environment for the second compile path. That's something
which I also don't see koji providing. A new build root will be
produced from the then-up-to-date RPMs listed as BuildRequires. There
is no bookkeeping of the RPMs used in the first build. If anything is
different you won't get the desired effect.
But this doesn't mean no package can use PGO. Those where the workload
runs can be performed on the build machines it's reasonably easy to
perform the optimization. This should, for instance, be done for all
scripting languages. These packages hopefully contain test suites which
can serve as the beginning of a workload body. Additional code could be
collected in new packages (like, for instance, bash-workload) which
could be added as BuildRequires if compiling with PGO is wanted.
Good idea - though
I'm worried that test suites may give a skewed view
of the branches.
Python has a benchmarking suite that tries to reflect real-world
workloads, and I've filed
https://bugzilla.redhat.com/show_bug.cgi?id=613045
"RFE: Add profile guided optimization to our builds of Python 2"
and
https://bugzilla.redhat.com/show_bug.cgi?id=613046
"RFE: Add profile guided optimization to our builds of Python 3"
Help doing this for Python would be welcome, though it may be better to
focus on python3 for now, until after the 2.6 to 2.7 transition is done.
Dave