Gentoo Archives: gentoo-dev

From: David Nielsen <Lovechild@××××××××.com>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] -fbranch-probabilities optimisation
Date: Sat, 17 May 2003 07:21:49
Message-Id: 1053156276.8866.1.camel@pilot.stavtrup-st.dk
In Reply to: [gentoo-dev] -fbranch-probabilities optimisation by Chris Davies
1 I love it, count me in for testing, I've been talking about this for
2 some time but I never actually got around to trying profiling out, but
3 it would be a useful feature to have in portage.
4
5 - David
6
7 On Sat, 2003-05-17 at 04:49, Chris Davies wrote:
8 > Hi,
9 >
10 > I had the idea to build -fbranch-probabilities optimisation into portage. This is where a sample run of data is taken using the program compiled with -fprofile-arcs, and that data then used to reorganise the object code so conditional branches are layed out in a more efficient manner.
11 >
12 > To give an idea about how much time this optimisation actually saves, I ran a test with bladeenc (an MP3 encoder) encoding an entire album of wav files. The CFLAGS used only differed by a the -fbranch-probabilities, and the test was run 5 times to get an average. The result was that the version with no branch data took 8.35.106s on average to complete the encoding, whereas the the optimised version took only 8.11.502s. The branch data was 64KBs in total.
13 >
14 > Does this sound like something we could work into portage? I initially had the idea of building patches for every package likely to be improved by this optimisation (mainly CPU bound ones) and just applying them to the package before compilation. The user could then choose wether or not to actually use the data by including or excluding -fbranch-probabilities in make.conf.
15 >
16 > Obviously I'd have to work up some kind of test rig to automatically generate arc data for packages, but that shouldn't be too much of a problem as long as we keep the number of packages under control. The only problem I can see is that -fbranch-probabilities spits out ugly warnings if no arc data is present, although in this situation gcc defaults back to it's standard behaviour (I think).
17 >
18 > Thoughts? Opinions?
19 > Thanks,
20 > C.Davies
21 >
22 >
23 > --
24 > gentoo-dev@g.o mailing list
25 >
26
27
28 --
29 gentoo-dev@g.o mailing list