Bug#489726: should numpy be built with atlas?
[EMAIL PROTECTED] writes: On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.0-2 Severity: serious python-numpy now has an unconditional dependency on libatlas3gf-base, needing the specialized atlas libraries as a runtime dependency. Users still should have the option to use the standard blas and lapack libs instead of the untested/unmaintained atlas libraries in debian. The problem is that the new (1.0) numpy building system needs ATLAS at compile time to enable fast matrix-multiplication. If ATLAS is not found at compile time, numpy.core._dotblas.so is not built and slow matrix multiplication is used even if the end user has ATLAS installed. In the old numpy _dotblas.so was always compiled using refblas and the end user would still have had the option of using ATLAS. I'm not sure I understand why ATLAS is now needed at compile time, but look here: http://scipy.org/scipy/numpy/ticket/667 and here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784 I think python-numpy should stay as it is now and a bug-wishlist should be reported to the atlas package to encourage packaging of the new stable version (3.8.2). Filing a ticket on numpy trac may help, but the fate of ticket 667 seems to indicate that there's no will of fixing this bug upstream... thanks for the update. Looking at the blas package, I see that the cblas library is included in libblas3. So it looks like the numpy check is wrong, testing for a package name, and not for a feature. This seems to explain why it did work in etch, and this should be fixed in python-numpy. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489726: should numpy be built with atlas?
On 7/8/08, Matthias Klose [EMAIL PROTECTED] wrote: thanks for the update. Looking at the blas package, I see that the cblas library is included in libblas3. So it looks like the numpy check is wrong, testing for a package name, and not for a feature. This seems to explain why it did work in etch, and this should be fixed in python-numpy. Hi Ondrej, Hi Matthias. Removing the two lines in numpy/core/setup.py indeed seems to do the trick. Feel free to test the attached patch, generated against the python-numpy source package in sid. On my system it generates a numpy package with a _dotblas.so file correctly linked to lapack libs. If ATLAS is then installed, the ATLAS libraries are used instead. Ondrej: if the patch works, would you report it upstream? have a nice day! tiziano atlas.patch Description: Binary data
Bug#489726: should numpy be built with atlas?
On Tue, Jul 8, 2008 at 1:58 PM, Tiziano Zito [EMAIL PROTECTED] wrote: On 7/8/08, Matthias Klose [EMAIL PROTECTED] wrote: thanks for the update. Looking at the blas package, I see that the cblas library is included in libblas3. So it looks like the numpy check is wrong, testing for a package name, and not for a feature. This seems to explain why it did work in etch, and this should be fixed in python-numpy. Hi Ondrej, Hi Matthias. Removing the two lines in numpy/core/setup.py indeed seems to do the trick. Feel free to test the attached patch, generated against the python-numpy source package in sid. On my system it generates a numpy package with a _dotblas.so file correctly linked to lapack libs. If ATLAS is then installed, the ATLAS libraries are used instead. Ondrej: if the patch works, would you report it upstream? Yes, but first I'll upload a new package, because depending on the atlas packages is not good. It works on my system. Your script (attached) gives me: $ ./test_atlas.py Using ATLAS: 0.53141283989 $ wajig remove atlas3-base libatlas3gf-base $ ./test_atlas.py Using ATLAS: 1.64572000504 So it seems to work, even though the difference is not so big. I am now going to test the package on i386 and then upload if all is ok. We can then talk with upstream what is the best way to fix this in the long term. Ondrej #! /usr/bin/env python import numpy import time try: import numpy.core._dotblas print 'Using ATLAS:' except ImportError: print 'No ATLAS:' t = time.time() x = numpy.random.random((1000,1000)) y = numpy.random.random((1000,1000)) z = numpy.dot(x, y) print time.time()-t
Bug#489726: should numpy be built with atlas?
On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.0-2 Severity: serious python-numpy now has an unconditional dependency on libatlas3gf-base, needing the specialized atlas libraries as a runtime dependency. Users still should have the option to use the standard blas and lapack libs instead of the untested/unmaintained atlas libraries in debian. Hi Matthias, I changed that on a request from a user: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489253 so should we revert this change? I.e. should numpy not be built with atlas support? This will make it quite slow in Debian. CCing to debian python as well to get more opinions on this. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489726: should numpy be built with atlas?
Ondrej Certik writes: On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.0-2 Severity: serious python-numpy now has an unconditional dependency on libatlas3gf-base, needing the specialized atlas libraries as a runtime dependency. Users still should have the option to use the standard blas and lapack libs instead of the untested/unmaintained atlas libraries in debian. Hi Matthias, I changed that on a request from a user: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489253 so should we revert this change? I.e. should numpy not be built with atlas support? This will make it quite slow in Debian. CCing to debian python as well to get more opinions on this. afaiu this has nothing to do if blas/lapack or atlas are used; apparently _dotblas.so is not built when just using blas/lapack. this seems to be the real bug which we should fix. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489726: should numpy be built with atlas?
On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote: Package: python-numpy Version: 1:1.1.0-2 Severity: serious python-numpy now has an unconditional dependency on libatlas3gf-base, needing the specialized atlas libraries as a runtime dependency. Users still should have the option to use the standard blas and lapack libs instead of the untested/unmaintained atlas libraries in debian. The problem is that the new (1.0) numpy building system needs ATLAS at compile time to enable fast matrix-multiplication. If ATLAS is not found at compile time, numpy.core._dotblas.so is not built and slow matrix multiplication is used even if the end user has ATLAS installed. In the old numpy _dotblas.so was always compiled using refblas and the end user would still have had the option of using ATLAS. I'm not sure I understand why ATLAS is now needed at compile time, but look here: http://scipy.org/scipy/numpy/ticket/667 and here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784 I think python-numpy should stay as it is now and a bug-wishlist should be reported to the atlas package to encourage packaging of the new stable version (3.8.2). Filing a ticket on numpy trac may help, but the fate of ticket 667 seems to indicate that there's no will of fixing this bug upstream... thank you, tiziano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]