[Numpy-discussion] new mingw-w64 based numpy and scipy wheel (still experimental)

[Carl Kleffner]

2015-01-27 0:16 GMT+01:00 Sturla Molden <sturla.molden at gmail.com>:

> 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.
>

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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150127/777dddc6/attachment.html>