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 <[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
Sorry, I meant install-time. DS > 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
