Glibc received the capability to transparently load libraries for specific CPU families with some SIMD extensions combinations in 2017, a move that should be beneficial for a lot of x86 users. However, the current form of the implementation[1] limits two "good" sets of modern SIMD instructions to Intel processors only, preventing competitor CPUs with equivalent capabilities to fully perform, something that should not happen in any free software package. This feels quite like a flashback to the icc/mkl "cripple AMD" routine from 2009.[2] [1]: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1432d38ea04ab5e96f21a38;hp=3b5f801ddb838311b5b05c218caac3bdb00d7c95 (see also the current sysdeps/x86/cpu-features.c) [2]: http://www.agner.org/optimize/blog/read.php?i=49 The crux of the problem lies in the `(cpu_features->kind == arch_kind_intel)` (LHS now renamed cpu_features->basic.kind) comparison that surrounds the entire x86_64 case. Although AMD has not yet made any processors with AVX512, their newer processors (Zen -- Epyc, Ryzen) should at least satisfy the haswell test case. Since the dl_platform check is only used for dispatching SIMD libraries anyways, glibc should remove the check and let the processors prove themselves with their feature flags.
A minor update on AMD CPUs: according to the bunch of PTA_* macros in GCC sources, 2017Q1 AMD Zen (znver1) does cover everything Haswell has with the exception of HLE (Hardware Lock Elision), a backward-compatible feature. In other words, all haswell binaries will work on znver1.
We really need feedback from AMD for this change, and it has been difficult for us to talk to engineers there. If you have contacts there, please encourage them to reach out to Red Hat Engineer Partner Management via their own channels (or contact me directly). I agree that this situation is unfortunate, and that AMD customers may not get the best possible performance as the result. The "haswell" platform subdirectory is somewhat ill-defined, see bug 24080. I don't think current AMD CPUs implement the ERMS feature, which Intel assumes is part of the "haswell" definition. *** This bug has been marked as a duplicate of bug 23249 ***
(In reply to Florian Weimer from comment #2) > We really need feedback from AMD for this change, and it has been difficult > for us to talk to engineers there. If you have contacts there, please > encourage them to reach out to Red Hat Engineer Partner Management via their > own channels (or contact me directly). I agree that this situation is > unfortunate, and that AMD customers may not get the best possible > performance as the result. Agreed. We want to give AMD customers the best possible performance, and that requires collaboration with AMD.