hi,

i was under the assumption that most processors already perform branch
prediction. no ? do you think that -fbranch-probabilities provides a
more 'comprehensive' view of the executing program ?

kind regards
anupam

> Hi,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> Thoughts? Opinions?  Thanks, C.Davies


--
gentoo-dev@g.o mailing list