[PyOpenCL] is_blocking default (was: Re: Problem with transfer with cast to float32 using ATI Stream SDK)
lists at informa.tiker.net
Sat Dec 25 18:45:37 PST 2010
Hi Jan, all,
I've changed the default for all is_blocking= keyword arguments from
False to True. This was suggested by Jan (see below). It turns out that
defaulting to a asynchronous transfer is not what most people (including
myself!) expect, and it can lead to crashes/odd results that are hard to
debug. I've therefore made this change in current git, and I'll stick
this into a release soon, likely in January. As Jan points out, this
doesn't technically break code, it may just lead to performance
decreases that are easy to fix in a backward-compatible way, which seems
If your code relies on the non-blocking default, check it to avoid the
slow-down caused by the changed default.
Also, if you strongly disagree with this change, speak up now.
On Wed, 15 Dec 2010 11:58:35 +0100, "Jan H. Meinke" <j.meinke at fz-juelich.de> wrote:
> Thanks for your answer.
> On 11/23/10 01:22, Andreas Kloeckner wrote:
> > I'm wondering whether we should default cl.enqueue_write_buffer's
> > is_blocking to True, which would eliminate this whole class of
> > problems. FWIW, I've been bitten by this same issue. Opinions? Ideas on
> > how to do this without breaking API? (Rename e_w_b?)
> I think the most elegant way would be to make cl.enqueue_write_buffer
> increase the reference count to the buffer used until the transfer has
> been completed. I assume, however, the transfer is handled by the OpenCL
> runtime and not PyOpenCL making this difficult if not impossible without
> a fairly large overhead.
Agreed, on both counts. However, in addition to not freeing the buffer,
the user also has to make sure it's not overwritten before the transfer
completes. So, short of copying, we can't take all responsibility for
correct asynch code away from the user.
> While defaulting is_blocking to True is a change in the API, it should
> work for most people. It might impact performance since the transfers
> aren't done in the background, but I don't see how it would break code.
> I think it would be a good idea.
Again, agreed. I've made this change, see above.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the PyOpenCL