[gentoo-dev] Do we want optimal performance?

[gentoo-dev] Do we want optimal performance?

[Klavs Klavsen]

Hi guys,

Just read an interesting article about Xeon vs. Opteron from anandtech -
where they really show how much difference compile optimizations (or not)
does - and how it differs for different programs for different processors.

http://www.anandtech.com/linux/showdoc.aspx?i=2163&p=1

To me this clearly shows, that if Gentoo wants the best performance - we
can't use a "one cflags fits them all" approach. I do know that if a
program breaks, those CFLAGS are pulled out in the individual ebuild, but
this is not due to poor performance.

IMHO the only way for Gentoo to prove its true potential - is to somehow
build an array of compile options, with CPU's on X, programs on Y and
GCC-version on Z. Getting the numbers for each CPU, will ofcourse require
writing tests, for each program - but IMHO this can be done, if we do it
one at a time.

I would suggest these tests be included like the gentoo-stats program, as
something the individual Gentooist can choose to run after each compile -
which would give him the optimal performance (and recompile X number of
times to test different flags out) on his CPU/program/GCCversion
combination, and at the same time, send the result to a Gentoo database.

I know I would definetely have the patience to let it test and test again,
if it meant more performance for me Smile

The end result should be, that Gentoo automagically selects the optimal
CFLAGS (in performance and stability - perhaps with some optimizations
flagged as "unstable" so people can select "optimize for performance" vs.
"optimize for stability") depending on the X, Y and Z from above.

I would very much like to be one of the guys that gets the ball rolling,
but as I'm not a Gentoo Dev - We (or just I) need to agree with the Gentoo
Dev's on how this could best be done.

What do you think? am I crazy? It seems to me that the anandtech tests
shows that it is more than just a 1% or 2% difference, with the right
CFLAGS - and that the right CFLAGS for one program, can be the worst for
another on same CPU/GCC combination.


-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Paul de Vrieze]

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

On Wednesday 08 September 2004 12:15, Klavs Klavsen wrote:
> Hi guys,
>
> Just read an interesting article about Xeon vs. Opteron from anandtech
> - where they really show how much difference compile optimizations (or
> not) does - and how it differs for different programs for different
> processors.
>
> http://www.anandtech.com/linux/showdoc.aspx?i=2163&p=1
>
> To me this clearly shows, that if Gentoo wants the best performance -
> we can't use a "one cflags fits them all" approach. I do know that if a
> program breaks, those CFLAGS are pulled out in the individual ebuild,
> but this is not due to poor performance.
>
> IMHO the only way for Gentoo to prove its true potential - is to
> somehow build an array of compile options, with CPU's on X, programs on
> Y and GCC-version on Z. Getting the numbers for each CPU, will ofcourse
> require writing tests, for each program - but IMHO this can be done, if
> we do it one at a time.
>
> I would suggest these tests be included like the gentoo-stats program,
> as something the individual Gentooist can choose to run after each
> compile - which would give him the optimal performance (and recompile X
> number of times to test different flags out) on his
> CPU/program/GCCversion combination, and at the same time, send the
> result to a Gentoo database.
>
> I know I would definetely have the patience to let it test and test
> again, if it meant more performance for me Smile
>
> The end result should be, that Gentoo automagically selects the optimal
> CFLAGS (in performance and stability - perhaps with some optimizations
> flagged as "unstable" so people can select "optimize for performance"
> vs. "optimize for stability") depending on the X, Y and Z from above.
>
> I would very much like to be one of the guys that gets the ball
> rolling, but as I'm not a Gentoo Dev - We (or just I) need to agree
> with the Gentoo Dev's on how this could best be done.
>
> What do you think? am I crazy? It seems to me that the anandtech tests
> shows that it is more than just a 1% or 2% difference, with the right
> CFLAGS - and that the right CFLAGS for one program, can be the worst
> for another on same CPU/GCC combination.

To do this for programs, one would need to have a realistic suite of 
"tests" that simulate the real world use of the application. Of course 
that also allows -fprofile_arcs to be used.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Do we want optimal performance?

[Corvus Corax]

Am Wed, 8 Sep 2004 13:29:01 +0200
schrieb Paul de Vrieze <pauldv@gentoo.org>:

> ...
> 
> To do this for programs, one would need to have a realistic suite of 
> "tests" that simulate the real world use of the application. Of course 
> that also allows -fprofile_arcs to be used.
> 
> Paul
> 

depending on the type of program - for easy command line converter tools, an
easy "time" command would be sufficient (used that to determine potential (in
code) optimizations for my motiontrack stuff)

however for libraries like QT or gtk which affect on screen performace of gui
programs - both run-time and load - this will get much harder.

Maybe one could program a test-suite for each library that fires each function
once and times them, along with a flag saved before startup to determine load
time - but it would have to be done for every huge library.

And finally the timing of interactive programs itself - well, usually most time
goes while waiting for user input anyway, but there are timing critical tasks,
too, imagine pattern searches or other big db operatins - or file load/save in
openoffice, picture effects in gimp and such.
those could maybe timed by doing them on a real huge data blog, where the single
operation takes that long, that the user can measure it manually with a
stopwatch.
If the operation takes 40 seconds, and you can gain 3 seconds by
optimisations, it is a blunt measurable improvement. However I dont like that
idea, maybe one can time the operation by watching tmp files in background or
something like this.

Or the maintainer could go into the code and insert some debug lines to print
timing information to stderr or such. But this would be way to much work for
most maintainers and most software isnt it ?

(Well I still could do it on my own software and tell the maintainer the
result;)


just some thoughts...

regards

Corvus



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Paul de Vrieze]

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

On Wednesday 08 September 2004 14:03, Corvus Corax wrote:
> Am Wed, 8 Sep 2004 13:29:01 +0200
>
> schrieb Paul de Vrieze <pauldv@gentoo.org>:
> > ...
> >
> > To do this for programs, one would need to have a realistic suite of
> > "tests" that simulate the real world use of the application. Of
> > course that also allows -fprofile_arcs to be used.
> >
> > Paul
>
> depending on the type of program - for easy command line converter
> tools, an easy "time" command would be sufficient (used that to
> determine potential (in code) optimizations for my motiontrack stuff)

Timing is not the issue, the issue is what you have the program do. 
Initializing and then dying is not really a truthfull representation of 
normal behaviour.

> however for libraries like QT or gtk which affect on screen performace
> of gui programs - both run-time and load - this will get much harder.

Certainly, for gui's you need some kind of scripting that simulates actual 
user actions. (fortunately the interactive behaviour is not the 
bottleneck in most interactive applications as most user actions lead to 
almost trivial computations)

> Maybe one could program a test-suite for each library that fires each
> function once and times them, along with a flag saved before startup to
> determine load time - but it would have to be done for every huge
> library.

This is handwork, and also the different functions need different weights 
based on a.o. the frequency of their work. In other words it is a very 
big lot of work, and completely specific to the library/application at 
hand.

>
> And finally the timing of interactive programs itself - well, usually
> most time goes while waiting for user input anyway, but there are
> timing critical tasks, too, imagine pattern searches or other big db
> operatins - or file load/save in openoffice, picture effects in gimp
> and such.
> those could maybe timed by doing them on a real huge data blog, where
> the single operation takes that long, that the user can measure it
> manually with a stopwatch.

This is not interesting for gentoo to offer. If the user wants to do 
manual timing he allways can. What would be interesting is automated 
timing. This unfortunately is not really easy with current packages. This 
is most easy for applications with test suites. With relatively small 
effort these test suites could double up as "representative applications 
use" for timing and arc profiling (a newer option of gcc)

> If the operation takes 40 seconds, and you can gain 3 seconds by
> optimisations, it is a blunt measurable improvement. However I dont
> like that idea, maybe one can time the operation by watching tmp files
> in background or something like this.
>
> Or the maintainer could go into the code and insert some debug lines to
> print timing information to stderr or such. But this would be way to
> much work for most maintainers and most software isnt it ?

Well, I agree that there is much that can be done to improve application 
performance. However, even with cflags (which in many cases do not make 
the huge difference), it are all application specific optimizations. 
These are things that application providers should do, not 
packagers/distributors. We don't have the knowledge or the time to try to 
find out for each specific cpu/application combination what the "fastest" 
cflags are.

Also the review at the website still has it's issues. While it is quite 
known that -O3 is in many cases slower than -O2, it is also true that the 
internal architecture of CPU's matters. Fact is that gcc has had support 
and testing on amd64 machines for a lot longer time than on xeons with 
64bit extensions. Scheduling on the two different cpus is likely to have 
different optimal strategies. It is unlikely that the xeon 64-bit 
scheduler is as optimized as the amd64 scheduler. The x86_64 compiler 
also defaults to generating amd64 optimal code (amd64 used to be the only 
processor), so it is not strange that this codes performs much faster on 
an opteron than on a xeon.

This leads to the observation that one can still base a buying decision on 
the benchmarks one can not actually say that the opteron IS faster than 
the xeon. Only that the opteron can execute opteron optimized code faster 
than a xeon can. It is also known that the pentium4 architecture (which 
the xeon has) is highly dependend on good scheduling so the observation 
is not really a surprise.

Paul

ps. This does not mean that the opteron is not faster than the xeon, just 
that this test does not give a reasonable indication of it.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Do we want optimal performance?

[Alin Nastac]

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

Klavs Klavsen wrote:

>The end result should be, that Gentoo automagically selects the optimal
>CFLAGS (in performance and stability - perhaps with some optimizations
>flagged as "unstable" so people can select "optimize for performance" vs.
>"optimize for stability") depending on the X, Y and Z from above.
>  
>
If you don't want to give gentooers a chance to set whatever they want 
in CHOST,CFLAGS and CXXFLAGS it would be a mistake. Not everyone want 
the greatest opimization for their processor! For example, I use on my 
servers optimizations for pentium2 no matter what processor I have on 
that particular computer.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Do we want optimal performance?

[Marcus D. Hanwell]

Alin Nastac wrote:

> Klavs Klavsen wrote:
>
>> The end result should be, that Gentoo automagically selects the optimal
>> CFLAGS (in performance and stability - perhaps with some optimizations
>> flagged as "unstable" so people can select "optimize for performance" 
>> vs.
>> "optimize for stability") depending on the X, Y and Z from above.
>>  
>>
> If you don't want to give gentooers a chance to set whatever they want 
> in CHOST,CFLAGS and CXXFLAGS it would be a mistake. Not everyone want 
> the greatest opimization for their processor! For example, I use on my 
> servers optimizations for pentium2 no matter what processor I have on 
> that particular computer.

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

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.

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.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Patrick Lauer]

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

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.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Do we want optimal performance?

[Klavs Klavsen]

Marcus D. Hanwell said:
> 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. 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?
>
exactly.

> 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.
>
> 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.
>
Glad I'm not the only one then :)

I do realise there wouldn't be much point in doing this flag-optimization
for every package - but I'm sure everybody could benefit greatly from this
for servers, with MySQL, PostgreSQL, apache etc. etc. Would be nice with
if this resulted in a set of optimal CFLAGS (as fast as possible, without
stability problems) and perhaps some performance CFLAGS (with perhaps some
stability problems) for these packages (for each CPU-type) - so people
know what they are doing.

It would in esssense be a record of "automated performance testing
numbers" with "unstable CFLAGS added, if not detected with automated
performance testing, then added via bugzilla.

IMHO a very good start would be with tests for the major serverpackages
(as they are the easiest to do test-suites fore - and most likely we can
already find test-suites for these) and then go from there.
To most, they won't care if bzip2 is a little slower - but they would
care, if their LAMP setup was quicker for the same buck :)

-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Paul de Vrieze]

On Wednesday 08 September 2004 16:21, Klavs Klavsen wrote:
>
> I do realise there wouldn't be much point in doing this
> flag-optimization for every package - but I'm sure everybody could
> benefit greatly from this for servers, with MySQL, PostgreSQL, apache
> etc. etc. Would be nice with if this resulted in a set of optimal
> CFLAGS (as fast as possible, without stability problems) and perhaps
> some performance CFLAGS (with perhaps some stability problems) for
> these packages (for each CPU-type) - so people know what they are
> doing.

Well, find out what is the way to get them as fast as possible, submit 
that to the upstream developers so they can overlay that upon the default 
cflags. Then everybody is happy, including gentoo as it does not cause us 
extra support or testing headaches.

> It would in esssense be a record of "automated performance testing
> numbers" with "unstable CFLAGS added, if not detected with automated
> performance testing, then added via bugzilla.

Read a bit up on complexity theory, will you.

> IMHO a very good start would be with tests for the major serverpackages
> (as they are the easiest to do test-suites fore - and most likely we
> can already find test-suites for these) and then go from there.
> To most, they won't care if bzip2 is a little slower - but they would
> care, if their LAMP setup was quicker for the same buck :)

Providing this will add major complexity to the packages and portage. The 
only thing that might help is the arc profiling stuff. The rest is at 
your own leisure. profiling and improving code in any case is more likely 
to lead to significant speed increases.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Spider]

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

<cut>

Rather than adding intricate and headache-inducing supports for per
package CFLAG changing and falling down to an seemingly endless series
of pains caused by such things. . (  fex. the complexity involved,
thankyou)

Rather make an effort to add into portage a generalized way of useing
gcc's automatic profiling support,  Allowing the people who care so
deeply to do this on the workload that just they use, and leaving the
rest of us without need to care for it.  

//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

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

Re: [gentoo-dev] Do we want optimal performance?

[Robert Moss]

> Rather make an effort to add into portage a generalized way of useing
> gcc's automatic profiling support,  Allowing the people who care so
> deeply to do this on the workload that just they use, and leaving the
> rest of us without need to care for it.

Exactly... I imagine that, with the new GIMPLE stuff in gcc-3.5, it's 
highly likely that this stuff would be totally pointless inside a couple 
of years anyway. Theoretically at least, you can implement this at 
function level and even below, so don't get too hung up on this - this 
is a brute force "solution," and a neat solution exists.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Chris Gianelloni]

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

On Wed, 2004-09-08 at 06:15, Klavs Klavsen wrote:
> To me this clearly shows, that if Gentoo wants the best performance - we
> can't use a "one cflags fits them all" approach. I do know that if a
> program breaks, those CFLAGS are pulled out in the individual ebuild, but
> this is not due to poor performance.

Gentoo is not all about performance.  While many of our users want to
squeeze the every drop of performance out of their systems, many use
Gentoo for any number of other reasons such as our philosophy, our
community, the manageability of portage, or even because they think
Larry the Cow just owns.

> IMHO the only way for Gentoo to prove its true potential - is to somehow
> build an array of compile options, with CPU's on X, programs on Y and
> GCC-version on Z. Getting the numbers for each CPU, will ofcourse require
> writing tests, for each program - but IMHO this can be done, if we do it
> one at a time.

I just want to ask where the manpower to do this will come from?  We
would have to start over with every CPU upgrade and every toolchain
upgrade.  It appears it would be an unending task of hours upon hours of
labor for each package.  Have you looked at the sheer number of CFLAGS
available?

> I would suggest these tests be included like the gentoo-stats program, as
> something the individual Gentooist can choose to run after each compile -
> which would give him the optimal performance (and recompile X number of
> times to test different flags out) on his CPU/program/GCCversion
> combination, and at the same time, send the result to a Gentoo database.

I see no problem with it provided you could find someone to actually do
the work.  This would be *very* boring work for most, which means it
would be abandoned by anyone but the most determined quite quickly.

> I know I would definetely have the patience to let it test and test again,
> if it meant more performance for me Smile

Excellent.  Nothing is stopping you from doing exactly this on your own
machine, though, so go for it.

> The end result should be, that Gentoo automagically selects the optimal
> CFLAGS (in performance and stability - perhaps with some optimizations
> flagged as "unstable" so people can select "optimize for performance" vs.
> "optimize for stability") depending on the X, Y and Z from above.

Well, as soon as you enter in the possibility of user-defined
selections, then there is no point.  If we're going for optimal
performance, we shoot for optimal performance.  After all, with all this
test data who would know better, us, or each individual user who may or
may not have performed all the testing?

> I would very much like to be one of the guys that gets the ball rolling,
> but as I'm not a Gentoo Dev - We (or just I) need to agree with the Gentoo
> Dev's on how this could best be done.

You don't have to be a developer to get involved.  That is one of the
greatest things about Gentoo.

> What do you think? am I crazy? It seems to me that the anandtech tests
> shows that it is more than just a 1% or 2% difference, with the right
> CFLAGS - and that the right CFLAGS for one program, can be the worst for
> another on same CPU/GCC combination.

While I agree that there can be great performance increases, I believe
that there is a definite trade-off between performance and
manageability.  This would be wholly unmanageable without an army of
testers working around the clock until Gentoo ceased to be... *grin*

-- 
Chris Gianelloni
Release Engineering - Operations/QA Manager
Games - Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Do we want optimal performance?

[Klavs Klavsen]

Chris Gianelloni said:
[SNIP]
> Gentoo is not all about performance.  While many of our users want to
> squeeze the every drop of performance out of their systems, many use
> Gentoo for any number of other reasons such as our philosophy, our
> community, the manageability of portage, or even because they think
> Larry the Cow just owns.
>
hehe. I totally agree. I choose Gentoo for the flexibility, for instance
in getting the programversions I want to use - except I'm sad that
gcc-versions get phased out too quickly IMHO, so I can't easily choose to
stay with an "old" gcc like 3.2.2 - without running into packages I
suddenly can't upgrade automatically, because they depend on a newer GCC,
which I can see no reason for them to do.

This would ofcourse not be so big a problem, if we had proper reverse
depedencies - but like things are now - I must admit I'm afraid of
upgrading gcc/glibc on a machine in production.. have been bitten by that
one before (I always have package of the old one - but still).
[SNIP]
>
> I just want to ask where the manpower to do this will come from?  We
> would have to start over with every CPU upgrade and every toolchain
> upgrade.  It appears it would be an unending task of hours upon hours of
> labor for each package.  Have you looked at the sheer number of CFLAGS
> available?
>
You are probably right - especially when I'm told that gcc-3.5 has great
profiling capabilities (GIMPLE - whatever that is :) - which I agree would
be the better solution (so people can easily optimize their machine -
doing profiles for their usage).

>> I would suggest these tests be included like the gentoo-stats program,
>> as
>> something the individual Gentooist can choose to run after each compile
>> -
>> which would give him the optimal performance (and recompile X number of
>> times to test different flags out) on his CPU/program/GCCversion
>> combination, and at the same time, send the result to a Gentoo database.
>
> I see no problem with it provided you could find someone to actually do
> the work.  This would be *very* boring work for most, which means it
> would be abandoned by anyone but the most determined quite quickly.
>
Agreed - that's why I wanted to "throw it out there"  - so I could get
some feedback on the idea and see if it would stick.

[SNIP]
>> What do you think? am I crazy? It seems to me that the anandtech tests
>> shows that it is more than just a 1% or 2% difference, with the right
>> CFLAGS - and that the right CFLAGS for one program, can be the worst for
>> another on same CPU/GCC combination.
>
> While I agree that there can be great performance increases, I believe
> that there is a definite trade-off between performance and
> manageability.  This would be wholly unmanageable without an army of
> testers working around the clock until Gentoo ceased to be... *grin*
>
The idea would ofcourse be that, only the "obvious" programs would be
tested - but if profiling were implemented/possible with gcc-3.5 and
portage easily - I'm  fairly certain that would be of more value (would
that also help select the right CFLAGS ?)

-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Paul de Vrieze]

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

On Wednesday 08 September 2004 21:11, Klavs Klavsen wrote:
> Chris Gianelloni said:
> [SNIP]
>
> > Gentoo is not all about performance.  While many of our users want to
> > squeeze the every drop of performance out of their systems, many use
> > Gentoo for any number of other reasons such as our philosophy, our
> > community, the manageability of portage, or even because they think
> > Larry the Cow just owns.
>
> hehe. I totally agree. I choose Gentoo for the flexibility, for instance
> in getting the programversions I want to use - except I'm sad that
> gcc-versions get phased out too quickly IMHO, so I can't easily choose to
> stay with an "old" gcc like 3.2.2 - without running into packages I
> suddenly can't upgrade automatically, because they depend on a newer GCC,
> which I can see no reason for them to do.

Most applications should not explicitly depend on a specific version of the 
compiler. There are however some serious bugs in certain compiler versions 
that show up in certain complex applications (like openoffice). Those bugs 
are sometimes a reason to stop support for that particular version (although 
not using -march=pentium4 stops most 3.2.x family problems)
>
> You are probably right - especially when I'm told that gcc-3.5 has great
> profiling capabilities (GIMPLE - whatever that is :) - which I agree would
> be the better solution (so people can easily optimize their machine -
> doing profiles for their usage).

According to wikipedia and the gcc website it is an intermediate machine 
independent language that is used for optimization.

> The idea would ofcourse be that, only the "obvious" programs would be
> tested - but if profiling were implemented/possible with gcc-3.5 and
> portage easily - I'm  fairly certain that would be of more value (would
> that also help select the right CFLAGS ?)

Easy profiling mainly shows where bottlenecks are (not the subtle ones that 
involve the cpu cache for example, for that you might want to try the 
valgrind cachegrind module)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Do we want optimal performance?

[Marcus D. Hanwell]

Klavs Klavsen wrote:

>Chris Gianelloni said:
>  
>
>> While I agree that there can be great performance increases, I believe
>>
>>that there is a definite trade-off between performance and
>>manageability.  This would be wholly unmanageable without an army of
>>testers working around the clock until Gentoo ceased to be... *grin*
>>
>>    
>>
>The idea would ofcourse be that, only the "obvious" programs would be
>tested - but if profiling were implemented/possible with gcc-3.5 and
>portage easily - I'm  fairly certain that would be of more value (would
>that also help select the right CFLAGS ?)
>
>  
>
I would tend to agree here - if GCC 3.5 has features that can 
automatically profile applications and use the correct optimisations 
then there would be little point in spending the time doing this by hand 
(even if using some automated test scripts).

I personally saw it being of use for larger applications in the tree, 
such as Apache, MySQL, PostgreSQL, PHP, Postfix, bincimap, Courier, KDE, 
GNOME, GCC, GlibC etc. It would certainly be an impossible task to 
perform this work on all of the tree for all archs :)

I personally use amd64 platform with fairly modest CFLAGS="-march=k8 -O2 
-pipe" at the moment - going for best all round performance with 
stability. There are things such as fftw where I do try to optimise if 
possible, and I would be interested in a 10% speed gain on the fftw 
library for a 5 hour simulation run!

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do we want optimal performance?

[Lisa Seelye]

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

On Wed, 2004-09-08 at 06:15, Klavs Klavsen wrote:
> Hi guys,
> 
> Just read an interesting article about Xeon vs. Opteron from anandtech -
> where they really show how much difference compile optimizations (or not)
> does - and how it differs for different programs for different processors.

To me the phrase "optimal performance" means that all of the programs I
use compile, run, are stable, and give a respectable "response time." 
Who cares if Apache serves up your pages 0.005 seconds faster as long as
they're served up in a respectable time?

I laugh at the people who run with every cflag optimisation they can
because chances are there's no real reason for them to need such
optimisation at such a risk for buggy behavior.

I think that the people who /need/ these optimisations will know what
they're doing in advance and how to customise their cflags accordingly.

-- 
Regards,
Lisa Seelye
Key fingerprint = 09CF 52D6 B82B 72B9 97A7  601B CB46 B556 1E49 6FC5

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Do we want optimal performance?

[Daniel Goller]

although i am against overly tweaking CFLAGS, someone suggested 
something that might be more sane to ask for:

/etc/portage/packages.cflags

an easy way to maintain your cflags you worked so hard for to obtain, 
you can trade them in the forums or ebay and then append to your file, 
not much work to implement in my eyes, and all the testing work is done 
by those who want it

this way those of you who want a per package set of CFLAGS get it w/o it 
being an impossible task for gentoo to implement

now you just need to get someone to make this happen or say "no, not 
even that will happen"

if the portage team picks it up, make sure to thank Magnade for the idea

Daniel


Klavs Klavsen wrote:

>Hi guys,
>
>Just read an interesting article about Xeon vs. Opteron from anandtech -
>where they really show how much difference compile optimizations (or not)
>does - and how it differs for different programs for different processors.
>
>http://www.anandtech.com/linux/showdoc.aspx?i=2163&p=1
>
>To me this clearly shows, that if Gentoo wants the best performance - we
>can't use a "one cflags fits them all" approach. I do know that if a
>program breaks, those CFLAGS are pulled out in the individual ebuild, but
>this is not due to poor performance.
>
>IMHO the only way for Gentoo to prove its true potential - is to somehow
>build an array of compile options, with CPU's on X, programs on Y and
>GCC-version on Z. Getting the numbers for each CPU, will ofcourse require
>writing tests, for each program - but IMHO this can be done, if we do it
>one at a time.
>
>I would suggest these tests be included like the gentoo-stats program, as
>something the individual Gentooist can choose to run after each compile -
>which would give him the optimal performance (and recompile X number of
>times to test different flags out) on his CPU/program/GCCversion
>combination, and at the same time, send the result to a Gentoo database.
>
>I know I would definetely have the patience to let it test and test again,
>if it meant more performance for me Smile
>
>The end result should be, that Gentoo automagically selects the optimal
>CFLAGS (in performance and stability - perhaps with some optimizations
>flagged as "unstable" so people can select "optimize for performance" vs.
>"optimize for stability") depending on the X, Y and Z from above.
>
>I would very much like to be one of the guys that gets the ball rolling,
>but as I'm not a Gentoo Dev - We (or just I) need to agree with the Gentoo
>Dev's on how this could best be done.
>
>What do you think? am I crazy? It seems to me that the anandtech tests
>shows that it is more than just a 1% or 2% difference, with the right
>CFLAGS - and that the right CFLAGS for one program, can be the worst for
>another on same CPU/GCC combination.
>
>
>  
>

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] per package cflags (was Re: Do we want optimal performance?)

[Travis Tilley]

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

Daniel Goller wrote:
> although i am against overly tweaking CFLAGS, someone suggested 
> something that might be more sane to ask for:
> 
> /etc/portage/packages.cflags
> 
> an easy way to maintain your cflags you worked so hard for to obtain, 
> you can trade them in the forums or ebay and then append to your file, 
> not much work to implement in my eyes, and all the testing work is done 
> by those who want it

mkdir /etc/portage and copy this file there (MUCH thanks to solar for 
writing this. he like... kicks ass an stuff). it implements an 
/etc/portage/package.cflags without needing to patch portage. i think 
this might require portage 2.0.51_pre... no idea, i havent used 2.0.50 
in a while.


Travis Tilley <lv@gentoo.org>

[-- Attachment #2: bashrc --]
[-- Type: text/plain, Size: 1435 bytes --]

# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# /etc/portage/bashrc

if [ "$0" = "/usr/lib/portage/bin/ebuild.sh" ]; then

	if [ "${DEBUG}" != "" ]; then
		echo ----------------------------------------------------
		echo \$_=$_
		echo \$\*=$*
		echo \$@=$@
		echo \$0=$0


		echo PORTDIR=$PORTDIR
		echo CATEGORY=$CATEGORY
		echo PN=$PN
		echo PV=$PV
		echo PR=$PR
		echo PF=$PF
		echo P=$P

		echo USER=$USER
		echo HOME=$HOME
		echo PATH=${PATH}
		echo LD_PRELOAD=${LD_PRELOAD}
		echo ----------------------------------------------------
	fi

	eecho() {
		[ "$NOCOLOR" = "false" ] && echo -ne '\e[1;34m>\e[1;36m>\e[1;35m>\e[0m ' || echo -n ">>> "
		echo "$*"
	}

	case "$*"  in
		# stay really quiet here.
		depend) : ;;
		*)
			if [ "$(/bin/basename /${LD_PRELOAD})" = "libsandbox.so" ]; then
				eecho "$USER +sandbox($*) $PWD"
			else	
				eecho "$USER -sandbox($*) $PWD"
			fi
			if [ -e ${ROOT}/etc/portage/package.cflags ]; then
				save_IFS
				IFS=$'\n'
				for x in $(/bin/cat ${ROOT}/etc/portage/package.cflags); do
					unset IFS
					x="$(echo $x)"
					IFS=$'\n'
					if [ "${x:0:1}" != "#" ]; then
						PKG="${x%%[$'\t\n ']*}"
						if [ "$PKG" == "$CATEGORY/$PN" ]; then
							export CFLAGS="${x/$PKG/}"
							eecho "Using package.cflags entry for $PN - CFLAGS=\"${CFLAGS}\""
						fi
					fi
				done
				restore_IFS
			fi

		;;
	esac
fi


[-- Attachment #3: Type: text/plain, Size: 37 bytes --]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] per package cflags (was Re: Do we want optimal performance?)

[Robin H. Johnson]

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

On Wed, Sep 08, 2004 at 09:51:15PM -0400, Travis Tilley wrote:
> Daniel Goller wrote:
> >although i am against overly tweaking CFLAGS, someone suggested 
> >something that might be more sane to ask for:
> >
> >/etc/portage/packages.cflags
> >
> >an easy way to maintain your cflags you worked so hard for to obtain, 
> >you can trade them in the forums or ebay and then append to your file, 
> >not much work to implement in my eyes, and all the testing work is done 
> >by those who want it
> mkdir /etc/portage and copy this file there (MUCH thanks to solar for 
> writing this. he like... kicks ass an stuff). it implements an 
> /etc/portage/package.cflags without needing to patch portage. i think 
> this might require portage 2.0.51_pre... no idea, i havent used 2.0.50 
> in a while.
[snip]
Could this be generalized to do /etc/portage/package.env like somebody
else asked for?

And then simply put a CFLAGS line in the file referenced by package.env,
as it seems that it really would belong there.

-- 
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] per package cflags (was Re: Do we want optimal performance?)

[Ned Ludd]

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

On Wed, 2004-09-08 at 22:26, Robin H. Johnson wrote:
> On Wed, Sep 08, 2004 at 09:51:15PM -0400, Travis Tilley wrote:
> > Daniel Goller wrote:
> > >although i am against overly tweaking CFLAGS, someone suggested 
> > >something that might be more sane to ask for:
> > >
> > >/etc/portage/packages.cflags
> > >
> > >an easy way to maintain your cflags you worked so hard for to obtain, 
> > >you can trade them in the forums or ebay and then append to your file, 
> > >not much work to implement in my eyes, and all the testing work is done 
> > >by those who want it
> > mkdir /etc/portage and copy this file there (MUCH thanks to solar for 
> > writing this. he like... kicks ass an stuff). it implements an 
> > /etc/portage/package.cflags without needing to patch portage. i think 
> > this might require portage 2.0.51_pre... no idea, i havent used 2.0.50 
> > in a while.
> [snip]
> Could this be generalized to do /etc/portage/package.env like somebody
> else asked for?
> 
> And then simply put a CFLAGS line in the file referenced by package.env,
> as it seems that it really would belong there.

I played with that idea for a few mins, but unfortunately I found no
easy way in bash to deal with the quotes.
Assuming this syntax.

sys-apps/paxctl CFLAGS="-Os -fomit-frame-pointer" 
sys-devel/gdb CFLAGS="-O2 -g3"
app-misc/beep FEATURES="sfperms sandbox" LDFLAGS="-Wl,-z,now
-Wl,-z,relro"
dev-libs/openssl CFLAGS="-O3 -fno-omit-frame-pointer -m32"
..

Maybe somebody else is motivated to do it from the basic idea. I gave up
and settled for the easy way out of package.cflags package.ldflags here
locally.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] per package cflags (was Re: Do we want optimal performance?)

[Robin H. Johnson]

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

On Wed, Sep 08, 2004 at 11:42:56PM -0400, Ned Ludd wrote:
> On Wed, 2004-09-08 at 22:26, Robin H. Johnson wrote:
> > On Wed, Sep 08, 2004 at 09:51:15PM -0400, Travis Tilley wrote:
> > > Daniel Goller wrote:
> > > >although i am against overly tweaking CFLAGS, someone suggested 
> > > >something that might be more sane to ask for:
> > > >
> > > >/etc/portage/packages.cflags
> > > >
> > > >an easy way to maintain your cflags you worked so hard for to obtain, 
> > > >you can trade them in the forums or ebay and then append to your file, 
> > > >not much work to implement in my eyes, and all the testing work is done 
> > > >by those who want it
> > > mkdir /etc/portage and copy this file there (MUCH thanks to solar for 
> > > writing this. he like... kicks ass an stuff). it implements an 
> > > /etc/portage/package.cflags without needing to patch portage. i think 
> > > this might require portage 2.0.51_pre... no idea, i havent used 2.0.50 
> > > in a while.
> > [snip]
> > Could this be generalized to do /etc/portage/package.env like somebody
> > else asked for?
> > 
> > And then simply put a CFLAGS line in the file referenced by package.env,
> > as it seems that it really would belong there.
> 
> I played with that idea for a few mins, but unfortunately I found no
> easy way in bash to deal with the quotes.
> Assuming this syntax.
> 
> sys-apps/paxctl CFLAGS="-Os -fomit-frame-pointer" 
> sys-devel/gdb CFLAGS="-O2 -g3"
> app-misc/beep FEATURES="sfperms sandbox" LDFLAGS="-Wl,-z,now
> -Wl,-z,relro"
> dev-libs/openssl CFLAGS="-O3 -fno-omit-frame-pointer -m32"
> ..
> 
> Maybe somebody else is motivated to do it from the basic idea. I gave up
> and settled for the easy way out of package.cflags package.ldflags here
> locally.
I'll take a look at it and see about hacking up a prototype :-).

The general consensus that was reached on the rough design of it was:
/etc/portage/package.env:
ebuild-atom file 

where ebuild-atom is a complete version atom per ebuild(5) and file is
one or more space-seperated names of files found in
/etc/portage/package.env.d/ that get used after /etc/portage/bashrc.

-- 
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] per package cflags (was Re: Do we want optimal performance?)

[Robert Moss]

This has already been done AFAICT. Go to the following URI:

http://home.jesus.ox.ac.uk/~ecatmur/gentoo/etc/portage/

You want the bashrc, and the stuff in env.d gives you an example of how 
to use it. This is a lovely implementation (well I like it, anyway - 
nice and simple) which I think merits consideration for addition to 
Portage proper.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] per package cflags (was Re: Do we want optimal performance?)

[Will Buckner]

on 09/08/04 23:42 Ned Ludd said the following:
<snip>
> 
> I played with that idea for a few mins, but unfortunately I found no
> easy way in bash to deal with the quotes.
> Assuming this syntax.
> 
> sys-apps/paxctl CFLAGS="-Os -fomit-frame-pointer" 
> sys-devel/gdb CFLAGS="-O2 -g3"
> app-misc/beep FEATURES="sfperms sandbox" LDFLAGS="-Wl,-z,now
> -Wl,-z,relro"
> dev-libs/openssl CFLAGS="-O3 -fno-omit-frame-pointer -m32"
> ..
> 
> Maybe somebody else is motivated to do it from the basic idea. I gave up
> and settled for the easy way out of package.cflags package.ldflags here
> locally.
> 

What about sed'ing out the package name and then eval'ing the rest of the line?

Wcc

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] per package cflags (was Re: Do we want optimal performance?)

[Ciaran McCreesh]

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

On Thu, 09 Sep 2004 00:41:36 -0400 Will Buckner <wcc@techmonkeys.org>
wrote:
| > app-misc/beep FEATURES="sfperms sandbox" LDFLAGS="-Wl,-z,now
| > -Wl,-z,relro"
| 
| What about sed'ing out the package name and then eval'ing the rest of
| the line?

No need for sed, that can be done using a bash ${%% *} construct.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Do we want optimal performance?

[Klavs Klavsen]

Daniel Goller said:
> although i am against overly tweaking CFLAGS, someone suggested
> something that might be more sane to ask for:
>
> /etc/portage/packages.cflags
>
> an easy way to maintain your cflags you worked so hard for to obtain,
> you can trade them in the forums or ebay and then append to your file,
> not much work to implement in my eyes, and all the testing work is done
> by those who want it
>
> this way those of you who want a per package set of CFLAGS get it w/o it
> being an impossible task for gentoo to implement
>
> now you just need to get someone to make this happen or say "no, not
> even that will happen"
>
> if the portage team picks it up, make sure to thank Magnade for the idea
>
[SNIP]

hehe - I'll thank Magnade and whoever came up with the
/usr/portage/packages.env idea - as I definetely think the packages.env is
the winner - as it does cover every env. var you'd want to set - and not
just CFLAGS. Flexibility wins again :)

-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62
See our managed CMS Hosting Service at http://www.VirkPaaNettet.dk

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer


--
gentoo-dev@gentoo.org mailing list