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!
Drew
Reply to: