<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 9, 2014 at 11:49 AM, Julian Taylor <span dir="ltr"><<a href="mailto:jtaylor.debian@googlemail.com" target="_blank">jtaylor.debian@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 09.05.2014 12:42, David Cournapeau wrote:<br>
><br>
><br>
><br>
> On Fri, May 9, 2014 at 1:51 AM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a><br>
</div><div class="">> <mailto:<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> On Mon, Apr 28, 2014 at 3:29 PM, David Cournapeau<br>
</div><div class="">> <<a href="mailto:cournape@gmail.com">cournape@gmail.com</a> <mailto:<a href="mailto:cournape@gmail.com">cournape@gmail.com</a>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Sun, Apr 27, 2014 at 11:50 PM, Matthew Brett<br>
</div>> <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a> <mailto:<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>>><br>
<div class="">> > wrote:<br>
> >><br>
> >> Aha,<br>
> >><br>
> >> On Sun, Apr 27, 2014 at 3:19 PM, Matthew Brett<br>
</div>> <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a> <mailto:<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>>><br>
<div class="">> >> wrote:<br>
> >> > Hi,<br>
> >> ><br>
> >> > On Sun, Apr 27, 2014 at 3:06 PM, Carl Kleffner<br>
</div>> <<a href="mailto:cmkleffner@gmail.com">cmkleffner@gmail.com</a> <mailto:<a href="mailto:cmkleffner@gmail.com">cmkleffner@gmail.com</a>>><br>
<div><div class="h5">> >> > wrote:<br>
> >> >> A possible option is to install the toolchain inside<br>
> site-packages and<br>
> >> >> to<br>
> >> >> deploy it as PYPI wheel or wininst packages. The PATH to the<br>
> toolchain<br>
> >> >> could<br>
> >> >> be extended during import of the package. But I have no idea,<br>
> whats the<br>
> >> >> best<br>
> >> >> strategy to additionaly install ATLAS or other third party<br>
> libraries.<br>
> >> ><br>
> >> > Maybe we could provide ATLAS binaries for 32 / 64 bit as part<br>
> of the<br>
> >> > devkit package. It sounds like OpenBLAS will be much easier to<br>
> build,<br>
> >> > so we could start with ATLAS binaries as a default, expecting<br>
> OpenBLAS<br>
> >> > to be built more often with the toolchain. I think that's how<br>
> numpy<br>
> >> > binary installers are built at the moment - using old binary<br>
> builds of<br>
> >> > ATLAS.<br>
> >> ><br>
> >> > I'm happy to provide the builds of ATLAS - e.g. here:<br>
> >> ><br>
> >> > <a href="https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds" target="_blank">https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds</a><br>
> >><br>
> >> I just found the official numpy binary builds of ATLAS:<br>
> >><br>
> >> <a href="https://github.com/numpy/vendor/tree/master/binaries" target="_blank">https://github.com/numpy/vendor/tree/master/binaries</a><br>
> >><br>
> >> But - they are from an old version of ATLAS / Lapack, and only<br>
> for 32-bit.<br>
> >><br>
> >> David - what say we update these to latest ATLAS stable?<br>
> ><br>
> ><br>
> > Fine by me (not that you need my approval !).<br>
> ><br>
> > How easy is it to build ATLAS targetting a specific CPU these days<br>
> ? I think<br>
> > we need to at least support nosse and sse2 and above.<br>
><br>
> I'm getting crashes trying to build SSE2-only ATLAS on 32-bits, I<br>
> think Clint will have some time to help out next week.<br>
><br>
> I did some analysis of SSE2 prevalence here:<br>
><br>
> <a href="https://github.com/numpy/numpy/wiki/Window-versions" target="_blank">https://github.com/numpy/numpy/wiki/Window-versions</a><br>
><br>
> Firefox crash reports now have about 1 percent of machines without<br>
> SSE2. I suspect that people running new installs of numpy will have<br>
> slightly better machines on average than Firefox users, but it's only<br>
> a guess.<br>
><br>
> I wonder if we could add a CPU check on numpy import to give a polite<br>
> 'install from the exe' message for people without SSE2.<br>
><br>
><br>
> We could, although you unfortunately can't do it easily from ctypes only<br>
> (as you need some ASM).<br>
><br>
> I can take a quick look at a simple cython extension that could be<br>
> imported before anything else, and would raise an ImportError if the<br>
> wrong arch is detected.<br>
><br>
<br>
</div></div>assuming mingw is new enough<br>
<br>
#ifdef __SSE2___<br>
raise_if(!__builtin_cpu_supports("sse"))<br>
#endof<br></blockquote><div><br></div><div>We need to support it for VS as well, but it looks like win32 API has a function to do it: <a href="http://msdn.microsoft.com/en-us/library/ms724482%28VS.85%29.aspx">http://msdn.microsoft.com/en-us/library/ms724482%28VS.85%29.aspx</a><br>
<br>Makes it even easier.<br><br>David <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
in import_array() should do it<br>
<div class=""><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>