can we improve support for 8 byte integers in linear algebra libraries?

[migueldiascosta]

For MKL, the i8 toolchainoption selects the ilp64 variants of the libraries [1, 2]

We can easily make OpenBLAS also build a library with 8 byte integers with e.g. buildopts = ['', 'INTERFACE64=1'] in the easyconfigs, and a small change in the easyblock to pass this option to testopts and installopts, and eventually rename and check libraries.

(FlexiBLAS also supports this, with INTEGER8=ON, and in that case adds the 64 suffix to the command and library names)

There is also the option of adding a suffix to the symbol names (e.g., SYMBOLSUFFIX=64_ in OpenBLAS), but in that case the behaviour would be different to MKL and the application would need to be aware of that (e.g. [3, 4])

I think this will also be useful in order to build Julia from source, at least with the same defaults as upstream

But we do need to choose a convention for the library names and eventually symbol suffixes and stick to it

thoughts?

[1] https://github.com/easybuilders/easybuild-framework/blob/712f9d293235d19f34d0aeb109a0837ae03129dd/easybuild/toolchains/linalg/intelmkl.py#L136
[2] https://github.com/easybuilders/easybuild-framework/blob/b64c4969b28bd11c29bfabed82ee1a1a4b22d327/easybuild/toolchains/fft/intelfftw.py#L58)
[3] https://numpy.org/devdocs/user/building.html#bit-blas-and-lapack
[4] https://scipy.github.io/devdocs/building/#reference-for-build-options

[akesandgren]

There is a major problem to be solved though, Scalapack (PBLAS in particular) from netlib has no I8 support whatsoever, at least last time i checked..
I've been meaning to do stuff there, but never got enough time to even start...

[migueldiascosta]

@akesandgren well, I was thinking more of shared memory situations, and even then "opt-in" (and even using the different symbols besides the different library names) - when using Scalapack one can in principle simply increase the number of MPI processes to decrease the number of elements that each one needs to address

but sure, if the MKL 'i8' behaviour could be completely replicated, it would be cleaner

[jfgrimm]

running to this issue when trying to compile the latest GAMESS with the foss toolchain; GAMESS rejects OpenBLAS if it doesn't have 8-byte integer support

RE ScaLAPACK -- this looks to have some ilp64 support since Reference-ScaLAPACK/scalapack#19 (v2.2)

[guusbertens]

Fedora Linux's solution is to provide various copies of the .so and .a: they have one for LP64 (libopenblaso.so.0) and one for ILP64 (libopenblaso64.so.0). They ship just one set of header files. The way this is supposed to be used seems to be:

• For LP64: include "cblas.h". Link against LP64 library.
• For ILP64: define OPENBLAS_USE64BITINT, then include "cblas.h". Link against ILP64 library.

Hence, to use LP64 OpenBLAS no code changes are needed, which makes this backwards compatible. To use ILP64 OpenBLAS, minimal changes are needed.

EasyBuild could do this too: provide a single OpenBLAS EasyConfig, that installs LP64 and ILP64 versions in the same module. This means that loading a toolchain (e.g. foss/2023a) is all one needs to do.

Alternatively, they could be different EasyConfigs and different corresponding modules. Then, to use the one or the other, a user would need to first load the toolchain, and then swap out the default OpenBLAS module for the ILP64 one (order matters!).

With a single EasyConfig, users would need to make above changes to their code to use ILP64 OpenBLAS. With multiple EasyConfigs, users need to load an additional module but they don't need to change their code.

What do you think is best?

[akesandgren]

The normal way to name the libs is to have _lp64 or _ilp64 suffixes, then link the _lp64 to the default non-suffixed name.
calling it libopenblaso64 is just plain wrong since it doesn't actually say what the 64 refers to.

And it should absolutely be a single easyconfig.