[Numpy-discussion] Use OpenBLAS for the binary releases?

David Cournapeau cournape at gmail.com
Tue Nov 20 19:43:02 EST 2012

On Tue, Nov 20, 2012 at 7:35 PM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> On 11/20/2012 06:22 PM, David Cournapeau wrote:
>> On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden <sturla at molden.no> wrote:
>>> On 20.11.2012 15:38, David Cournapeau wrote:
>>>> I support this as well in principle for our binary release: one issue
>>>> is that we don't have the infrastructure on mac to build an installer
>>>> with multi-arch support, and we can't assume every mac out there has
>>>> SSE 3 or 4 available.
>>> Perhaps we could check the CPU architecture at run-time, and then load
>>> (or install) the correct extension module? OpenBLAS does have functions
>>> for testing if SSE 3 or 4 are available, which we could adapt:
>> Doing at runtime would be really hard. On windows, our installer does
>> it at install time, and openblas should be pretty much the same than
>> atlas there.
> Is there a specific reason it *has* to happen at compile-time? I'd think
> one could do something like just shipping a lot of separate Python
> extensions which are really just the same module linked with different
> versions of the library, and then
> if cpu_is_nehalem:
>      import blas_nehalem as blas
> elif ...

For this to work, we would need to to compile not just the library
itself for each arch, but also every extension that link to it (e.g.
for blas, every extension linking to blas would need to be linked
against each arch library). That would be a nightmare to manage.

> One thing is one would want to propagate the BLAS/LAPACK to other
> extensions through a function pointer table much like the current NumPy
> C API.

That would be the better solution, but doing this in such a way that
would work on every platform is a significant effort.


More information about the NumPy-Discussion mailing list