[Numpy-discussion] NumPy nogil API

mark florisson markflorisson88@gmail....
Sun Oct 30 15:48:25 CDT 2011


Hello,

First, I'd like to report a bug. It seems ndarray does not implement
tp_traverse or tp_clear, so if you have a reference cycle in an
ndarray with dtype object none of those objects will ever be
collected.

Secondly, please bear with me, I'm not a NumPy expert, but would it be
possible to have NumPy export an API that can be called without the
GIL? In the upcoming Cython release 0.16 (soon to be released) we will
have what is called typed memoryviews [1], which allow you to obtain a
typed view on any PEP 3118 buffer, and it allows you to do a lot more
things without the GIL. e.g. it allows you to pass these views around,
transpose them, slice them (in the same way as in NumPy but slightly
more restricted, it doesn't support masks and such), index them etc
without the GIL.

However, there is a lot of good functionality in NumPy that is simply
not accessible without going through a Python and GIL layer, only to
have NumPy (possibly) release the GIL.

So instead we could have an API that takes a C-level ndarray view
descriptor (shape/strides/ndim (possibly suboffsets), base type
description) that would do the actual work (and perhaps doesn't even
need to know anything about Python) and won't need the GIL (this
wouldn't work for the dtype object, of course). The Py_buffer struct
comes to mind, but format strings are hard to deal with. It would be
the caller's responsibility to do any necessary synchronization. This
API would simply be wrapped by a Python API that gets this "view" from
the PyArrayObject, and which may or may not decide to release the GIL,
and call the nogil API. This wrapping API could even be written easily
in Cython.
As for exceptions and error handling, there are many ways we can think
of doing this without requiring the GIL.

One of the reasons that I think this is important is that when you're
using cython.parallel [2] you don't want to hold the gil, but you do
want your NumPy goodies. Cython re-implements a very small subset of
NumPy to get you the core functionality, but to get back to NumPy
world you have to acquire the GIL, convert your memoryview slice to an
ndarray (using the buffer interface through numpy.asarray()) and then
have NumPy operate on that. It's a pain to write and it's terrible for
performance. Even if you forget the GIL part, there's still the
(expensive and explicit) conversion.

In general I think there might be many advantages to such
functionality other than for Cython. There shouldn't really be a
reason to tie NumPy only to the CPython platform.

Anyway, what do you guys think, does this make any sense?

Mark

[1]: https://sage.math.washington.edu:8091/hudson/job/cython-docs/doclinks/1/src/userguide/memoryviews.html
[2]: http://docs.cython.org/src/userguide/parallelism.html


More information about the NumPy-Discussion mailing list