[Numpy-discussion] Changing the distributed binary for numpy 1.0.4 for windows ?
Mon Dec 10 20:59:43 CST 2007
An idea that occurred to me after reading Fernando's email. A function
could be called at numpy import time that specifically checks for the
instruction set on the CPU running and makes sure that is completely
covers the instruction set available through all the various calls,
including to BLAS. If this kind of thing were added, numpy could fail
with a loud warning rather than dying with mysterious errors later on.
The trouble would seem that you can switch your BLAS shared library
without re-compiling numpy, so numpy would have to do a run-time query
of ATLAS, etc. for compilation issues. Which is likely
library-dependent, and furthermore, not having looked into BLAS
implementations, I'm not sure that (m)any of them provide such
information. Do they? Is this idea technically possible?
Fernando Perez wrote:
> On Dec 10, 2007 4:41 PM, Robert Kern <email@example.com> wrote:
>> The current situation is untenable. I will gladly accept a slow BLAS for an
>> official binary that won't segfault anywhere. We can look for a faster BLAS later.
> Just to add a note to this: John Hunter and I just finished teaching a
> python workshop here in Boulder, and one attendee had a recurring
> all-out crash on WinXP. Eventually John was able to track it to a bad
> BLAS call, but the death was an 'illegal instruction'. We then noticed
> that this was on an older Pentium III laptop, and I'd be willing to
> bet that the problem is an ATLAS compiled with SSE2 support. The PIII
> chip only has plain SSE, not SSE2, and that's the kind of crash I've
> seen when accidentally running code compiled in my office machine (a
> P4) on my laptop (a similarly old PIII).
> It may very well be that it's OK to ship binaries with ATLAS, but just
> to build them without any fancy instruction support (no SSE, SSE2 or
> anything else of that kind, just plain x87 code).
> Numpy-discussion mailing list
More information about the Numpy-discussion