On 11/20/2012 06:22 PM, David Cournapeau wrote:
> On Tue, Nov 20, 2012 at 5:03 PM, Sturla Molden <[email protected]> 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 ...
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
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
