-
Notifications
You must be signed in to change notification settings - Fork 32
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
BLAS interface completeness? #138
Comments
…mented This warns about the currently undocumented behavior of JuliaLinearAlgebra#138 that `using MKL` is not a complete wrapper and is thus breaking.
I'm a bit confused, what do you mean by the bindings being incomplete and the function being missing? This should be handled by the lbt layer redirecting to MKL's function, and the stacktrace given in SciML/LinearSolve.jl#427 (comment) seems to show it is actually being dispatched into the library for the |
See also here. |
From my tests, it appears that the two pairs of LAPACK auxiliary routines |
They are physically in the MKL library:
And
When I load MKL into the REPL, the forward has a pointer in it: julia> BLAS.lbt_get_forward(:dlanv2_, BLAS.LBT_INTERFACE_LP64)
Ptr{Nothing} @0x00007f96022fb2a0 However, the ILP64 version does not: julia> BLAS.lbt_get_forward(:dlanv2_, BLAS.LBT_INTERFACE_ILP64)
Ptr{Nothing} @0x00007f967e8ceb50
julia> BLAS.lbt_get_default_func()
Ptr{Nothing} @0x00007f967e8ceb50 The reason is that the e.g., the manual states:
If I use the LBT footgun API to create the mapping for the ILP version julia> dlanv_ = BLAS.lbt_get_forward(:dlanv2_, BLAS.LBT_INTERFACE_LP64)
Ptr{Nothing} @0x00007f2bbd2fb2a0
julia> BLAS.lbt_set_forward("dlanv2_", dlanv_, BLAS.LBT_INTERFACE_ILP64)
0
julia> lanv2(1.,2.,3.,4.)
(-0.3722813232690143, 0.0, 5.372281323269014, 0.0, -0.8245648401323938, 0.5657674649689923) |
The symbol is called from inside of the SLICOT library. Will the mapping also apply to such calls? |
Is slicot linked against libblastrampoline? If so, I believe this mapping would also apply to calls that are made from SLICOT through libblastrampoline. |
What are the implications on the |
Looks like it https://github.com/JuliaPackaging/Yggdrasil/blob/c0b6369e57c315ea92ec01c3734d2a0ccb559a5d/S/SLICOT/build_tarballs.jl#L84 |
There should be no problems with SLICOT. I contacted the main developer of SLICOT (Vasile Sima) and he confirmed that SLICOT is MKL compliant (of course there could be differences in the employed versions). I myself replaced the function dlanv2 with a generic version programmed in Julia and all tests for PeriodicSystems are passed also with MKL. So until now, only dlanv2 and dladiv raise problems. |
That mapping will also fix the ccall for the functions. I have put together an initial list of methods that seem to be missing and need this mapping in #140. I tried your example from the forum with that change in the package, and it works calling |
Fixed in #140 and should be further fixed in a future MKL release upstream as well. |
I was pretty surprised to find that the MKL.jl bindings were incomplete. That doesn't seem to be documented anywhere? In order for
using MKL
to be non-breaking, it needs to be complete or have fallbacks in any case where MKL does not provide a solution. In terms of what I can find from https://discourse.julialang.org/t/again-errors-with-no-blas-lapack-library-loaded/105943/8 SciML/LinearSolve.jl#427, at leastlacpy
seems to be missing.The text was updated successfully, but these errors were encountered: