On Tue, 2005-06-21 at 09:54 +0200, Maciej Żenczykowski wrote:

Okay, two questions then... a) If (some) i386 packages are being built with -march=i486 then they (possibly, I do realize there's only like 2 or 3 new instructions) won't run on a 386 anyway, will they? so shouldn't they be called .i486.rpm?

They should. But I'm sure it's some legacy/compatibility consideration I haven't considered. Building for the i486, especially its TLB, makes a world of difference in performance.

b) If i386 is basically no longer used for anything anyway, shouldn't we actually have no .386.rpm packages and instead have .486.rpm for most stuff with .486/586/686/athlon.rpm for kernel/ssl/glibc?

That's basically what we have. AFAIK, Red Hat has been building with --march=i486 and --mtune=i686 (I said "mopt" prior and I was mistaken, it's "mtune") since RHL8.0, possibly 7.3.

I think they even switched to --mtune=pentium4 for some releases, although I have to think Red Hat is re-thinking that since Intel is moving back to the pre-P4 cores. I think that move was because Athlon seems to run P4 optimized code quite well too (BTW, I'm _not_ talking about extensions and the SSE pipes).

c) If redhat isn't supporting anything below a 686 anyway

This seems to be the case on RHEL's kernel, GLibC, etc..., but FC still seems to ship i486 compatible packages for kernel, GLibC, etc... -- although it depends.

then why don't they switch all .386 packages all the way up to 686?

Good question. I assume it's because someone _might_ want to build a i486 kernel, GLibC, etc... Besides, --mtune=i686 atop of --march=i486 does a good enough job without having to go to a completely pre-i686 incompatible --march=i686. It's almost overkill.

And then there's x86-64, which is also an arch/optimization game too (with many options that I won't get into).

I know the performance gain isn't stellar,

Well, there are significant performance gains by merely using -- march=i486 for various support (like the TLB), and then --mtune=i686 optimizes the code generation for a 2-issue MMX + 2-issue FPU which is in all Pentium Pro and forward processors.

For the most part, Intel Pentium Pro/II/III/4 i686 processors execute i486 ISA well enough, and i686 scheduler optimizations brings you very close to what you'd get out of i686 ISA, while still being i486 ISA compatible.

i586 Pentium/Pentium-MMX is quite different though. It sometimes has severe issues with its ALU/control at i486 instructions. Intel learned a lot from the design of i586 as well as Digital on the Alpha, which brought about the i686 re-design even before Pentium "taped-out." The _only_ architecture that _significantly_ benefits from specific ISA builds (and not just optimizations) is i586. i686 executes i486 ISA code quite well, especially if tuned for i686.

Most people don't realize that i586 and i686 were basically less than 2 years apart (1992 and 1994, respectively), even though they are _radically_different_ core designs -- almost done simultaneously (with an initial delay before i686). The problem is that Intel never bothered to introduce a "consumer" i686 until 3-4 years (1997+) after its debut, artificially extending the i586 consumer lifespan to 1998, when it should have died back in 1995, not even 3 years after its intro.

I'm sure that was a business decision coupled with the fact that there were serious packaging v. cost issues to resolve with the i686 design for the time. Ack, so many variables to discuss there.

but if the packages are not designed for installation on anything < 686

Just the kernel, GLibC, etc... lack pre-i686 versions in the _stock_ binary install. What Red Hat is basically saying is that they don't want to support pre-i686 ISAs, and I don't blame them.

At the same time, it would be a significant extra efforts to ensure quality if Red Hat didn't take the overwhelming majority of Fedora Core binaries versions and just ship them in RHEL as-built/tested. Rebuilding for i686 would introduce issues, for little performance gain beyond the current march=i486/mtune=i686 approach.

At least that is my "best guess."

then there's not much point in _not_ compiling for 686 - the binary packages will be the approx same size anyway and will require the same amount of CDspace/bandwidth.

I think it's more about shipping packages that have been well tested as- is in Fedora Core. Again, march=i486/mtune=i686 gets you very close.

I know someone will say that those packages could be used on a non-686 class CPU, but on a non-686 class CPU you don't want to be using a recent distribution anyway, do you?

I'm sure a major factor is the largely unified FC-RHEL inter-quality, as well as just testing in general. There's not much to gain by building with --march=i686 versus --march=i486/--mtune=i686. The reliability in re-using the build that has been tested in the "leading edge" distros (RHL/FC) for the "enterprise" distro (RHEL) outways it IMHO.

Except for the few, core packages that can make a major difference -- like the kernel, GLibC, etc..., --march=i486/--mtune=i686 brings you pretty close to --march=i686.

I have a 350MHz Celeron (which is a 686) and it is already way to slow for any desktop/Xwindows applications (Fedora Core 2 on a Celeron 400

• 192MB ram is basically usable with a light window manager [twm], but

that's about the limit). So the class of CPU's which aren't 686, but which could use RHEL4/Centos4 are very limited (aren't they?) to only a minimum core set of server applications... Anyway you get my drift... :) Comments?

You haven't seen a 500+MHz i486 ISA compatible, have you? SGS-Thompson makes them, and even Cyrix got up there on the M1 clocks (well over 300MHz, possibly 400MHz IIRC?).

Well Okay, so maybe it wasn't two :)

Maciej Żenczykowski wrote:

c) If redhat isn't supporting anything below a 686 anyway then why don't they switch all .386 packages all the way up to 686? I know the performance gain isn't stellar, but if the packages are not designed for installation on anything < 686 then there's not much point in _not_ compiling for 686 - the binary packages will be the approx same size anyway and will require the same amount of CDspace/bandwidth.

The key word is "support". They don't support it, but you are welcome to install it on preatty much anything from i386 to P4, and it will most likely run. The "we don't support it" here means only that if you run into trouble, you are on your own to solve it. I think Bryan was a bit wrong when it said how the packages are compiled. The options are "-m32 -march=i386 -mtune=i686" for wast majority of packages (some have different tune option). If you ever build any SRPM package, you'll clearly see that in the output. Unless Red Hat folks are manually instructing rpmbuild to use -march=i486 flag on each and every build. That combination of flags is probably the most tested one, and by far less likely to generate incorrect code than any other combination of flags.

To install on i386 or i486 you'd obviously need to build kernel yourself (for some distros, you'd also need to build i586 kernel). All other packages will work, even the quazy-i386 glibc. On i386 you will loose NPTL, and that is the only part of glibc that uses i486 instructions (the rest is compiled with -march=i386). Actually, if you list the files from i386 glibc package, you'll see it has way more branched directory structure than i686 version of package (i386 version has directory branches with additional i486, i586 and i686 optimized code).

For average package, there is almost no difference in size and performance if compiled with -march=i386 or -march=i686. The almost only part of instruction set where you would see performance benefits are instructions for implementing atomic locking and SMP. Since that stuff is handled almost exclusivly in kernel and glibc, that's why those are practically almost the only packages with dedicated i686 version (plus openssl libraries, that seem to benefit from i686 instruction set too).

On Tue, 2005-06-21 at 08:47 -0400, Matthew Miller wrote:

This is highly, highly theoretical, since I don't think there's very many machines anywhere in the world with a i386 ISA and enough memory to boot CentOS.

Not even embedded cores from a almost decade ago use less than an i486 ISA compatible. Don't forget embedded, because there _are_ "Pentium II class" (500MHz) cores that _are_ only i486 ISA compatible.

Not worth the bother. In a few years, everything will be x86_64.

x86/PAE36 will continue for a long, long time -- be it embedded or in virtual machines (in the near future of virtual cores).