10 ms·

Glibc sysdeps: dl_platform detection effectively performs “cripple AMD”

217 points by arthur2e5 7y ago

panpanna 7y ago
Wait, where in glibc is SIMD used anyway?
- clmul 7y ago
  I know that it is used at least for the implementation of functions like memcpy.
- bonzini 7y ago
  All string functions: not surprising since recent processors have the crazy PCMPxSTRy instructions that are basically a hardware implementation of strcmp, strchr, memchr, strspn etc. memcpy and memset use SSE on some generations, but these days are best inlined by the compiler as "rep movsb/stosb".
  - stingraycharles 7y ago
    I better hope AVX512 isn’t used on simple string functions, as it causes so much heat Intel CPUs have to reduce their clock speed significantly, affecting other running processes as well. https://www.tcm.phy.cam.ac.uk/~mjr/IT/clocks.html https://www.tcm.phy.cam.ac.uk/~mjr/IT/clocks.html
    - physicsguy 7y ago
      There’s nothing wrong with dropping the clock speed when the whole point of SIMD instructions is that they execute on multiple data. As long as the clock speed drop beats the multiplicative speedup from doing 4x/8x/whatever operations in parallel, it’s fine
      - stingraycharles 7y ago
        My point is that the clock speed is also dropped for other processes. So it's not a simple heuristic "oh if we have more data than X we can use AVX512 instead of AVX256", because you do not know what other processes are doing, and they will be slowed down as well. This type of heuristic only works if you are the sole users of the server, e.g. a database server.
      - vnorilo 7y ago
        The problem is that the architecture in question would take forever in cpu time terms to switch back and forth, so a sprinkle of heavy avx512 was the worst of all worlds. In addition, some cpus would emulate 512 with half width micro-ops during voltage ramp up. Yes, it sounds crazy.
      - temac 7y ago
        Not it is not fine at all. If you have too many instructions but not enough, your whole CPU will run slower mostly on non AVX-512 instructions, and maybe even your whole package => the end result will just be slower. Not to say that those processors are bad, but AVX-512 on them is for niche workloads.
    - lazyjones 7y ago
      > it causes so much heat Intel CPUs have to reduce their clock speed significantly, How about: don't buy affected CPUs if you care. The last thing people who write libraries should care about is a few selected CPUs that underperform on a generally useful feature.
      - temac 7y ago
        Nope. At this point given the state of the market, and given what AVX512 does to begin with (so maybe the "at this point" will be for forever), it makes very very little sense to use it everywhere. It would just be actively detrimental to most users.
    - jbapple 7y ago
      The instruction and instruction set referenced in the comment you're referring to (PCMPxSTRy and SSE) are not AVX512; they were introduced long before AVX512 chips were manufactured.
  - saagarjha 7y ago
    > memcpy and memset use SSE on some generations, but these days are best inlined by the compiler as "rep movsb/stosb". Why? I’ve usually seen this get compiled to some version of “mov byte ptr, inc”.
    - bonzini 7y ago
      You want to copy more one byte at a time (unrolling by 4, 8 or more; and for memset, multiplying the stored value by 0x01010101...). In recent processors rep movsb and rep stosb do all that in microcode, and are also able to copy or fill the destination one cache line at a time.
  - robocat 7y ago
    For example strlen: https://stackoverflow.com/questions/57650895/why-does-glibcs-strlen-need-to-be-so-complicated-to-run-quickly https://stackoverflow.com/questions/57650895/why-does-glibcs...
    - temac 7y ago
      That's not a very good example; this code is generic (although non portable) C optimized implementation, not something making use of fancy processor instructions. It is even less probable that the compiler understand it and manage to optimize it to using dedicated instructions, when it is written that way.
- fulafel 7y ago
  Compilers do autovectorization (with varying degrees of success) so potentially in lots of places?
  - goatinaboat 7y ago
    This is about the library not the compiler.
    - LfLxfxxLxfxx 7y ago
      A library is compiled with a compiler.
      - masklinn 7y ago
        This check is the opposite of compiler autovectorisation. Its point is specifically for the library to dispatch between implementations (e.g. to an explicitly vectorised one)
        fulafel 7y ago
        Yes, and it can make sense to dispatch between compiler-vectorised and non-simd implementations.
        masklinn 7y ago
        It does make sense, the issue at hand is how it's done: by checking for the CPU vendor / product line rather than asking the CPU if it has the operations we want.
        fulafel 7y ago
        Yep - capabilities based switching makes most sense when you are just interested on what code can successfully execute, and not making decisions based on known perf characteristics of microarchitectures. But this subthread was about "where in glibc is SIMD used anyway?" and the answer is that in all code, potentially.
- arthur2e5 7y ago
  Read the bug again! The feature is about "transparently" loading libraries that are put in specific subdirectories based on the CPU so that a single configuration can work fast everywhere. Intel's Clear Linux wrote about that in https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture https://clearlinux.org/news-blogs/transparent-use-library-pa....
cotillion 7y ago
While this patch from @intel.com looks bad i wonder what has AMD been doing in the meantime? Atleast intel appears to have someone looking at Glibc performance.
- rwire 7y ago
  Does anyone have (a source to) stories about cable-cutting among telecom providers? I've encountered them before but now all I can find is this little lawsuit against Comcast: https://copocetic.com/accused-of-actual-cord-cutting-comcast-kinda-sorta-denies-it-b7d73700345 https://copocetic.com/accused-of-actual-cord-cutting-comcast...
- PedroBatista 7y ago
  Intel’s software division is bigger the the whole AMD.
hunta2097 7y ago
Could this be a legitimate unintended consequence of the pull request or some new dirty pool tactic? Either way I agree with Mingye Wang's assessment, this kind of thing cannot be allowed to get into the source tree. Hopefully AMD will increase their Linux activities with their new bigger market share and income.
krapht 7y ago
Hm, is this really "crippling" AMD? Seems more like Intel submitted a performance patch that is only enabled for Intel processors, but could be extended to support AMD too. There's a moral difference. It is wrong to intentionally degrade the performance of your competitors. It is not wrong to not do something that benefits others.
- acqq 7y ago
  > It is not wrong to not do something that benefits others. The patch however sneakily removes the chance that the features existing and working on the competing processors are properly detected and used. In free software it’s clearly evil.
  - ori_b 7y ago
    So patch it. That's the point of free software: the freedom to modify it to your needs.
    - smcl 7y ago
      Well the patch certainly met Intel's needs (a nice little performance bump over its ascendant rival) ... and since someone with a keen eye spotted it, now the rest of us can submit a patch to correct that. But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.
      - jlg23 7y ago
        > But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well. In large FOSS projects you have enough eyes on those patches to ensure they actually converge towards some (unbiased) optimum.
        alacombe 7y ago
        That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?
rgbrenner 7y ago
Am I missing something? Intel submitted a patch in 2017 that enabled support for a feature that was supported in their processors. 2 years later, AMD still hasn't made processors that support one of those features (AVX512), and only recently released processors that met the requirements for the other haswell test... And somehow this is labeled "cripple AMD"? It would be one thing if Intel did this while AMD had processors that worked on it.. but they didn't. And code cannot tell the future. That's why we have programmers. They're supposed to change the code when it needs to be changed.
- FartyMcFarter 7y ago
  > And code cannot tell the future. In this case it doesn't need to, I believe. There are ways to find out at runtime which instruction sets are supported, in a vendor-agnostic way.
  - arthur2e5 7y ago
    "Code cannot tell the future" is also the 2009 excuse Intel gave for icc not supporting processors that are GenuineIntel but not Family 6, incidentally. History is wonderful, isn't it? Back in the days we already knew what the still-current best practice to see what flags a CPU has is.
    - JustFinishedBSG 7y ago
      You can't expect Intel to know about obscure features like CPU feature flags, it's not like they invented it.... oh.
- adrian_b 7y ago
  "only recently released processors that met the requirements for the other haswell" This is false. Zen was introduced in Q1 2017, before that patch was written and it already implemented all the useful parts of the Skylake instruction set (and also the SHA extension not implemented by Skylake). The fact that the CPU vendor should not be used when testing for CPU features was already discussed a lot, many years ago, so someone of the library maintainers should have noticed this bug and removed the inappropriate test. About AMD not supporting yet AVX-512, that is far less annoying than the fact that Intel does not support AVX-512 yet in any of their CPUs which are actually competitive in their target market (Ice Lake is worse than Comet Lake, Cascade Lake is worse than Epyc 2).
kbumsik 7y ago
Isn't it AMD's job, not GNU's job? > something that should not happen in any free software package. Some people takes "free software" pretty wrong. Free software doesn't mean being fair to all hardwares. It only is fair to accepting contributions from people who want their machines to work with it. They would be individual contributors but they are mostly people from the hardware vendors. That's being said, Linux/Free software have being supporting Intel very well because Intel itself is one of the biggest contributor. It's time for AMD to hire more software engineers to support better drivers and software ecosystem.
- raverbashing 7y ago
  No, it is GNU's job Features have feature flags, you shouldn't be doing comparison like "this is an Intel model X then it runs this" but it should be "this has feature X then it supports X" period It's the same crap as the ICC compiler throwing the slower code at AMD even though it would support the features
  - smcl 7y ago
    It's the job of the maintainer of glibc, but I think we can legitimately ask questions of Intel's contribution since it's pretty sneaky and in bad faith
    - raverbashing 7y ago
      Yes this should have been caught in a code review
- simion314 7y ago
  The code is bad, it should detect features not vendor names . the proper fix should be CC-ed to the Intel developer so he can learn the good way of doing it. This kind of bad code makes sites to ask me to run a modern browser just because my modern browser is not in the dev whitelist or this kind of bad code caused Microsoft not to have Windows9 because some developers where clever and instead of checking for features or check for win95 and win98 they wrote a shorter line of code and checked for "Win9". In conclusion there are 2 possibilities: 1 the Intel dev did a mistake 2 it was intentional to limit the improvements to Intel only you are arguing that 2 is fine, then you are fine if google, Facebooks, Microsoft also put checks in their commits and limit features only if the code runs in their OS,browser,site. This kind of obvious user hostile commits are bad and don't have a place in free software and IMO the Intel compiler should not intentionally cripple a competitor. Also this attitude would mean that each company should now have a developer dedicated to check competitors contributions to make sure no intentional bad commits are sneak in because in your opinion is fair to intentionally do it.
AnssiH 7y ago
The point is to put Haswell-optimized code in the "haswell" subdirectory. However, compiling code with -march=haswell (implying -mtune=haswell) does a lot of other platform/manufacturer-specific optimizations as well (not just usage of the various extensions), like favoring instructions X that perform slightly better over other instructions Y, even if instructions X would be significantly slower on AMD processors. So it does not seem 100% certain, at least without testing, that using "haswell" on AMD would be beneficial (it depends on whether the speed-up from extra extensions offsets possible speed loss due to other Intel-specific optimization). And Intel was probably not going to do such testing. But my guess is that using the "haswell" libraries on AMD will be beneficial, and the check will probably be loosened accordingly in the future. Note, though, that the feature checks currently performed do not seem exhaustive, so I don't think one can simply remove the Intel check as-is. Haswell has a lot more extensions than the ones currently checked.
- iforgotpassword 7y ago
  I'm not sure it is even worth it to distinguish by CPU model. My hunch is that the optimizations the compiler does for a specific model are vastly overshadowed by the gains of having certain extensions available at all. So glibc should only distinguish by avx512, sse4.2, etc. usually a CPU that has a newer extension available also has all of the older ones, the question is how many exceptions would arise, and what the speed penalty would be to fall back to the next slower implementation.
  - jandrewrogers 7y ago
    The implementations of extensions on different CPU microarchitectures can vary quite a bit from the same vendor. And performance of those extensions can vary by an order of magnitude between CPU vendors, sometimes because vendors will initially add CPU extensions as microcode if they did not design the extension themselves. AMD has microcoded many Intel extensions in some of their architectures for binary compatibility but without performance benefits, and many of their native implementations behave differently in material ways for optimization. The existence of the feature does not imply you should use it for highly optimized code, it may be slower than software versions of the same thing, or that you should use the feature in the same way to optimize code. It is quite complicated. The AMD and Intel microarchitectures are different enough in design that some low-level optimizations around many extensions really don't translate well between them. The differences can be big enough that you take them into account at the C++ level too, writing target-specific code. Individual CPU vendors are in the best position to provide software optimization for specific implementations of their microarchitectures. Unfortunately, AMD invests relatively little in this and relies on the open source community to fill in these gaps whereas Intel is excellent at providing first-party software optimization support for their CPUs.
gameswithgo 7y ago
A relevant point here may be that with Zen2, just released and very popular, AMD supports AVX/AVX2 properly for the first time. Previous, AMD cpus could execute AVX instructions but it wouldn't actually be faster, so there was not much point in properly detecting that anyway. Now there is.
- adrian_b 7y ago
  No,already the first Zen in 2017 supported perfectly AVX2. It just had half of the throughput of Haswell/Broadwell/Skylake. Nevertetheless, using 256-bit AVX instructions was still slightly faster in most cases than using 128-bit AVX or SSE, because less instructions had to be fetched and decoded. When Zen was first released in 2017, using -march=haswell in gcc produced faster programs than using -march=znver1 or -march=bdverX. Using AVX2 + FMA and all the other instructions introduced by Haswell & Broadwell was always the right thing to do when compiling for AMD Zen. Nothing has changed with Zen 2, except that the throughput of the AVX programs that are not limited by the memory throughput has doubled now.
  - gameswithgo 7y ago
    >No,already the first Zen in 2017 supported perfectly AVX2. It just had half of the throughput of Haswell/Broadwell/Skylake. I just said that dude.
    - jsjohnst 7y ago
      Read the very next sentence and you’ll see why GP’s reply to you mattered. > Nevertetheless, using 256-bit AVX instructions was still slightly faster in most cases than using 128-bit AVX or SSE, because less instructions had to be fetched and decoded.
      - loeg 7y ago
        OP's original comment also vaguely implied that Zen1 AVX/AVX2 was so dysfunctional it was no better than ... SSE? Scalar arithmetic? At best it was vague and incorrect.
deleted 7y ago
[deleted]
dogma1138 7y ago
While it might appear scammy AMD lacks instructions on some of its pre-Ryzen CPUs as the coverage for MOVEBE and the Bit Manipulation instructions are quite inconsistent. TBH the case for Intel isn’t that much different they have (Atoms mainly) post-Haswell CPUs that don’t support all of the instructions in this patch that would fail the master CPUID check and would not receive the optimizations either. If someone wants to split it into checking 30 specific CPUID flags and then figuring out which libraries can be linked because many of them would require some or all of these instructions by all means do that...

217 points by arthur2e5 7y ago

panpanna 7y ago

Wait, where in glibc is SIMD used anyway?

clmul 7y ago
I know that it is used at least for the implementation of functions like memcpy.
bonzini 7y ago
All string functions: not surprising since recent processors have the crazy PCMPxSTRy instructions that are basically a hardware implementation of strcmp, strchr, memchr, strspn etc. memcpy and memset use SSE on some generations, but these days are best inlined by the compiler as "rep movsb/stosb".
- stingraycharles 7y ago
  I better hope AVX512 isn’t used on simple string functions, as it causes so much heat Intel CPUs have to reduce their clock speed significantly, affecting other running processes as well. https://www.tcm.phy.cam.ac.uk/~mjr/IT/clocks.html https://www.tcm.phy.cam.ac.uk/~mjr/IT/clocks.html
  - physicsguy 7y ago
    There’s nothing wrong with dropping the clock speed when the whole point of SIMD instructions is that they execute on multiple data. As long as the clock speed drop beats the multiplicative speedup from doing 4x/8x/whatever operations in parallel, it’s fine
    - stingraycharles 7y ago
      My point is that the clock speed is also dropped for other processes. So it's not a simple heuristic "oh if we have more data than X we can use AVX512 instead of AVX256", because you do not know what other processes are doing, and they will be slowed down as well. This type of heuristic only works if you are the sole users of the server, e.g. a database server.
    - vnorilo 7y ago
      The problem is that the architecture in question would take forever in cpu time terms to switch back and forth, so a sprinkle of heavy avx512 was the worst of all worlds. In addition, some cpus would emulate 512 with half width micro-ops during voltage ramp up. Yes, it sounds crazy.
    - temac 7y ago
      Not it is not fine at all. If you have too many instructions but not enough, your whole CPU will run slower mostly on non AVX-512 instructions, and maybe even your whole package => the end result will just be slower. Not to say that those processors are bad, but AVX-512 on them is for niche workloads.
  - lazyjones 7y ago
    > it causes so much heat Intel CPUs have to reduce their clock speed significantly, How about: don't buy affected CPUs if you care. The last thing people who write libraries should care about is a few selected CPUs that underperform on a generally useful feature.
    - temac 7y ago
      Nope. At this point given the state of the market, and given what AVX512 does to begin with (so maybe the "at this point" will be for forever), it makes very very little sense to use it everywhere. It would just be actively detrimental to most users.
  - jbapple 7y ago
    The instruction and instruction set referenced in the comment you're referring to (PCMPxSTRy and SSE) are not AVX512; they were introduced long before AVX512 chips were manufactured.
- saagarjha 7y ago
  > memcpy and memset use SSE on some generations, but these days are best inlined by the compiler as "rep movsb/stosb". Why? I’ve usually seen this get compiled to some version of “mov byte ptr, inc”.
  - bonzini 7y ago
    You want to copy more one byte at a time (unrolling by 4, 8 or more; and for memset, multiplying the stored value by 0x01010101...). In recent processors rep movsb and rep stosb do all that in microcode, and are also able to copy or fill the destination one cache line at a time.
- robocat 7y ago
  For example strlen: https://stackoverflow.com/questions/57650895/why-does-glibcs-strlen-need-to-be-so-complicated-to-run-quickly https://stackoverflow.com/questions/57650895/why-does-glibcs...
  - temac 7y ago
    That's not a very good example; this code is generic (although non portable) C optimized implementation, not something making use of fancy processor instructions. It is even less probable that the compiler understand it and manage to optimize it to using dedicated instructions, when it is written that way.
fulafel 7y ago
Compilers do autovectorization (with varying degrees of success) so potentially in lots of places?
- goatinaboat 7y ago
  This is about the library not the compiler.
  - LfLxfxxLxfxx 7y ago
    A library is compiled with a compiler.
    - masklinn 7y ago
      This check is the opposite of compiler autovectorisation. Its point is specifically for the library to dispatch between implementations (e.g. to an explicitly vectorised one)
      - fulafel 7y ago
        Yes, and it can make sense to dispatch between compiler-vectorised and non-simd implementations.
        masklinn 7y ago
        It does make sense, the issue at hand is how it's done: by checking for the CPU vendor / product line rather than asking the CPU if it has the operations we want.
        fulafel 7y ago
        Yep - capabilities based switching makes most sense when you are just interested on what code can successfully execute, and not making decisions based on known perf characteristics of microarchitectures. But this subthread was about "where in glibc is SIMD used anyway?" and the answer is that in all code, potentially.
arthur2e5 7y ago
Read the bug again! The feature is about "transparently" loading libraries that are put in specific subdirectories based on the CPU so that a single configuration can work fast everywhere. Intel's Clear Linux wrote about that in https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture https://clearlinux.org/news-blogs/transparent-use-library-pa....

cotillion 7y ago

While this patch from @intel.com looks bad i wonder what has AMD been doing in the meantime? Atleast intel appears to have someone looking at Glibc performance.

rwire 7y ago
Does anyone have (a source to) stories about cable-cutting among telecom providers? I've encountered them before but now all I can find is this little lawsuit against Comcast: https://copocetic.com/accused-of-actual-cord-cutting-comcast-kinda-sorta-denies-it-b7d73700345 https://copocetic.com/accused-of-actual-cord-cutting-comcast...
PedroBatista 7y ago
Intel’s software division is bigger the the whole AMD.

hunta2097 7y ago

Could this be a legitimate unintended consequence of the pull request or some new dirty pool tactic? Either way I agree with Mingye Wang's assessment, this kind of thing cannot be allowed to get into the source tree. Hopefully AMD will increase their Linux activities with their new bigger market share and income.

krapht 7y ago

Hm, is this really "crippling" AMD? Seems more like Intel submitted a performance patch that is only enabled for Intel processors, but could be extended to support AMD too. There's a moral difference. It is wrong to intentionally degrade the performance of your competitors. It is not wrong to not do something that benefits others.

acqq 7y ago
> It is not wrong to not do something that benefits others. The patch however sneakily removes the chance that the features existing and working on the competing processors are properly detected and used. In free software it’s clearly evil.
- ori_b 7y ago
  So patch it. That's the point of free software: the freedom to modify it to your needs.
  - smcl 7y ago
    Well the patch certainly met Intel's needs (a nice little performance bump over its ascendant rival) ... and since someone with a keen eye spotted it, now the rest of us can submit a patch to correct that. But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.
    - jlg23 7y ago
      > But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well. In large FOSS projects you have enough eyes on those patches to ensure they actually converge towards some (unbiased) optimum.
      - alacombe 7y ago
        That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?

rgbrenner 7y ago

Am I missing something? Intel submitted a patch in 2017 that enabled support for a feature that was supported in their processors. 2 years later, AMD still hasn't made processors that support one of those features (AVX512), and only recently released processors that met the requirements for the other haswell test... And somehow this is labeled "cripple AMD"? It would be one thing if Intel did this while AMD had processors that worked on it.. but they didn't. And code cannot tell the future. That's why we have programmers. They're supposed to change the code when it needs to be changed.

FartyMcFarter 7y ago
> And code cannot tell the future. In this case it doesn't need to, I believe. There are ways to find out at runtime which instruction sets are supported, in a vendor-agnostic way.
- arthur2e5 7y ago
  "Code cannot tell the future" is also the 2009 excuse Intel gave for icc not supporting processors that are GenuineIntel but not Family 6, incidentally. History is wonderful, isn't it? Back in the days we already knew what the still-current best practice to see what flags a CPU has is.
  - JustFinishedBSG 7y ago
    You can't expect Intel to know about obscure features like CPU feature flags, it's not like they invented it.... oh.
adrian_b 7y ago
"only recently released processors that met the requirements for the other haswell" This is false. Zen was introduced in Q1 2017, before that patch was written and it already implemented all the useful parts of the Skylake instruction set (and also the SHA extension not implemented by Skylake). The fact that the CPU vendor should not be used when testing for CPU features was already discussed a lot, many years ago, so someone of the library maintainers should have noticed this bug and removed the inappropriate test. About AMD not supporting yet AVX-512, that is far less annoying than the fact that Intel does not support AVX-512 yet in any of their CPUs which are actually competitive in their target market (Ice Lake is worse than Comet Lake, Cascade Lake is worse than Epyc 2).

kbumsik 7y ago

Isn't it AMD's job, not GNU's job? > something that should not happen in any free software package. Some people takes "free software" pretty wrong. Free software doesn't mean being fair to all hardwares. It only is fair to accepting contributions from people who want their machines to work with it. They would be individual contributors but they are mostly people from the hardware vendors. That's being said, Linux/Free software have being supporting Intel very well because Intel itself is one of the biggest contributor. It's time for AMD to hire more software engineers to support better drivers and software ecosystem.

raverbashing 7y ago
No, it is GNU's job Features have feature flags, you shouldn't be doing comparison like "this is an Intel model X then it runs this" but it should be "this has feature X then it supports X" period It's the same crap as the ICC compiler throwing the slower code at AMD even though it would support the features
- smcl 7y ago
  It's the job of the maintainer of glibc, but I think we can legitimately ask questions of Intel's contribution since it's pretty sneaky and in bad faith
  - raverbashing 7y ago
    Yes this should have been caught in a code review
simion314 7y ago
The code is bad, it should detect features not vendor names . the proper fix should be CC-ed to the Intel developer so he can learn the good way of doing it. This kind of bad code makes sites to ask me to run a modern browser just because my modern browser is not in the dev whitelist or this kind of bad code caused Microsoft not to have Windows9 because some developers where clever and instead of checking for features or check for win95 and win98 they wrote a shorter line of code and checked for "Win9". In conclusion there are 2 possibilities: 1 the Intel dev did a mistake 2 it was intentional to limit the improvements to Intel only you are arguing that 2 is fine, then you are fine if google, Facebooks, Microsoft also put checks in their commits and limit features only if the code runs in their OS,browser,site. This kind of obvious user hostile commits are bad and don't have a place in free software and IMO the Intel compiler should not intentionally cripple a competitor. Also this attitude would mean that each company should now have a developer dedicated to check competitors contributions to make sure no intentional bad commits are sneak in because in your opinion is fair to intentionally do it.

AnssiH 7y ago

The point is to put Haswell-optimized code in the "haswell" subdirectory. However, compiling code with -march=haswell (implying -mtune=haswell) does a lot of other platform/manufacturer-specific optimizations as well (not just usage of the various extensions), like favoring instructions X that perform slightly better over other instructions Y, even if instructions X would be significantly slower on AMD processors. So it does not seem 100% certain, at least without testing, that using "haswell" on AMD would be beneficial (it depends on whether the speed-up from extra extensions offsets possible speed loss due to other Intel-specific optimization). And Intel was probably not going to do such testing. But my guess is that using the "haswell" libraries on AMD will be beneficial, and the check will probably be loosened accordingly in the future. Note, though, that the feature checks currently performed do not seem exhaustive, so I don't think one can simply remove the Intel check as-is. Haswell has a lot more extensions than the ones currently checked.

iforgotpassword 7y ago
I'm not sure it is even worth it to distinguish by CPU model. My hunch is that the optimizations the compiler does for a specific model are vastly overshadowed by the gains of having certain extensions available at all. So glibc should only distinguish by avx512, sse4.2, etc. usually a CPU that has a newer extension available also has all of the older ones, the question is how many exceptions would arise, and what the speed penalty would be to fall back to the next slower implementation.
- jandrewrogers 7y ago
  The implementations of extensions on different CPU microarchitectures can vary quite a bit from the same vendor. And performance of those extensions can vary by an order of magnitude between CPU vendors, sometimes because vendors will initially add CPU extensions as microcode if they did not design the extension themselves. AMD has microcoded many Intel extensions in some of their architectures for binary compatibility but without performance benefits, and many of their native implementations behave differently in material ways for optimization. The existence of the feature does not imply you should use it for highly optimized code, it may be slower than software versions of the same thing, or that you should use the feature in the same way to optimize code. It is quite complicated. The AMD and Intel microarchitectures are different enough in design that some low-level optimizations around many extensions really don't translate well between them. The differences can be big enough that you take them into account at the C++ level too, writing target-specific code. Individual CPU vendors are in the best position to provide software optimization for specific implementations of their microarchitectures. Unfortunately, AMD invests relatively little in this and relies on the open source community to fill in these gaps whereas Intel is excellent at providing first-party software optimization support for their CPUs.

gameswithgo 7y ago

A relevant point here may be that with Zen2, just released and very popular, AMD supports AVX/AVX2 properly for the first time. Previous, AMD cpus could execute AVX instructions but it wouldn't actually be faster, so there was not much point in properly detecting that anyway. Now there is.

adrian_b 7y ago
No,already the first Zen in 2017 supported perfectly AVX2. It just had half of the throughput of Haswell/Broadwell/Skylake. Nevertetheless, using 256-bit AVX instructions was still slightly faster in most cases than using 128-bit AVX or SSE, because less instructions had to be fetched and decoded. When Zen was first released in 2017, using -march=haswell in gcc produced faster programs than using -march=znver1 or -march=bdverX. Using AVX2 + FMA and all the other instructions introduced by Haswell & Broadwell was always the right thing to do when compiling for AMD Zen. Nothing has changed with Zen 2, except that the throughput of the AVX programs that are not limited by the memory throughput has doubled now.
- gameswithgo 7y ago
  >No,already the first Zen in 2017 supported perfectly AVX2. It just had half of the throughput of Haswell/Broadwell/Skylake. I just said that dude.
  - jsjohnst 7y ago
    Read the very next sentence and you’ll see why GP’s reply to you mattered. > Nevertetheless, using 256-bit AVX instructions was still slightly faster in most cases than using 128-bit AVX or SSE, because less instructions had to be fetched and decoded.
    - loeg 7y ago
      OP's original comment also vaguely implied that Zen1 AVX/AVX2 was so dysfunctional it was no better than ... SSE? Scalar arithmetic? At best it was vague and incorrect.

deleted 7y ago

[deleted]

dogma1138 7y ago

While it might appear scammy AMD lacks instructions on some of its pre-Ryzen CPUs as the coverage for MOVEBE and the Bit Manipulation instructions are quite inconsistent. TBH the case for Intel isn’t that much different they have (Atoms mainly) post-Haswell CPUs that don’t support all of the instructions in this patch that would fail the master CPUID check and would not receive the optimizations either. If someone wants to split it into checking 30 specific CPUID flags and then figuring out which libraries can be linked because many of them would require some or all of these instructions by all means do that...