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

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-30 05:58:10

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
Sent: Tuesday, December 30, 2014 5:01
To: boost_at_[hidden]
Subject: Re: [boost] Synchronization (RE: [compute] review)

> On December 29, 2014 6:49:35 PM EST, Kyle Lutz wrote:

>> Also, in case you were unaware, you can always disable all
>> exceptions in Boost.Compute by defining BOOST_NO_EXCEPTIONS.

> BOOST_NO_EXCEPTIONS invokes a global handler to note a failure. That means
> after every library call, the user must check a global value to determine
> if there was an error. Overloading with a Boost.System error_code localizes
> error checking. (Asio does this, for example.) I consider that a superior
> way to avoid exception overhead.

Either way, I don't see how you avoid checking whether an error occurred after each operation.  And when you do detect an error, then you can certainly skip some work, but you're still stuck waiting for the non-failed operations to complete before you can destroy any of the datastructures they're using.  And that would be much simpler with a good contingent of RAII-friendly constructs, like those we're discussing.

Therefore, I don't see the issue of exceptions vs. error codes (nor the mechanism of error code access) being relevant to the discussion of synchronization.  The synchronization support needs to be there, no matter what.  And it should be relatively unobtrusive and easy to use.

> The question is whether exception overhead is a bottleneck in coding with this
> library's API.  It is necessary to weigh the likelihood of errors against the
> costs of reporting and detecting them.  Conditional logic to check for errors
> is not pipelining friendly, but throwing exceptions is terribly expensive.

By comparison with network programming (since you cited Boost.ASIO), GPU/OpenCL errors should be far less common.  Therefore, error handling needn't be optimized for performance.  I think our only concern is successful recovery.  Indeed, as OpenCL provides no cancelation mechanism, you cannot avoid waiting around for any partial results to be computed that haven't failed.

BTW, the types of operations generating these errors typically involve communication with a device or at least a couple syscalls.  So, the kind of ALU pipeline effects of conditional statements that you mention aren't relevant, here.

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.