AMD Developers Looking At GNU C Library Platform Optimizations For Zen

[ddriver]

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.

[Michael]

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.

[sykobee]

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).

[Nille]

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?

[ms178]

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.

[Volta]

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.

[Sethox]

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.

[Volta]

AMD became smarter. Just about time.

[phoronix]

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...

http://www.phoronix.com/scan.php?page=news_item&px=GNU-libc-Platform-Optimize-Zen