Subject: Re: [boost] [compute] Some remarks
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-04 05:26:15
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?
> [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