Freddie Witherden <freddie(a)witherden.org> writes:
On 04/09/13 21:39, Andreas Kloeckner wrote:
> There currently isn't any functionality in PyOpenCL that would allow
> that. It's pretty easy to add, but I'm wondering if having this is
> actually a good idea. Specifically, if you 'reach into' MyBuf's private
> buffer and mix up the bits in there by running a kernel on the data, I
> feel like you might as well make that explicit by having 'mybuf.buffer'
> (or some such) attribute access in the kernel invocation line, rather
> than the--only seemingly!--higher level 'mybuf'. This seems to fall
> under 'explicit is better than implicit' in the zen of Python. :)
> Maybe your situation is not covered by what I've said though--if you
> truly need this and have no way around it, or if you think I'm wrong,
> please yell at me.
One problem with explicitly fetching the attribute is that it breaks
'banking'. With the implied technique outlined above one can define:
def __init__(self, bufs):
self._bufs = bufs
self._curix = 0
# Check types/dims of bufs match...
def __getattr(self, attr):
return getattr(self._bufs[self._curix], attr)
def active(self, ix):
self._currix = ix
and use this as if it were a MyBuf without worry. However, in the
explicit methodology there is always the risk someone will write:
def bind_kernel(..., mbb, ...)
b = mbb._buf
# Get prg
return lambda: prg.mykernel(..., b, ...)
which breaks horrifically if mbb is a MyBufBank (as the lambda function
is bound to b which resolves to whatever the active bank was when the
assignment was executed).
I guess I view it as less of an implicit/explicit thing and instead as a
data encapsulation thing. All that matters to me is that an object can
yield a buffer when requested rather than how it does so internally.
After thinking about this for a bit, I've decided that I'd prefer not to
do this. Especially with the cffi port currently in progress, this would
stand a chance of adding complication for fairly limited benefit.
Sorry--hope you understand,