1 |
hi, |
2 |
|
3 |
i was under the assumption that most processors already perform branch |
4 |
prediction. no ? do you think that -fbranch-probabilities provides a |
5 |
more 'comprehensive' view of the executing program ? |
6 |
|
7 |
kind regards |
8 |
anupam |
9 |
|
10 |
> Hi, |
11 |
> |
12 |
> I had the idea to build -fbranch-probabilities optimisation into |
13 |
> portage. This is where a sample run of data is taken using the program |
14 |
> compiled with -fprofile-arcs, and that data then used to reorganise |
15 |
> the object code so conditional branches are layed out in a more |
16 |
> efficient manner. |
17 |
> |
18 |
> To give an idea about how much time this optimisation actually saves, |
19 |
> I ran a test with bladeenc (an MP3 encoder) encoding an entire album |
20 |
> of wav files. The CFLAGS used only differed by a the |
21 |
> -fbranch-probabilities, and the test was run 5 times to get an |
22 |
> average. The result was that the version with no branch data took |
23 |
> 8.35.106s on average to complete the encoding, whereas the the |
24 |
> optimised version took only 8.11.502s. The branch data was 64KBs in |
25 |
> total. |
26 |
> |
27 |
> Does this sound like something we could work into portage? I initially |
28 |
> had the idea of building patches for every package likely to be |
29 |
> improved by this optimisation (mainly CPU bound ones) and just |
30 |
> applying them to the package before compilation. The user could then |
31 |
> choose wether or not to actually use the data by including or |
32 |
> excluding -fbranch-probabilities in make.conf. |
33 |
> |
34 |
> Obviously I'd have to work up some kind of test rig to automatically |
35 |
> generate arc data for packages, but that shouldn't be too much of a |
36 |
> problem as long as we keep the number of packages under control. The |
37 |
> only problem I can see is that -fbranch-probabilities spits out ugly |
38 |
> warnings if no arc data is present, although in this situation gcc |
39 |
> defaults back to it's standard behaviour (I think). |
40 |
> |
41 |
> Thoughts? Opinions? Thanks, C.Davies |
42 |
|
43 |
|
44 |
-- |
45 |
gentoo-dev@g.o mailing list |