[Numpy-discussion] Windows, blas, atlas and dlls

Dag Sverre Seljebotn d.s.seljebotn@astro.uio...
Mon Feb 18 12:41:58 CST 2013

On 02/18/2013 06:48 PM, Pauli Virtanen wrote:
> 18.02.2013 19:20, Dag Sverre Seljebotn kirjoitti:
>> On 02/18/2013 05:29 PM, rif wrote:
>>> But I'd hope that the overhead for going through the wrappers is
>>> constant, rather than dependent on the size, so that for large matrices
>>> you'd get essentially equivalent performance?
>> That is correct.
>> Ah, so then the quality of the BLAS matters much less in this situation.
>> But if you have a code that is used with either many small or fewer
>> large matrices, then a compiled loop over a good BLAS is a good
>> compromise without splitting up the code paths.
> I'm open to suggestions on providing low-level Cython interface to BLAS
> and LAPACK in scipy.linalg. I think this is possible with Cython --- we
> already have scipy.interpolate talking to scipy.spatial, so why not also
> 3rd party modules.
> Pull requests are accepted --- there are several interesting Cython
> BLAS/LAPACK projects though.

I think there should be a new project, pylapack or similar, for this, 
outside of NumPy and SciPy. NumPy and SciPy could try to import it, and 
if found, fetch a function pointer table. (If not found, just stay with 
what has been working for a decade.)

The main motivation would be to decouple building NumPy from linking 
with BLAS and have that all happen at run-time. But a Cython interface 
would follow naturally too.

I've wanted to start on this for some time but the Hashdist visions got 
bigger and my PhD more difficult...

As for the interesting Cython BLAS/LAPACK projects, the ones I've seen 
(Tokyo, my own work on SciPy for .NET) isn't templated enough for my 
taste. I'd start with writing a YAML file describing BLAS/LAPACK, then 
generate the Cython code and wrappers from that, since the APIs are so 

Dag Sverre

More information about the NumPy-Discussion mailing list