Re: [boost] Synchronization (RE: [compute] review)

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-31 03:15:10

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas M
Sent: Wednesday, December 31, 2014 2:14
To: boost_at_[hidden]
Subject: Re: [boost] Synchronization (RE: [compute] review)

> On 31/12/2014 02:31, Gruenke,Matt wrote:

> I don't consider the proposed ways to be mutually exclusive, or at least
> not as much as I interpret your post.

They're not, nor did I mean to imply they were.  I think they're very much complementary.  Ideally, we'd get all three.  I consider #2 the highest priority, because writing exception-safe code without it would be very difficult and cumbersome.  #3 is similarly valuable, if you're directly using the command_queue.  #1 is "only" an optimization - not a correctness/safety issue.

> With respect to the command_queue "guarantee" I keep my opinion that I
> consider it absolutely useful; I also don't see why it's more error-prone
> in general (see below).

It's error-prone, because the guarantee must have a smaller scope than all of the containers it's intended to protect.  You can't just instantiate new containers as you need them.  That type of usage error isn't possible with event guarantees.

You're correct to point out that this applies equally to wait_list guarantees.  Hence, I am withdrawing my support for them.

> With respect to performance there can be two-fold advantages of synchronizing
> at the command-queue level: firstly as already mentioned not having to pay the
> OpenCL overhead for creating and waiting on a number of individual events;

He's always creating the events.  So, the only difference is whether you wait on them.  Waiting should amount to a mutex-protected flag check (and a pthread_condition_wait(), if the event is incomplete).  Locking and releasing mutexes is cheap, unless it actually blocks.  In some tests I've run, years ago, it's on the order of a hundred cycles, on Linux, maybe less.

> and secondly for an out-of-order command queue the issuing of explicit waits
> for all events, which must occur in some order, may cause unnecessary
> rearrangement/ordering of the queue's execution order (AFAIK it's the
> implementers freedom if it gives preference to the just-issued wait or not).

So, waiting on an event is going to change their scheduling?  Call me a skeptic, but I doubt that.  If it does happen, then a better approach would be to enqueue a marker and wait on that.  Or just make an explicit call to command_queue::wait(), if you know there are no other commands in there.

In any case, the issue is probably be moot.  First, it seems like Boost.Compute won't be supporting out-of-order command queues.  Second, unless you're using async copies and avoiding algorithms that implicitly synchronize for other reasons (i.e. to return results by value), then you'll block on the results before you ever get near the end of scope (in the non-error case, that is).

I think our positions are fairly entrenched, at this point.  But don't let me stop you from trying to convince Kyle.  In the end, his is the only opinion that matters.

Matt

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.