From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28524 invoked from network); 8 Sep 2004 11:31:33 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 8 Sep 2004 11:31:33 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C50ff-000187-Du for arch-gentoo-dev@lists.gentoo.org; Wed, 08 Sep 2004 11:31:28 +0000 Received: (qmail 4066 invoked by uid 89); 8 Sep 2004 11:31:15 +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 31767 invoked from network); 8 Sep 2004 11:31:15 +0000 From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Date: Wed, 8 Sep 2004 13:29:01 +0200 User-Agent: KMail/1.7 References: <33333.10.0.0.51.1094638559.squirrel@10.0.0.51> In-Reply-To: <33333.10.0.0.51.1094638559.squirrel@10.0.0.51> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2786465.JR3D0UGuex"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409081329.10457.pauldv@gentoo.org> Subject: Re: [gentoo-dev] Do we want optimal performance? X-Archives-Salt: 0db7d310-7a3c-4a75-867e-7d3c51641e72 X-Archives-Hash: b8d113bf64f072874790cbd11786ef19 --nextPart2786465.JR3D0UGuex Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=3D2163&p=3D1 > > 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=20 "tests" that simulate the real world use of the application. Of course=20 that also allows -fprofile_arcs to be used. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart2786465.JR3D0UGuex Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBPu0GbKx5DBjWFdsRAuRnAKDRdWqEpjcLqwlz0d4ldoGLm4UgcwCgnRVA WQn4Pgow+w/brcpN/H1stNo= =Yiad -----END PGP SIGNATURE----- --nextPart2786465.JR3D0UGuex--