Re: [boost] [compute] Some remarks

Subject: Re: [boost] [compute] Some remarks
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-01-04 05:55:33

On Sunday, January 04, 2015 11:26:15 Vicente J. Botet Escriba wrote:
> Le 03/01/15 14:15, Hartmut Kaiser a écrit :
> >> Thomas Heller <thom.heller <at> gmail.com> writes:
> >>> 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?
> > 
> > First of all, I fully support Thomas here. Futures (and the extensions
> > proposed in the 'Concurrency TS') are a wonderful concept allowing
> > asynchronous computation. Those go beyond 'classical' futures, which just
> > represent a result which has not computed yet. These futures allow for
> > continuation style coding as you can attach continuations and compose new
> > futures based on logical operations on others.
> 
> +1
> 
> >> This is something Joel tries to convince me of but I'm resisting. Could
> >> you
> >> shed some light on how events are almost equivalent to futures? Futures
> >> store the result of the asynchronous computation. Events are markers that
> >> can be queried to find out an operation finished and can be blocked on
> >> until
> >> an operation is finished. The data however is stored somewhere else.
> >> Futures
> >> are in this sense safer abstractions as they prevent users from accessing
> >> results that are not yet finished. That is my understanding of futures, I
> >> might be wrong here, please correct me if I am.
> >> 
> >> So I consider futures and events orthogonal concepts. One can be, with
> >> some
> >> effort and loss of expressiveness, changed to the other concept and vice
> >> versa. But I'm not sure if the code makes sense after the change.
> >> Consider
> >> these examples:
> >> 
> >> future<void> f = copy_async(src, dst);
> >> fill_async(dst, 42.);
> >> 
> >> This does not work, a dependency or dataflow graph has to be created
> >> between
> >> copy and fill, so:
> >> 
> >> future<void> f = copy_async(src, dst);
> >> fill_async(dst, 42., f);
> > 
> > What about:
> >      future<void> f = copy_async(src, dst);
> >      f.then([](future<void>&& f) { fill_async(dst, 42.); })
> > 
> > or (assuming await will be available, which almost all of the committee
> > 
> > thinks is something we need):
> >      await copy_async(src, dst);
> >      fill_async(dst, 42.);
> > 
> > i.e. the code looks 'normal' but is fully asynchronous thanks to await and
> > futures.
> > 
> >> But that is not a future, that is an event. How to write this with
> >> futures?
> >> 
> >> I think it should be this but I might be wrong:
> >> 
> >> future<dst::iterator> f = copy_async(src, dst);
> >> fill_async(f, 42);
> > 
> > You're right that an event is separating the fact that data is available
> > from the data itself. Well, the opencl guys decided that this is the right
> > way of doing things. I really hope that we know better. Just because the
> > underlying opencl API exposes the trigger and the data separately does not
> > imply that we have to do the same thing in the API exposed from our
> > libraries. At the same time and as you already mentioned, future<void> is
> > perfectly well usable for representing even this use case.
> 
> As std::copy returns the OutputIterator copy_async should return a
> future<OutputIterator>. But this iterator is not dst.
> 
>      future<dst::iterator> it = copy_async(src, dst);
>      it.then([](future<dst::iterator>&&) { fill_async(dst, 42.); })
> 
> An alternative could be a duplicate_async algorithm that returns a
> future for a copy of the elements in a new constructed Container.
> 
>      future<Container> dst = duplicate_async<Container>(src);
>      dataflow(fill_async, dst, 42);
> 
> With await this would become
> 
>      auto dstf = await duplicate_async<Container>(src);
>      dataflow(fill_async, dstf, 42);
> 
> 
> Would it be possible to implement this duplicate_async with OpentCL?
> Would this interface be much more inefficient?
> 
> If this seems too expensive, another alternative could be add also the
> dst parameter to the duplicate-async function.
> 
>      future<Container&> dstf = duplicate_async(src, dst);
>      dataflow(fill_async, dstf, 42);
> 
> BTW Hartmut, do you plan to propose to the standard the dataflow function?

We thought about it, and it would absolutely make sense to make std::async 
complete. The implementation of dataflow is almost exactly the one out of the 
await proposal. That being said, it's a poor man's await and await is way more 
elegant and to be preferred.

> 
> > [1] https://github.com/STEllAR-GROUP/hpx
> > [2] https://www.youtube.com/watch?v=4OCUEgSNIAY
> 
> Thanks for the link to the presentation.
> 
> Happy new year to all of you,
> Vicente
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost