Chris Adams (cmadams@xxxxxxxxxx) 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 best. *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 well switch > > 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; optimize > > 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 > either. See the Fedora Foundations [1] and Objectives [2] 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 suppose.) > > If you want numbers, I did some benchmarking of code [1] with various > > 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 > > -mtune=generic". > > > > P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270 > > march=i686/ -1.1% +2.0% +0.9% +0.6% > > mtune=generic > > march=i586/ +0.3% -0.3% -0.2% +1.3% > > mtune=atom > > march=i686/ -1.5% +1.2% +0.5% +1.7% > > mtune=atom > > > > Bill > > > > [1] 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? It doesn't. Bill [1] http://fedoraproject.org/wiki/Foundations [2] http://fedoraproject.org/wiki/Objectives -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
