public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Patrick Lauer <patrick@gentoo.org>
To: "Marcus D. Hanwell" <linux@cryos.net>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Do we want optimal performance?
Date: Wed, 08 Sep 2004 15:43:43 +0200	[thread overview]
Message-ID: <1094651023.11986.10.camel@localhost> (raw)
In-Reply-To: <413F0813.5030308@cryos.net>

[-- 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 --]

  reply	other threads:[~2004-09-08 13:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 10:15 [gentoo-dev] Do we want optimal performance? Klavs Klavsen
2004-09-08 11:29 ` Paul de Vrieze
2004-09-08 12:03   ` Corvus Corax
2004-09-08 13:16     ` Paul de Vrieze
2004-09-08 12:19 ` Alin Nastac
2004-09-08 13:24   ` Marcus D. Hanwell
2004-09-08 13:43     ` Patrick Lauer [this message]
2004-09-08 14:21     ` Klavs Klavsen
2004-09-09  7:52       ` Paul de Vrieze
2004-09-08 12:49 ` Spider
2004-09-08 17:16   ` Robert Moss
2004-09-08 18:20 ` Chris Gianelloni
2004-09-08 19:11   ` Klavs Klavsen
2004-09-08 19:54     ` Paul de Vrieze
2004-09-08 20:05     ` Marcus D. Hanwell
2004-09-08 19:41 ` Lisa Seelye
2004-09-09  0:49 ` Daniel Goller
2004-09-09  1:51   ` [gentoo-dev] per package cflags (was Re: Do we want optimal performance?) Travis Tilley
2004-09-09  2:26     ` Robin H. Johnson
2004-09-09  3:42       ` Ned Ludd
2004-09-09  3:49         ` Robin H. Johnson
2004-09-09 17:23           ` Robert Moss
2004-09-09  4:41         ` Will Buckner
2004-09-09  4:51           ` Ciaran McCreesh
2004-09-09  6:07   ` [gentoo-dev] Do we want optimal performance? Klavs Klavsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1094651023.11986.10.camel@localhost \
    --to=patrick@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=linux@cryos.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox