From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7657 invoked from network); 8 Sep 2004 13:43:49 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 8 Sep 2004 13:43:49 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C52jl-0004QX-7s for arch-gentoo-dev@lists.gentoo.org; Wed, 08 Sep 2004 13:43:49 +0000 Received: (qmail 4807 invoked by uid 89); 8 Sep 2004 13:43:48 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 27378 invoked from network); 8 Sep 2004 13:43:48 +0000 From: Patrick Lauer To: "Marcus D. Hanwell" Cc: gentoo-dev@lists.gentoo.org In-Reply-To: <413F0813.5030308@cryos.net> References: <33333.10.0.0.51.1094638559.squirrel@10.0.0.51> <413EF8CE.7080209@gentoo.ro> <413F0813.5030308@cryos.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Teg/zWgmCrr42ZqHZpLx" Organization: Gentoo Message-Id: <1094651023.11986.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Sep 2004 15:43:43 +0200 Subject: Re: [gentoo-dev] Do we want optimal performance? X-Archives-Salt: dc61a201-ac05-4a26-8cde-475eacf077a5 X-Archives-Hash: 6f6ae137b418ffe55e135a46861aee57 --=-Teg/zWgmCrr42ZqHZpLx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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=20 > they want, or even override the default C_FLAGS and CXXFLAGS as in=20 > 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=20 > subset of the packages in Gentoo, and set default CFLAGS which could=20 > 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=20 > be added to profiles for different archs. With cascading profiles you=20 > could choose the profile with package specific optimisation, or a more=20 > 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=20 > this mentioned before, and I do believe that for certain packages this=20 > would be most beneficial. For other packages there may never be much poin= t. =46rom my point of view, the number of packages that gain are not critical.=20 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=20 feel more interactive by just reducing startup time in many cases. --=-Teg/zWgmCrr42ZqHZpLx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBPwyOqER3hOUoZM4RApj/AJ95JG/L+CgVIDVJsMgX+/Rz1oRJOgCeNYVz PQNMPmXBCblUbR8blOFIHvk= =bu+n -----END PGP SIGNATURE----- --=-Teg/zWgmCrr42ZqHZpLx--