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

[phoronix]

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?page=news_item&px=AMD-GNU-Discussing-Better-RT

[geearf]

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?

[kylew77]

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!

[wizard69]

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.

[eydee]

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.

[JustinTurdeau]

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.

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.

[discordian]

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.

[zxy_thf]

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.

[jabl]

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.

[brent]

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?