[Numpy-discussion] Use OpenBLAS for the binary releases?
Dag Sverre Seljebotn
Tue Nov 20 13:36:18 CST 2012
On 11/20/2012 08:35 PM, Dag Sverre Seljebotn wrote:
> On 11/20/2012 06:22 PM, David Cournapeau wrote:
>> On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden <firstname.lastname@example.org> 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
Sorry, I meant install-time.
> 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 ...
> I'm asking a question about whether this would work in principle, I
> realize it would perhaps not fit that well in the current NumPy codebase.
> 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.
> Dag Sverre
More information about the NumPy-Discussion