Re: RFC: threading-aware virtual BLAS/LAPACK
On 20/05/2020 16:09, Mo Zhou wrote:
> (forwarding my mail from -devel to -science to RFC)
> Hi fellow devs,
>
> I've suddenly got some inspiration on this problem, which resulted in a
> much better solution for the problem the original proposal confronts.
>
> I like this overhauled solution.
>
> No extra shared libs, no extra SONAMEs. No extra burden for the
> BLAS/LAPACK maintainers. Minor patching work for maintainers with
> special demands.
>
> --- New solution ---
>
> 1. BLAS providers create new directory under
> /usr/lib/<triplet>/libblas-<threading>/
> and put another copy of their alternative symlinks into the
> directories.
>
> e.g. libopenblas-pthread provides the extra symlink:
> /usr/lib/<triplet>/libblas-pthread/libblas.so{,.3}
>
> 2. Maintainers of reverse dependencies, when they have specific
> requirement on the threading implemetation, add the
> /usr/lib/<triplet>/libblas-<threading>/
> directory to the RPATH property of the resulting ELF binaries.
> In that way the programs can use the BLAS implementation without
> worring about the uncertainty of the alternatives configuration.
>
> Other packages insensitive to the threading implementations will
> use the libblas.so.3 in the global scope:
> /usr/lib/<triplet>/libblas.so.3 (a symlink)
I'm in favour of the solution, when there are multiple variants, of:
/usr/lib/<triplet>/<variant>/lib/libblas.so
as a symlink
/usr/lib/<triplet><variant>/include/blah.h
with the real library in /usr/lib/<triplet>/libblas-<threading>.so
linked to from libblas.so
This enables reverse dependencies to use:
--with-blas-dir=/usr/lib/<triplet>/<variant>
This pattern is used within hdf5, openmpi, netcdf-parallel, etc. already.
The main libraries are in the base directory with different sonames.
If you have multiple libraries with the same soname (even if linked by
different rpaths) you eventually encounter the problem that somewhere on
your stack you link both of them.
This has happened with netcdf and paraview, visit, for example: some
plugins use netcdf underneath (or via a library like xdmf or adios) :
some plugins need a serial version so they can open compressed netcdf
files, while other plugins expect a parallel netcdf which is
incompatible. Both can end up linked into the same user executable, and
the symbols will clash unless sonames are used to distinguish them.
Regards
Alastair
> --- end solution ---
>
> That's it, much simpler and much more efficient than my first version.
>
> Comments please?
>
> @Edd, does it look like a decent solution for the threading trouble of R-4.0.0?
>
--
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
Reply to: