[Numpy-discussion] NumPy nogil API
markflorisson88 at gmail.com
Tue Nov 1 05:48:46 EDT 2011
2011/10/31 Stéfan van der Walt <stefan at sun.ac.za>:
> On Mon, Oct 31, 2011 at 11:28 AM, Zachary Pincus
> <zachary.pincus at yale.edu> wrote:
>>> As an example, it'd be nice to have scipy.ndimage available without the GIL:
>>> Now, this *can* easily be done as the core is written in C++. I'm just
>>> pointing out that some people may wish more for calling scipy.ndimage
>>> inside their prange than for some parts of NumPy.
>> Not exactly to your larger point wrt the GIL, but I *think* some skimage (née scikits.image) folks are trying to rewrite most of ndimage's functionality in cython. I don't know what the status of this effort is though...
> We still rely on scipy.ndimage in some places, but since we don't have
> to support N-dimensional arrays, we can often do things in a slightly
> simpler and faster way. Almost all the performance code in the scikit
> is written in Cython, which makes it trivial to release the GIL on
> internal loops.
That's good to hear. However, as was the point of my inquiry, it would
be a lot nicer if it didn't release the GIL itself and require the GIL
to be called, but if it wouldn't require the GIL to be called in the
first place. Such an API (especially if written in Cython), can be
easily exposed to both C and Cython. You then want a wrapper function
that is callable from Python (i.e., requires the GIL), which decides
whether or not it should release the GIL, and which calls the nogil
In the simplest of cases, one may use a cpdef nogil function, but I
expect that often you'd have to use cdef nogil with a def wrapper. It
does mean that the nogil API part would not take any kind of objects,
but only C structures and such (which could be encapsulated by the
respective objects). Of course, it may not always be possible,
feasible or useful to have such an API, but when it comes to arrays
and images it probably will be.
> I am actively soliciting feedback from current or prospective users,
> so that we can drive the scikit in the right direction. Already, it's
> an entirely different project from what is was a couple of months ago.
> We stopped trying to duplicate the MATLAB toolbox functionality, and
> have been adding some exciting new algorithms. The number of pull
> requests have tripled since the 0.3 release, and we're aiming to have
> 0.4 done this week.
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
More information about the NumPy-Discussion