Intel MKL backend

[termoshtt]

Recently I created intel-mkl-src crate to use Intel MKL in Rust easily. It is still experimental and only supports static link, but I confirmed it works with ndarray-linalg in my machine (Arch Linux).
I extract the static library (and compressed by xz) from the official package for Linux, and thus I expect that it does not works on other platforms.

[termoshtt]

Sorry I found critical bug :<

[termoshtt]

I have fixed the bug, and it will works :)

[termoshtt]

Test has been passed.

[IvanUkhov]

I just want to say “thank you” for your work here and in blas-sys. The reason I don’t do anything is that I’m not sure if it should be made a part of these crates. Currently, one can make use of your crate by disabling all other implementation providers and depending on intel-mkl-src directly.

[termoshtt]

Currently, one can make use of your crate by disabling all other implementation providers and depending on intel-mkl-src directly.

I cannot construct it :< Could you give me a small sample?

[IvanUkhov]

One could write in Cargo.toml something like

[dependencies]
lapack-sys = { version = "0.11", default-features = false }
intel-mkl-src = "0.2.5"

and then

use lapack_sys;
use intel_mkl_src;

[termoshtt]

Thanks, I've gotten a working example.

I’m not sure if it should be made a part of these crates. Currently, one can make use of your crate by disabling all other implementation providers and depending on intel-mkl-src directly.

This is also true for OpenBLAS and others, right?

I prefer the rust's *-sys and *-src system. In this case the crates lapack, lapack-sys, and *-src are closely related but independently exist. I think only lapack should be seen from end-users, and the backend should be switched by its features list without crate specification.
It is inconsistent that openblas can be used by the feature, but intel-mkl need a "complicated" way.

[IvanUkhov]

Please have a look at the discussion here. I lean toward what @astraw proposes there. To this end, I’ve already created blas-src and lapack-src. Ideally, the usage of blas, blas-sys, lapack, and lapack-sys should look as follows:

[dependencies]
blas = "0.18"
blas-src = { version = "0.1", features = ["openblas"] }

But one will also have to mention the linking crate in the codebase:

extern crate blas;
extern crate blas_src;

The next step is to remove all the features from those four main crates. However, it should first be agreed upon by those who’re actively involved in this project.

[astraw]

I just added a comment at blas-lapack-rs/blas-sys#17 describing that approach is working for me in practice. I agree with removing feature flags from the low-level binding and wrapper crates and specifying the actual implementation in a crate used as a dependency only in the final binary.

[termoshtt]

I see the policy. Can I send PR to blas-src and lapack-src to enable intel-mkl backend?

[IvanUkhov]

@termoshtt, I think it’s better to wait. We haven’t come to any conclusion yet.

[termoshtt]

OK.

BTW, blas-src lacks feature flags for openblas-src which switch shared/static/system.

[IvanUkhov]

Yeah, those features are another complication if we want to have a single access point to different implementations.

[IvanUkhov]

I close this, as it’ll eventually be somewhere else, such as on this page.