Show methods for LBTConfig and LBTLibraryInfo

[carstenbauer]

See discussion in JuliaLinearAlgebra/MKL.jl#73. Because of the new libblastrampoline facilities, BLAS.get_config() is replacing BLAS.vendor() as the way to check which BLAS is used. However, the current output is very hard to parse and contains lots of unnecessary information. This PR improves the printing of the relevant LBT types.

Before the PR:

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig(LinearAlgebra.BLAS.LBTLibraryInfo[LinearAlgebra.BLAS.LBTLibraryInfo("/Applications/Julia-1.7.app/Contents/Resources/julia/bin/../lib/julia/libopenblas64_.dylib", Ptr{Nothing} @0x00007fb4d1d16690, "64_", UInt8[0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff  …  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01], :ilp64, :plain)], [:f2c_capable], ["LAPACKE_c_nancheck", "LAPACKE_cbbcsd", "LAPACKE_cbbcsd_work", "LAPACKE_cbdsqr", "LAPACKE_cbdsqr_work", "LAPACKE_cgb_nancheck", "LAPACKE_cgb_trans", "LAPACKE_cgbbrd", "LAPACKE_cgbbrd_work", "LAPACKE_cgbcon"  …  "zunmlq_", "zunmql_", "zunmqr_", "zunmr2_", "zunmr3_", "zunmrq_", "zunmrz_", "zunmtr_", "zupgtr_", "zupmtr_"])

julia> using MKL

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig(LinearAlgebra.BLAS.LBTLibraryInfo[LinearAlgebra.BLAS.LBTLibraryInfo("/Users/crstnbr/.julia/artifacts/073ff95e2c63501547247d6e1321bf4ee2a78933/lib/libmkl_rt.1.dylib", Ptr{Nothing} @0x00007fb4d1e84e20, "", UInt8[0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff  …  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01], :ilp64, :plain)], [:f2c_capable], ["LAPACKE_c_nancheck", "LAPACKE_cbbcsd", "LAPACKE_cbbcsd_work", "LAPACKE_cbdsqr", "LAPACKE_cbdsqr_work", "LAPACKE_cgb_nancheck", "LAPACKE_cgb_trans", "LAPACKE_cgbbrd", "LAPACKE_cgbbrd_work", "LAPACKE_cgbcon"  …  "zunmlq_", "zunmql_", "zunmqr_", "zunmr2_", "zunmr3_", "zunmrq_", "zunmrz_", "zunmtr_", "zupgtr_", "zupmtr_"])

julia> BLAS.get_config().loaded_libs[1]
LinearAlgebra.BLAS.LBTLibraryInfo("/Users/crstnbr/.julia/artifacts/073ff95e2c63501547247d6e1321bf4ee2a78933/lib/libmkl_rt.1.dylib", Ptr{Nothing} @0x00007fb4d1e84e20, "", UInt8[0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff  …  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01], :ilp64, :plain)

After the PR:

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries:
└ libopenblas64_.dylib

julia> using MKL
[ Info: Precompiling MKL [33e6dc65-8f57-5167-99aa-e5a354878fb2]

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries:
└ libmkl_rt.1.dylib

julia> BLAS.get_config().loaded_libs[1]
LinearAlgebra.BLAS.LBTLibraryInfo
├ Library: libmkl_rt.1.dylib
├ Interface: ilp64
└ F2C: plain

Should I also add tests for the new printing?

(cc: @ViralBShah, @staticfloat)

[staticfloat]

This is beautiful! Very nice! I would say that in the overall LBTConfig output it's quite useful to know whether a loaded library is LP64 or ILP64; I can think of two ways to do this. Either print the libraries out in two separate categories:

# Example where only MKL is loaded
julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
ILP64 Libraries:
└ libmkl_rt.1.dylib

# Example where both OpenBLAS and OpenBLAS32 are loaded:
julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
ILP64 Libraries:
└ libopenblas64_.dylib
LP64 Libraries:
└ libopenblas.dylib

Or print out the interface alongside each library:

# Example where both OpenBLAS and OpenBLAS32 are loaded:
julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries:
├ [ILP64] libopenblas64_.dylib
└ [ LP64] libopenblas.dylib

[carstenbauer]

Good suggestion, I implemented the second variant.

(BTW, we don't have an rjust method that pads a string with spaces, do we?)

[ViralBShah]

Should we print where the LAPACK also comes from?

[staticfloat]

If a separate LAPACK is loaded, it will show up in this list.

[ViralBShah]

@staticfloat Do we want to call it ILP64_?

[carstenbauer]

@staticfloat Do we want to call it ILP64_?

Let me note that the symbols in LBT_INTERFACE_MAP already call this :ilp64 rather than :ilp64_. So using "ILP64" is at least consistent.

[staticfloat]

@staticfloat Do we want to call it ILP64_?

No, we don't care about the suffix here. ILP64 is a semantic difference, suffixing is just naming, it doesn't matter to the user at all.

[staticfloat]

Thanks so much for this @crstnbr!

[ViralBShah]

Should we mark vendor() as deprecated for the 1.7 release cycle so that we can remove it in 1.8. It is a private API, but this way we don't have to worry about breakage.

[staticfloat]

Yes please.

[ViralBShah]

@crstnbr Would you be up for making the deprecation PR?

[carstenbauer]

@ViralBShah will do.

[carstenbauer]

@ViralBShah I see that, on master, there already is a Base.depwarn call in BLAS.vendor() - although it doesn't trigger for me unless I change force=true. (Relevant commit, actually by you: dc81980)

Can you tell me what should happen in the deprecation PR?

Currently, I could only think of moving the BLAS.vendor() definition to LinearAlgebra/src/deprecated.jl and (It must still live inside the BLAS module I guess.) adding a deprecation entry to NEWS.md.

[simeonschaub]

Ah yes, we don't show deprecation warnings by default anymore. You need to start Julia with --depwarn=yes to see the warning.

[carstenbauer]

Ah yes, we don't show deprecation warnings by default anymore. You need to start Julia with --depwarn=yes to see the warning.

Fair enough, thanks for the info. Although I wonder how useful deprecations are then as they might not be seen by many users. (I guess package developers can be trained to check with the cmd line flag)

[ViralBShah]

I think we mark it as a deprecation, and put it in our HISTORY and announce the changes as part of the 1.7 release. That would give us a smooth path to removing it in 1.8. Also, we did a package scan, and almost nobody uses it - and whoever does will be happier with the new API. So, I don't actually anticipate any major issue.