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: Asbjørn (lordcrc_at_[hidden])
Date: 2014-12-22 05:13:53

On 22.12.2014 05:32, Kyle Lutz wrote:
> Well one concern with removing the word "enqueue" from the name is
> that the function actually *does* enqueue a command in the queue. For
> instance, if you queue up a couple kernel launches (which are
> asynchronous) followed by a synchronous read (with
> enqueue_read_buffer()), the asynchronous operations in the queue will
> still be executed before the read operation (i.e. the normal FIFO
> queue behavior).

Fair enough. For me this is implied since you're operating on a command_queue, 
not say command_graph.

> That sounds very cool. I'd definitely be interested in exploring an
> API like that. I've also been keeping my eye on the papers from the
> C++ concurrency working group (for instance, N3857). It would be good
> to align work in this direction for Boost.Compute with the proposed
> standards (where feasible).

I agree w.r.t. standards. Not a lot like that in the Delphi world so I tend to 
explore on my own :)

> Interesting, could you provide a test-case to reproduce this? In my
> testing (on Intel and others) I haven't found any problems with the
> code I supplied (though I've heard there may be issues with precision
> complex operations involving transcendental functions/sqrt()/etc. on
> some implementations).

I'll have to verify, but I'm pretty sure it was my simple Legendre polynomial 
evaluation test. It simply evaluates P_10(x) for several million points x \in 
[-1, 1]. So just multiplications and additions/subtractions.

I'll rerun the tests to make sure I'm not just imagining things :)

Cheers
- Asbjørn