[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] BLAS/LAPACK Ecosystem Enhancement for Debian

On 2020-03-26 22:46, Mo Zhou wrote:
Hi science team,

As discussed before, thanks to google, I'm participating GSoC this year
and I'll work to improve our BLAS/LAPACK ecosystem. Details can be found
in my GSoC proposal document:

Great job, I hope you do well!

The expected diliverables of this project are:

 1. Documentation and the Debian Science Team Policy.
 2. Introducing NEW meaningful packages (e.g. libflame).

Two recent fresh installations has brought my attention to some factors that you could help with.

1) By default only the reference implementation libblas-dev is installed, which we know is relatively slow.

I recommend instead to make libblas-dev a dummy dependency package which depends on the various implementation, all of them listed in order according to the recommended implementation for each architecture. Having them listed in one package Dependency like this can also help system admins keep aware of which alternatives are available (otherwise blis might never be noticed). An analogy is the mpi-default-bin / mpi-default-dev package, which pulls in the preferred MPI implementation (although the libmpi are not compatible so only one is listed there)

Then place the reference implementation in its own package (which still provides libblas.so/libblas.so.3). It could be called libblas-reference-dev, would be at the back of the libblas-dev's Depends: list (unless some of them are known to break specific architectures)

e.g. libblas-dev Depends: libopenblas-dev | libblis-dev | libatlas-base-dev | libblas-reference-dev (probably just the base packages here are better, not explicitly listing the threading alternatives. Each of them can bring in the preferred threading)

That way, when a fresh installation installs libblas-dev, it will install an implementation that can be expected to work well.

2) The naming of the alternatives links is not intuitive, marked arch-specifically as libblas.so-x86_64-linux-gnu, libblas.so.3-x86_64-linux-gnu, etc. Normally it would just be libblas.so, as in "update-alternatives --config libblas.so", or better still "update-alternatives --config blas".
Is it really necessary to include the arch in the alternative name?

2b) A separate thing to look into is whether the alternative for libblas.so.3 can be slaved on to libblas.so (or vice versa) so they don't have to be configured separately. If there's likely to be a libblas.so.4 then it makes more sense to keep them separate, but it's been libblas.so.3 since the 1980s I believe. They are different packages so it's not so straightforward to slave-link them to one another. But the HDF5 maintainer recently found a way to do it (to link hdf5-mpi.pc against the preferred MPI alternative, see libhdf5-openmpi-dev.postinst)

3) There don't seem to be many benchmark comparisons of BLIS vs OpenBLAS. If you have time it would be nice to see the comparison (including other implementations too as time permits).

Good luck!


Reply to: