Update to use libblastrampoline

[ViralBShah]

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

[xrq-phys]

Hi.

Thanks for contacting.
I'm not familiar with libblastrampoline, but what I want to tout is that BLIS provides a more flexible API compared to standard BLAS (e.g. generic strides and mixed precision) and I want to make use of it.

At this moment simply substituting the backend seems to be insufficient in that sense.

[ViralBShah]

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.

[xrq-phys]

I've once mimicid MKL.jl and created this toy.

I can directly put the switcher code inside this repo but trying libblastrampoline out seems more interesting.

[ViralBShah]

Basically, lbt_forward in current Julia master (1.7-dev), allows you to switch the underlying BLAS for all routines with a new one with MKL or potentially BLIS, without having to rebuild the system image.

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

[xrq-phys]

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

[ViralBShah]

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.

[ViralBShah]

JuliaPackaging/Yggdrasil#2657

[carstenbauer]

Just wanted to drop a +1 here. Getting MKL via a simple using MKL is awesome. Would be great for BLIS too!

[carstenbauer]

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 BLAS.set_num_threads(N) sets the number of OpenBLAS threads. Is there a way to also set the BLIS threads or, more generally, the threads of a specific BLAS/LAPACK in the LBT stack (cc @staticfloat)? For now I use

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

[staticfloat]

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.

[carstenbauer]

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, BLAS.get_num_threads/BLAS.set_num_threads doesn't allow me to specify the library. Do we need to extend the API here or is there another way to access the registered get/set_num_threads functions?

UPDATE: According to the doc strings for lbt_get/set_num_threads I should get/set the num threads of all libraries at the same time. But that doesn't seem to be the case?

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]

FYI: https://github.com/carstenbauer/BLISBLAS.jl

[xrq-phys]

@carstenbauer I think LBT's failure to set # of threads is due to this line. libblastrampoline 64_ suffix to all library subroutines not just BLAS ones, while BLIS is built only with the latter.

[xrq-phys]

Sorry not really.

BLIS DOES has 64_ suffix, but is in the form of bli_thread_set_num_threads_64_ instead of bli_thread_set_num_threads64_.

I would suppose in this case we shall amend libblastrampoline since BLIS in 32-bit case also yields bli_thread_set_num_threads_.