Re: Removing ATLAS?
* Sébastien Villemot <sebastien@debian.org> [2023-07-08 10:01]:
As the maintainer of the atlas package over the last decade, I now
wonder whether we should remove it from the archive.
As a reminder, ATLAS is an optimized BLAS implementation, that fits
into our BLAS/LAPACK alternatives framework.¹ Its strategy for
achieving good performance is to adjust various internal array sizes
(at build time) so that they fit in the processor cache. It was
probably the first optimized BLAS added to Debian (in 1999).
Today, the project looks dead. The last stable release (3.10.3)
happened in 2016. The last development release (3.11.41, not packaged)
was in 2018. The git repository has seen no commit since 2019.²
Moreover, there are better alternatives. Most people today use
OpenBLAS. There is also BLIS, which can in particular be used on
architectures not supported by OpenBLAS.
Also note that ATLAS has never been really well-suited to our
distribution model. To get the most of ATLAS, you have to recompile it
locally using the specific CPU that you want to target; a generic
binary package like the one we distribute is a suboptimal solution,
since it is not adapted to the local CPU cache size.
So, given all that, I’m inclined to (try to) remove atlas during the
trixie development cycle.
There are quite a few package which (build-)depend on atlas, I attach a
list. But my guess is that these should be easily fixable, because most
(if not all) do not require ATLAS specifically. One should normally not
need to build-depend on atlas, since all our BLAS implementations are
ABI-compatible (build-depending on libblas-dev should give an
equivalent binary, unless one is doing static linking). For the
dependencies of binary packages, I guess those were added to ensure
that the user has an optimized BLAS installed; so they can probably be
replaced by something like libopenblas0 | libblis4 (keeping in mind
that since BLAS/LAPACK implementations are managed by the alternatives
system, a dependency relationship cannot enforce the implementation
used at runtime on the user machine).
Any thought on this?
Thanks for starting this discussion and proposing a plan, Sébastien.
I looked at xmds2, which currently build-depends and depends on
libatlas-base-dev. For those who do not know, xmds2 is a tool written in
Python for generating C++ code that solvesq differential equations, using
a XML file with the description of the problem.
When generating the C++ code, the xmds tool tries to link against
libcblas.so, which, currently, only exists in the libatlas-base-dev
package.
I “fixed” the problem with a hacky patch to the file
xpdeint/support/wscript and by changing the dependencies to
libopenblas-dev | libblis-dev. If someone can review my changes [*], I
will be grateful.
Another issue is whether we should propose this patch (or something
similar) to the upstream authors. Thoughts are welcome.
Best,
Rafael
[*] https://salsa.debian.org/science-team/xmds2/-/commit/cf0fc3d85e86ebdeba9d929d5ecf656ce7657259
Reply to: