<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 1:38 PM, Matthew Brett <span dir="ltr"><<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Mar 4, 2016 at 12:29 AM, David Cournapeau <<a href="mailto:cournape@gmail.com">cournape@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Mar 4, 2016 at 4:42 AM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Summary:<br>
>><br>
>> I propose that we upload Windows wheels to pypi.  The wheels are<br>
>> likely to be stable and relatively easy to maintain, but will have<br>
>> slower performance than other versions of numpy linked against faster<br>
>> BLAS / LAPACK libraries.<br>
>><br>
>> Background:<br>
>><br>
>> There's a long discussion going on at issue github #5479 [1], where<br>
>> the old problem of Windows wheels for numpy came up.<br>
>><br>
>> For those of you not following this issue, the current situation for<br>
>> community-built numpy Windows binaries is dire:<br>
>><br>
>> * We have not so far provided windows wheels on pypi, so `pip install<br>
>> numpy` on Windows will bring you a world of pain;<br>
>> * Until recently we did provide .exe "superpack" installers on<br>
>> sourceforge, but these became increasingly difficult to build and we<br>
>> gave up building them as of the latest (1.10.4) release.<br>
>><br>
>> Despite this, popularity of Windows wheels on pypi is high.   A few<br>
>> weeks ago, Donald Stufft ran a query for the binary wheels most often<br>
>> downloaded from pypi, for any platform [2] . The top five most<br>
>> downloaded were (n_downloads, name):<br>
>><br>
>> 6646,<br>
>> numpy-1.10.4-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl<br>
>> 5445, cryptography-1.2.1-cp27-none-win_amd64.whl<br>
>> 5243, matplotlib-1.4.0-cp34-none-win32.whl<br>
>> 5241, scikit_learn-0.15.1-cp34-none-win32.whl<br>
>> 4573, pandas-0.17.1-cp27-none-win_amd64.whl<br>
>><br>
>> So a) the OSX numpy wheel is very popular and b) despite the fact that<br>
>> we don't provide a numpy wheel for Windows, matplotlib, sckit_learn<br>
>> and pandas, that depend on numpy, are the 3rd, 4th and 5th most<br>
>> downloaded wheels as of a few weeks ago.<br>
>><br>
>> So, there seems to be a large appetite for numpy wheels.<br>
>><br>
>> Current proposal:<br>
>><br>
>> I have now built numpy wheels, using the ATLAS blas / lapack library -<br>
>> the build is automatic and reproducible [3].<br>
>><br>
>> I chose ATLAS to build against, rather than, say OpenBLAS, because<br>
>> we've had some significant worries in the past about the reliability<br>
>> of OpenBLAS, and I thought it better to err on the side of<br>
>> correctness.<br>
>><br>
>> However, these builds are relatively slow for matrix multiply and<br>
>> other linear algebra routines compared numpy built against OpenBLAS or<br>
>> MKL (which we cannot use because of its license) [4].   In my very<br>
>> crude array test of a dot product and matrix inversion, the ATLAS<br>
>> wheels were 2-3 times slower than MKL.  Other benchmarks on Julia<br>
>> found about the same result for ATLAS vs OpenBLAS on 32-bit bit, but a<br>
>> much bigger difference on 64-bit (for an earlier version of ATLAS than<br>
>> we are currently using) [5].<br>
>><br>
>> So, our numpy wheels likely to be stable and give correct results, but<br>
>> will be somewhat slow for linear algebra.<br>
><br>
><br>
> I would not worry too much about this: at worst, this gives us back the<br>
> situation where we were w/ so-called superpack, which have been successful<br>
> in the past to spread numpy use on windows.<br>
><br>
> My main worry is whether this locks us into ATLAS  for a long time because<br>
> of package depending on numpy blas/lapack (scipy, scikit learn). I am not<br>
> sure how much this is the case.<br>
<br>
</div></div>You mean the situation where other packages try to find the BLAS /<br>
LAPACK library and link against that?   My impression was that neither<br>
scipy or scikit-learn do that at the moment, but I'm happy to be<br>
corrected.<br>
<br>
You'd know better than me about this, but my understanding is that<br>
BLAS / LAPACK has a standard interface that should allow code to run<br>
the same way, regardless of which BLAS / LAPACK library it is linking<br>
to.  So, even if another package is trying to link against the numpy<br>
BLAS, swapping the numpy BLAS library shouldn't cause a problem<br>
(unless the package is trying to link to ATLAS-specific stuff, which<br>
seems a bit unlikely).<br>
<br>
Is that right?<br></blockquote><div><br></div><div><br></div><div>AFAIK, numpy doesn't provide access to BLAS/LAPACK. scipy does. statsmodels is linking to the installed BLAS/LAPACK in cython code through scipy. So far we haven't seen problems with different versions. I think scipy development works very well to isolate linalg library version specific parts from the user interface.</div><div><br></div><div>AFAIU, The main problem will be linking to inconsistent Fortran libraries in downstream packages that use Fortran.</div><div>Eg. AFAIU it won't work to pip install a ATLAS based numpy and then install a MKL based scipy from Gohlke.</div><div><br></div><div>I don't know if there is a useful error message, or if this just results in puzzled users.</div><div><br></div><div>Josef</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Matthew<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>