Re: RFC: threading-aware virtual BLAS/LAPACK
Mo Zhou <lumin@debian.org> writes:
> 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)
>
> --- end solution ---
>
> That's it, much simpler and much more efficient than my first version.
>
> Comments please?
Would it make sense for DH to acquire functionality to automate dealing
with this?
> On Wed, May 13, 2020 at 10:54:00PM +0200, Gard Spreemann wrote:
>>
>> An aside: do autopkgtest or other CIs currently test packages with
>> varied combinations of BLAS/LAPACK providers?
>
> No. But that's easy to implement.
>
> For example, we can add the following test cases in the autopkgtest
> control file of openblas:
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-pthread-dev
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-openmp-dev
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-serial-dev
>
> In this way we BLAS/LAPACK maintainers can immediately spot regressions
> in important packages. (adding these tests seems like my work)
D'oh, I should have thought of that. Thanks!
-- Gard
Reply to: