[Numpy-discussion] The BLAS problem (was: Re: Wiki page for building numerical stuff on Windows)
jtaylor.debian at googlemail.com
Fri Apr 11 14:29:46 EDT 2014
On 11.04.2014 18:03, Nathaniel Smith wrote:
> On Fri, Apr 11, 2014 at 12:21 PM, Carl Kleffner <cmkleffner at gmail.com> wrote:
>> a discussion about OpenBLAS on the octave maintainer list:
> I'm getting the impression that OpenBLAS is being both a tantalizing
> opportunity and a practical thorn-in-the-side for everyone -- Python,
> Octave, Julia, R.
> How crazy would it be to get together an organized effort to fix this
> problem -- "OpenBLAS for everyone"? E.g., by collecting patches to fix
> the bits we don't like (like unhelpful build system defaults),
> applying more systematic QA, etc. Ideally this could be done upstream,
> but if upstream is MIA or disagrees about OpenBLAS's goals, then it
> could be maintained as a kind of "OpenBLAS++" that merges regularly
> from upstream (compare to  for successful projects handled in
> this way). If hardware for testing is a problem, then I suspect
> NumFOCUS would be overjoyed to throw a few kilodollars at buying one
> instance of each widely-distributed microarchitecture released in the
> last few years as a test farm...
x86 cpus are backward compatible with almost all instructions they ever
introduced, so one machine with the latest instruction set supported is
sufficient to test almost everything.
For that the runtime kernel selection must be tuneable via the
environment so you can use kernels intended for older cpus.
The larger issue is finding a good and thorough testsuite that wasn't
written 30 years ago and thus does covers problem sizes larger than a
few megabytes. These are the problem sizes are that often crashed
openblas in the past.
Isn't there a kind of comprehensive BLAS verification testsuite which
all BLAS implementations should test against and contribute to available
E.g. like the POSIX compliance testsuite.
More information about the NumPy-Discussion