On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor <jtaylor.deb...@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?) -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
