Hacker News Reader

Comment by eyegor | Hacker News Reader

Holy cow, my main takeaway is that mkl is complete garbage on amd parts and that isn't on accident. This makes me think I need to go back and relink some programs against blis or openblas for amd systems... Even though we primarily switched cluster hardware to amd it never occurred to us that mkl would run at half the throughput of open implementations.

View on HN

You can override the detection function and get the faster Intel AVX kernels:

https://danieldk.eu/Posts/2020-08-31-MKL-Zen

Some back history: they used to use (slow) SSE kernels when a non-Intel CPU is detected. Over time, they started adding kernels for Zen, but last time I tested the Zen kernels were still slower than the AVX kernels. So it still pays off override the Intel CPU detection.

It looks like these benchmarks use MKL 2020 update 3. If I recall correctly, this version did not have the Zen sgemm kernels yet. A newer MKL version would perform much better and if you disable Intel detection, MKL would be competitive on Zen.

That sort of support has come and gone in different versions, though I couldn't tell you which. But, really, why bother? There is too much mythology around Intel stuff.

I don't understand why people use MKL on AMD hardware rather than AMD's (current) library, which is basically upstream BLIS for those architectures; their old one from the Operton era wasn't good. OpenBLAS has been largely competitive with MKL even on Intel anyway over many years, and the MKL licence used not to allow the sort of use people made of it. MKL is infinitely slower than OpenBLAS/BLIS averaged over the hardware relevant to HPC, like the POWER system I support.

Numerics code is annoying to maintain, and most of us have code bases that already use mkl. Intels compilers make it easy and quick to use, whereas openblas was always a headache in my experience. Plus amd hardware only became competitive in the past few years, so it hasn't mattered.

I don't follow. Assuming you're talking BLAS/LAPACK (libflame is the LAPACK equivalent using BLIS) I don't see why the implementation matters, and if you're dependent on MKL for some reason you can't run on some of the biggest and best HPC systems amongst others. You can expect BLAS and LAPACK implementations to be ABI-compatible (via a common Fortran 77 ABI), so even choosing at run time is an LD_PRELOAD away. Better, it's an ldconfig, alternatives, or LD_LIBRARY_PATH away with a sensible policy like Debian's. AMD was competitive with Opteron and Bulldozer for us long ago, if not their BLAS (done by NAG?).

Reply on news.ycombinator.com