On Tue, Dec 09, 2003 at 02:28:13AM +0100, John Nilsson wrote: > Selecting the correct -m flags is an easy operation as you will get all > information you'll need from /proc/cpuinfo. When it comes to selecting -f > flags you'll have to know the bottlenecs of the code and what the optimization > will do to the code. More importantly you will have to test and compare > diffrent settings. This is most definetly not a simple task. See the genflags package I wrote for this purpose. It was a _lot_ of work, as even the format of /proc/cpuinfo is different accross arches and kernel versions. More annoyingly, the string for a given process as listed in that file has tended to shift over kernel versions, making life harder.
> Needless to say this is a very daunting task to perform for an entire > operating system. As the whole deal is so complex most of us will just trust > some urban myth found in a quick google or on the mailing lists. > This often leads to errors for new users, setting -03 as optimization or > breaking a package with -ffast-math (as I have done a couple of times). > Even when things work you can't guarantee a good optimization if you don't > benchmark the system. The complexity of the issue ensures that what one > finds as good optimization isn't necesary good for some one else. Thats the express purpose that genflags was created for, to provide users with a known good set of high-performance CFLAGS so they didn't need to mess around with it too much. > Then there is the issue about stability. Users are bound to break thing if > they set flags on pure guess and the leave it at that. A huge amout of support > queries on the mailing-lists and bugs.gentoo.org boils down to beeing unstable gcc > settings. A solution mostyl used to remedy this problem is to use "strip-flags" in > ebuilds to remove known unstable flags (or all flags in some cases). strip-flags to remove problematic flags on a per ebuild basis is the best solution. I do agree that unstable gcc settings are a big problem, eg in a recent bug it turned out the submitter's system (an older Pentium I) couldn't handle -O3 without flaking out. Reduce it to -O2 and the box went fine (both for compiling and already compiled packages). > What we would need here is a sytem that ensures that the default flags for > compiling each application is the best you can do while keeping the sytem > stable. The system should provide mature recomendations of flags for those of > us willing to risk a little stability for absolute speed. The system should > take advantage of the ordinary software improvment mechanism used by OSS > projects: evolution. Small but measureable improvments that all users > benefit from. again, genflags was created for this. I've considered a sequel to genflags based on the genetic optimization of compiler flags as mentioned on Slashdot a while ago, but for lack of time, i'm not even looking at doing it now. Stable and high-performance is an per-system definition, as evidenced by the bug I mentioned with -O3. > Specification > ============= > To implemnt a system like this the current use of CFLAGS and CXXFLAGS in > /etc/make.conf will be limited to -m flags, (in the future this might be > generated from /proc/cpuinfo for defaults). A new setting CSTYLE can be set to > 'speed', 'size', 'debug' or 'oldstyle'. > In each ebuild CFLAGS_SPEED, CFLAGS_SIZE and CFLAGS_DEBUG is populated with > the machine indipendent flags found to result in the desired goal for that > package. > If the user set CSTYLE=oldstyle CFLAGS will override the perpackage flags > otherwise it will be appended to the package flags. Again, this is genflags integrated to the system. > By having CFLAGS in ebuild we ensure that they are related to a specific set > pf source code. Meaningful benchmarks can be carried out and improvments can > be filed to bugs.gentoo.org. Again, this is very much variable depending on your system, not just the source code. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgp00000.pgp
Description: PGP signature
