Closed athas closed 6 years ago
I'm not a huge fan, for two reasons:
.get()
wrapper is far from itFor automatic compatibility, it would probably be best to always convert to a ndarray
subclass with a no-op .get()
method. Or find a way to turn the C types into actual PyOpenCL arrays.
Maybe it'd be best to add a compat
module that exposes a slower PyOpenCL compatible interface, and keep the main one as fast as possible. But maybe some actual profiling is needed to determine what's actually fast and what not. Maybe a simple wrapper is negligible.
I don't need general PyOpenCL compatibility. By looking at my own Python/Futhark programs (about ten), the vast majority need only the .get()
method. Adding this would merely ease the writing of programs that work with either backend.
Alright, there is a compat module now, which I think is ugly AF, but it serves the purpose you want.
When code produced by futhark-pyopencl returns an array, it returns a PyOpenCL array. These have a
.get()
method for turning them into Numpy arrays. futhark-pycffi has the same functionality, but by calling theto_futhark()
method on the Futhark object. Would it be possible to wrap the raw cffi objects in another object that provides a.get()
method (and maybe other things in the future)?My hope is to write Python programs that automatically pick either a futhark-pyopencl or a futhark-pycffi version at runtime, based on what is available. This would allow things to Just Work for most users, and the ones who are able can get more performance by also installing and running futhark-pycffi.