Hi Bogdan, On Sun, 3 Apr 2011 12:37:42 +1000, Bogdan Opanchuk <[email protected]> wrote: > 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)?
In principle, I'm open to the idea of a CUDA/CL abstraction layer. I don't think this would have a measurable performance impact, but we *should* back up that claim that if we decide to make one. What kept me from making one is that the two sets of launch logic are sufficiently non-alike (CUDA dealing with cache size bits, CL adapting to Apple specifics, CL dealing with wait_fors (it doesn't yet, but it needs to)...) that I thought the having two different invocation codes might not be such a horrible idea. Perhaps the right recipe would be to try and gradually move the two codes towards using a common set of functions, before trying to go whole-hog and unify them entirely. I also noticed that you have two sets of launch logic in PyFFT--what was your reasoning behind that? > 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)? That might not be such a bad idea. It makes us rely more heavily on Python's dependency handling, but I suppose that's ok. I've registered a PyPI project for this: http://pypi.python.org/pypi/compyte (fairly empty) git tree at: http://git.tiker.net/trees/compyte.git (I'm shooting for, e.g., 'compyte.primitives.scan'. :) I'll probably release the 2011.1 versions of PyCUDA and PyOpenCL without this, but we can look at unifying this afterwards. Andreas
pgpzEWiehVQMB.pgp
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
