OpenBLAS vs reference blas implementation

Development
1

I’d like to build GNU Octave with 64 bit indices support, and I’m using their release candidate - version 6.0.90 - available from here.

I encountered an issue with blas implementations incompatibility. Octave has 3 dependencies besides blas itself, that require blas by themselves: qrupdate, arpack, sundials and suitesparse.

It seems that only with openblas, I’m able to get this from octave’s configure report:

  64-bit array dims and indexing:       yes
  64-bit BLAS array dims and indexing:  yes

When using reference blas and lapack implementations, I get:

  64-bit array dims and indexing:       yes
  64-bit BLAS array dims and indexing:  no

I learned, after discussing with upstream that a test failure I experienced was due to mismatched blas implementations used between octave and it’s dependencies’ blas. Hence I’m wondering if there’s a policy towards defaulting to the reference blas and lapack implementation, vs openblas, where the former doesn’t seem to have 64 bit indexing support by default:

$ nix eval -f. blas.isILP64
false

Maybe this is not intended? (I’m on x86_64).

Are there any licensing issues that make the reference blas implementation preferred over openblas?

My current status is this: I’m going to make qrupdate use openblas, like octave itself, since octave is the only package that depends upon qrupdate, but for suitesparse, arpack and sundials I am less sure, currently I’m testing building all of them with openblas.

For suitesparse, upstream recommends not using openblas, and not even the reference implementation. They recommend using mkl which is unfree. See GitHub - DrTimothyAldenDavis/SuiteSparse: The official SuiteSparse library: a suite of sparse matrix algorithms authored or co-authored by Tim Davis, Texas A&M University .

Regarding the licensing concern, it seems that the licenses of suitesparse, arpack and sundials are compatible with that of OpenBLAS (OpenBLAS’ is bsd3), but I could be wrong.

@ttuegel is maintainer of suitesparse and arpack. @flokli & @idontgetoutmuch are maintainers of sundials which accidentally, I’d be glad to have their opinion on Add KLU support to sundials by GuillaumeDesforges · Pull Request #94930 · NixOS/nixpkgs · GitHub .

Regards.

2

I am very happy with the PR. I am not sure why it’s not been accepted. I am use the PR all the time now.

I think sundials should work with openblas. I would be very interested in any performance results you get. I am not sure what the benchmarks are here though.

I occasionally use octave so great for doing this.

3

The PR is almost entierly unrelated, it’s just a sort of a blocker for Octave 6.

I think I have at least slightly misunderstood this expression:

https://github.com/doronbehar/nixpkgs/blob/81cae8a42703af55a9cca4d17e7c25bb35149129/pkgs/build-support/alternatives/blas/default.nix#L1-L5

The default blas attribute is a copy of files from the openblasCompat package which is compiled with 64 integers width support turned off:

https://github.com/doronbehar/nixpkgs/blob/81cae8a42703af55a9cca4d17e7c25bb35149129/pkgs/top-level/all-packages.nix#L26077-L26079

Upstream recommends not using a blas implementation with 64 bit support, unless “I really need it”. If someone is interested in using it, they should use the same implementation for all other deps.

The policy Octave devs recommends regarding the “unless you really need it” is aligned with that of Nixpkgs - blas is openblasCompat in disguise, and hence this answers my question.

I do think though, it’d be nice to make octave able to get compiled with 64 bit indexing support, and hence it’s worth adding a build flag for this, that will tell it, and all of it’s relevant deps to use openblas (with 64 bit indexing support (if on the right system)). I’ll work on it for the upcoming Octave 6 release.

It’s still interesting to get some benchmarks data, but I’m afraid that won’t worth my time. I will note, that I was able to get benchmarks easily thanks to phoronix-test-suite. I ran:

nix run nixpkgs.phoronix-test-suite -c phoronix-test-suite benchmark system/octave-benchmark

With the right octave in $PATH.

The nature of the Octave code that runs in the benchmark itself has influence on the results, and I have not yet investigated it.

4

This is the intended behavior. The reference BLAS only supports 32-bit indices, even on 64-bit platforms. (Fortran integers are still 32-bit by default.) openblasCompat should be a drop-in replacement for reference BLAS and LAPACK, and therefore has only 32-bit indices. All packages in a dependency graph should agree about the BLAS implementation, especially with regard to bit-width.