I agree. The usage of ATLAS is more suitable for source based distros like Gentoo. Plus, according to my past benchmarks, ATLAS, even if compiled locally with -march=native flags, still falls behind OpenBLAS and BLIS in terms of performance.
Both OpenBLAS and BLIS are still healthy, actively maintained. So I agree it is time to let old libraries fade away. BTW, deprecating ATLAS can also help us remove the libcblas.so as well as fixing its reverse dependencies to use the correct libblas.so. On Sat, 2023-07-08 at 10:01 +0200, Sébastien Villemot wrote: > Hi, > > 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? > > Cheers, > > ¹ https://wiki.debian.org/DebianScience/LinearAlgebraLibraries > ² https://github.com/math-atlas/math-atlas/ >
