| 1 |
> Thats the express purpose that genflags was created for, to provide |
| 2 |
> users with a known good set of high-performance CFLAGS so they didn't |
| 3 |
> need to mess around with it too much. |
| 4 |
|
| 5 |
Still there is no room for improvement when dealing with system wide |
| 6 |
optimization. |
| 7 |
|
| 8 |
> > Then there is the issue about stability. Users are bound to break |
| 9 |
> thing if |
| 10 |
> > they set flags on pure guess and the leave it at that. A huge amout |
| 11 |
> of support |
| 12 |
> > queries on the mailing-lists and bugs.gentoo.org boils down to |
| 13 |
> beeing unstable gcc |
| 14 |
> > settings. A solution mostyl used to remedy this problem is to use |
| 15 |
> "strip-flags" in |
| 16 |
> > ebuilds to remove known unstable flags (or all flags in some |
| 17 |
> cases). |
| 18 |
> strip-flags to remove problematic flags on a per ebuild basis is the |
| 19 |
> best solution. I do agree that unstable gcc settings are a big |
| 20 |
> problem, |
| 21 |
> eg in a recent bug it turned out the submitter's system (an older |
| 22 |
> Pentium I) couldn't handle -O3 without flaking out. Reduce it to -O2 |
| 23 |
> and |
| 24 |
> the box went fine (both for compiling and already compiled packages). |
| 25 |
|
| 26 |
This is a bug in GCC. While a workaround may be a quick solution for |
| 27 |
Gentoo, one shouldn't base the whole system on bugs. |
| 28 |
|
| 29 |
|
| 30 |
> > What we would need here is a sytem that ensures that the default |
| 31 |
> flags for |
| 32 |
> > compiling each application is the best you can do while keeping the |
| 33 |
> sytem |
| 34 |
> > stable. The system should provide mature recomendations of flags |
| 35 |
> for |
| 36 |
> those of |
| 37 |
> > us willing to risk a little stability for absolute speed. The |
| 38 |
> system |
| 39 |
> should |
| 40 |
> > take advantage of the ordinary software improvment mechanism used |
| 41 |
> by |
| 42 |
> OSS |
| 43 |
> > projects: evolution. Small but measureable improvments that all |
| 44 |
> users |
| 45 |
> > benefit from. |
| 46 |
> again, genflags was created for this. I've considered a sequel to |
| 47 |
> genflags based on the genetic optimization of compiler flags as |
| 48 |
> mentioned on Slashdot a while ago, but for lack of time, i'm not even |
| 49 |
> looking at doing it now. |
| 50 |
|
| 51 |
You might want to chek: |
| 52 |
http://www.coyotegulch.com/potential/gccga/gccga.html |
| 53 |
http://www.rocklinux.net/packages/ccbench.html |
| 54 |
|
| 55 |
I meant by evolution: the process of users submiting patches to improve |
| 56 |
individual ebuilds. |
| 57 |
|
| 58 |
|
| 59 |
> Stable and high-performance is an per-system definition, as evidenced |
| 60 |
> by |
| 61 |
> the bug I mentioned with -O3. |
| 62 |
|
| 63 |
And should as such be fixed... in gcc. If gcc cant optimize correct |
| 64 |
knowing the cache size of the cpu, gcc is broken. Fix gcc. |
| 65 |
|
| 66 |
|
| 67 |
/John |
Archives