Boost.Compute, an STL-shaped layer over the OpenCL API

A core wrapper and an STL layer above it

The library is described in two layers, and the split explains how it feels to use. The core is a thin C++ wrapper over the OpenCL API, providing access to compute devices, contexts, command queues and memory buffers. On top of that sits a generic, STL-like interface supplying common algorithms such as transform(), accumulate() and sort(), along with common containers such as vector<T> and flat_set<T>. Above that is a set of extensions for parallel computing algorithms, with exclusive_scan(), scatter() and reduce() named in the README, and a collection of fancy iterators including transform_iterator<>, permutation_iterator<> and zip_iterator<>. The intended user is a C++ developer with an OpenCL capable device who wants the GPU to be a place you call a function on a range, not a second codebase in a kernel language.

Every copy between host and device is in your source

The example the README gives is a sort of a million floats, and it is worth reading as a data flow diagram rather than as code. You take the default compute device, create a context and a command queue on it, generate random numbers into a host vector, create a device vector of the same size, copy the host range into the device range, sort the device range, and copy it back. There is no automatic staging and no implicit buffer, which means the data movement cost is visible in the program and can be planned. It also means the shape of a GPU program here is fixed: host side setup, explicit copies, one or more device operations, explicit copy back. The library gives you the containers and the algorithms, but the pipeline is yours to write, and a program that does many small operations will pay for a transfer per stage unless you restructure it.

Header-only, so the compile line is the whole install

Boost.Compute is a header-only library, so no linking against it is required. The README gives the compile command for the sort example, and the include path is the only Boost.Compute specific part of it.

g++ -I/path/to/compute/include sort.cpp -lOpenCL

The OpenCL flag is the one that matters for a reader who has never used this library. The library itself is headers, but the code it generates calls into an OpenCL implementation, so a runtime has to be present and linkable on the machine. There is no configure step, no package manager entry and no build to run before compiling your program. If you already have an OpenCL toolchain, adding Boost.Compute to a project is a matter of an include directory, which is why this library is still pleasant to use in a large C++ build where adding a compiled dependency would be friction.

Two build systems, because it is a Boost library

The repository layout shows a library that has to satisfy two audiences. There is a build.jam file, the Boost.Build description that lets the library be consumed as part of a Boost release with the usual headers, tests and documentation conventions, and a CMakeLists.txt with a cmake/ directory and a separate CMakeLists.txt inside example/. The include/ directory holds the public headers, meta/ holds the Boost package metadata, doc/ the documentation, test/ the test suite, and perf/ a separate performance directory. This is a repository shaped by the Boost conventions rather than by a modern application layout, and it has an observable consequence: examples live in their own directory with their own build description, so building the examples and building the library are separate acts. The perf/ directory also signals that this project has an explicit interest in measurement, not just correctness, which matches the topic list.

Twenty-six examples carry the documentation weight

The example directory is long, and the names describe the range of what the library is for. There is the canonical hello_world.cpp and the opencl_test.cpp and list_devices.cpp that tell you what the machine can do, plus memory_limits.cpp for the awkward questions. There are algorithm examples such as k_means.cpp, black_scholes.cpp, monte_carlo.cpp and nbody.cpp, and graphics-adjacent ones such as mandelbrot.cpp and matrix_transpose.cpp. Some examples are about the plumbing rather than the maths, with copy_data.cpp, host_sort.cpp and mapped_view.cpp showing the three ways of handling data. Vendor-specific capability is visible too, with amd_cpp_kernel.cpp and inline_ptx.cpp. The OpenCV and OpenGL examples, opencv_convolution.cpp, opencv_flip.cpp, opencv_histogram.cpp, opencv_optical_flow.cpp, opencv_sobel_filter.cpp and opengl_sphere.cpp, show integration points rather than pure computation. The README points to a tutorial page and to this directory for more, which tells you where to look when a documented API name is not enough.

A maintenance profile you can read off the badges

The badges tell an unusual story. The build status comes from Travis CI and the coverage status from Coveralls, both linked from a project hosted on GitHub, and the Windows build status comes from AppVeyor. There is no GitHub Actions workflow in the repository, and the repository has no GitHub releases, so there is no tagged version stream to point a dependency at. The project is not archived and the last push was on 2026-08-12, so the code is still moving. The most telling line is the Help Wanted section, which says the project is looking for additional developers with interest in parallel computing and asks people to email the maintainer for more information. That is an honest signal about a mature but thinly staffed library, and it belongs in any evaluation of a dependency. The licence situation is stated in the repository metadata as BSL-1.0, the Boost Software Licence 1.0, and the tree carries a LICENSE_1_0.txt file, so the terms are the permissive Boost Software Licence 1.0.

When a hand written kernel is the better tool

There are two clear boundaries. The first is the OpenCL dependency itself. Boost.Compute is a way to write OpenCL from C++, so a project that has to target a non OpenCL backend gets nothing from it, and a project with a working OpenCL implementation but unusual device features may find that the generic algorithms do not use them, which is where inline_ptx.cpp and amd_cpp_kernel.cpp sit in the example set. The second boundary is the host sort. The example directory includes host_sort.cpp, which is the library telling you plainly that for some problems the correct implementation is the standard library one on the CPU, and a GPU data transfer costs more than the computation saved. Choosing Boost.Compute over writing raw OpenCL C by hand is the other decision a team makes. Hand written kernels give you full control of the work group shape, the local memory usage and the generated source, and they let you reuse a kernel you already tuned for another API. Boost.Compute gives you a host side interface you can call like the standard library and an STL shaped surface, which is a better fit when the algorithm is already written and you want it to run somewhere else.

Editorial conclusion

Boost.Compute fits a C++ codebase that already has a working OpenCL runtime and wants to move a few hot loops onto a GPU without learning a second language, and it fits a team that wants the same algorithm source to run on the host and the device. It does not fit a project that has to support a backend other than OpenCL, and it does not fit an application where an implicit buffer or a unified memory model would matter, because every copy is written by hand in your code. Verify three things first: that the OpenCL implementation you will deploy on exposes the device features your kernels assume, that the sort and reduce paths you plan to use are actually the ones the examples exercise, and that the licence file in the tree, LICENSE_1_0.txt, matches the Boost Software Licence 1.0 terms your organisation expects.

Frequently asked questions

Official sources

1. boostorg/compute on GitHub
2. Issues
3. License: BSL-1.0
4. Project website
5. README