[gentoo-dev] CFLAGS moved to ebuilds.

[gentoo-dev] CFLAGS moved to ebuilds.

[John Nilsson]

[-- Attachment #1.1: Type: text/plain, Size: 159 bytes --]

It was suggested in a discussion (bug[35184]) that this was files as a  
GLEP. This is just a quick dirty draft. Any comments would be  
apreciated.

/John

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: per_package_cflags-glep.txt --]
[-- Type: text/plain; charset=unknown-8bit, Size: 3578 bytes --]

GLEP: XXX
Title: Code dependant CFLAGS in ebuilds.
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/07/19 12:09:20 $
Author:	John Nilsson <john@milsson.nu>,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 08 Dec 2003
Post-History: 


Abstract
========

This GLEP describes an alternative process for selecting compiler
optimzations. In essence moving all architecure independet CFLAGS from current
make.conf to the ebuilds.


Motivation
==========

To optimize compilation you have to know the harware you are compiling for and
you have to know the code you are compiling. In GCC you generally select
options starting with -m for harware dependent options and -f for code
dependent options. 

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.

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.

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).

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.


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.


Rationale
=========

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.



Backwards Compatibility
=======================

This can be implemented without breaking the current implementation. A use of
CFLAGS_DEFAULT in make.globals could be the fallback if an ebuild misses the
required CFLAGS_ setting.


References
==========


Copyright
=========

This document has been placed in the public domain.


[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On 12/09/03  John Nilsson wrote:

> It was suggested in a discussion (bug[35184]) that this was files as a
>  
> GLEP. This is just a quick dirty draft. Any comments would be  
> apreciated.

While it might be a good idea on the first view it has a number of
problems:

- the effect of -f and -O flags can be dependent on the hardware, e.g.
-O3 creates bigger binaries that are faster than -O2 on a Xeon, but
slower on a Duron or Celeron (due to different cache sizes). I'm sure
this also applies to other flags. Further -O3 toggles different -f flags
on different architectures (-fomit-frame-pointer on some non-x86 archs).

- developer time: it would need an extreme amount of developer time to
test all possible combinations for all C/C++ based packages, even if
it's only done for new ebuilds.

- user confusion: users will be very confused about this change when
they CFLAGS don't work anymore (and allowing them to override them will
negate most of the benefits of this proposal)

- compatibility: each new gcc version has some new flags, so all these
per-package flags would ahve to be revised as soon as there is a new gcc
version out (with new version I mean the x or y in x.y.z).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[Mike Frysinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 08 December 2003 21:25, Marius Mauch wrote:
> - developer time: it would need an extreme amount of developer time to
> test all possible combinations for all C/C++ based packages, even if
> it's only done for new ebuilds.

also multiply that by each gcc revision ...
3.2.3 and 3.3.1 and 3.3.2 each had interesting bugs that affected 
compilation/optimization ... each setting would have to be tested for 
improvements/regressions/etc...
- -mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBP9Uzq0FjO5/oN/WBAQIuiBAAxXtNId2nsNMv6cAiPw+Vsl4dGwZDlQ/p
aA0hrcZUaXeRYAjrDi/aBcPxnzeRLKvnV/9ZmUY4amho3yMb6PFtx/Bxyz2gEnH4
WKk12YaC/DferkwVV75u+8y7r7OT9U5sjcCAOi4+9nd2k896mhIKNYVLL5QtoJzS
yaNPlYBdvMh90VfFBzJbK1k301zjY4BHo/a1MjfeGfe4+hwphxH530PsvMRMQdKX
IcQlDrEHoEDQDErSIHHSLnzvRRVlStn8OXG/myVQFE2n0PukHbfmM3by9jkteW1s
vQxib0b8QFoFFv+uCbglrM22aAFzSrA9gKwegFeim69/Syv3gVC8zeYVBglARWrQ
ZHjFZM+J9E9K8jPAyYdKZmq+3Sx45iM9oeaoe4PAR5RD4+Il4TI1e80e32+OMFlb
m/dF2+JC+Q8AJYH1eRfDj94DQRavCn10x5gSaJyf6uxYQ9qd0QlGYACPAtol6vNr
y9Lz4tj+Swlp/KE9Pzoa0iQeyPEfdRKbrCAHUjvWzyQEKrloXxDnQWL1LUkmCrWr
Rs2TlNT6Zp1GHHv9hPn45cwtSz/o+CIusQXFpGwhERSofBU2AhMLoIRbFbDMc6i+
ETCHYEWyT59Z048yYZyUMzaJPOtFL3tAqi5YFoYny/blgl115ZP+u7khTtyBMrMF
e9Bc0vgiG1E=
=e/XA
-----END PGP SIGNATURE-----



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 4266 bytes --]

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     : robbat2@orbis-terrarum.net
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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[John Nilsson]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

> 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.

Still there is no room for improvement when dealing with system wide  
optimization.
 
> > 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).

This is a bug in GCC. While a workaround may be a quick solution for  
Gentoo, one shouldn't base the whole system on bugs.


> > 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.

You might want to chek:
http://www.coyotegulch.com/potential/gccga/gccga.html
http://www.rocklinux.net/packages/ccbench.html

I meant by evolution: the process of users submiting patches to improve  
individual ebuilds.


> Stable and high-performance is an per-system definition, as evidenced
> by
> the bug I mentioned with -O3.

And should as such be fixed... in gcc. If gcc cant optimize correct  
knowing the cache size of the cpu, gcc is broken. Fix gcc.


/John

[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[John Nilsson]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

On 12/09/03 03:25:38, Marius Mauch wrote:
> On 12/09/03  John Nilsson wrote:
> 
> > It was suggested in a discussion (bug[35184]) that this was files  
> as
> a
> >
> > GLEP. This is just a quick dirty draft. Any comments would be
> > apreciated.
> 
> While it might be a good idea on the first view it has a number of
> problems:
> 
> - the effect of -f and -O flags can be dependent on the hardware, e. 
> g.
> -O3 creates bigger binaries that are faster than -O2 on a Xeon, but
> slower on a Duron or Celeron (due to different cache sizes). I'm sure
> this also applies to other flags. Further -O3 toggles different -f
> flags
> on different architectures (-fomit-frame-pointer on some non-x86
> archs).

How is this related to this scheme? Also bugs in gcc should be fixed in  
gcc.

> - developer time: it would need an extreme amount of developer time  
> to
> test all possible combinations for all C/C++ based packages, even if
> it's only done for new ebuilds.

They wouldn't. Most packages would use a standard set of cflags and  
with time user tests and patches would move these towards the optimal.

> - user confusion: users will be very confused about this change when
> they CFLAGS don't work anymore (and allowing them to override them
> will
> negate most of the benefits of this proposal)

Those people who don't use default flags would probably find per  
package optimization a nice feature.

> - compatibility: each new gcc version has some new flags, so all  
> these
> per-package flags would ahve to be revised as soon as there is a new
> gcc
> version out (with new version I mean the x or y in x.y.z).


probably and hopefully ;)

One might have a compiler theme file with cascading (as in css) 
settings.

/John

[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[Jason Mobarak]

I'm in favour of this GLEP, while it's implementation may be difficult it would
provide users with a better basis for what is good for a particular package. I
c?ompile with relatively safe flags and I feel like my system isn't really
benefitting from the fact that I'm compiling stuff because I don't know much
about cflags and what their particular implications are for certain packages. I
feel relatively certain that there is a high percentage of Gentoo users that are
the same as me.

Also, from a support standpoint, having a stable set of flags that a user can
compile with in order to debug problems is quite beneficial in my opinion.

Debian does not have problems providing separate packages for separate
architectures, why should this be a problem for Gentoo? -- especially if we
utilise our large user base in aiding us to find optimal compilation
optimisations.

-- 
-------------------------~
----------Jason-A-Mobarak-~
-aether-at-gentoo-dot-org-~
-------------------------~


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 4345 bytes --]

On Tue, Dec 09, 2003 at 11:17:23PM +0100, John Nilsson wrote:
> >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.
> Still there is no room for improvement when dealing with system wide  
> optimization.
Your wording here is unclear, I think you mean to say that there IS room for
improvement over system wide constant CFLAGS?

> >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).
> This is a bug in GCC. While a workaround may be a quick solution for  
> Gentoo, one shouldn't base the whole system on bugs.
No it isn't a bug in GCC, it's a bug with the user's specific hardware.
I have an older Pentium I system that runs just fine with -O3 and the
user's specified CFLAGS. I didn't force everybody to use -O2, I just got
that user to change his own system down to -O2.

> >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.
> You might want to chek:
> http://www.coyotegulch.com/potential/gccga/gccga.html
This is the original item I was referencing, but you still run into the
problem that you need to run things on a system basis to get effective
results.

http://www.coyotegulch.com/acovea/index.html is the rest of the article,

> http://www.rocklinux.net/packages/ccbench.html
This basically brute forces the genetic algorithms, with absolutely no
thought as to the net effects on the results of the given flags, eg, on
my home server (an AthlonXP 2400+), it returns these results:
gcc -O3 -march=athlon -fomit-frame-pointer -funroll-loops
-frerun-loop-opt -funroll-all-loops -fschedule-insns

Of that, '-frerun-loop-opt' and '-fschedule-insns' are redundant as they
are implied by -O3.

-fomit-frame-pointer and I can't debug code properly anymore, and if I
try to use -funroll-all-loops to compile mysql, even with it's
--with-low-memory option, gcc wants 600mb of memory to compile it's
sql_yacc.cc.

> I meant by evolution: the process of users submiting patches to improve  
> individual ebuilds.
What improves the performance of a given application on one machine does
NOT nessicary improve it on another machine.

Read the gcc manpage and see:
-fprofile-arcs
-fbranch-probabilities
(also read http://gcc.gnu.org/news/profiledriven.html)

Just adding these to ccbench doubles the amount of time taken to
test (as you must compile with -fprofile-arcs, run, compile with
-fbranch-probabilities, run again). It also provides some extremely
interesting and varying results. The bubblesort test for example,
improves between +15% and +300% depending on the other compiler flags.
Towers of Hanoi goes from -20% to +50%.

If users submitted _good_ non-interactive testcases for every ebuild, it
wouldn't difficult to apply -fprofile-arcs/branch-probabilities and or
acovea to most packages at all, apart from the massive increase in
compile time.

> >Stable and high-performance is an per-system definition, as evidenced
> >by the bug I mentioned with -O3.
> And should as such be fixed... in gcc. If gcc cant optimize correct  
> knowing the cache size of the cpu, gcc is broken. Fix gcc.
Again, it isn't a gcc bug, it's an issue with a specific machine (not
even a class of systems or cpus).

Lets take a tangent on this whole issue for a moment. Ignoring the
implementation concerns, the end goal of your GLEP is this:
The basic gain you want, is for the support of per-package CFLAG
modifications (inside the ebuilds), for the purpose of performance
optimization.

Do I have this correct?

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] CFLAGS moved to ebuilds.

[John Nilsson]

[-- Attachment #1: Type: text/plain, Size: 5872 bytes --]

On 12/10/03 02:15:02, Robin H. Johnson wrote:
> On Tue, Dec 09, 2003 at 11:17:23PM +0100, John Nilsson wrote:
> > >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.
> > Still there is no room for improvement when dealing with system  
> wide
> 
> > optimization.
> Your wording here is unclear, I think you mean to say that there IS
> room for
> improvement over system wide constant CFLAGS?

English is not my native language. Writing this GLEP made me realize I  
have problems expressing my thoughts in ANY language =). If this GLEP  
is going to survive, comments on formulations and wordings (and  
spelling) is greatly appreciated.

Yes I meant that it is next to impossible to find a system wide  
optimization beyond "-march=<arch> -O2 -pipe" fit for the majority of  
users.


> > >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).
> > This is a bug in GCC. While a workaround may be a quick solution  
> for
> 
> > Gentoo, one shouldn't base the whole system on bugs.
> No it isn't a bug in GCC, it's a bug with the user's specific
> hardware.
> I have an older Pentium I system that runs just fine with -O3 and the
> user's specified CFLAGS. I didn't force everybody to use -O2, I just
> got
> that user to change his own system down to -O2.

I miss understood you. Still this is a bug in a specific cpu. You cant  
guarantee stability in any case if the hardware is broken.

> > >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.
> > You might want to chek:
> > http://www.coyotegulch.com/potential/gccga/gccga.html
> This is the original item I was referencing, but you still run into
> the
> problem that you need to run things on a system basis to get  
> effective
> results.

Yeah, I had the page open when I read your mail so I though I'd spare  
you the trouble of looking it up =)

> http://www.coyotegulch.com/acovea/index.html is the rest of the
> article,
> 
> > http://www.rocklinux.net/packages/ccbench.html
> This basically brute forces the genetic algorithms, with absolutely  
> no
> thought as to the net effects on the results of the given flags, eg,
> on
> my home server (an AthlonXP 2400+), it returns these results:
> gcc -O3 -march=athlon -fomit-frame-pointer -funroll-loops
> -frerun-loop-opt -funroll-all-loops -fschedule-insns
> 
> Of that, '-frerun-loop-opt' and '-fschedule-insns' are redundant as
> they
> are implied by -O3.
> 
> -fomit-frame-pointer and I can't debug code properly anymore, and if  
> I
> try to use -funroll-all-loops to compile mysql, even with it's
> --with-low-memory option, gcc wants 600mb of memory to compile it's
> sql_yacc.cc.

I had the same reaction. ccbench was what made me realize that any kind  
of systemwide optimization is only guesswork (often bad such).



> > I meant by evolution: the process of users submiting patches to
> improve
> > individual ebuilds.
> What improves the performance of a given application on one machine
> does
> NOT nessicary improve it on another machine.

True, but you would have much better situation to test that fact, then  
what wa have now.


> Read the gcc manpage and see:
> -fprofile-arcs
> -fbranch-probabilities
> (also read http://gcc.gnu.org/news/profiledriven.html)
> 
> Just adding these to ccbench doubles the amount of time taken to
> test (as you must compile with -fprofile-arcs, run, compile with
> -fbranch-probabilities, run again). It also provides some extremely
> interesting and varying results. The bubblesort test for example,
> improves between +15% and +300% depending on the other compiler  
> flags.
> Towers of Hanoi goes from -20% to +50%.
> 
> If users submitted _good_ non-interactive testcases for every ebuild,
> it
> wouldn't difficult to apply -fprofile-arcs/branch-probabilities and  
> or
> acovea to most packages at all, apart from the massive increase in
> compile time.

Couldn't one save the profile data in the portage tree once a generic  
usecase was found?

 
> > >Stable and high-performance is an per-system definition, as
> evidenced
> > >by the bug I mentioned with -O3.
> > And should as such be fixed... in gcc. If gcc cant optimize correct
> 
> > knowing the cache size of the cpu, gcc is broken. Fix gcc.
> Again, it isn't a gcc bug, it's an issue with a specific machine (not
> even a class of systems or cpus).
> 
> Lets take a tangent on this whole issue for a moment. Ignoring the
> implementation concerns, the end goal of your GLEP is this:
> The basic gain you want, is for the support of per-package CFLAG
> modifications (inside the ebuilds), for the purpose of performance
> optimization.
> 
> Do I have this correct?

Yes pleace ignore implementation details, they whre only provided as an  
alternative example scenario, Very open for discussion =)

The goal is not the speed as such, but the testability of it. I want to  
move from the current situation where you have absolutley no knowlege  
of the optimzation results to a situation where you would actually be  
able to give evidence of improvments or the reverse.

Reusability of cflags if you wish =)



/John

[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]