Chris Adams (cmadams(a)hiwaay.net) said:
> - We don't really support i586 in any meaningful matter
What does this mean? Does Fedora not run on i586? Why was there a
mass-rebuild for i586 if it doesn't work?
I know of *no one* in the community who tests on i586 to ensure that it
works. (If this drags them out of silence, so be it!) It is certainly not
part of the QA matrix for testing RCs. On the kernel side, I doubt the kernel
team even has hardware around that they could test fixes on.
On the userspace side, we don't do a lot, if any, of optimization (or
testing) of yum or the installer for working in small memory environments. I
believe the minimum memory actually used for any of the qualification tests
in the installer for F11 was 512MB.
At a certain level, I suspect many, if not all, bugs of a "Fedora does
not install/takes three days to do anything/does not run well" on a i586-class
box are going to be CLOSED/WONTFIX-UNLESS-YOU-ARE-SENDING-A-PATCH, at
*That's* what I mean by "we don't really support i586 in any meaningful
manner". As for why it was done that way in F-11, paranoia mostly (about
the XO not being fully vetted, among other things.)
> - We are likely doing a mass rebuild for F-12 anyways, might as
> while we're doing it
That's a pretty poor justification.
The common complaint leveled about doing it was "why go to the extra effort".
If we're doing a mass rebuild, it's essentailly zero extra effort.
> - Atom is the only currently produced 32-bit x86 chip of note;
> for what's currently available
There are also lots of other chips that people run 32 bit x86 code on.
I don't think Atom is a majority percentage of 32 bix x86 Fedora users
See the Fedora Foundations  and Objectives  page. If we're truly
about being on the leading edge, being innovative, etc., the main target
of Fedora should be current hardware, even if older hardware is still
supported. The only *current* 32-bit x86 hardware is Atom. (And Nano, I
> If you want numbers, I did some benchmarking of code  with
> build options on a variety of processors, with the F-11 gcc code. All
> of these results are relative to a F-11 baseline of "-march=i586
> P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
> march=i686/ -1.1% +2.0% +0.9% +0.6%
> march=i586/ +0.3% -0.3% -0.2% +1.3%
> march=i686/ -1.5% +1.2% +0.5% +1.7%
>  gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode
Okay, before I thought you said this was a "1-2% improvement across the
board", but now it is a 1% improvement on some CPU-intensive operations
on some CPUs (and a 1% performance hit on other CPUs).
Well, if you're using a P4, you may have already lost, as it's not really
a good CPU for optimization, period. The fact that -march=i686 is a lose
on P4 makes it unique among everything I have access to, and the thing
that really dragged the benchmark down on P4 was software we don't even
ship (MP3 decode).
How does this affect multilib on x86_64?