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

David Cournapeau cournape@gmail....
Tue Dec 11 04:31:56 CST 2007


On Dec 11, 2007 3:16 PM, Fernando Perez <fperez.net@gmail.com> wrote:
>
> On Dec 10, 2007 11:04 PM, David Cournapeau <cournape@gmail.com> wrote:
> > On Dec 11, 2007 12:46 PM, Andrew Straw <strawman@astraw.com> wrote:
> > > According to the QEMU website, QEMU does not (yet) emulate SSE on x86
> > > target, so a Windows installation on a QEMU virtual machine may be a
> > > good way to build binaries free of these issues.
> > > http://fabrice.bellard.free.fr/qemu/qemu-tech.html
> > I tried this, this does not work (it actually emulates SSE). I went
> > further, and managed to disable SSE support in qemu...
> >
> > But again, what's the point:  it takes ages to compile (qemu without
> > the hardware accelerator is slow, like ten times slower), and you will
> > end up with a really bad atlas, since atlas optimizaton is entirely
> > based on runtime timers, which do not make sense anymore.
> >
> > I mean, really, what's the point of doing all this compared to using
> > blas/lapack from netlib ? In practice, is it really slower ? For what
> > ? I know I don't care so much, and I am a heavy user of numpy.
>
> For certain cases the difference can be pretty dramatic,

Is it if you use it on a CPU which is really different than the one
used for the compilation ? For example, the default atlas on debian
(built on pentium 2, no sse) is not really much faster than netlib,
IMHO.

> ship TWO
> binaries of Numpy/Scipy each time:
>

I think that in the short term, that's the only solution. The netlib
one being the default, the atlas one being the optional (with
CoreDuoSSE2 something in the name). It should work by default
everywhere.

David


More information about the Numpy-discussion mailing list