Boost logo

Boost :

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)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk