[Numpy-discussion] Default builds of OpenBLAS development branch are now fork safe
Wed Mar 26 13:34:39 CDT 2014
On 26.03.2014 16:27, Olivier Grisel wrote:
> Hi Carl,
> I installed Python 2.7.6 64 bits on a windows server instance from
> rackspace cloud and then ran get-pip.py and then could successfully
> install the numpy and scipy wheel packages from your google drive
> folder. I tested dot products and scipy.linalg.svd and they work as
> Would it make sense to embed the blas and lapack header files as part
> of this numpy wheel and make numpy.distutils.system_info return the
> lib and include folder pointing to the embedded libopenblas.dll and
> header files so has to make third party libraries directly buildable
> against those?
as for using openblas by default in binary builds, no.
pthread openblas build is now fork safe which is great but it is still
not reliable enough for a default.
E.g. the current latest release 0.2.8 still has one crash bug on
dgemv, and wrong results zherk/zer2 and dgemv/cgemv.
git head has the former four fixed bug still has wrong results for cgemv.
The not so old 0.2.8 also fixed whole bunch more crashes and wrong
result issues (crashes on QR, uninitialized data use in dgemm, ...).
None of the fixes received unit tests, so I am somewhat pessimistic that
it will improve, especially as the maintainer is dissertating (is that
the right word?) and most of the code is assembler code only few people
can write (it is simply not required anymore, we have code generators
and intrinsics for that).
Openblas is great if you do not have the patience to build ATLAS and
only use a restricted set of functionality and platforms you can easily
Currently it is in my opinion not suitable for a general purpose library
I don't have any objections to adding get_info("openblas") if that does
not work yet. Patches welcome.
More information about the NumPy-Discussion