Re: [boost] [compute] Some remarks

Subject: Re: [boost] [compute] Some remarks
From: Sebastian Schaetz (seb.schaetz_at_[hidden])
Date: 2015-01-03 07:20:32

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? 

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);

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);

Is this correct? Now everything is a future, is it not? Another alternative
is to hide futures in the containers/ranges/iterators and let the do the
right thing implicitly. This is what NT2 [0] does afaik.

In my library [1] I have feed (equivalent to command_queues) and mark
(equivalent to events) types so I can write code like this: 

device d(0);  
feed f1(d);
feed f2(d);
mark m1(f1);
mark m2(f2);
wait_for(m1); // block calling thread
f1.continue_when(m2); // block feed until other feed reached mark

and I'm trying to get rid of this and use futures. But it makes no sense
without making everything a future. 

Best Regards,
Sebastian