Gentoo Archives: gentoo-portage-dev

From: Bastian Balthazar Bux <BastianBalthazarBux@×××××××××.it>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] src_profile() request for comments
Date: Wed, 28 Sep 2005 16:48:02
In Reply to: Re: [gentoo-portage-dev] src_profile() request for comments by Jason Stubbs
1 Jason Stubbs wrote:
2 > On Thursday 29 September 2005 00:27, Paul de Vrieze wrote:
3 >
4 >>On Wednesday 28 September 2005 17:10, Jason Stubbs wrote:
5 >>
6 >>>On Wednesday 28 September 2005 23:42, Bastian Balthazar Bux wrote:
7 >>>
8 >>>>with src_profile() responsible to do basically two things:
9 >>>>- run the builded app with some fake data
10 >>>>- rebuild the source using the gathered profile info.
11 >>>>
12 >>>>The first step within some ebuilds could be done by src_test, the
13 >>>>second is basically a reduced src_compile.
14 >>>>
15 >>>>any thoughts ?
16 >>>
17 >>> -fno-guess-branch-probability
18 >>> Do not guess branch probabilities using a randomized model.
19 >>>
20 >>> Sometimes GCC will opt to use a randomized model to guess
21 >>>branch probabilities, when none are available from either profiling
22 >>>feed- back (-fprofile-arcs) or __builtin_expect. This means that
23 >>>differ- ent runs of the compiler on the same program may produce
24 >>>different object code.
25 >>>
26 >>> In a hard real-time system, people don't want different runs
27 >>>of the compiler to produce code that has different behavior; minimizing
28 >>>non-determinism is of paramount import. This switch allows users to
29 >>>reduce non-determinism, possibly at the expense of inferior
30 >>>optimization.
31 >>>
32 >>> The default is -fguess-branch-probability at levels -O, -O2,
33 >>>-O3, -Os.
34 >>>
35 >>>Any "test data" that could be used to automatically profile is
36 >>>essentially just a randomized model. So it would seem gcc has it
37 >>>inbuilt already.
38 >>
39 >>The difference is that the randomized model used by gcc is not based on
40 >>possible input to the program (as that might be very big), but on
41 >>possible input to more lowlevel concepts such as functions (or even the
42 >>condition statement). As such test data, if reasonably representative of
43 >>actual data for the application, would give a rather accurate profile of
44 >>the branching probabilities and program paths. The more data the better
45 >>of course.
46 >
47 >
48 > Yes, but I can't think of an application that would be profileable through
49 > automated means and have a useful set of test data that is relevant to real
50 > world execution. My point was that if it's not based on real world then it's
51 > essentially random data.
52 >
53 > Having it so that portage installs a profiled version which automatically
54 > collects data and stores it somewhere for portage to use in a recompile
55 > sounds like more of a worthwhile persuit to my ears.
56 >
57 > --
58 > Jason Stubbs
59 >
62 To say it all, the starting point of this mumbleing was to achieve
63 optimizations on MySQL.
65 IT's very difficult to me mind at how a c-code optimizer, with any
66 degree of intelligence, could predict the usage of such a big piece of
67 code (At least using a finite amount of time).
69 The idea was to select a certain number of tests from the included
70 test-suite, the ones more rappresentative of a normal usage and then
71 pass the gathered data again to gcc that could do a better work.
73 As said before, this is still mumbleing, not even tryed it ;)
75 IMHO other packages may want this expecially becouse seems that this
76 kind of profiling is going to become better and better with new releases
77 of gcc.
78 --
79 gentoo-portage-dev@g.o mailing list