From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6243 invoked by uid 1002); 17 May 2003 07:52:14 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 28150 invoked from network); 17 May 2003 07:52:09 -0000 To: Chris Davies Cc: gentoo-dev@gentoo.org References: <20030517024911.GA6515@vaughan.foofalicious.com> X-Attribution: anupam X-Face: #&PJXI(wRWLNfY"ja`j-UdQ0qmNrnHaXIz.`I6{DYk5=axNLB.HNzI3=]4>j9+N|z:H'Fhc CX_g;6?lb8~r&NOvWm"='kN#*jScukS+s|Z4>i>$vFMK3OF%1?.GS%\FaBYO}}/vD$oC?Q From: Anupam Kapoor Date: 16 May 2003 17:52:13 -0700 In-Reply-To: <20030517024911.GA6515@vaughan.foofalicious.com> Message-ID: <87y91675tu.fsf@speakeasy.net> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [gentoo-dev] -fbranch-probabilities optimisation X-Archives-Salt: afed94d0-fcd1-4e09-aeb6-1b20e84c74ae X-Archives-Hash: af2cc977ee569e12c8d73a34bd1b937b 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@gentoo.org mailing list