The problem is that GCC is not (or at least wasn't when I tested it on gcc 2.96) smart enough to optimize for processor X while restricting to Y instruction set when Y is different from both X and 386. Ie if you use "-mcpu=i686 -march=i586" (ie optimize for 686 but restrict to Pentium instruction) it generates code who runs at exactly the same speed that if you had typed "-mcpu=i686 -march=i386". When I say exactly I mean within 0.1% or 0.2% margin (ie within noise limits) and for EVERY test. The usual thing when playing with compiler parms was that on at least one of my tests one of the flags providing at least a 2 or 3% difference. Not there. Complete equality. At this point the logical deduction is that gcc "downgraded" to 386 mode because it was unable to generate code using the 686 timetable and 586 instructions. As I said I tested the above on gcc 2.96 and haven't repeated the experience on gcc 3.x So except for marketing purposes it doesn't make sense to try to compile "normal" packages with 586 as the minimal processor. The packages where there will be a difference are those who rely either on hand-written assembler like the kernel or glibc. On Mon, 2005-01-31 at 21:34, Aleksandar Milivojevic wrote: > James Wilkinson wrote: > > 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 -- Jean Francois Martinez <jfm512@xxxxxxx>
