2011/10/31 Stéfan van der Walt <ste...@sun.ac.za>: > On Mon, Oct 31, 2011 at 11:28 AM, Zachary Pincus > <zachary.pin...@yale.edu> wrote: >>> As an example, it'd be nice to have scipy.ndimage available without the GIL: >>> http://docs.scipy.org/doc/scipy/reference/ndimage.html >>> >>> 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 equivalent. 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. > > Regards > Stéfan > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
