Looks interesting. One question: what support does the library provide to

orchestrate parallelism, i.e. doing useful work while the GPGPU is executing a kernel? Do you have something like:

int main() { // create data array on host int host_data[] = { 1, 3, 5, 7, 9 };

// create vector on device boost::compute::vector<int> device_vector(5);

// copy from host to device future<void> f = boost::compute::copy_async(host_data, host_data + 5, device_vector.begin());

// do other stuff

f.get(); // wait for transfer to be done

return 0; }

?

All libraries I have seen so far assume that the CPU has to idle while waiting for the GPU, is yours different?

Yes. The library allows for asynchronous computation and the API is almost exactly the same as your proposed example. See this example: http://kylelutz.github.com/compute/boost_compute/advanced_topics.html#boost_... Cheers, Kyle

...

Looks interesting. One question: what support does the library provide to

orchestrate parallelism, i.e. doing useful work while the GPGPU is executing a kernel? Do you have something like:

int main() { // create data array on host int host_data[] = { 1, 3, 5, 7, 9 };

// create vector on device boost::compute::vector<int> device_vector(5);

// copy from host to device future<void> f = boost::compute::copy_async(host_data, host_data + 5, device_vector.begin());

// do other stuff

f.get(); // wait for transfer to be done

return 0; }

?

All libraries I have seen so far assume that the CPU has to idle while waiting for the GPU, is yours different?

Yes. The library allows for asynchronous computation and the API is almost exactly the same as your proposed example.

See this example: http://kylelutz.github.com/compute/boost_compute/advanced_topics.html#boos t_compute.advanced_topics.asynchronous_operations

That's excellent (sorry I have not seen this in the docs before). However I think it's not a good idea to create your own futures. This does not scale well nor does it compose with std::future or boost::future. Is there a way to use whatever futures (or more specifically, threading implementation) the user decides to use? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

...

...

Looks interesting. One question: what support does the library provide to

orchestrate parallelism, i.e. doing useful work while the GPGPU is executing a kernel? Do you have something like:

int main() { // create data array on host int host_data[] = { 1, 3, 5, 7, 9 };

// create vector on device boost::compute::vector<int> device_vector(5);

// copy from host to device future<void> f = boost::compute::copy_async(host_data, host_data + 5, device_vector.begin());

// do other stuff

f.get(); // wait for transfer to be done

return 0; }

?

All libraries I have seen so far assume that the CPU has to idle while waiting for the GPU, is yours different?

Yes. The library allows for asynchronous computation and the API is almost exactly the same as your proposed example.

See this example: http://kylelutz.github.com/compute/boost_compute/advanced_topics.html# boos t_compute.advanced_topics.asynchronous_operations

That's excellent (sorry I have not seen this in the docs before). However I think it's not a good idea to create your own futures. This does not scale well nor does it compose with std::future or boost::future. Is there a way to use whatever futures (or more specifically, threading implementation) the user decides to use?

Also, do you have asynchronous versions for all algorithms? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

On Sun, Mar 3, 2013 at 6:15 AM, Gabriel Redner <gredner@gmail.com> wrote:

Hi Kyle,

This looks like a very interesting library! When I have a bit of time I may see see if some of my simulation codes are good candidates to make use of your API.

Thanks! Please let me know if you encounter any problems.

For the moment, just a few points from reading the docs:

- Under "Lambda Expressions", I am pretty sure that "+ 4" is not the right way to "subtract four" :-)

Fixed. Thanks for pointing this out!

- Like Karsten I am interested in zip iterators - my simulation code uses such structures heavily.

Zip iterators are a feature I have planned but haven't had time to implement yet. Stay tuned!

- What is the command_queue argument that appears in all of the algorithms? For instance here: http://kylelutz.github.com/compute/boost/compute/copy.html the signature for 'copy' takes four arguments - three iterators and a command_queue - but the example only passes the iterators, and there is no other mention of command_queues.

Command queues specify the context and device for the algorithm's execution. For all of the standard algorithms the command_queue parameter is optional. If not provided, a default command_queue will be created for the default GPU device and the algorithm will be executed there.

- Under "Vector Data Types", why floats but not doubles? Is this an OpenCL restriction? (sorry for the ignorance - my GPGPU knowledge is mostly on the CUDA side). Also, what header are they declared in?

Doubles are supported by both my library and by OpenCL. However, doubles are not supported by all compute devices. Trying to use doubles on a device that doesn't support them will cause a runtime_exception to be thrown. The list under "Vector Data Types" just gives a few examples. All of the scalar and vector data types are declared in the "boost/compute/types.hpp" header. Thanks for the feedback! Cheers, Kyle

On Sun, Mar 3, 2013 at 9:15 PM, Ioannis Papadopoulos <ipapadop@cse.tamu.edu> wrote:

How does it compare to VexCL (https://github.com/ddemidov/vexcl), Bolt (http://developer.amd.com/tools/heterogeneous-computing/amd-accelerated-paral...) and Thrust (https://developer.nvidia.com/thrust)?

VexCL is an expression-template based linear-algebra library for OpenCL. The aims and scope are a bit different from the Boost Compute library. VexCL is closer in nature to the Eigen library while Boost.Compute is closer to the C++ standard library. I don't feel that Boost.Compute really fills the same role as VexCL and in fact VexCL could be built on top of Boost.Compute. Bolt is an AMD specific C++ wrapper around the OpenCL API which extends the C99-based OpenCL language to support C++ features (most notably templates). It is similar to NVIDIA's Thrust library and shares the same failure, lack of portability. Thrust implements a C++ STL-like API for GPUs and CPUs. It is built with multiple backends. NVIDIA GPUs use the CUDA backend and multi-core CPUs can use the Intel TBB or OpenMP backends. However, thrust will not work with AMD graphics cards or other lesser-known accelerators. I feel Boost.Compute is superior in that it uses the vendor-neutral OpenCL library to achieve portability across all types of compute devices.

A comparison would be nice. Moreover, why not piggy-back on the libraries that are already available (and they probably have better optimizations in place) and simply write a nice wrapper around them (and maybe, crazy idea, allow a single codebase to use both AMD and nVidia GPUs at the same time)?

Boost.Compute does allow you to use both AMD and nVidia GPUs at the same time with the same codebase. In fact you can also throw in your multi-core CPU, Xeon Phi accelerator card and even a Playstation 3. Not such a crazy idea after all ;-). -kyle