MKL.jl icon indicating copy to clipboard operation
MKL.jl copied to clipboard

Use system Intel MKL

Open carstenbauer opened this issue 4 years ago • 10 comments

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.

carstenbauer avatar Jul 05 '21 14:07 carstenbauer

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

DilumAluthge avatar Jul 05 '21 17:07 DilumAluthge

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!

carstenbauer avatar Jul 05 '21 17:07 carstenbauer

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

giordano avatar Jul 05 '21 17:07 giordano

@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

carstenbauer avatar Jul 05 '21 18:07 carstenbauer

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

ViralBShah avatar Jul 05 '21 21:07 ViralBShah

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

andreasnoack avatar Jul 06 '21 06:07 andreasnoack

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 avatar Jul 06 '21 07:07 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.

carstenbauer avatar Jul 06 '21 15:07 carstenbauer

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.

giordano avatar Jul 06 '21 15:07 giordano

See https://github.com/JuliaLang/Pkg.jl/issues/2664

carstenbauer avatar Jul 06 '21 15:07 carstenbauer