Re: Could an Intel 486 wake up with FC3

From: Aleksandar Milivojevic (amilivojevic_at_pbl.ca)
Date: 01/31/05

  • Next message: James Mckenzie: "Re: FC3 :Apache Problem"
    Date: Mon, 31 Jan 2005 14:34:01 -0600
    To: For users of Fedora Core releases <fedora-list@redhat.com>
    
    

    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@pbl.ca>    Pollard Banknote Limited
    Systems Administrator                           1499 Buffalo Place
    Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7
    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: James Mckenzie: "Re: FC3 :Apache Problem"

    Relevant Pages

    • Re: MICROSOFT WINDOWS XP FIREWALL
      ... Click Start / Help and Support, enter "firewall" in the search box, ... follow instructions. ... >did not know that Win XP had a built in firewall and have ...
      (microsoft.public.windowsupdate)
    • Who Alberts additional assignment fosters, Fahd dares prior to favourite, white gardens.
      ... improved instructions try. ... regrets pairs in support of Ramsi's local philosopher. ... noisy or lexical will combine classical examinations to incidentally ... He may shall newly, unless Allahdad tests ...
      (sci.crypt)
    • [OOPS] 2.6.10-ac9 while watching TV and disk IO
      ... Trace; c0139998 ... This architecture has variable length instructions, ... This decode from eip onwards should be reliable ... # ACPI Support ...
      (Linux-Kernel)
    • Re: feedback to NVidia [was: Nvidia Drivers]
      ... What "C" code causes these instructions to be generated by gcc. ... these engines in the existing gcc code base. ... "C" expect also a complementary lack of support for "C" in these ... Vendor support is my requirement! ...
      (Fedora)
    • [CLA-2004:821] Conectiva Security Announcement - XFree86
      ... Greg MacManus from iDEFENSE Labs discoveredtwo vulnerabilities ... in the way the X server deals with font files. ... It is recommended that all XFree86 users upgrade their packages. ... Detailed instructions regarding the use of apt and upgrade examples ...
      (Bugtraq)