<p dir="ltr">On Apr 5, 2016 10:23 AM, "Matthew Brett" <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>> wrote:<br>
><br>
> On Mon, Mar 28, 2016 at 2:33 PM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > Olivier Grisel and I are working on building and testing manylinux<br>
> > wheels for numpy and scipy.<br>
> ><br>
> > We first thought that we should use ATLAS BLAS, but Olivier found that<br>
> > my build of these could be very slow [1].  I set up a testing grid [2]<br>
> > which found test errors for numpy and scipy using ATLAS wheels.<br>
> ><br>
> > On the other hand, the same testing grid finds no errors or failures<br>
> > [3] using latest OpenBLAS (0.2.17) and running tests for:<br>
> ><br>
> > numpy<br>
> > scipy<br>
> > scikit-learn<br>
> > numexpr<br>
> > pandas<br>
> > statsmodels<br>
> ><br>
> > This is on the travis-ci ubuntu VMs.<br>
> ><br>
> > Please do test on your own machines with something like this script [4]:<br>
> ><br>
> > source test_manylinux.sh<br>
> ><br>
> > We have worried in the past about the reliability of OpenBLAS, but I<br>
> > find these tests reassuring.<br>
> ><br>
> > Are there any other tests of OpenBLAS that we should run to assure<br>
> > ourselves that it is safe to use?<br>
><br>
> Here is an update on progress:<br>
><br>
> We've now done a lot of testing on the Linux OpenBLAS wheels.   They<br>
> pass all tests on Linux, with Intel kernels:<br>
><br>
> <a href="https://travis-ci.org/matthew-brett/manylinux-testing/builds/120825485">https://travis-ci.org/matthew-brett/manylinux-testing/builds/120825485</a><br>
> <a href="http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian/builds/22">http://nipy.bic.berkeley.edu/builders/manylinux-2.7-debian/builds/22</a><br>
> <a href="http://nipy.bic.berkeley.edu/builders/manylinux-2.7-fedora/builds/10">http://nipy.bic.berkeley.edu/builders/manylinux-2.7-fedora/builds/10</a><br>
><br>
> Xianyi, the maintainer of OpenBLAS, is very helpfully running the<br>
> OpenBLAS buildbot nightly tests with numpy and scipy:<br>
><br>
> <a href="http://build.openblas.net/builders">http://build.openblas.net/builders</a><br>
><br>
> There is still one BLAS-related failure on these tests on AMD chips:<br>
><br>
> <a href="https://github.com/xianyi/OpenBLAS-CI/issues/10">https://github.com/xianyi/OpenBLAS-CI/issues/10</a><br>
><br>
> I propose to hold off distributing the OpenBLAS wheels until the<br>
> OpenBLAS tests are clean on the OpenBLAS buildbots - any objections?</p>
<p dir="ltr">Alternatively, would it make sense to add a local patch to our openblas builds to blacklist the piledriver kernel and then distribute them now? (I'm not immediately sure what would be involved in doing this but it seems unlikely that it would require anything tricky?)</p>
<p dir="ltr">-n</p>