[SciPy-user] making an existing scipy installation use atlas libraries

David Cournapeau david@ar.media.kyoto-u.ac...
Mon Oct 8 22:39:53 CDT 2007


Eike Welk wrote:
> On Monday 08 October 2007 17:00, Lev Givon wrote:
>> Received from Robert Kern on Sun, Oct 07, 2007 at 03:29:42PM EDT:
>>> Lev Givon wrote:
>>>> The scipy installation instructions for Linux relating to atlas
>>>> (http://tinyurl.com/2kuwcy) appear to imply that one can force
>>>> an existing scipy installation that was built against netlib
>>>> blas and lapack to take advantage of subsequently installed
>>>> atlas libraries by directing the library loader to point to the
>>>> atlas-provided libblas.so and liblapack.so libraries rather
>>>> than their netlib equivalents. Does this approach provide
>>>> inferior performance compared to building numpy/scipy directly
>>>> against atlas (i.e., such that the atlas objects are built into
>>>> the cblas/clapack modules)?
>>> ATLAS has a few other libraries that are needed besides its
>>> libblas.so and liblapack.so.  You would essentially have to
>>> relink the extension modules, not just change LD_LIBRARY_PATH.
Robert, you are right that atlas does need other libraries by default, 
but this does not prevent from doing what Lev Givon wants to do. You 
just have to relink the atlas libraries (actually, the debian packages 
do that to build a complete libblas.so and liblapack.so, which contains 
all necessary symbols from libatlas.so), which is easier than relinking 
numpy/scipy extensions (you only have to do it once, for example). 
Incidently, that's what I am doing in the ashigabou repository as well 
(in the atlas package).

I would also like to know if this makes any difference (using atlas as a 
pure drop-in of blas/lapack vs explicitely compiling numpy/scipy with 
atlas) performance wise (I would think not, because once distutils got 
atlas, it just set the linking options to use it as blas/lapack, but I 
may be wrong).

cheers,

David


More information about the SciPy-user mailing list