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

David Cournapeau cournape@gmail....
Tue Dec 11 18:41:14 CST 2007

On Dec 12, 2007 3:04 AM, Christopher Barker <Chris.Barker@noaa.gov> wrote:
> Fernando Perez wrote:
> > a simple, reasonable solution that is likely to work: ship TWO
> > binaries of Numpy/Scipy each time:
> >
> > 1. {numpy,scipy}-reference: built with the reference blas from netlib,
> > no atlas, period.
> >
> > 2. {}-atlas: built with whatever the developers have at the time,
> > which will likely mean these days a core 2 duo with SSE2 support.
> > What hardware it was built on should be indicated, so people can at
> > least know this fact.
> I disagree -- having an atlas version that only works on recent hardware
> is just asking for complaints -- I think the ONLY way to go is for the
> "standard" binary to be universal. Instructions should be provided for
> building other versions, and if third parties want to distribute
> processor-dependent versions, then great, but that's an extra.

But that's the problem: it is next to impossible to build ATLAS which
works on any processor ! At least, it is not supported by ATLAS
developers, and the way it suggested did not work for me.

> By the way, I've always been confused by static linking of lapack/atlas
> -- it seems to me that this kind of thing is on of the best uses of
> dynamic linking -- the main binary is processor dependent, and it is
> linked, at runtime, with the host's processor specific lib. -- could we
> do it that way:

I believe that lapack/blas are dynamically linked by default. But for
a portable solution, I don't see any other solution than  dynamic
loading. The BLAS/LAPACK library would be like a plug-in, loaded at
runtime. But this requires some work, and in perticular, doing it in a
cross platform way is not trivial

> The standard distro includes a universal dynamic lib.
> Folks build processor-specific libs that can be dropped in to replace
> the universal one if someone so desires.

Asking the users to do is  just asking for new a set of problems,
IMHO. I used this approach for the rpms on ashigabou repository (they
are compiled against netlib blas/lapack, but you can change the used
libraries using runtime library path), but that's not portable. What
is needed is a true runtime system in numpy which can detect the
processor (not too difficult, although doing it for all compilers is
not trivial either), load the right library (difficult to do in a
cross platform way), and use it accordingly (not too difficult, but
requires some work).


More information about the Numpy-discussion mailing list