Re: [boost] [compute] Some remarks

Subject: Re: [boost] [compute] Some remarks
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-01-02 11:08:56

On Friday, January 02, 2015 00:03:37 Gruenke, Matt wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas
> Heller Sent: Thursday, January 01, 2015 13:56
> To: boost_at_[hidden]
> Subject: [boost] [compute] Some remarks
> 
> > Additionally, I think that the author and other reviewers are running in
> > circles when it comes to synchronization. IMHO, the event alone is enough
> > and perfectly fine.
> 
> It's true that the library could have been designed to rely solely on
> events.  All operations could accept wait_lists and return either an event
> or a wait_list (for those algorithms with multiple outputs).
> 
> Since it wasn't done in that way (and I don't mean to imply any judgment,
> here; I recognize there are benefits to the current design), we're in a
> position of looking to plug holes in the existing design to enable full
> exception safety and reduce the set of usage errors that can occur.

Well, that's exactly what I am trying to say ... The current design of the 
library completely disregards the research that has been done to support 
asynchronous operations. We have std::future (which is almost equivalent to a 
OpenCL event), why not use the same mechanisms here? OpenCL event supports 
dataflow like statements, which can be expressed with futures just as well. 
With the when_XXX and wait_XXX functions as proposed, even wait_list becomes 
useless, you'd also gain the ability to mix and match various different 
"futures" (by different futures, I mean futures with different shared_state 
implementations). This gives you almost perfect composability and exception 
safety. This allows to construct algorithms which are tightly coupled, yet are 
able to easily overlap different phases of computation. Anything that is 
implicitly hidden behind data structures or algorithms seems like a bad idea 
to me as you might have to be overly conservative which goes against the 
"don't pay for what you don't need" principle. 

> 
> 
> 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.
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost