[Numpy-discussion] The BLAS problem (was: Re: Wiki page for building numerical stuff on Windows)

[Nathaniel Smith]

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:
> http://article.gmane.org/gmane.comp.gnu.octave.maintainers/38746

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 [1][2][3] 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...

I think the goal is pretty clear: a modern optionally-multithreaded
BLAS under a BSD-like license with a priority on correctness,
out-of-the-box functionality (like runtime configurability and feature
detection), speed, and portability, in that order.

I unfortunately don't have the skills to actually lead such an effort
(I've never written a line of asm in my life...), but surely our
collective communities have people who do?

-n

[1] http://www.openssh.com/portable.html
[2] http://www.eglibc.org/mission (a "friendly fork" of glibc holding
stuff that Ulrich Drepper got cranky about, which eventually was
merged back)
[3] https://en.wikipedia.org/wiki/Go-oo

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org