Hi Andreas,
On Sun, Apr 3, 2011 at 12:08 PM, Andreas Kloeckner
<[email protected]> wrote:
> That's a great idea. In fact, the new scan primitive in PyCUDA and
> PyOpenCL already works like that. A glue layer {pycuda,pyopencl}._cluda
> exists now in both packages to smooth over the differences. If anything
> you need isn't already covered in there, that's the place to add it.
Thanks, I was not aware of _clcuda.py existense. I had a look at it
and scan.py, and that's what I noticed:
1. These preambles in _clcuda.py are the only abstractions you have.
That is, the code basically looks like:
if CUDA:
# do everything with PyCuda functions
else:
# do everything with PyOpenCL functions
Both parts have almost the same logic, so they can be joined into one
using some abstractions over Cuda/CL kernel, Cuda/CL context and so
on. Are there any other reasons to do so except some gain in
performance (how big is it, by the way)?
2. scan.py is identical in PyCuda and PyOpenCL. Perhaps it would be
better to separate it from both and convert into a library (which will
include RNG, reduction and all sorts of platform-independent stuff)?
Best regards,
Bogdan
_______________________________________________
PyOpenCL mailing list
[email protected]
http://lists.tiker.net/listinfo/pyopencl
