Bug 24979 - sysdeps: dl_platform detection effectively performs "cripple AMD"
Summary: sysdeps: dl_platform detection effectively performs "cripple AMD"
Status: RESOLVED DUPLICATE of bug 23249
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.32
: P2 normal
Target Milestone: ---
Assignee: Florian Weimer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-08 06:29 UTC by Mingye Wang
Modified: 2019-09-12 15:47 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mingye Wang 2019-09-08 06:29:23 UTC
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.
Comment 1 Mingye Wang 2019-09-08 14:13:44 UTC
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.
Comment 2 Florian Weimer 2019-09-09 07:15:15 UTC
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 ***
Comment 3 Carlos O'Donell 2019-09-12 15:47:32 UTC
(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.