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