Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014

Subject: Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014
From: Kyle Lutz (kyle.r.lutz_at_[hidden])
Date: 2014-12-21 23:41:52

On Sun, Dec 21, 2014 at 3:01 PM, Sebastian Schaetz
<seb.schaetz_at_[hidden]> wrote:
> Asbjørn <lordcrc <at> gmail.com> writes:
>
>> In my "just for fun" Delphi.Compute library (written in Delphi, inspired by
>> Boost.Compute) I made Copy() and Transform() return futures of the output
>> buffers, as well as accept futures as parameters. Note, Delphi doesn't have
>> iterators like C++ so my routines operate directly on buffers.
>>
>> So when Transform() say got a Future<Buffer> instead of a Buffer for a
>> parameter, it would add the future's associated event to the wait list
> passed to
>> clEnqueueNDRangeKernel (technically the Buffer type has an implicit
> conversion
>> operator to an "immediate" Future<Buffer>).
>>
>> This made it pretty seamless to queue up everything and then just wait for
> the
>> final read (the default "copy device buffer to host array and return it"
> call is
>> blocking). The code looks sequential but would only block on that last read.
>
> This idea is pretty nifty and I've been pondering this exact way of
> implementing asynchrony as well in my library.
>
> Another method that I also like would be to just let the buffer store the
> futures. This is how Joel's/Numscale's NT2 works [0], he gave an awesome
> talk about it at this years Meeting C++ [1]. But this might just be a
> higher-level interface more applicable to expression trees as opposed to STL
> like functions.
>
> A third way would be to return a future<void> from all meta-functions and
> allow meta-functions to take a future<void> - this would directly map to the
> stream/command_queue but the interface is maybe not that meaningful any more.

Yeah, these are all interesting ideas. While I'm a bit hesitant to
bake this behavior into the low-level command_queue interface, I'd be
more than happy to support this type of API at a higher level.

I've also been meaning to look at Aura again more closely. Last time
was many months ago and it looks like you've done quite a lot of work
since then.

And if your either of you are interested in trying to implement any of
these ideas in Boost.Compute I'd be very happy to work together. There
is already a "<boost/compute/experimental/...>" directory which would
be a great place for developing this type of API.

-kyle