| 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 |
> |
| 60 |
|
| 61 |
|
| 62 |
To say it all, the starting point of this mumbleing was to achieve |
| 63 |
optimizations on MySQL. |
| 64 |
|
| 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). |
| 68 |
|
| 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. |
| 72 |
|
| 73 |
As said before, this is still mumbleing, not even tryed it ;) |
| 74 |
|
| 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 |
Archives