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