Use 64-bit BLAS

[bluss]

Using 64-bit BLAS allows removing the fallback for arrays with dimensions larger than the 32-bit supported by regular openblas.

64-bit refers to the index / stride / dimension size used.

[steabert]

I took a quick look at this with https://github.com/steabert/openblas-src/tree/ilp64 and https://github.com/steabert/cblas-sys/tree/ilp64, but as my rust knowledge is very limited at this point, I'm not sure if that would be the proper way to go.

For one thing, one would like to make sure there is no feature mismatch between them. I guess in this library, it would just come down to detecting the feature that was set in the dependency, or propagating the feature?

The biggest PITA with C/C++ and Fortran is usually getting mixed ilp64 and lp64 application/libraries with mostly garbage or the occasional crash at runtime.

[bluss]

Thanks for looking at this. The issue is pretty old, and I'm not sure what's the right path or if it's needed. To be pragmatic, using whatever can commonly be installed as "system blas" would be preferred, but there might even be use cases for supporting both.

[steabert]

There is a long story about "system blas" and the fact that it's mostly useless to anyone trying to run actual calculations :)

Because of historical reasons, the BLAS interface has the INTEGER type to specify dimensions, as it came from Fortran. There is no defined size for that, but most compilers default to 32bit. Then came CBLAS, which uses int for the dimensions. Since all compilers use 32bit as default size, anything that uses the standard BLAS/CBLAS headers will end up expecting 32bit int size, and that is also what any "system blas" offers.

The tragedy is that those CBLAS dimensions should have been size_t so that on 64bit systems the dimension would follow the size of the indexing. If you would write the interface in Rust, one would expect to have usize for the dimensions. This does not affect the performance of any BLAS library at all, integers are only used for indexing. The same goes for LAPACK.

So, the common procedure in computing is to compile the BLAS/LAPACK libraries with 64-bit default integer size. That data model is referred to as ilp64. This is usually supported by all fortran compilers, and some C/C++ compilers. This is what happens if you build OpenBLAS with INTERFACE64=1.

So, in the end, the only reason that the system blas has 32bit integer sizes for the dimensions is historic, and since that's the expected interface, that's what shipped with most distros. Usually, the ilp64 flavour of BLAS/LAPACK gets installed next to the system blas (which is lp64), and you just link to whatever you want. In practice that leads to issues of course, if you link to the wrong library.

What OpenBLAS e.g. offers is to have both interfaces into a single library file, but with different symbols, although that means you have to adapt your interface to use that: OpenMathLib/OpenBLAS#646, and related discussion: numpy/numpy#5906.

So after my little rant (sorry!), to the question of relevance / use case:

• if you use ndarray and don't want to compile anything, you'll most probably have to support the system blas, which means casting to c_int in the end.
• if you use ndarray and are fine with downloading and compiling e.g.OpenBLAS, there is zero reason to not compile that with INTERFACE64 on a 64-bit system, in which you'll end up casting to c_long_long.

I was excited to see the openblas-src package, as that does step 2. But they seem to only support the default integer size in the interface. The inertia in dealing with this issue is enormous, because of all the default system blas libraries out there. I'm not sure what's best either, but if packages like openblas-src exist for rust projects, there is no reason to support the old default there.

[bluss]

Thanks for the explanation! Sounds like it's tricky to solve in Rust's bindings too. For toolchain reasons I think it's a pain to have to compile blas just to run tests or CI - this is one reason to have a system-installed alternative. And in Rust, it's very common with clean builds too, and not reusing cargo builds between different projects, so build time always adds up.

[steabert]

You're absolutely right, it should be possible to use the system blas. I was hoping we could make it so that when neccessary, one could just flip a switch to compile an ilp64 version.