-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Silviu Marin-Caea wrote: > On Wednesday 11 October 2006 19:13, Andreas Jaeger wrote: >> We have so far two compiler optimization topics: >> >> * Building for i686 in the future (Bug 186074) > > Hell, yeah!! > > Who's installing SUSE on Pentium I nowadays? I have a Pentium II CPU > to donate to one such individual in the totally unlikely case > he exists. :-)
Please read the complete thread on the bug, especially my comment: https://bugzilla.novell.com/show_bug.cgi?id=186074#c34 IMO that point is ridiculous (where's the evidence ? real benchmarks ?) lame as a typical application ? ah cmon... I've seen these discussions over and over again, and never seen any real evidence that optimizing for i686 (or athlon) instead of i586 actually brings any noticeable performance gain *for typical applications* (OpenOffice, firefox, thunderbird, KDE, digikam, ... or even postfix, apache, ...). Those typical applications usually do a lot more I/O (disk or other devices) than they do raw CPU processing (lame is a really bad example wrt this as it is exactly the opposite). While it might make sense for a very few packages, it doesn't for 99% of them (please please please prove me wrong). When will people understand that compiler optimization flags are no black magic wand that makes your system faster. The best way to achieve a faster running system is optimizing the code itself (use less memory, use more effective algorithms or technologies), not compiler voodoo. Get real. The compiler has a pretty dumb and generic view of your code, it does not understand what you are trying to do. OTOH the software developer can make modifications that provide a huge performance benefit (e.g. not loading the same file several times but load once and cache, do less I/O, use less memory, use SAX/StAX for XML parsing instead of DOM, use optimized SQL queries and indexes, ...). And I've never seen compiler flags make I/O operations faster. Note that -Bdirect and similar optimizations are a totally different thing. Those actually provide a huge benefit wrt loading shared libraries at startup (and hence, make application startup a lot faster) because they more or less "fix" the dumbness of the linker and dynamic linker wrt shared libraries. - -Bdirect is being developed mostly by ppl from Novell (especially Michael Meeks, you can hardly follow his talks about that [1], it's a very complex topic ;)). But you must always take potential side effects into account and this is why changing compiler and linker flags needs a lot of thorough testing because in the end, what we want most is applications that *work*. Optimizing for i686 definitely has a drawback: makes running SUSE on old hardware impossible (agreed, that would be really old hardware, but still). [1]http://ftp.belnet.be/mirrors/FOSDEM/FOSDEM2006-OpenOffice.avi cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFLjyYr3NMWliFcXcRAlDTAJ4siXHSwxE7FjOfP/0E/ChpEGx1GwCfXt0s GTlBX0xUP7kuF/RxPhulrhY= =ckQ/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
