Aleksandar Milivojevic wrote:
On the sidenote, since i586 is minimal supported platform, I don't know why packages are still built as i386, and not as i586.
*Very* frequently asked question in some quarters. The short answer is that it doesn't appear to be worth it.
There were very few instructions added to the instruction set between the 386 and the 686, and apparently most of those that were added aren't the sort of instructions that noticably accelerate programs.
The exceptions, the instructions that do help performance, give better control of spinlocks and multi-threaded code. That does help, especially on multi-processor kit, but the code that uses those instructions tends to be abstracted into glibc, which *is* compiled for the different processors. [1]
In the meantime, some surprisingly recent kit (VIA CPUs, for example) don't include all the 686 support.
The Fedora development crew have repeatedly said that they would be very interested to see benchmarks that prove a particular program would benefit from different compile settings. [2] But they do expect these benchmarks to be rigourous: same kit, the same location on the drive (if relevant), system rebooted between runs, just different compile flags.
As you say, these days the programs are *optimised* for Pentium 4s: apparently this works well for most other modern x86 CPUs.
James.
[1] Remember that all these programs are cross-platform: they can't rely on running on an Intel-compatible processor, so the Right Thing is usually to push this sort of thing into an OS library.
The thing is, thay haven't pushed it into OS library. And I don't see any plans on releasing those libraries in i586 versions. glibc is built as i386 and i686 only. The only package that is exception from i386/i686 rule is the kernel which is built as i586/i686 (why not build it as i386 with i486 for NPTL, instead of i586, when the rest of the system is built that way anyhow?). Because of this there were some very nasty problems in FC2 when running (some) programs that depend on Berkely DB library. Namely Cyrus IMAPD RPMs were unusable on anything but i686. I found references that for FC3, they compiled glibc with i486 instruction set to resolve the problem (however, glibc RPM still claims to be i386?!).
The problem is that NPTL is considered "must have" on Red Hat systems for some time now. NPTL is available only for i486 and above (for long time it was only i586 or even i686 and above, don't remember correctly). So there is a clash. Base build architecture (i386) can't accomodate a "must have" feature of distribution. Many people found out this the hard way when FC2 was released. Some programs simply did not work on i586. Also worth mentioning is that there will never be support for NPTL using i386-only instruction set (so it isn't something like "we'll wait until it is backported", that port is not going to happen, ever).
It would be kinda cleaner also. There would be only i586 packages, plus several core OS libraries and kernel with both i586 and i686 packages. So that would be only two architectures, instead of the current mix that contains 3 1/2 architectures: i386, glibc quazy-i386 (which is poluted with i486 instructions for NPTL support), i586 (kernel only, glibc should have been built with i586 too, but it wasn't), and i686.
As for VIA processors, I haven't suggested using i686, but i586 as base build architecture (with instruction ordering optimized for current P4s for packages that don't have i686 version, and for i586/P4 for packages that have both i586/i686 versions). Actually, in reality the result was exactly the opposite of what you suggested might happen. Because distribution was mainly built as i386, on FC2 some packages do not work on some of the supported processors. If distribution was mainly built as i586, there would be no problems.
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
