I prefer top-posting, let me know if it's a no-no.
It seems the way to proceed would be by creating another parallel
low-level interface to the system calls via cffi without pyboost, and
then slowly replace the existing low-level interfaces with the new ones
until we can eventually remove the old ones. Hopefully that will not
cause too many memory leaks in the transition.
How is the coverage of the test suite, can we be reasonably confident
that if tests pass and the benchmark does not suffer, the package still
On 05/19/2013 02:54 AM, Andreas Kloeckner wrote:
Matti Picus <matti(a)picus.org.il> writes:
> I am interested in getting PyOpenCL to work with PyPy, an
> implementation of cpython with a JITwww.pypy.org
. Has there been any
> discussion or thought about doing this? PyPy has a basic
> implementation of numpy called numpypy that I contribute to, and it
> has a rudimentary numpy-compatible c interface available as an
> external module at
> The PyPy team has a cpython-compatible replacement for ctypes called
> cffi, that is jit-friendly on PyPy and no slower than ctypes on
> So it seems like all the pieces exist to start, is anyone else interested in
> getting the work done?
I've been thinking about replacing the Boost.Python bits in PyOpenCL
with cffi, and I'd be interested in figuring out how feasible all this
is. It certainly looks doable from my point of view. My main objective
in getting PyPy to work with PyOpenCL is making kernel invocation even
cheaper than it currently is, or rather, be able to afford more
kernel-invocation-time niceties than we currently can.
I'd obviously like to preserve PyOpenCL's documented interface.