Announcement

Collapse
No announcement yet.

AMD Developers Looking At GNU C Library Platform Optimizations For Zen

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

  • AMD Developers Looking At GNU C Library Platform Optimizations For Zen

    Phoronix: AMD Developers Looking At GNU C Library Platform Optimizations For Zen

    It's long overdue but AMD engineers are now looking at refactoring the GNU C Library (Glibc) platform support to enhance the performance for AMD Zen processors...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    AMD became smarter. Just about time.

    Comment


    • #3
      Originally posted by Volta View Post
      AMD became smarter. Just about time.
      I'd say that AMD just put valuable resources on the right places, in my mind "smarts" has nothing to do with choice (only reasoning). Let's see if they keep up the trend.

      Comment


      • #4
        Originally posted by Sethox View Post
        I'd say that AMD just put valuable resources on the right places, in my mind "smarts" has nothing to do with choice (only reasoning). Let's see if they keep up the trend.
        If they did this earlier they would have even higher advantage in the server area now.

        Comment


        • #5
          Originally posted by Volta View Post

          If they did this earlier they would have even higher advantage in the server area now.
          I agree that AMD is very late on this topic, but better late than never. And their current users will see a free performance boost out of this. I wonder if upstream Glibc developers could have implemented the ifunc functionality differently to be of use to both Intel and AMD (and other x86 vendors) from the start. As Haswell and Zen share much of the same instructions I don't get it why they haven't enabled the functionality there, too. Their concerns of performance regressions could have been checked with testing on that hardware.

          Comment


          • #6
            As a owner of a 3600 im happy about it. But why were advanced options behind a vendor check? i understand if intel does this in his own stuff, but in the gnu c library?

            Comment


            • #7
              It's good this is happening, now. Sad that AMD neglected this, despite seemingly being chased.

              However surely this should be more generic? Isn't this why we have cpuid in x86 (although this is for loading libraries tbh, not a good idea to do inline cpuid calls in these, only when loading)? I guess the argument that an ISA is present but slower than an alternative is reasonable to retain overrides, but the default should be to obey what the CPU says it can do.

              I guess having /intel/haswell|icelake|etc and /amd/zen|zen2|zen3 (and /via/...) is good for distributing pre-built optimised libraries in x86-64 distros.

              Shame that they don't do it like ARM - just specify a complete architecture specification for arch impls to follow, or risc-v with extensions. These haswell binaries are a good start as one of these specifications - you either support all of that, or you're not compatible with that level of the specification (ARM v8.x as comparison).
              Last edited by sykobee; 25 March 2020, 09:22 AM.

              Comment


              • #8
                Originally posted by Nille View Post
                As a owner of a 3600 im happy about it. But why were advanced options behind a vendor check? i understand if intel does this in his own stuff, but in the gnu c library?
                Because AMD developers weren't there to test/comment when Intel was upstreaming that code in the first place and obviously Intel is only testing on their own hardware. Especially in some cases around AVX it may make sense to be more selective when to enable it given the frequency differences and other behavior.
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #9
                  It's not that the GNU C Library has been intentionally thwarting AMD CPUs
                  Yeah, let's not support amd cuz intel has teh moneyz to do our job for us and poor amd is cheaping out...

                  Precisely the same kind of putrid scheme nvidia has employed to discourage most game developers from properly optimizing their games for radeon.

                  Comment


                  • #10
                    By the way, as Clear Linux makes heavy use of that functionality, I'd bet that AMD CPUs will see additional significant performance gains in some benchmarks. One user already reported: "I patched cpu-features.c to allow arch_kind_amd cpus to match the haswell platform definition and have been getting good very good performance results with the glibc-bench benchmarks as well as a haswell optimized openblas which in turn improved results for R and octave (on a znver2 cpu). It seems intel as already has done most of the hard work for amd here?"

                    Comment

                    Working...
                    X