| 1 |
On Wed, 2004-09-08 at 15:24, Marcus D. Hanwell wrote: |
| 2 |
> Alin Nastac wrote: |
| 3 |
[snip] |
| 4 |
> People could still have the choice to set whatever blanket optimisations |
| 5 |
> they want, or even override the default C_FLAGS and CXXFLAGS as in |
| 6 |
> package.use etc. |
| 7 |
I'd prefer it if this was not implemented. Most of the time the |
| 8 |
performance gains are not worth the extra bugginess you risk. |
| 9 |
Even "conservative" settings like -O3 are not always stable. |
| 10 |
|
| 11 |
My system runs with -O2, and it's quite fast. So I don't see the |
| 12 |
advantage of tweaking and modding everything to the last bit ... |
| 13 |
|
| 14 |
> Wouldn't this allow us to find optimal CFLAGS etc for a |
| 15 |
> subset of the packages in Gentoo, and set default CFLAGS which could |
| 16 |
> then be overridden? |
| 17 |
"Optimal" depends on many factors like architecture, memory,... |
| 18 |
So what might be very good on an Athlon might slow down a Sparc etc. |
| 19 |
Thus you'd have to test all permutations of switches across all arches |
| 20 |
with different memory/disk/ ... subsystems |
| 21 |
|
| 22 |
In short, please don't :-) |
| 23 |
|
| 24 |
> I for one would be in favour of this. It could be a gradual process, may |
| 25 |
> be added to profiles for different archs. With cascading profiles you |
| 26 |
> could choose the profile with package specific optimisation, or a more |
| 27 |
> generic profile with no package specific optimisations. |
| 28 |
I guess that using the "performance" profile will most likely get your |
| 29 |
bug reports invalidated ... (just guessing) |
| 30 |
Before you go ahead and create more bugginess, do enough QA so that |
| 31 |
simple jobs like "emerge -e world" finish without errors. Otherwise all |
| 32 |
that tweaking accomplishes nothing. |
| 33 |
|
| 34 |
> Not a Gentoo dev, but I for one think this is a great idea. I have seen |
| 35 |
> this mentioned before, and I do believe that for certain packages this |
| 36 |
> would be most beneficial. For other packages there may never be much point. |
| 37 |
From my point of view, the number of packages that gain are not critical. |
| 38 |
What do I get from a 5% faster mplayer? at ~20% CPU, I drop to ... 19% ... wow |
| 39 |
|
| 40 |
It would most likely be better to use tools like prelink, it makes systems |
| 41 |
feel more interactive by just reducing startup time in many cases. |
Archives