Cross-distro Call for BLAS64/LAPACK64 Convention Alignment
Dear BLAS/LAPACK maintainers[0],
(Please invite more distribution maintainers to join the discussion
if you know the right contact, thanks. Please keep the debian-science
public mailing list in CC to keep the discussion public.)
Mordern BLAS/LAPACK implementations, such as OpenBLAS, BLIS, etc
support compile-time options to enable the array-64bit-indexing[1]
feature. BLAS/LAPACK libraries with such feature enabled are not
compatible to the 32bit-indexing versions in the ABI level, but
they lack a standard in SONAME and ELF symbol names. Please allow
me to omit the explanation about why we need to reach a consensus
on BLAS64/LAPACK64 convention and why scientific computing users
need them, as I think all the participants have enough background
on this problem.
In this mail I'll simply call these 64bit-indexing implementations
as BLAS64/LAPACK64. I'm trying to reach a consensus with major
distributions on the convention for BLAS64/LAPACK64 libraries,
including SONAME and ELF symbol names. @nalimilan had already
said about this on GitHub during the Julia's debate on their
libopenblas64_.so .
------ First let's look at the SONAME ---------
32-bit indexing BLAS/LAPACK are not compatible with the
64-bit indexing BLAS/LAPACK libraries in the ABI level.
If we don't change the SONAME for the 64-bit ones,
every people, including developers and users, would
get confused on what configuration is.
Fedora's .spec compiles OpenBLAS more than once, producing
a series of libraries (which share the same functionality)
with different index length and different threading models.
Particularly the named the default 64bit-indexing variant
of OpenBLAS as "libopenblas64.so".
Last year I raised a similar discussion on debian-devel
about the convention. The first version I proposed is
things like "libblas-ilp64.so" and "libopenblas-ilp64.so"
following MKL/Fortran's convention. But our opinion
eventually converged at "libopenblas64.so", "libblas64.so",
etc.
Hereby I propose:
*. We (cross-distro) append the "64" string to the SONAME
of a 64bit-indexing BLAS/LAPACK variant in order to
differentiate them from the currently existing
32bit-indexing ones.
----- Then let's look at the symbol names ------------
Different 32-bit BLAS/LAPACK libraries are expected to
be compatible with each other in both API/ABI level.
Based on this prior knowledge Debian developed a
runtime-switching mechanism[3] to switch the actually
used BLAS/LAPACK library, which had been working
well for years. Recently we've even introduced
intel-mkl (non-free) into this mechanism.
For most BLAS/LAPACK implementations that support
64bit-indexing, the symbol names are not mangled.
which means both libblas.so and libblas64.so
provide symbols such as "sgemm_" (fortran
subroutine for single-precision general
matrix-matrix multiplication", but with different
index types (int32_t v.s. int64_t).
Hereby I propose:
* We (cross-distro) don't mangle the symbols in
a 64bit-indexing BLAS/LAPACK library to avoid
introducing surprise to scientific computing
users.
The following special case explains why I propose so:
----- And there are special cases : Julia -------
Julia re-SONAME'ed their vendored openblas into
libopenblas64_.so, and mangled all the exported
symbols by suffixing "64_".
To some extent this choice is made in order to
avoid symbol clash with system libraries if
libblas.so and libblas64.so are indirectly
dynamically linked to a program.
This choice has a downside: Julia's pre-bulit binaries
are all linked against libopenblas64_.so (e.g. Arpack.jl)
And distribution packages won't be useful
anymore to Julia's ecosystem.
-----
What's your opinion? If we made a good start,
later on I'll try to contact some upstream such as intel's MKL team.
-----
[0] Felix Yan: Archlinux
Susi Lehtola: Fedora
Sébastien Villemot: Debian
Benda Xu: Gentoo
François Bissey: Gentoo
Milan Bouchet-Valat: Julia
Me: Debian & Gentoo
[1] The feature stems from a Fortran feature that could change
the default length of "INTEGER" type to 32bit or 64bit:
"-fdefault-integer-8"
The current BLAS/LAPACK libraries provided by distributions
are basically compiled in the 32bit-indexing mode (even if
on amd64), which makes them infeasible for dealing with
super large arrays.
[2]
https://src.fedoraproject.org/rpms/openblas/blob/master/f/openblas.spec
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/openblas
https://salsa.debian.org/science-team/openblas/
https://github.com/gentoo/gentoo/tree/master/sci-libs/openblas
[3] https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
Reply to: