7 ms·

See the caveat at the end: > It is also possible that the resulting code path has some precision loss or other problems on AMD hardware. I have not tested for

by creato 7y ago

See the caveat at the end: > It is also possible that the resulting code path has some precision loss or other problems on AMD hardware. I have not tested for that! Intel doesn't test it either, which is why they disable it. You could argue that they should test and enable on AMD CPUs, but this isn't clearly scummy behavior (to me), it's not a zero cost decision they made solely to screw over AMD. Buying the hardware and testing it has a cost. It may not even be possible to test it to the same degree they test their own hardware. There may be modes, subtle differences between architecture versions, etc. that are hard to know about to test for.

nemetroid 7y ago
Until the opposite has been shown, the assumption should be that a CPU that indicates that it supports AVX2 does support AVX2.
- roenxi 7y ago
  That is not the case, this is at the boundary of software and hardware and real-world concerns dominate. It is quite possible that a library highly optimised to a specific hardware set could have ghastly bugs on hardware it isn't tested on and testing has a cost. Intel is being reasonable and in a sense prudent by only supporting hardware they understand very well. It isn't like they are sending the lawyers out to sue anyone writing high performance code on AMD chips - that would be unreasonable.
  - the8472 7y ago
    The usual approach (e.g. taken in the linux kernel, llvm, hotspot jvm) is to look at the cpuid capability flags and rely on them by default and only blacklist specific CPU models when they don't implement advertised features correctly, not the other way around.
  - yxhuvud 7y ago
    Then don't test it. It is perfectly ok (and even expected) for Intel to not test on AMD. Just don't intentionally cripple it.
- bitL 7y ago
  There are over 10 different x86 CPUs, some with very dodgy implementation of basic x86, not mentioning extensions. It could have been just a typical "safe" corporate decision to run optimized code path only on specific Intel CPUs. They use different code paths for different Intel CPUs/generations as well. Now imagine they had to believe that Hygon/SiS/Vortex implement it properly... It's not completely black/white.
- p1necone 7y ago
  Yup, the number of people in this thread buying into Intel's excuses is astounding to me.
RL_Quine 7y ago
The idea that a R&D department has cost restrictions doesn't really hold water. You can be sure that they already have rooms filled with every single AMD processor that's ever been released, and a bunch which haven't. The cost of buying retail products at the scale of a company, even a small startup, is peanuts compared with even a single engineers salary. I was recently asked which test phones to buy for application development, and didn't get kick back when I said to buy every single one of the top selling on Amazon, to begin with.
- rat9988 7y ago
  The question is why would they spend that much money to test it on a competing platform.
  - wtallis 7y ago
    Intel's pretty motivated to do so for competitive analysis reasons even if they don't care about doing QA to benefit AMD.
    - Iwan-Zotow 7y ago
      Well, I'm pretty sure Intel tests competitor product, and maybe even test MKL. So what? Suppose I (being Intel engineer, which I'm not) tested linalg+MKL on threadripper and found it to be 50% slower. Then WHAT? Ask management for more money for MKL team to make it faster on AMD? I don't think such proposal would fly.
      - karavelov 7y ago
        I don't think anybody expects Intel to do anything in that case. What is expected is not to cripple performance when running on competitors CPUs.
  - Iwan-Zotow 7y ago
    Problem is not testing per se. Ok, they tested and found out MKL is 50% slower. Then what? Write proposal for MKL team to spend time/money to make MKL faster on AMD? I don't think this would fly with upper management...
jchw 7y ago
I don't understand. Shouldn't Intel be using the CPUID feature detection system they created? https://software.intel.com/en-us/articles/how-to-detect-new-instruction-support-in-the-4th-generation-intel-core-processor-family https://software.intel.com/en-us/articles/how-to-detect-new-... They don't need to test to see if it works on AMD. The processor advertises it. In their own words: > It is important to understand that a new instruction is supported on a particular processor only if the corresponding CPUID feature flag is set. Applications must not assume support of any instruction set extension simply based on, for example, checking a CPU model or family and must instead always check for _all_ the feature CPUID bits of the instructions being used. Indeed, my 3900X has the AVX2 flag flipped. So why would it not get used? I don't think the precision loss argument really holds water. If you can't trust their AVX2 implementation, why can you trust any other instruction on the CPU to not have similar problems? Unless I am misunderstanding something, it really looks like they're not following their own advice and artificially limiting the use of AVX2 to only Intel processors. edit: Also, we really have no reason to trust Intel's honesty. Don't forget: https://web.archive.org/web/20110312082557/http://www.compilerreimbursementprogram.com/ https://web.archive.org/web/20110312082557/http://www.compil...
- creato 7y ago
  Many instructions (that likely see heavy use in MKL) are approximations, the exact implementation and behavior of these approximations varies across platforms (including possibly architecture versions). The docs you quoted describes the necessary conditions for using an instruction to avoid crashes/illegal instruction issues. That doesn't cover these kinds of more subtle differences that exist. For example, I just made a plot of |1/x - rcpps(x)|: https://snipboard.io/Rei74t.jpg https://snipboard.io/Rei74t.jpg
  - jchw 7y ago
    I'm very much not buying it. Although of course an instruction for something like approximations can vary across different micro-architectures and vendors, there has to be some definition for what the baseline is. Without it, the instruction may as well output junk. Indeed, I just checked and Intel's "Intel 64 and IA-32 Architectures Software Developer’s Manual" contains a bound on the error of the approximation in rcpps: The relative error for this approximation is: |Relative Error| ≤ 1.5 ∗ 2^−12 In fact, the document goes on to further define a lot of the behavior of the instruction in edge cases. Because that's kind of important for an architecture. If the extended instruction set did different things on every different processor, it would be useless. So I don't think this is really the issue. I don't think Intel MKL defines what the error is for many operations, so it is presumably not defined, and therefore it'd be hard for AMD's implementation to run afoul. It's also not going to be reproducibility/consistency, since they cover this in a separate issue: https://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler https://software.intel.com/en-us/articles/consistency-of-flo...
tagrun 7y ago
I can't tell if you're being naive or deliberately perpetuating an Intel FUD. You're being part of the problem by doubling down on some ambiguous comment (which is not even based on any real test) as if there actually is a problem with AMD's AVX implementation. As a physicists, I can tell you for sure that no, this is not why Intel disables it. Intel had quite a success by purposely crippling icc/ifort and MKL on AMD, and created GenuineIntel as a legal barrier to prevent AMD (and AMD users) to come up with a workaround, which allowed Intel to essentially kill the competition in HPC. It is a well known fact that Intel has been actively working to cripple AMD's performance across the board. They invented GenuineIntel exclusively for that purpose, which was a part of the bigger picture filled with false advertisements, bribes (the most famous Intel bribe cases involved Dell), smear campaigns, lawsuits, so on and so forth. Intel has a long history of playing dirty against competitors.
- creato 7y ago
  > I can't tell if you're being naive or deliberately perpetuating an Intel FUD. You're being part of the problem by doubling down on some ambiguous comment (which is not even based on any real test) I have never actually seen Intel comment on this, I just personally have experienced headaches porting numerical code between two different architectures (not AMD <-> Intel though), where on the surface the architectures appear to be the same and straightforward to swap between, but in practice they are not. This doesn't mean one of the architectures had "problems" and the other did not. It's not about one architecture being inferior than the other, they're simply different.
  - deleted 7y ago
    [deleted]
  - tagrun 7y ago
    I'm not sure what you're trying to imply here. I'm not sure if it's relevant either, as this is about the implementation of the same instruction set (AVX/AVX2) on Intel and AMD, whereas you say "not Intel <-> AMD though". Can you be more specific? In any case, I never saw any real reason which warrant disabling an entire instruction set, such as AVX. Which is why you don't see such artificial crippling in open source implementations of LAPACK/BLAS/sundials/etc, and people (including me) have been using the same fortran code for many decades across many architectures. And in case this is what you're trying to imply, no, they don't really give different numerical results on different CPUs.
simion314 7y ago
>Intel doesn't test it either, which is why they disable it. I think the software part of Intel should not sabotage the competition, we don't like when Google devs are sabotaging Firefox intentionally or by laziness, as a software dev you test for the feature, if it is present you use it and if for some reason the hardware is broken then you implement the workarounds if your customers demand it or if not let AMD to fix the broken feature. As a developer myself the least I could do is to add a flag to turn the crippling on/off but let it on by default, then the users can decide that precision/thermals or things are worse on AMD and enable crippled mode.
Dylan16807 7y ago
Almost no software is tested on a proper suite of different architectures. If you don't want to test it, the proper answer is to emit valid code without any shenanigans.
eberkund 7y ago
What kind of reasoning is that? When I develop software I don't start by writing an if-statement that exits if the user's hardware is not identical to the hardware specs that I wrote and tested the software on. Certain things should carry the expectation they are compatible, not the other way around. Innocent before proven guilty! I would say an instruction set (the sole purpose of which is to avoid scenarios like the one you're describing) are one of those things.

by creato 7y ago

nemetroid 7y ago

Until the opposite has been shown, the assumption should be that a CPU that indicates that it supports AVX2 does support AVX2.

roenxi 7y ago
That is not the case, this is at the boundary of software and hardware and real-world concerns dominate. It is quite possible that a library highly optimised to a specific hardware set could have ghastly bugs on hardware it isn't tested on and testing has a cost. Intel is being reasonable and in a sense prudent by only supporting hardware they understand very well. It isn't like they are sending the lawyers out to sue anyone writing high performance code on AMD chips - that would be unreasonable.
- the8472 7y ago
  The usual approach (e.g. taken in the linux kernel, llvm, hotspot jvm) is to look at the cpuid capability flags and rely on them by default and only blacklist specific CPU models when they don't implement advertised features correctly, not the other way around.
- yxhuvud 7y ago
  Then don't test it. It is perfectly ok (and even expected) for Intel to not test on AMD. Just don't intentionally cripple it.
bitL 7y ago
There are over 10 different x86 CPUs, some with very dodgy implementation of basic x86, not mentioning extensions. It could have been just a typical "safe" corporate decision to run optimized code path only on specific Intel CPUs. They use different code paths for different Intel CPUs/generations as well. Now imagine they had to believe that Hygon/SiS/Vortex implement it properly... It's not completely black/white.
p1necone 7y ago
Yup, the number of people in this thread buying into Intel's excuses is astounding to me.

RL_Quine 7y ago

The idea that a R&D department has cost restrictions doesn't really hold water. You can be sure that they already have rooms filled with every single AMD processor that's ever been released, and a bunch which haven't. The cost of buying retail products at the scale of a company, even a small startup, is peanuts compared with even a single engineers salary. I was recently asked which test phones to buy for application development, and didn't get kick back when I said to buy every single one of the top selling on Amazon, to begin with.

rat9988 7y ago
The question is why would they spend that much money to test it on a competing platform.
- wtallis 7y ago
  Intel's pretty motivated to do so for competitive analysis reasons even if they don't care about doing QA to benefit AMD.
  - Iwan-Zotow 7y ago
    Well, I'm pretty sure Intel tests competitor product, and maybe even test MKL. So what? Suppose I (being Intel engineer, which I'm not) tested linalg+MKL on threadripper and found it to be 50% slower. Then WHAT? Ask management for more money for MKL team to make it faster on AMD? I don't think such proposal would fly.
    - karavelov 7y ago
      I don't think anybody expects Intel to do anything in that case. What is expected is not to cripple performance when running on competitors CPUs.
- Iwan-Zotow 7y ago
  Problem is not testing per se. Ok, they tested and found out MKL is 50% slower. Then what? Write proposal for MKL team to spend time/money to make MKL faster on AMD? I don't think this would fly with upper management...

jchw 7y ago

I don't understand. Shouldn't Intel be using the CPUID feature detection system they created? https://software.intel.com/en-us/articles/how-to-detect-new-instruction-support-in-the-4th-generation-intel-core-processor-family https://software.intel.com/en-us/articles/how-to-detect-new-... They don't need to test to see if it works on AMD. The processor advertises it. In their own words: > It is important to understand that a new instruction is supported on a particular processor only if the corresponding CPUID feature flag is set. Applications must not assume support of any instruction set extension simply based on, for example, checking a CPU model or family and must instead always check for _all_ the feature CPUID bits of the instructions being used. Indeed, my 3900X has the AVX2 flag flipped. So why would it not get used? I don't think the precision loss argument really holds water. If you can't trust their AVX2 implementation, why can you trust any other instruction on the CPU to not have similar problems? Unless I am misunderstanding something, it really looks like they're not following their own advice and artificially limiting the use of AVX2 to only Intel processors. edit: Also, we really have no reason to trust Intel's honesty. Don't forget: https://web.archive.org/web/20110312082557/http://www.compilerreimbursementprogram.com/ https://web.archive.org/web/20110312082557/http://www.compil...

creato 7y ago
Many instructions (that likely see heavy use in MKL) are approximations, the exact implementation and behavior of these approximations varies across platforms (including possibly architecture versions). The docs you quoted describes the necessary conditions for using an instruction to avoid crashes/illegal instruction issues. That doesn't cover these kinds of more subtle differences that exist. For example, I just made a plot of |1/x - rcpps(x)|: https://snipboard.io/Rei74t.jpg https://snipboard.io/Rei74t.jpg
- jchw 7y ago
  I'm very much not buying it. Although of course an instruction for something like approximations can vary across different micro-architectures and vendors, there has to be some definition for what the baseline is. Without it, the instruction may as well output junk. Indeed, I just checked and Intel's "Intel 64 and IA-32 Architectures Software Developer’s Manual" contains a bound on the error of the approximation in rcpps: The relative error for this approximation is: |Relative Error| ≤ 1.5 ∗ 2^−12 In fact, the document goes on to further define a lot of the behavior of the instruction in edge cases. Because that's kind of important for an architecture. If the extended instruction set did different things on every different processor, it would be useless. So I don't think this is really the issue. I don't think Intel MKL defines what the error is for many operations, so it is presumably not defined, and therefore it'd be hard for AMD's implementation to run afoul. It's also not going to be reproducibility/consistency, since they cover this in a separate issue: https://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler https://software.intel.com/en-us/articles/consistency-of-flo...

tagrun 7y ago

I can't tell if you're being naive or deliberately perpetuating an Intel FUD. You're being part of the problem by doubling down on some ambiguous comment (which is not even based on any real test) as if there actually is a problem with AMD's AVX implementation. As a physicists, I can tell you for sure that no, this is not why Intel disables it. Intel had quite a success by purposely crippling icc/ifort and MKL on AMD, and created GenuineIntel as a legal barrier to prevent AMD (and AMD users) to come up with a workaround, which allowed Intel to essentially kill the competition in HPC. It is a well known fact that Intel has been actively working to cripple AMD's performance across the board. They invented GenuineIntel exclusively for that purpose, which was a part of the bigger picture filled with false advertisements, bribes (the most famous Intel bribe cases involved Dell), smear campaigns, lawsuits, so on and so forth. Intel has a long history of playing dirty against competitors.

creato 7y ago
> I can't tell if you're being naive or deliberately perpetuating an Intel FUD. You're being part of the problem by doubling down on some ambiguous comment (which is not even based on any real test) I have never actually seen Intel comment on this, I just personally have experienced headaches porting numerical code between two different architectures (not AMD <-> Intel though), where on the surface the architectures appear to be the same and straightforward to swap between, but in practice they are not. This doesn't mean one of the architectures had "problems" and the other did not. It's not about one architecture being inferior than the other, they're simply different.
- deleted 7y ago
  [deleted]
- tagrun 7y ago
  I'm not sure what you're trying to imply here. I'm not sure if it's relevant either, as this is about the implementation of the same instruction set (AVX/AVX2) on Intel and AMD, whereas you say "not Intel <-> AMD though". Can you be more specific? In any case, I never saw any real reason which warrant disabling an entire instruction set, such as AVX. Which is why you don't see such artificial crippling in open source implementations of LAPACK/BLAS/sundials/etc, and people (including me) have been using the same fortran code for many decades across many architectures. And in case this is what you're trying to imply, no, they don't really give different numerical results on different CPUs.

simion314 7y ago

>Intel doesn't test it either, which is why they disable it. I think the software part of Intel should not sabotage the competition, we don't like when Google devs are sabotaging Firefox intentionally or by laziness, as a software dev you test for the feature, if it is present you use it and if for some reason the hardware is broken then you implement the workarounds if your customers demand it or if not let AMD to fix the broken feature. As a developer myself the least I could do is to add a flag to turn the crippling on/off but let it on by default, then the users can decide that precision/thermals or things are worse on AMD and enable crippled mode.

Dylan16807 7y ago

Almost no software is tested on a proper suite of different architectures. If you don't want to test it, the proper answer is to emit valid code without any shenanigans.

eberkund 7y ago

What kind of reasoning is that? When I develop software I don't start by writing an if-statement that exits if the user's hardware is not identical to the hardware specs that I wrote and tested the software on. Certain things should carry the expectation they are compatible, not the other way around. Innocent before proven guilty! I would say an instruction set (the sole purpose of which is to avoid scenarios like the one you're describing) are one of those things.