Intel and AMD settled a suit in 2009 : 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."

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.

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.

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-...

> 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.

> 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.

4. This is one person (or a small group) at Intel who considers it the right thing to do.

Maybe?

> 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.

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.ht...

[1] https://devmesh.intel.com/projects/intel-ispc-in-unreal-engi...

Or 5. they want to stave off another unfair competition complaint.

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.

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).

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.

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).

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.