Use system Intel MKL

[carstenbauer]

Would be great if there was a way to tell MKL.jl to use a system-wide Intel MKL installation instead of relying on MKL_jll. On an HPC cluster it seems suboptimal that every user downloads a separate MKL instance.

[DilumAluthge]

I wonder if there is a way to use Overrides.toml to accomplish this?

[carstenbauer]

This would be particularly great since using MKL.jl seems to / should become the standard way to use Intel MKL in Julia. Apart from switching out LIBM this would enable me to just use the default binaries, no need to compile from source anymore!

[giordano]

I wonder if there is a way to use Overrides.toml to accomplish this?

https://docs.binarybuilder.org/stable/jll/#Non-dev'ed-JLL-packages

[carstenbauer]

@giordano That looks great, thanks for the pointer. I'll try to play around with it tomorrow.

Note for future self: https://pkgdocs.julialang.org/dev/artifacts/#Overriding-artifact-locations

[ViralBShah]

Sounds like a good idea if this is possible, if we can do it without affecting the experience for users who will use the default (which is that we download the MKL JLL for them).

[andreasnoack]

Wouldn't the simplest solution be to provide MKL_jll from a centralized package installation on the cluster?

[carstenbauer]

Wouldn't the simplest solution be to provide MKL_jll from a centralized package installation on the cluster?

In theory, maybe. In current practice, certainly not (IMO).

Intel MKL is a pretty standard requirement in HPC and, at least for now, setting up and using a centralised admin depot is rather elaborate and, IMHO, also somewhat intransparent and immature (see the multiple rather vague threads on discourse on this topic).

Also, Julia still isn't properly supported by many (most?) HPC clusters. An MKL_jll.jl option can be used by the user. Setting up a centralised depot is a task for the admins and hence might take forever or might not happen at all if one is unlucky (not to mention version updates).

(BTW, I'd really like to see this whole idea of a centralised depot to be worked out and documented more. I hope to be able to find some time to work on this over the next few months.)

[carstenbauer]

Alright, I tested the Overrides.toml based approach. While it works in the sense that both MKL_jll and its dependency IntelOpenMP_jll indeed use my custom artifacts - essentially folders with lib/ subfolders into which I symlinked the system-wide libraries - there is one big issue: Pkg eagerly downloads the original artifacts despite my overrides and then just doesn't use them afterwards. This, of course, renders this approach useless for the use case discussed here. (Note that this doesn't happen for MKL_jll itself because it is lazy. However, according to @giordano essentially MKL_jll and CUDA_jll are the only wrapper packages that are lazy.)

So either we (can) make IntelOpenMP_jll lazy as well or providing MKL / MKL_jll through a central depot is indeed the way forward.

[giordano]

I'd try to see whether there is a chance Pkg.jl can be instructed to not download overridden artifacts. You'd solve the issue in a much more general way than doing it something special only in MKL.jl.

[carstenbauer]

See JuliaLang/Pkg.jl#2664