[Numpy-discussion] Strategy for OpenBLAS

Matthew Brett matthew.brett at gmail.com
Tue May 26 10:56:43 EDT 2015


This morning I was wondering whether we ought to plan to devote some
resources to collaborating with the OpenBLAS team.

Summary:  we should explore ways of setting up numpy as a test engine
for OpenBLAS development.


I am getting the impression that OpenBLAS is looking like the most
likely medium term solution for open-source stack builds of numpy and
scipy on Linux and Windows at least.

ATLAS has been our choice for this up until now, but it is designed
for optimizing to a particular CPU configuration, which will likely
make it slow on some or even most of the machines a general installer
gets installed on.  This is only likely to get more severe over time,
because current ATLAS development is on multi-core optimization, where
the number of cores may need to be set at compile time.

The worry about OpenBLAS has always been that it is hard to maintain,
and fixes don't always have tests.  There might be other alternatives
that are a better bet technically, but don't currently have OpenBLAS'
dynamic selection features or CPU support.

It is relatively easy to add tests using Python / numpy.  We like
tests.  Why don't we propose a collaboration with OpenBLAS where we
build and test numpy with every / most / some commits of OpenBLAS, and
try to make it easy for the OpenBLAS team to add tests.    Maybe we
can use and add to the list of machines on which OpenBLAS is tested
[1]?  We Berkeley Pythonistas can certainly add the machines at our
buildbot farm [2].  Maybe the Julia / R developers would be interested
to help too?



[1] https://github.com/xianyi/OpenBLAS/wiki/Machine-List
[2] http://nipy.bic.berkeley.edu/buildslaves

More information about the NumPy-Discussion mailing list