From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev-return-8974-arch-gentoo-dev=gentoo.org@gentoo.org> Received: (qmail 12821 invoked by uid 1002); 9 Dec 2003 19:11:47 -0600 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: <mailto:gentoo-dev@gentoo.org> List-Help: <mailto:gentoo-dev-help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 3393 invoked from network); 9 Dec 2003 19:11:45 -0600 Date: Tue, 9 Dec 2003 17:15:02 -0800 From: "Robin H. Johnson" <robbat2@gentoo.org> To: John Nilsson <john@milsson.nu>, Gentoo Developers <gentoo-dev@gentoo.org> Message-ID: <20031210011502.GB2505@curie-int.orbis-terrarum.net> Mail-Followup-To: John Nilsson <john@milsson.nu>, Gentoo Developers <gentoo-dev@gentoo.org> References: <20031209012813.GG15677@newkid> <20031209043949.GA24593@curie-int.orbis-terrarum.net> <20031209221723.GA24847@newkid> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <20031209221723.GA24847@newkid> User-Agent: Mutt/1.5.5.1i Subject: Re: [gentoo-dev] CFLAGS moved to ebuilds. X-Archives-Salt: 0c6029a2-039c-4bb0-a1e2-c04494563b98 X-Archives-Hash: 5411ae447ff3efbd4932ecc9e4857af4 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 09, 2003 at 11:17:23PM +0100, John Nilsson wrote: > >Thats the express purpose that genflags was created for, to provide > >users with a known good set of high-performance CFLAGS so they didn't > >need to mess around with it too much. > Still there is no room for improvement when dealing with system wide =20 > optimization. Your wording here is unclear, I think you mean to say that there IS room for improvement over system wide constant CFLAGS? > >strip-flags to remove problematic flags on a per ebuild basis is the > >best solution. I do agree that unstable gcc settings are a big > >problem, eg in a recent bug it turned out the submitter's system (an > >older Pentium I) couldn't handle -O3 without flaking out. Reduce it > >to -O2 and the box went fine (both for compiling and already compiled > >packages). > This is a bug in GCC. While a workaround may be a quick solution for =20 > Gentoo, one shouldn't base the whole system on bugs. No it isn't a bug in GCC, it's a bug with the user's specific hardware. I have an older Pentium I system that runs just fine with -O3 and the user's specified CFLAGS. I didn't force everybody to use -O2, I just got that user to change his own system down to -O2. > >again, genflags was created for this. I've considered a sequel to > >genflags based on the genetic optimization of compiler flags as > >mentioned on Slashdot a while ago, but for lack of time, i'm not even > >looking at doing it now. > You might want to chek: > http://www.coyotegulch.com/potential/gccga/gccga.html This is the original item I was referencing, but you still run into the problem that you need to run things on a system basis to get effective results. http://www.coyotegulch.com/acovea/index.html is the rest of the article, > http://www.rocklinux.net/packages/ccbench.html This basically brute forces the genetic algorithms, with absolutely no thought as to the net effects on the results of the given flags, eg, on my home server (an AthlonXP 2400+), it returns these results: gcc -O3 -march=3Dathlon -fomit-frame-pointer -funroll-loops -frerun-loop-opt -funroll-all-loops -fschedule-insns Of that, '-frerun-loop-opt' and '-fschedule-insns' are redundant as they are implied by -O3. -fomit-frame-pointer and I can't debug code properly anymore, and if I try to use -funroll-all-loops to compile mysql, even with it's --with-low-memory option, gcc wants 600mb of memory to compile it's sql_yacc.cc. > I meant by evolution: the process of users submiting patches to improve = =20 > individual ebuilds. What improves the performance of a given application on one machine does NOT nessicary improve it on another machine. Read the gcc manpage and see: -fprofile-arcs -fbranch-probabilities (also read http://gcc.gnu.org/news/profiledriven.html) Just adding these to ccbench doubles the amount of time taken to test (as you must compile with -fprofile-arcs, run, compile with -fbranch-probabilities, run again). It also provides some extremely interesting and varying results. The bubblesort test for example, improves between +15% and +300% depending on the other compiler flags. Towers of Hanoi goes from -20% to +50%. If users submitted _good_ non-interactive testcases for every ebuild, it wouldn't difficult to apply -fprofile-arcs/branch-probabilities and or acovea to most packages at all, apart from the massive increase in compile time. > >Stable and high-performance is an per-system definition, as evidenced > >by the bug I mentioned with -O3. > And should as such be fixed... in gcc. If gcc cant optimize correct =20 > knowing the cache size of the cpu, gcc is broken. Fix gcc. Again, it isn't a gcc bug, it's an issue with a specific machine (not even a class of systems or cpus). Lets take a tangent on this whole issue for a moment. Ignoring the implementation concerns, the end goal of your GLEP is this: The basic gain you want, is for the support of per-package CFLAG modifications (inside the ebuilds), for the purpose of performance optimization. Do I have this correct? --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQE/1nOWsnuUTjSIToURAu86AKCPYaGZ4tOe0EcWMfsYx5y+M4bbuQCfYM4j X33351MGsW/6kmwsyUpjfB0= =fIqn -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C--