Announcement

Collapse
No announcement yet.

Arch Linux Developers Discuss Idea Of Providing An x86-64-v3 Port

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

  • #21
    Originally posted by StanGenchev View Post
    I get that we should raise the minimum requirements, as it doesn't make any sense to run 2021 OS and software on late 90s and early 2000s hardware but why are they pushing AVX as minimum?

    Does it really matter on OS-level? What are the benefits?
    Also, there are new CPUs from both Intel and AMD that do not have AVX. For example Intel Pentium Gold G6600 was released in 2020 and AMD A8 7680 was released in 2019.

    Are the benefits so big that we are willing to abandon new CPUs?

    Did you even read the article?

    Comment


    • #22
      Originally posted by pininety View Post

      I can understand that but the speed benefit from forcing AVX2 over AVX1 in general use does not seem that big. Oh well, maybe someone will come along and make a v2.5 and then i will be covered.
      Compilers are notoriously poor at making very efficient use of specialized registers, which is why programs that can benefit greatly from them very often use hand-written assembly when utilizing them.

      Said programs typically check at runtime what your CPU supports, and use the appropriate assembly code, so their performance doesn't really depend much on being compiled for a specific '-march='.

      Comment


      • #23
        So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?

        Comment


        • #24
          Originally posted by Random_Jerk View Post
          So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?
          You could also just use CFLAGS/ CXXFLAGS with ="-march=native -O2 -pipe -fstack-protector-strong" and it will be even better than just x86-64-v3.

          Comment


          • #25
            Originally posted by Random_Jerk View Post
            So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?
            You'd need the newest glibc 2.33 and GCC 11.0.1 at the minimum for feature levels to be supported, chances are that you are on an older toolchain. But you can try -march=native for your CPU. I'd add -flto=auto also for LDFLAGS to be on the safe side but I'd need to test if that is really neccessary for using all of your cores with LTO during the linking stage.

            Comment


            • #26
              Originally posted by Random_Jerk View Post
              So, to set switch to v3 for my existing Arch install, all I have to do ...
              ... all you have to do is wait for this proposal to come through and get implemented. As of now, Arch does not offer any ports to newer x86_64 variants.

              For self-built packages, though, yes, you can do that.

              Comment


              • #27
                Originally posted by Random_Jerk View Post
                So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?
                look at https://gitlab.archlinux.org/archlin...90696d3bda7b6b
                To make some tests
                equivalent to x86-64-v3 using current GCC and LLVM, we can compile
                packages using:
                ::
                CFLAGS="$CFLAGS -mcx16 -msahf -mpopcnt -msse3 -msse4.1 -msse4.2 -mssse3 \
                -mavx -mavx2 -mbmi -mbmi2 -mf16c -mfma -mlzcnt -mmovbe -mxsave"
                CXXFLAGS="$CFLAGS"

                Comment


                • #28
                  Originally posted by horstderheld View Post


                  Did you even read the article?
                  Did you read my question?

                  Sarcasm aside I see why you misunderstood, I worded it badly. I'm asking why people/companies in general want AVX as minimum for the OS, not Arch Linux devs specifically. RedHat (and therefore RHEL, CentOS, Fedora), Intel, Canonical and a few others want to raise the minimum requirements and not provide separate "v2" and "v3" releases.
                  Also this is still a suggestion not a fact, so Arch devs could go directly to raising the minimum requirements and not do separate releases. Honestly, it would make sense for such a bleeding edge distro.
                  Last edited by StanGenchev; 16 March 2021, 11:54 AM.

                  Comment


                  • #29
                    Originally posted by Nille View Post
                    Why not go the FatBinary approach. Compile different Versions and link them in one file. And let the CPU Dispacher choose the correct codepath for the system. Full Compatibility with best performance, just for the price of a bit more space required on mass storage.
                    If I remember correctly this approach increases binary sizes by a lot. This approach also limits your optimization opportunities (e.g. as others in this thread pointed out already there are improvements to be had by standardizing on a UEFI-only boot process which are a byproduct of the newer platform but don't have something to do with the ISA; I am sure that there are other new platform or CPU features which could further improve performance or usability if you would make such a hard cut in compatibility).

                    Comment


                    • #30
                      Originally posted by bug77 View Post
                      Yes, please.
                      I concur. I think the new proposal is a good compromise between offering options for both progressives and legacy users, maintenance and infrastructure burden. And after some time they can move entirely to v3 (and start offering a v4 build when Alder Lake/Zen 4 and their successors spread AVX-512 into the mainstream market in volume).

                      Comment

                      Working...
                      X