On 26/01/15 16:30, Carl Kleffner wrote:
> Thanks for all your ideas. The next version will contain an augumented
> libopenblas.dll in both numpy and scipy. On the long term I would
> prefer an external openblas wheel package, if there is an agreement
> about this among numpy-dev.
Thanks for all your great work on this.
An OpenBLAS wheel might be a good idea. Probably we should have some
sort of instruction on the website how to install the binary wheel. And
then we could include the OpenBLAS wheel in the instruction. Or we could
have the OpenBLAS wheel as a part of the scipy stack.
But make the bloated SciPy and NumPy wheels work first, then we can
worry about a dedicated OpenBLAS wheel later :-)
> Another idea for the future is to conditionally load a debug version of
> libopenblas instead. Together with the backtrace.dll (part of
> mingwstatic, but undocumentated right now) a meaningfull stacktrace in
> case of segfaults inside the code comiled with mingwstatic will be given.
An OpenBLAS wheel could also include multiple architectures. We can
compile OpenBLAS for any kind of CPUs and and install the one that fits
best with the computer.
Also note that an OpenBLAS wheel could be useful on Linux. It is clearly
superior to the ATLAS libraries that most distros ship. If we make a
binary wheel that works for Windows, we are almost there for Linux too :-)
For Apple we don't need OpenBLAS anymore. On OSX 10.9 and 10.10
Accelerate Framework is actually faster than MKL under many
circumstances. DGEMM is about the same, but e.g. DAXPY and DDOT are
faster in Accelerate.
NumPy-Discussion mailing list