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

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2014-12-31 04:47:13

On December 30, 2014 5:58:10 AM EST, "Gruenke,Matt" <mgruenke_at_[hidden]> wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob
> Stewart
> 
> > 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. 

You don't, but one is local to the last function call and the other is a global value.

> 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.

Okay

> 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.

People were looking for ways to avoid exceptions. Whether that was to support embedded environments without exception support or to avoid exception overhead, I don't know.

> The synchronization support needs to be there, no
> matter what.  And it should be relatively unobtrusive and easy to use.

Sure

> > 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.

What about embedded programming environments without exception support?

> 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.

They still apply if the error checking is done on the host side.

___
Rob

(Sent from my portable computation engine)