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. Sturla _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
