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