Intel MKL on AMD Zen

I hate the overuse of acronyms (IHTOOA). One way to get back is just to start making up your own -- throw a few random TLA's out at your next meeting. It's fun.

Also, I would like to push for an anti-acronym day. A full day where you have to use full and complete terminology. Ironic thing is, you don't add that many syllables when you say "Proof of Concept" vs POC and similar such absurd overused abbreviations.

> using acronyms without ever defining them.

I don't agree. The article quite clearly refers to Intel MKL, which is widely known at least in the number crunching world. Plus, it's just a blog post.

"MKL" is the name of it, and what it stands for doesn't really matter. Just like "AMD".

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

Maybe?

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

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.

And thats exactly the key question. The original kernel that Intel uses on their own CPUs works perfectly fine on AMD. Otherwise Matlab wouldn't have validated it in their production release in 2020a. So the key question is: Why is Intel taking efforts in implementing a specific kernel for AMD that is somewhat slower. I guess there aren't too many answers out there that make sense.

The entire Industry should develop a true interest to push OSS alternatives. And all OSS projects should honestly think twice about implementing such a CSS like the MKL as a standard.

Definitely not mine either, though I haven't benchmarked in a few years (and would love this to be true).

So what are the results with libxsmm and current AMD BLAS, as that must be for small dimensions?

The reason it's serial BLAS that mainly matters is that HPC codes are usually parallelized above the BLAS; why do you want the nesting? Swapping in threaded OpenBLAS or BLIS is something you might do with basically serial stuff like vanilla R, e.g. https://loveshack.fedorapeople.org/blas-subversion.html#_add... OpenBLAS threading has been somewhat buggy, but the main problem with its OpenMP support currently seems to be that using OMP_PLACES kills it.

The proprietary software mix might still perform better on AMD.

There are a very finite number of HPC clusters available to any given researcher with a given grant. Each european country might have 1-10 available and you have to apply for compute time.

If you’re in a commercial setting, your company might have 1 cluster and N simulation programs.