5 ms·

Wow, why is Intel supporting Zen kernels in MKL? That seems... really interesting. One of the few places where Intel still has a somewhat clear advantage is in

Wow, why is Intel supporting Zen kernels in MKL? That seems... really interesting. One of the few places where Intel still has a somewhat clear advantage is in high performance numerical code that can't be easily multiprocessed (e.g. off-the-shelf ML code) because MKL is much faster than AMD alternatives. Also, does anyone know if one can use patchelf on e.g. Python (or the numpy compiled section?) to get MKL/Zen support? I don't have my Zen CPU on me to test.

GrayShade 6y ago
I might be too cynical, but it looks like they're adding Zen kernels that perform worse than the Intel ones, so I'm not sure it's better than before.
- danieldk 6y ago
  Indeed, I had three theories, from optimistic to cynical: 1. They are sharing increasingly much code between oneDNN (formerly MKL-DNN) and Intel MKL. So, it simply pays of from a development cost perspective. 2. Intel sees AArch64 as a serious competitor. AMD may be an enemy, but at least an enemy on the same architecture. Better to strengthen x86_64 than to give AArch64 too much momentum in HPC. (The #1 supercomputer in TOP500 is AArch64 [1]) 3. Write Zen kernels, make them slightly less efficient than the Intel ones. They still beat OpenBLAS et al. in benchmarks, even on Zen. But to HPC customers they can show that Intel CPUs are faster. I think (1) is somewhat optimistic, given the huge benefit that they had with MKL in HPC. If (1) is not the case, I definitely hope (2) is. [1] https://www.top500.org/news/japan-captures-top500-crown-arm-powered-supercomputer/ https://www.top500.org/news/japan-captures-top500-crown-arm-...
  - Torkel 6y ago
    4. This is one person (or a small group) at Intel who considers it the right thing to do. Maybe?
    - nitrogen 6y ago
      Or 5. they want to stave off another unfair competition complaint.
    - nordsieck 6y ago
      > 4. This is one person (or a small group) at Intel who considers it the right thing to do. > Maybe? I guess it depends on where you work. Most places would probably fire someone who "took the initiative" to improve a competitor's product on company time.
      - cowsandmilk 6y ago
        Not on company time, but after leaving intel, some former employees added ARM support to ispc[0]. In the years since then, current Intel employees have maintained and even expanded the ARM support and Intel’s website even mentions it now[1]. [0] https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.html https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.ht... [1] https://devmesh.intel.com/projects/intel-ispc-in-unreal-engine-4-a-peek-behind-the-curtain https://devmesh.intel.com/projects/intel-ispc-in-unreal-engi...
  - nordsieck 6y ago
    > 2. Intel sees AArch64 as a serious competitor. AMD may be an enemy, but at least an enemy on the same architecture. Better to strengthen x86_64 than to give AArch64 too much momentum in HPC. (The #1 supercomputer in TOP500 is AArch64 [1]) Historically, this makes the most sense to me: AMD has pooped the bed before, and Intel was there to pick up the pieces and reclaim its crown. I think there's a legitimate worry that if ARM takes enough marketshare from x86/x64, that Intel will never get it back. > 3. Write Zen kernels, make them slightly less efficient than the Intel ones. They still beat OpenBLAS et al. in benchmarks, even on Zen. But to HPC customers they can show that Intel CPUs are faster. IMO, this is more on AMD than Intel. If Intel's kernel is faster than the open alternative, then Intel is doing AMD a favor, even if they're not doing the absolutely best job they possibly could.
    - Dylan16807 6y ago
      > IMO, this is more on AMD than Intel. If Intel's kernel is faster than the open alternative, then Intel is doing AMD a favor, even if they're not doing the absolutely best job they possibly could. If AMD chips are slow on the Intel-optimized kernel, then it's partly on AMD. If Intel writes an "AMD-optimized" kernel that's worse on AMD than the "Intel-optimized" kernel, that's definitely not on AMD. And in that case it's not doing them a favor to make that kernel when they could just use the same code on everything.
  - m0zg 6y ago
    I bet it's #3, and not necessarily maliciously. Higher end Intel SKUs do outperform AMD quite easily on practical floating point workloads. That's a fact that could be highlighted by testing _Intel_ MKL side by side. I don't really think it matters a whole lot in the grand scheme of things - all the serious compute has been on the GPUs for the past decade, and that's not about to change. It is critical for Intel now to make their Xe GPUs viable for HPC - something they're well positioned to do, but will fuck up anyway because they're a huge, bureaucratic behemoth with lots of political infighting, and people on the top have not a faintest clue as to what's going on, nor the ability to acquire such a clue.
drocer88 6y ago
Intel and AMD settled a suit in 2009 : https://www.amd.com/en/corporate/antitrust-ruling https://www.amd.com/en/corporate/antitrust-ruling " ... Intel must not ... Intentionally include design/engineering elements in its products that artificially impair the performance of any AMD microprocessor."
- arthur2e5 6y ago
  If you read Agner Fog's old "Cripple AMD" thread from 2009, when he actually served as a FTC witness, you will see that his later updates in 2010-11 shows no reduction in behavior of this kind on Intel's side. If Intel were to comply, this would've been a solved problem. What we are seeing has to be a new deal.
nl 6y ago
I think the real question one should be asking is "why is AMD's support for high-performance computing" so bad? This applies both to CPUs (where they have to rely on Intel for this) and toe GPUs (where their offerings are under resourced, buggy and lagging what NVidia offer).
- singhrac 6y ago
  This isn't too hard to explain, I think - until recently AMD has been very strapped for cash and all their software engineering bandwidth had gone towards optimizing games (where they're still keeping up with NVIDIA where progress doesn't seem to have slowed).
- gnufx 6y ago
  It remains to be seen how bad AMD support is on Frontier and El Capitain compared with Aurora (eventually). The new UK Tier 1 system is all Rome CPU.
- slavik81 6y ago
  I work for AMD on our GPU math libraries. If you have specific complaints, I will gladly listen. I can't promise more than that, but I will read and consider whatever you write. I'm a true believer in ROCm HIP. It has tremendous potential. I joined the company specifically because I wanted to help ensure its success... mostly by writing fast, reliable code, but also by listening to our users. If you (or anyone else) would prefer to respond privately, my email is my HN username at gmail.

GrayShade 6y ago

I might be too cynical, but it looks like they're adding Zen kernels that perform worse than the Intel ones, so I'm not sure it's better than before.

danieldk 6y ago
Indeed, I had three theories, from optimistic to cynical: 1. They are sharing increasingly much code between oneDNN (formerly MKL-DNN) and Intel MKL. So, it simply pays of from a development cost perspective. 2. Intel sees AArch64 as a serious competitor. AMD may be an enemy, but at least an enemy on the same architecture. Better to strengthen x86_64 than to give AArch64 too much momentum in HPC. (The #1 supercomputer in TOP500 is AArch64 [1]) 3. Write Zen kernels, make them slightly less efficient than the Intel ones. They still beat OpenBLAS et al. in benchmarks, even on Zen. But to HPC customers they can show that Intel CPUs are faster. I think (1) is somewhat optimistic, given the huge benefit that they had with MKL in HPC. If (1) is not the case, I definitely hope (2) is. [1] https://www.top500.org/news/japan-captures-top500-crown-arm-powered-supercomputer/ https://www.top500.org/news/japan-captures-top500-crown-arm-...
- Torkel 6y ago
  4. This is one person (or a small group) at Intel who considers it the right thing to do. Maybe?
  - nitrogen 6y ago
    Or 5. they want to stave off another unfair competition complaint.
  - nordsieck 6y ago
    > 4. This is one person (or a small group) at Intel who considers it the right thing to do. > Maybe? I guess it depends on where you work. Most places would probably fire someone who "took the initiative" to improve a competitor's product on company time.
    - cowsandmilk 6y ago
      Not on company time, but after leaving intel, some former employees added ARM support to ispc[0]. In the years since then, current Intel employees have maintained and even expanded the ARM support and Intel’s website even mentions it now[1]. [0] https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.html https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.ht... [1] https://devmesh.intel.com/projects/intel-ispc-in-unreal-engine-4-a-peek-behind-the-curtain https://devmesh.intel.com/projects/intel-ispc-in-unreal-engi...
- nordsieck 6y ago
  > 2. Intel sees AArch64 as a serious competitor. AMD may be an enemy, but at least an enemy on the same architecture. Better to strengthen x86_64 than to give AArch64 too much momentum in HPC. (The #1 supercomputer in TOP500 is AArch64 [1]) Historically, this makes the most sense to me: AMD has pooped the bed before, and Intel was there to pick up the pieces and reclaim its crown. I think there's a legitimate worry that if ARM takes enough marketshare from x86/x64, that Intel will never get it back. > 3. Write Zen kernels, make them slightly less efficient than the Intel ones. They still beat OpenBLAS et al. in benchmarks, even on Zen. But to HPC customers they can show that Intel CPUs are faster. IMO, this is more on AMD than Intel. If Intel's kernel is faster than the open alternative, then Intel is doing AMD a favor, even if they're not doing the absolutely best job they possibly could.
  - Dylan16807 6y ago
    > IMO, this is more on AMD than Intel. If Intel's kernel is faster than the open alternative, then Intel is doing AMD a favor, even if they're not doing the absolutely best job they possibly could. If AMD chips are slow on the Intel-optimized kernel, then it's partly on AMD. If Intel writes an "AMD-optimized" kernel that's worse on AMD than the "Intel-optimized" kernel, that's definitely not on AMD. And in that case it's not doing them a favor to make that kernel when they could just use the same code on everything.
- m0zg 6y ago
  I bet it's #3, and not necessarily maliciously. Higher end Intel SKUs do outperform AMD quite easily on practical floating point workloads. That's a fact that could be highlighted by testing _Intel_ MKL side by side. I don't really think it matters a whole lot in the grand scheme of things - all the serious compute has been on the GPUs for the past decade, and that's not about to change. It is critical for Intel now to make their Xe GPUs viable for HPC - something they're well positioned to do, but will fuck up anyway because they're a huge, bureaucratic behemoth with lots of political infighting, and people on the top have not a faintest clue as to what's going on, nor the ability to acquire such a clue.

drocer88 6y ago

Intel and AMD settled a suit in 2009 : https://www.amd.com/en/corporate/antitrust-ruling https://www.amd.com/en/corporate/antitrust-ruling " ... Intel must not ... Intentionally include design/engineering elements in its products that artificially impair the performance of any AMD microprocessor."

arthur2e5 6y ago
If you read Agner Fog's old "Cripple AMD" thread from 2009, when he actually served as a FTC witness, you will see that his later updates in 2010-11 shows no reduction in behavior of this kind on Intel's side. If Intel were to comply, this would've been a solved problem. What we are seeing has to be a new deal.

nl 6y ago

I think the real question one should be asking is "why is AMD's support for high-performance computing" so bad? This applies both to CPUs (where they have to rely on Intel for this) and toe GPUs (where their offerings are under resourced, buggy and lagging what NVidia offer).

singhrac 6y ago
This isn't too hard to explain, I think - until recently AMD has been very strapped for cash and all their software engineering bandwidth had gone towards optimizing games (where they're still keeping up with NVIDIA where progress doesn't seem to have slowed).
gnufx 6y ago
It remains to be seen how bad AMD support is on Frontier and El Capitain compared with Aurora (eventually). The new UK Tier 1 system is all Rome CPU.
slavik81 6y ago
I work for AMD on our GPU math libraries. If you have specific complaints, I will gladly listen. I can't promise more than that, but I will read and consider whatever you write. I'm a true believer in ROCm HIP. It has tremendous potential. I joined the company specifically because I wanted to help ensure its success... mostly by writing fast, reliable code, but also by listening to our users. If you (or anyone else) would prefer to respond privately, my email is my HN username at gmail.