[Numpy-discussion] Changing the distributed binary for numpy 1.0.4 for windows ?

David M. Cooke cookedm@physics.mcmaster...
Mon Dec 10 15:50:10 CST 2007


On Dec 10, 2007, at 10:30 , Matthieu Brucher wrote:
> 2007/12/10, Alexander Michael <lxander.m@gmail.com>: On Dec 10, 2007  
> 6:48 AM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
> > Hi,
> >
> >     Several people reported problems with numpy 1.0.4 (See #627 and
> > #628, but also other problems mentionned on the ML, which I cannot
> > find). They were all solved, as far as I know, by a binary I  
> produced
> > (simply using mingw + netlib BLAS/LAPACK,  no ATLAS). Maybe it  
> would be
> > good to use those instead ? (I can recompile them if there is a  
> special
> > thing to do to build them)
>
> Do I understand correctly that you are suggesting removing ATLAS from
> the Windows distribution? Wouldn't this make numpy very slow? I know
> on RHEL5 I see a very large improvement between the basic BLAS/LAPACK
> and ATLAS. Perhaps we should make an alternative Windows binary
> available without ATLAS just for those having problems with ATLAS?
> That's why David proposed the netlib version of BLAS/LAPACK and not  
> the default implementation in numpy.
>
> I would agree with David ;)


Our versions of BLAS/LAPACK are f2c'd versions of the netlib 3.0 BLAS/ 
LAPACK (actually, of Debian's version of these -- they include several  
fixes that weren't upstream).

So netlib's versions aren't going to be any faster, really. And  
netlib's BLAS is slow. Now, if there is a BLAS that's easier to  
compile than ATLAS on windows, that'd be improvement.

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|cookedm@physics.mcmaster.ca



More information about the Numpy-discussion mailing list