On 09.05.2014 12:42, David Cournapeau wrote:
>
>
>
> On Fri, May 9, 2014 at 1:51 AM, Matthew Brett <matthew.brett@gmail.com

> <mailto:matthew.brett@gmail.com>> wrote:
>
>     Hi,
>
>     On Mon, Apr 28, 2014 at 3:29 PM, David Cournapeau

>     <cournape@gmail.com <mailto:cournape@gmail.com>> wrote:
>     >
>     >
>     >
>     > On Sun, Apr 27, 2014 at 11:50 PM, Matthew Brett

>     <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>>

>     > wrote:
>     >>
>     >> Aha,
>     >>
>     >> On Sun, Apr 27, 2014 at 3:19 PM, Matthew Brett

>     <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>>

>     >> wrote:
>     >> > Hi,
>     >> >
>     >> > On Sun, Apr 27, 2014 at 3:06 PM, Carl Kleffner

>     <cmkleffner@gmail.com <mailto:cmkleffner@gmail.com>>

>     >> > wrote:
>     >> >> A possible option is to install the toolchain inside
>     site-packages and
>     >> >> to
>     >> >> deploy it as PYPI wheel or wininst packages. The PATH to the
>     toolchain
>     >> >> could
>     >> >> be extended during import of the package. But I have no idea,
>     whats the
>     >> >> best
>     >> >> strategy to additionaly install ATLAS or other third party
>     libraries.
>     >> >
>     >> > Maybe we could provide ATLAS binaries for 32 / 64 bit as part
>     of the
>     >> > devkit package.  It sounds like OpenBLAS will be much easier to
>     build,
>     >> > so we could start with ATLAS binaries as a default, expecting
>     OpenBLAS
>     >> > to be built more often with the toolchain.  I think that's how
>     numpy
>     >> > binary installers are built at the moment - using old binary
>     builds of
>     >> > ATLAS.
>     >> >
>     >> > I'm happy to provide the builds of ATLAS - e.g. here:
>     >> >
>     >> > https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds
>     >>
>     >> I just found the official numpy binary builds of ATLAS:
>     >>
>     >> https://github.com/numpy/vendor/tree/master/binaries
>     >>
>     >> But - they are from an old version of ATLAS / Lapack, and only
>     for 32-bit.
>     >>
>     >> David - what say we update these to latest ATLAS stable?
>     >
>     >
>     > Fine by me (not that you need my approval !).
>     >
>     > How easy is it to build ATLAS targetting a specific CPU these days
>     ? I think
>     > we need to at least support nosse and sse2 and above.
>
>     I'm getting crashes trying to build SSE2-only ATLAS on 32-bits, I
>     think Clint will have some time to help out next week.
>
>     I did some analysis of SSE2 prevalence here:
>
>     https://github.com/numpy/numpy/wiki/Window-versions
>
>     Firefox crash reports now have about 1 percent of machines without
>     SSE2.  I suspect that people running new installs of numpy will have
>     slightly better machines on average than Firefox users, but it's only
>     a guess.
>
>     I wonder if we could add a CPU check on numpy import to give a polite
>     'install from the exe' message for people without SSE2.
>
>
> We could, although you unfortunately can't do it easily from ctypes only
> (as you need some ASM).
>
> I can take a quick look at a simple cython extension that could be
> imported before anything else, and would raise an ImportError if the
> wrong arch is detected.
>

assuming mingw is new enough

#ifdef __SSE2___
raise_if(!__builtin_cpu_supports("sse"))
#endof

in import_array() should do it

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion