Announcement

Collapse
No announcement yet.

Fedora 29 Proposal "i686 Is For x86-64" Would Allow More Optimizations, Require SSE2

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora 29 Proposal "i686 Is For x86-64" Would Allow More Optimizations, Require SSE2

    Phoronix: Fedora 29 Proposal "i686 Is For x86-64" Would Allow More Optimizations, Require SSE2

    For years Fedora has been demoting 32-bit x86 and there's been efforts to drop 32-bit kernel builds and related efforts while the latest x86 proposal causing some controversy is the "i686 is for x86-64" feature proposal...

    http://www.phoronix.com/scan.php?pag...29-i686-x86_64

  • #2
    this seems like a very smart idea, this way "modern" 32 bit cpus will still be supported without hurting newer cpus, some Atoms comes to mind
    Last edited by davidbepo; 06-04-2018, 11:26 AM.

    Comment


    • #3
      I love it.

      Comment


      • #4
        Originally posted by davidbepo View Post
        this seems like a very smart idea, this way "modern" 32 bit cpus will still be supported without hurting newer cpus, some Atoms comes to mind
        32-bit x86 code is also somewhat smaller, which is better for 1M caches on some dual-core systems and of course consumes less RAM on systems with <4GB in total. Also most systems since 2001 support SSE2. Plain i686 covers the machines produced between 1995-2001. Those usually had less than one gigabyte of RAM (most likely 64 to 384 MB).
        Last edited by caligula; 06-04-2018, 11:47 AM.

        Comment


        • #5
          Well, if they did drop the i686 ISO images, then this shouldn't be that controversial, I mean since they'd be used in multilib anyway. I'm partial to this since i686 is already not "i386" (i.e. so it supports stuff like cmov and other such basic instructions) so it's not like their packages were already "maximally compatible" with old CPUs.

          Note that, to me, compatibility with 32-bit (or any) software is way more important than old cpu compatibility, so I don't see this as a problem at all (I'm aware some people will tho). Since they will retain compatibility and in fact even make it run a bit faster perhaps. It's not just about the old cpus when it's about 32-bit, the software can also use even AVX and such (albeit less registers than on x64 mode) though most people seem to think it must necessarily be i386 only.

          Another solution would be runtime dispatching of functions, but I guess that would bloat some things up (i.e. one path for x87, another for SSE2, ...). And yeah, 32-bit code is friendlier to cache, also data structures using a lot of pointers. Remember that cache space wastes a large amount of the CPU die, so it's pretty important.

          Comment


          • #6
            I am all for deprecating all CPUs before SS4. For 32-bit multilib call it i786

            Comment


            • #7
              Originally posted by gnufreex View Post
              I am all for deprecating all CPUs before SS4. For 32-bit multilib call it i786
              More like i868. i686 was Pentium Pro and Pentium 2. This is K8/P4 tech. so two generations later.

              Comment


              • #8
                Btw, why not set the new limit to SSSE3/SSE4 though? That would still cover all CPUs made the last 10 years, and up the x64 minimum at the same time.

                Comment


                • #9
                  Originally posted by carewolf View Post
                  Btw, why not set the new limit to SSSE3/SSE4 though? That would still cover all CPUs made the last 10 years, and up the x64 minimum at the same time.
                  The improvements in >SSE2 aren't as significant in general.

                  Comment


                  • #10
                    This could be awkward if intel release their next gen CPUs without SSE2 support.

                    AFAIK that was on the board to stop their designs performance being limited due to support for legacy instructions

                    Comment

                    Working...
                    X