Announcement

Collapse
No announcement yet.

AMD Working With GNU Developers To Provide More Robust Runtime Detection For Better Performance

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

  • AMD Working With GNU Developers To Provide More Robust Runtime Detection For Better Performance

    Phoronix: AMD Working With GNU Developers To Provide More Robust Runtime Detection For Better Performance

    Back in March we reported how AMD developers were looking at GNU C Library platform optimizations for Zen and in part could be leveraging some of the capabilities currently employed by Intel for Haswell and newer. It's looking like some solid progress is being made in that direction...

    http://www.phoronix.com/scan.php?pag...sing-Better-RT

  • #2
    When he says

    AVX2-optimized libraries
    Is it about how Clear ships various builds of the libraries depending on the CPU used?
    If so, will this be useful on any other distribution?

    Comment


    • #3
      Wow so existing Threadripper and Ryzen and Epix Processors have been running with one hand tied behind their back and are still as performant as they are!! Wow, can't wait to see how much better the 3 preform once using optimized compilers!

      Comment


      • #4
        Originally posted by kylew77 View Post
        Wow so existing Threadripper and Ryzen and Epix Processors have been running with one hand tied behind their back and are still as performant as they are!! Wow, can't wait to see how much better the 3 preform once using optimized compilers!
        My thoughts reading this article. I'm glad to see people making these AMD improvements public because some don't believe me when I say Linux gets better on AMD with every kernel update. While this isn't "kernel" per say it just moves performance forward even on leading edge hardware. Gotta like that.

        Comment


        • #5
          Originally posted by kylew77 View Post
          Wow so existing Threadripper and Ryzen and Epix Processors have been running with one hand tied behind their back and are still as performant as they are!! Wow, can't wait to see how much better the 3 preform once using optimized compilers!
          Probably that's an overestimation. The improvement should be there, but still quite small. Otherwise all other compilers/platforms could be lightyears ahead with gcc lagging behind, considering how unlikely it is that everyone keeps making the same mistake for several years.

          Comment


          • #6
            Originally posted by eydee View Post
            Otherwise all other compilers/platforms could be lightyears ahead with gcc lagging behind, considering how unlikely it is that everyone keeps making the same mistake for several years.
            What are you even talking about? This has very little to do with compilers. It's about making AMD processors use the SIMD-optimized ifuncs in glibc.

            Originally posted by eydee View Post
            Probably that's an overestimation. The improvement should be there, but still quite small
            That depends on the code in question, but it's not uncommon for routines like memchr() to be a bottleneck in some apps and SIMD can speed up such routines considerably.

            Comment


            • #7
              Originally posted by kylew77 View Post
              Wow so existing Threadripper and Ryzen and Epix Processors have been running with one hand tied behind their back and are still as performant as they are!! Wow, can't wait to see how much better the 3 preform once using optimized compilers!
              Nope, no new optimizations. This is just a separate binary with

              - Fallbacks removed (instead of picking the path at runtime)
              - potential improvements as the compiler can target the cpu

              None of which will make a big difference. If you need avx to get performance, then you won't do that through libc.

              Comment


              • #8
                One interesting point is, it may be about the time to propose a superset of x86_64 that includes "BMI1, BMI2, LZCNT, MOVBE, POPCNT, AVX2 and FMA", and name it as something like amd64.1 or x86_64b.

                Comment


                • #9
                  Originally posted by zxy_thf View Post
                  One interesting point is, it may be about the time to propose a superset of x86_64 that includes "BMI1, BMI2, LZCNT, MOVBE, POPCNT, AVX2 and FMA", and name it as something like amd64.1 or x86_64b.
                  Yes, and no.

                  Maintaining an ABI, compiling and testing distros for it is a huge and ongoing maintenance burden (see also: why is the X32 ABI more or less dead?).

                  What they're doing here might actually make sense, defining a new baseline (whether you call it "haswell", "x86_64b" or whatever) which is ABI-compatible with the existing x86-64 psABI, just an additional directory that is added to the default search path on compatible systems, and which libraries like glibc can opt-in to use.

                  Comment


                  • #10
                    It's infuriating that glibc uses the same bullshit vendor check to opt into these optimizations. And some maintainers even argue in favor of it. Why was this ever merged?

                    Comment

                    Working...
                    X