thanks to the tireless efforts of Marko Bencun and Yichao Yu, PyOpenCL
now has a reasonably functional branch  based on cffi instead of Boost.Python.
What this means is that there's real hope that at some point in the
not-too-distant future there will be a fully functional PyOpenCL that
runs on PyPy, which I personally find very exciting. This would amount
to a frighteningly nice environment within which to do high-performance
Now, we're not quite there yet. Let me quickly summarize the state of
- I can go grab PyPy 2.3 with apt-get (Debian has it, for example), make
a virtualenv, install numpy following the instructions , install
PyOpenCL as usual, run the tests, and passes 85% of them. (79/93 on my
I'll admit that I had never really played much with PyPy. The extent
to which all of this 'just works' with it is really impressive.
- That said, important bits are still missing. It's not ready for
production use. If you'd like to help out, see this file .
We're tantalizingly close.
This has important implications for the future of PyOpenCL. Here's where
I imagine we might be headed:
- For a while, there will be two equivalent implementations of PyOpenCL,
pyopencl_bpl and pyopencl_cffi. Eventually, pyopencl_bpl may be
deprecated. Both will install as "pyopencl". The "pyopencl" package
index entry will be an alias of one of the two--likely "pyopencl_bpl"
- PyOpenCL's array and algorithms functionality will be spun off into
separate packages ("clarray" and "clalgorithms"?). To ease the
transition, both pyopencl versions will depend on these packages, but
using them through their old names ("pyopencl.array" etc) will be
deprecated. Naturally, this will come with a long transition period to
give dependencies time to adapt. Interfaces will stay the same, so
that all that's needed in downstream software is a change of the
This step not just eases maintenance of both base wrappers, it is also
fairer to alternative CL algorithms packages like Bogdan's reikna and
potential alternative array libraries, which now don't have to face
the question of why they're replacing something that already comes
bundled with the wrapper. In addition, I've found that much of the
algorithms functionality often gets overlooked, because the name
'PyOpenCL' doesn't indicate that there's quite a bit more in the
- To make all of this easier, I will make one more release (2014.1) that
supports Python 2.4 and later, and for all releases after that, Python
2.6 will be required.