Boost.Compute provides a thin C++ wrapper around OpenCL host API at its core and builds a set of STL-like algorithms on top of that core. The user interface strongly resembles the STL and hence should be familiar to any C++ programmer.
The only minor problem I have with the design is the decision to provide another C++ wrapper for OpenCL host API instead of using the standard C++ bindings header [1] provided by the Khronos group (the body behind the OpenCL standard). This decision makes interaction with the existing OpenCL libraries (that use Khronos C++ bindings) somewhat complicated at times. I don't believe its possible to change the design at this point though, so I am prepared to live with it.
Having proposed several patches to the library, I can say that I am familiar with its implementation. The library is well structured, the code is well designed, well formatted and is easy to read and understand. The library provides a large number of examples and an extensive set of unit tests.
When the first public announcement of the library was made here on Boost mailing list, there were several performance problems. In particular the compute kernels were not cached at the first invocation, and some algorithms only provided serial implementation (some still do [2]). I know that a lot of effort has been put into the implementation since then, and the situation has much improved. The performance page [3] of the documentation shows that Boost.compute is able to outperform Nvidia's Thrust for some algorithms, but there is still some work to be done.
The documentation does a good job at providing both an overview of the library and an extensive API reference. Boost.compute uses Boostbook as the documentation generator, and has a look and feel compatible with the majority of Boost libraries.
I'd say that a library that allows to easily harvest the performance provided by the modern graphic processors and accelerators is extremely useful. For me, as an end user, the convenience could even outweigh a loss of a fraction of performance.
Since the library interface is so close to STL, it is extremely easy to try and use. I have successfully compiled the library with the recent versions of GCC and Clang. The unit tests run fine on NVIDIA, AMD, and Intel OpenCL platforms.
Among the current alternatives to the library that provide an STL-like set of containers and algorithms the Boost.Compute is the most portable, being built on top of standard OpenCL (see [4] for my take on differences between Boost.Compute and alternatives at stackoverflow.com).
One thing that could potentially make Boost.compute obsolete is the acception of n3960 [5] into standard. Kyle, what do you think about this?
I am the author of VexCL [6] library that has similar functionality to Boost.Compute, but provides higher level interface. I would say that I am well familiar with GPGPU programming, both CUDA and OpenCL. I have provided an implementation of Boost.Compute backend (algebra and operations) for Boost.Odeint library [7], and made a couple of Boost.Compute algorithms available through VexCL interface.
I think an inclusion of a GPGPU library into Boost is long overdue. In my opinion, Boost.Compute deserves to be accepted. The interface of the library is well designed, but it needs some work on the performance of the provided algorithms. Due to high reputation of Boost collection of libraries, a newly included library almost automatically becomes a de-facto standard in its field. This is why I want a GPGPU library accepted into Boost to show a state of the art performance. I beleive the work on performance may be continued after the library is accepted into Boost.
- cl.hpp -- OpenCL 1.2 C++ Bindings Header File, implementing the C++ Bindings Specification.
- boost/compute/algorithm/sort_by_key.hpp
- Boost.compute performance.
- Answer to Differences between VexCL, Thrust, and Boost.Compute.
- TS for C++ Extensions for Parallelism.
- VexCL -- a C++ vector expression template library for OpenCL/CUDA.
- Boost.compute backend for Boost.odeint.