-
Notifications
You must be signed in to change notification settings - Fork 4
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
Update to use libblastrampoline #3
Comments
Hi. Thanks for contacting. At this moment simply substituting the backend seems to be insufficient in that sense. |
Right, BLIS provides a more flexible API. We should also be able to provide a way for BLIS to replace the underlying Julia BLAS with only one line of code. I will try this out and report findings - but we first need to do some more work on the LAPACK front. |
I've once mimicid MKL.jl and created this toy. I can directly put the switcher code inside this repo but trying |
Basically, The only thing is that both OpenBLAS and MKL provide the full LAPACK, but when we use BLIS, we probably want to compile our own LAPACK from source and provide it in BinaryBuilder. cc @staticfloat |
I see. That would be a little tricky.
The little painful thing is that libFLAME doesn't provide full LAPACK77 API.
Yet NumPy supports it so maybe someone or myself would be interested in
making a wrapper.
On Mon, Mar 8, 2021 at 2:08 Viral B. Shah ***@***.***> wrote:
Basically, lbt_forward in current Julia master, allows you to switch the
underlying BLAS for all routines with a new one with MKL or potentially
BLIS.
The only thing is that both OpenBLAS and MKL provide the full LAPACK, but
when we use BLIS, we probably want to compile our own LAPACK from source
and provide it in BinaryBuilder.
cc @staticfloat <https://github.com/staticfloat>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4GUGUDMG52CSZ44X3VHGDTCO6K3ANCNFSM4YXIZHCQ>
.
--
--------------------
*Xu* RuQing
*許* ルーキン
東大理学系研究科
物理学専攻藤堂研
所属研究室Eメール: ruqing.xu@phys.s.u-tokyo.ac.jp
東京大学生Eメール: r-xu@g.ecc.u-tokyo.ac.jp
|
In order to use BLIS in Julia, we will just have LAPACK link to BLIS' BLAS API trough LBT. Then all packages that need BLAS can use BLIS and we can see how it performs. Separately this package and FLAME.jl in the future can explore further capabilities as you articulate. |
Just wanted to drop a +1 here. Getting MKL via a simple |
FWIW, using blis_jll
using LinearAlgebra
BLAS.lbt_forward(blis) seems to work nicely (up to the fact that the remaining LAPACK doesn't use / link against BLIS as mentioned by @ViralBShah above, see also here). I would really like to have a MKL.jl-like package for BLIS that does this simple BLAS switching via LBT. As I understand it from the comments above, the package here (BLIS.jl) currently has a different goal / approach. Is this correct (@xrq-phys)? Should I therefore create a new package, say, "BLISBLAS.jl"? Side comment: I realized that for the stacked OpenBLAS + BLIS (example above) the function blis_get_num_threads() = @ccall blis.bli_thread_get_num_threads()::Cint
blis_set_num_threads(nthreads) = @ccall blis.bli_thread_set_num_threads(nthreads::Cint)::Cvoid |
It looks to me like LBT should already know how to deal with BLIS. There is a completely generic way in which you can register get/set_numthreads functions for your own BLAS library, but BLIS should already be handled natively. |
Thanks for the info, that's good to know. But what if I have multiple BLAS/LAPACK libraries stacked on top of each other? Unless I'm missing something, UPDATE: According to the doc strings for julia> using LinearAlgebra
julia> BLAS.get_num_threads()
8
julia> using blis_jll
julia> BLAS.lbt_forward(blis; clear=false)
157
julia> BLAS.get_num_threads()
8
julia> blis_get_num_threads() = @ccall blis.bli_thread_get_num_threads()::Cint;
julia> blis_set_num_threads(nthreads) = @ccall blis.bli_thread_set_num_threads(nthreads::Cint)::Cvoid;
julia> blis_get_num_threads()
-1
julia> blis_set_num_threads(2)
julia> blis_get_num_threads()
2
julia> BLAS.get_num_threads()
8
julia> BLAS.set_num_threads(3)
julia> blis_get_num_threads()
2 |
@carstenbauer I think LBT's failure to set # of threads is due to this line. libblastrampoline |
Sorry not really. BLIS DOES has I would suppose in this case we shall amend |
You can teach LBT about your thread function name with the following Julia code:
Note that the 32-bit version of BLIS calls its thread setter function EDIT: Whoops, I mis-read my own API, this code chunk is wrong. |
Sorry I made a mistake. In BLIS only the setter has F77 interface:
while The problem is that Another issue is that: Btw line#14 and line#21 seem to have reversed setter and getter. |
Perhaps, at least the generic registration method should support thread-num setter with and without the |
I'm a little confused here; is
So what I see here is that one symbol has no trailing underscore, whereas another does have the trailing underscore. I call this a trailing underscore because the ILP64 symbol suffix that the BLIS library uses (as detected by LBT) is
This symbol suffix is detected by probing for a few F77 names with a few suffixes, and if we look at the names for those symbols that are exported from BLIS:
We see that the canonical name
Are you using a different version of
Good catch! Swapped in JuliaLinearAlgebra/libblastrampoline@145bb64
The generic registration method doesn't pay any attention to names; it relies on you to do the |
This line seems only working on strings? |
@staticfloat To your question, current configuration for BLIS builds Anyway, since libblastrampoline does not pass-in pointers, I'd stick to |
The issue observed above (#3 (comment)) should be fixed with the latest update to the Yggdrasil recipe (JuliaPackaging/Yggdrasil#7448).
|
It would be great to use the same mechanism that MKL.jl uses now, and leverage libblastrampoline.
https://github.com/JuliaLinearAlgebra/MKL.jl/blob/master/src/MKL.jl
The text was updated successfully, but these errors were encountered: