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