On Sun, Mar 3, 2013 at 6:39 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:

...

Also, do you have asynchronous versions for all algorithms?

As of now only copy_async() is implemented (as it is the most important for achieving good performance by overlapping memory transfers with computation). However, I am not sure if this is the best interface to be extended to all the other algorithms.

I've been thinking about moving towards an asynchronous execution function like std::async() which would be passed the algorithm function along with its arguments. However, I've encountered problems with overloading and having to explicitly specify the argument template types. This is one point where I'd like to get some feedback/ideas from the community. I would also like to have a <algorithm>_async_after() version which would take the algorithms parameters along with a list of futures/events to wait for before beginning execution. My dilemma is that extending these different versions would increase the size of the API by a factor of three.

Any feedback/ideas/comments would be very helpful.

I'd strongly suggest not to add <foo>_async_after(). All we need is a) a function/algorithm producing a future b) composable futures (see N3428, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3428.pdf) But for this to be universally applicable we should try to find a way to converge onto ONE future type. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu