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 :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk