From: David Nielsen <Lovechild@foolclan.com>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] -fbranch-probabilities optimisation
Date: 17 May 2003 09:24:36 +0200 [thread overview]
Message-ID: <1053156276.8866.1.camel@pilot.stavtrup-st.dk> (raw)
In-Reply-To: <20030517024911.GA6515@vaughan.foofalicious.com>
I love it, count me in for testing, I've been talking about this for
some time but I never actually got around to trying profiling out, but
it would be a useful feature to have in portage.
- David
On Sat, 2003-05-17 at 04:49, Chris Davies wrote:
> 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
>
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-05-17 7:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-17 2:49 [gentoo-dev] -fbranch-probabilities optimisation Chris Davies
2003-05-17 0:52 ` Anupam Kapoor
2003-05-17 23:28 ` Evan Powers
2003-05-17 7:24 ` David Nielsen [this message]
2003-05-17 11:43 ` Sven Vermeulen
2003-05-17 6:33 ` Werner Van Belle
2003-05-17 13:57 ` Sven Vermeulen
2003-05-17 14:13 ` Werner Van Belle
2003-05-17 16:00 ` Paul de Vrieze
2003-05-17 16:47 ` Chris Davies
2003-05-17 18:16 ` Paul de Vrieze
2003-05-18 9:23 ` Sven Vermeulen
2003-05-18 14:45 ` Chris Davies
2003-05-17 12:30 ` Matt Tucker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1053156276.8866.1.camel@pilot.stavtrup-st.dk \
--to=lovechild@foolclan.com \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox