List Archive: gentoo-performance
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
Sorry about the cross post, I didn't realise this list existed.
----- Forwarded message from Chris Davies <c.davies@...> -----
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).
firstname.lastname@example.org mailing list
----- End forwarded message -----
email@example.com mailing list