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.
OpenBLAS in the test wheels is build with DYNAMIC_ARCH, that is all
assembler based kernels are included and are choosen at runtime. Non
optimized parts of Lapack have been build with -march=sse2.
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 :-)
I have in mind, that binary wheels are not supported for Linux. Maybe this
could be done as conda package for Anaconda/Miniconda as an OSS alternative
to MKL.
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.
Sturla
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion