Again errors with no BLAS/LAPACK library loaded!

General Usage
1

After one week of a successful registration of a new version of PeriodicSystems, I am trying to prepare a new version by performing several commits. Running the tests, the following error pops up repeatedly

Error: no BLAS/LAPACK library loaded!

(see here)

I would appreciate any hint to identify the cause of these error messages and how to overcome them. What changed in Julia in the last week (perhaps the transition to v1.9.4)?

2 
julia> using LinearAlgebra

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries: 
â”” [ILP64] libopenblas64_.so

julia> using PeriodicSystems

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries: 
├ [ILP64] libmkl_rt.so
â”” [ LP64] libmkl_rt.so

loading PeriodicSystems causes MKL to completely replace OpenBLAS, and MKL likely doesn’t implement the BLAS functions you’re trying to call. Restoring OpenBLAS fixes the issue for me. You or some of your dependencies is forcing MKL in the entire session.

3

Looks like LinearSolve is to blame:

(jl_AYrTGj) pkg> why MKL
  PeriodicSystems → IRKGaussLegendre → OrdinaryDiffEq → LinearSolve → MKL
  PeriodicSystems → IRKGaussLegendre → OrdinaryDiffEq → NonlinearSolve → LinearSolve → MKL
  PeriodicSystems → OrdinaryDiffEq → LinearSolve → MKL
  PeriodicSystems → OrdinaryDiffEq → NonlinearSolve → LinearSolve → MKL

And that’s on Apple silicon :roll_eyes:

4

I am working under Windows. Here is what I got repeating the same commands using Julia v1.9.2:


julia> using LinearAlgebra

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries:
â”” [ILP64] libopenblas64_.dll

julia> using PeriodicSystems
[ Info: Precompiling PeriodicSystems [top-level]

julia> BLAS.get_config()
LinearAlgebra.BLAS.LBTConfig
Libraries:
â”” [ILP64] libopenblas64_.dll

So, I can not reproduce your results. The tests have been performed under Julia 1.9.3, but I registered a new version of the package last week, using the same version without problems!

5

There’s been a release of LinearSolve in the meantime. Here’s the guilty commit:

6

Also, note that your CI failure was on ubuntu-latest :wink:

7

I would appreciate very much any proposal for fixing this issue.

Just for my curiosity: Everybody using OrdinaryDiffEq will face this issue?

8

Only the subset of people using functions not implemented by MKL.

9

I raised an issue to fix this problem, and, apparently, I am not the only one affected by this problem. Since potentially, every Julia user could be affected (in one or another way) by switching at runtime in packages to different linear algebra support, this practice, in my opinion, should be forbidden, because of the possible unpredictable side effects. I already lost three days trying to debug a situation, for which I don’t feel responsible!

2 Likes
10

You do seem to be the only one effected by this problem. To reiterate @giordano , “Only the subset of people using functions not implemented by MKL.” The only two other things that were brought up were unrelated to your problem:

  • It seems Distributed is hardcoded to set OpenBLAS num threads to 1, not BLAS num threads. Weird, but okay that should get fixed.
  • 2 people reported that MKL is about 1.5x-2x slower on AMD Epyc (depending on the operation), and like 50 people reported speedups generally in the 2x-100x range (100x being sparse matrices when set to UMFPACK).

If this was the only thing reported in isolated, then it would not be reverted since that would be an absolutely self-serving definition of performance regression. It was by far a massive success in the performance department, though yes there is one specific case we know of now where MKL is slower. That said, what I didn’t want is the breaking behavior, and indeed since there is breaking behavior we will have to pull back on this.

For exactly why we have to use LBT in order to not be 100x slower on sparse matrix operations, and were told by Tim Davis that we shouldn’t be using OpenBLAS linked to UMFPACK, please see Allow UMFPACK to be run with an alternative BLAS under the hood · Issue #453 · JuliaSparse/SparseArrays.jl · GitHub

1 Like
11

I will try to fix the MKL related problems in my packages. I detected at least two pairs of LAPACK functions, dlanv2/slanv2 and dladiv/sladiv for which there are (apparently) no MKL interfaces which meet the OpenBLAS interfaces. Fortunately, I have pure Julia based implementations allowing arbitrary precision computations, so I will replace with calls to these functions.

I appreciate very much your desire to have top performance for all software pieces. If this can be done in an encapsulated way (as you propose for UMFPACK) this is a very good goal. However, by enforcing with a single call using MKL that a complex package as PeriodicSystems, with plenty of dependencies, executes using MKL, is in my opinion a delicate issue and a big responsibility, without the possibility to guarantee that the exhibited behaviour of all functions will remain the same.

1 Like
12

In theory changing BLAS changes no behavior, just performance. In practice I think we learned it’s not there yet, but I hope this is a forcing function towards breaking away from OpenBLAS