Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use system Intel MKL #82

Open
carstenbauer opened this issue Jul 5, 2021 · 10 comments · May be fixed by #84
Open

Use system Intel MKL #82

carstenbauer opened this issue Jul 5, 2021 · 10 comments · May be fixed by #84

Comments

@carstenbauer
Copy link
Member

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
Copy link
Member

DilumAluthge commented Jul 5, 2021

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

@carstenbauer
Copy link
Member Author

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
Copy link
Contributor

giordano commented Jul 5, 2021

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
Copy link
Member Author

carstenbauer commented Jul 5, 2021

@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
Copy link
Contributor

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
Copy link
Member

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

@carstenbauer
Copy link
Member Author

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
Copy link
Member Author

carstenbauer commented Jul 6, 2021

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
Copy link
Contributor

giordano commented Jul 6, 2021

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
Copy link
Member Author

See JuliaLang/Pkg.jl#2664

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants