[Numpy-discussion] Default builds of OpenBLAS development branch are now fork safe

[Julian Taylor]

On 26.03.2014 21:41, Nathaniel Smith wrote:
> On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
>> 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[1], and wrong results zherk/zer2[2] and dgemv/cgemv[3].
>> 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
>> test.
>> Currently it is in my opinion not suitable for a general purpose library
>> like numpy.
> 
> Those problems you list are pretty damning, but neither is it
> reasonable to expect everyone to manually build ATLAS on every machine
> they use (or their students use, or...) :-(. So what other options do
> we have for general purpose builds? Give up and use MKL? How's
> eigen-blas doing these days? (I guess from skimming their docs they
> use OpenMP?)
> 

I don't think general purpose builds need to have perfect performance.
we should provide something that works and allow users to tune it when
required. The slower general purpose build is also a great testcase to
verify that the tuned build works for your problem.

I didn't notice this is a reply to third party provided win64 binaries
with openblas. I though it was about official numpy binaries with
openblas again.
Third party binaries using openblas are great, especially these that
seem to warn that this is experimental.
It helps ironing out the kinks of openblas. Thanks for providing them.