Mailinglist Archive: opensuse-factory (592 mails)

< Previous Next >
Re: [opensuse-factory] Topics for tomorrow's dist meeting
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Thu, 12 Oct 2006 15:01:12 +0200
  • Message-id: <452E3C98.4040507@xxxxxxxxx>
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:

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).


- --
-o) Pascal Bleser
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
Version: GnuPG v1.4.2 (GNU/Linux)

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups