Bug#913567: python-numpy: Why depend on libatlas3-base
Hi, also, one of the PSI4 testcases fails with blas/lapack set to ATLAS, see https://github.com/psi4/psi4/issues/391 and https://github.com/psi4/psi4/issues/1461 So having that removed for buster would be very must appreciated. Michael
Bug#913567: python-numpy: Why depend on libatlas3-base?
Hi Sandro,
>provided by ATLAS; is this causing any problem?
yes: ATLAS does not work on all architectures (see #918076
for an example) and is generally harder to port.
I’ve seen you will upload a new version that works without,
but I wanted to still contribute this data point, so you
see that porters will also appreciate it ;-)
bye,
//mirabilos
PS: When adding pypy, please remember that also it is not
portable and will need an architecture whitelist. Thanks!
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh"). [aus dasr]
Bug#913567: python-numpy: Why depend on libatlas3-base?
Hi Sandro, I've discussed this matter on the debian science e-mail list asking for an cblas abstraction. I got a reply from Mo Zhou (https://lists.debian.org/debian-science/2019/01/msg2.html ). In short he suggested to file a bug against numpy (severity: important). I repeat the main part of the e-mail here: """ Debian's default (generic, no optimization) Atlas is really SLOW, such that I can write a faster BLAS by simply following this guide: https://github.com/flame/how-to-optimize-gemm Debian's reference BLAS (netlib) contains both BLAS and CBLAS API/ABI, which should be able to be linked against by numpy, and then we can make numpy use a high-performance BLAS backend by simply switching alternatives. Any user of a modern x84_64 CPU can easily find the giant performance gap between the default Atlas (generic code) and the default OpenBLAS (generic+optimized, runtime-dispatch). MKL would be even faster if the user doesn't mind installing non-free. I guess "cblas" is supposed to mean a backend with "cblas_*" API/ABI, and "blas" for "*_" (Fortran) API/ABI. If this is true, then at least MKL and openblas are expected to work well. As for numpy's linkage to libcblas.so ... I guess Sandro isn't aware of the fact that BLAS implementations such as OpenBLAS squashed both C and Fortran ABI into to a single shared object. And AFAIK only Atlas split the C ABI into an individual library libcblas.so . """ Regards, Jörg.
Bug#913567: python-numpy: Why depend on libatlas3-base?
reopen 913567 python-numpy 1:1.16.0~rc1-3
Bug#913567: python-numpy: Why depend on libatlas3-base?
Just wanted to add that openblas also provides a cblas interface in package libopenblas-dev via the header file /usr/include/x86_64-linux-gnu/cblas.h. Regards, Jörg.
Bug#913567: python-numpy: Why depend on libatlas3-base?
Sandro Tosi wrote on 12/11/2018 14:55: >> the package now depends on libatlas3-base besides the dependencies on >> BLAS/LAPACK. Couldn't this be avoided? > > libcblas was required to build numpy properly and, AFAICS, it's only > provided by ATLAS; is this causing any problem? > Hi, no it's not causing any problem at the moment. I was just concerned about the additional blas/lapack packages, since I have already installed libopenblas-dev and libopenblas-base. I was just wondering why some libraries now depend on libcblas as well as libblas but maybe this is a question better asked upstream. Regards, Jörg.
Bug#913567: python-numpy: Why depend on libatlas3-base?
> the package now depends on libatlas3-base besides the dependencies on > BLAS/LAPACK. Couldn't this be avoided? libcblas was required to build numpy properly and, AFAICS, it's only provided by ATLAS; is this causing any problem? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#913567: python-numpy: Why depend on libatlas3-base?
Package: python-numpy Version: 1:1.15.4-1 Severity: wishlist Dear Sandro Tosi, the package now depends on libatlas3-base besides the dependencies on BLAS/LAPACK. Couldn't this be avoided? Regards, Jörg.
