Re: [boost] [compute] Some remarks

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

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

futuredst::iterator it = copy_async(src, dst); it.then([](futuredst::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 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