-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 28/05/2014 07:04, Andreas Kloeckner wrote:
> Hi all,
>
> [snip]
>
> 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" initially.
>
> - 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 import name.
>
> 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 package.
>
> - 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.
I do have a couple of comments/queries. Firstly, what are the
advantages to maintaining both BPL and CFFI implementations of
PyOpenCL? It is my understanding that CFFI also supports CPython and
so could a single common code base not be used to target both PyPy and
CPython?
Secondly, how does the CFFI code compare to the existing BPL code?
Specifically, is it cleaner or more maintainable? I ask this as
someone who is highly sceptical about the utility of PyPy within the
scientific community. It would therefore be sad if significant effort
were to be expended into a CFFI implementation of PyOpenCL if the
primary motivation was to gain support for an unproven implementation
of Python.
I do quite like the idea of spinning the array wrappers out into their
own package, however.
Regards, Freddie.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOHIM8ACgkQ/J9EM/uoqVdjnACeIgYtLTAjNZCbcrrhpA5C3WK7
f2QAn3oGTM04kLQzjcBFMUK2uMbU/2Qt
=nVIc
-----END PGP SIGNATURE-----
_______________________________________________
PyOpenCL mailing list
[email protected]
http://lists.tiker.net/listinfo/pyopencl
