Boost logo

Boost :

Subject: Re: [boost] [compute] GPGPU Library - Request For Feedback
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2013-03-06 10:46:50


> On Sun, Mar 3, 2013 at 6:39 PM, Hartmut Kaiser <hartmut.kaiser_at_[hidden]>
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk