You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MKL is a rather large dependency and it would be nice to not ship it to the half of the ecosystem that pulls in FFTW in some form (okay, half is an overstatement but it's a pretty large amount). It's not even a default:
Alternatively, the FFTs in Intel's Math Kernel Library (MKL) can be used by running FFTW.set_provider!("mkl"). MKL will be provided through MKL_jll. This change of provider is persistent and has to be done only once, i.e., the package will use MKL when building and updating. Note however that MKL provides only a subset of the functionality provided by FFTW. See Intel's documentation for more information about potential differences or gaps in functionality. In case MKL does not fit the needs (anymore), FFTW.set_provider!("fftw") allows to revert the change of provider.
So why is it shipped by default? I think it really should be a separate package, MKLFFT.jl or something of the sort, so that those who want to use the MKL FFT can add the MKL FFT, and those who want the FFTW one (with a substantially smaller artifact and less issues, i.e. #227) can just use that.
It isn't. Pkg doesn't have optional packages, so we can't optionally depend on MKL_jll (unless you want to use Requires.jl), but the artifact isn't actually installed unless you opt into using MKL as provider.
MKL is a rather large dependency and it would be nice to not ship it to the half of the ecosystem that pulls in FFTW in some form (okay, half is an overstatement but it's a pretty large amount). It's not even a default:
So why is it shipped by default? I think it really should be a separate package, MKLFFT.jl or something of the sort, so that those who want to use the MKL FFT can add the MKL FFT, and those who want the FFTW one (with a substantially smaller artifact and less issues, i.e. #227) can just use that.
If it makes sense to have the developmental locality, then I would propose using a subpackage like how https://github.com/JuliaGPU/KernelAbstractions.jl has subpackages for its CUDAKernels, AMDGPUKernels, etc. https://github.com/JuliaGPU/KernelAbstractions.jl/tree/master/lib. That makes it 4 packages in one git repo, easy to maintain, but you don't have everyone install the Intel GPU drivers by virtue of having KernelAbstractions.jl
The text was updated successfully, but these errors were encountered: