[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)

Chris Adams (cmadams 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

*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

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


[1] http://fedoraproject.org/wiki/Foundations
[2] http://fedoraproject.org/wiki/Objectives

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]