[Numpy-discussion] MKL and OpenBLAS

Sturla Molden sturla.molden at gmail.com
Fri Jan 31 00:44:01 EST 2014

By the way, it seems OpenBLAS builds with clang on MacOSX, so presumably 
it works on Windows as well. Unlike GNU toolchains, there is a cl-clang 
frontend which is supposed to be MSVC compatible. BTW, clang is a 
fantastic compiler, but little known among Windows users where MSVC and 
MinGW dominate.


On 30/01/14 13:29, Carl Kleffner wrote:
> I fully agree with you. But you have to consider the following:
> - the officially mingw-w64 toolchains are build almost the same way. The
> only difference is, that they have non-static builds (that would be
> preferable for C++ development BTW)
> - you won't get the necessary addons like spec-files, manifest resource
> files for msvcr90,100 from there.
> - there is a urgent need for a free and portable C,C++, Fortran compiler
> for Windows with full blas, lapack support. You won't get that with
> numpy-MKL, but with a GNU toolchain and OpenBLAS. Not everyone can buy
> the Intel Fortran compiler or is allowed to install it.
> - you can build 3rd party extensions which use blas,lapack directly or
> with cython with such a toolchain regardless if you use numpy/scipy-MKL
> or mingw-based numpy/scipy
> - The licence question of numpy-MKL is unclear. I know that MKL is
> linked in statically. But can I redistribite it myself or use it in
> commercial context without buying a Intel licence?
> Carl
> 2014-01-30 Sturla Molden <sturla.molden at gmail.com
> <mailto:sturla.molden at gmail.com>>:
>     On 30/01/14 12:01, Carl Kleffner wrote:
>      > My conclusion is: mixing different compiler architectures for
>     building
>      > Python extensions on Windows is possible but makes it necessary
>     to build
>      > a 'vendor' gcc toolchain.
>     Right.
>     This makes a nice twist on the infamous XML and Regex story:
>     - There once was a man who had a problem building NumPy. Then he
>     thought, "I'll just use a custom compiler toolchain." Now he had two
>     problems.
>     Setting up a custom GNU toolchain for NumPy on Windows would not be
>     robust enough. And when there be bugs, we have two places to look for
>     them instead of one.
>     By using a tested and verified compiler toolchain, there is one place
>     less things can go wrong. I would rather consider distributing NumPy
>     binaries linked with MKL, if Intel's license allows it.
>     Sturla
>     _______________________________________________
>     NumPy-Discussion mailing list
>     NumPy-Discussion at scipy.org <mailto:NumPy-Discussion at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list