From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29146 invoked from network); 8 Sep 2004 19:11:06 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 8 Sep 2004 19:11:06 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C57qT-0001YB-Qf for arch-gentoo-dev@lists.gentoo.org; Wed, 08 Sep 2004 19:11:05 +0000 Received: (qmail 32665 invoked by uid 89); 8 Sep 2004 19:11:05 +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 21298 invoked from network); 8 Sep 2004 19:11:04 +0000 Message-ID: <32927.10.0.0.51.1094670662.squirrel@10.0.0.51> In-Reply-To: <1094667618.17323.74.camel@cgianelloni.nuvox.net> References: <33333.10.0.0.51.1094638559.squirrel@10.0.0.51> <1094667618.17323.74.camel@cgianelloni.nuvox.net> Date: Wed, 8 Sep 2004 21:11:02 +0200 (CEST) From: "Klavs Klavsen" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at enableit.dk Subject: Re: [gentoo-dev] Do we want optimal performance? X-Archives-Salt: 7d338bd7-7ac7-446a-9c0b-0e3fc6e801e0 X-Archives-Hash: 21fa77a471f66590c943846bae411c24 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