alpaka
Abstraction Library for Parallel Kernel Acceleration
|
The alpaka library is a header-only C++20 abstraction library for accelerator development.
Its aim is to provide performance portability across accelerators through the abstraction (not hiding!) of the underlying levels of parallelism.
It is platform independent and supports the concurrent and cooperative use of multiple devices such as the hosts CPU (x86, ARM, RISC-V and Power 8+) and GPU accelerators from different vendors (NVIDIA, AMD and Intel). A multitude of accelerator back-end variants using CUDA, HIP, SYCL, OpenMP 2.0+, std::thread and also serial execution is provided and can be selected depending on the device. Only one implementation of the user kernel is required by representing them as function objects with a special interface. There is no need to write special CUDA, HIP, SYCL, OpenMP or custom threading code. Accelerator back-ends can be mixed and synchronized via compute device queue. The decision which accelerator back-end executes which kernel can be made at runtime.
The abstraction used is very similar to the CUDA grid-blocks-threads domain decomposition strategy. Algorithms that should be parallelized have to be divided into a multi-dimensional grid consisting of small uniform work items. These functions are called kernels and are executed in parallel threads. The threads in the grid are organized in blocks. All threads in a block are executed in parallel and can interact via fast shared memory and low level synchronization methods. Blocks are executed independently and can not interact in any way. The block execution order is unspecified and depends on the accelerator in use. By using this abstraction the execution can be optimally adapted to the available hardware.
alpaka is licensed under MPL-2.0.
The alpaka documentation can be found in the online manual. The documentation files in .rst
(reStructuredText) format are located in the docs
subfolder of this repository. The source code documentation is generated with doxygen.
Accelerator Back-end | Lib/API | Devices | Execution strategy grid-blocks | Execution strategy block-threads |
---|---|---|---|---|
Serial | n/a | Host CPU (single core) | sequential | sequential (only 1 thread per block) |
OpenMP 2.0+ blocks | OpenMP 2.0+ | Host CPU (multi core) | parallel (preemptive multitasking) | sequential (only 1 thread per block) |
OpenMP 2.0+ threads | OpenMP 2.0+ | Host CPU (multi core) | sequential | parallel (preemptive multitasking) |
std::thread | std::thread | Host CPU (multi core) | sequential | parallel (preemptive multitasking) |
TBB | TBB 2.2+ | Host CPU (multi core) | parallel (preemptive multitasking) | sequential (only 1 thread per block) |
CUDA | CUDA 12.0+ | NVIDIA GPUs | parallel (undefined) | parallel (lock-step within warps) |
HIP(clang) | HIP 6.0+ | AMD GPUs | parallel (undefined) | parallel (lock-step within warps) |
SYCL(oneAPI) | oneAPI 2024.2+ | CPUs, Intel GPUs and FPGAs | parallel (undefined) | parallel (lock-step within warps) |
This library uses C++20 (or newer when available).
Accelerator Back-end | gcc 10.4 / 11.1 (Linux) | gcc 12.3 (Linux) | gcc 13.1 (Linux) | clang 10/11 (Linux) | clang 12 (Linux) | clang 13 (Linux) | clang 14 (Linux) | clang 15 (Linux) | clang 16 (Linux) | clang 17 (Linux) | clang 18 (Linux) | clang 19 (Linux) | icpx 2025.0 (Linux) | Xcode 15.4 / 16.1 (macOS) | Visual Studio 2022 (Windows) |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Serial | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
OpenMP 2.0+ blocks | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: [^1] | :white_check_mark: | :white_check_mark: |
OpenMP 2.0+ threads | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: [^1] | :white_check_mark: | :white_check_mark: |
std::thread | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
TBB | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
CUDA (nvcc) | :white_check_mark: (CUDA 12.0) | :white_check_mark: (CUDA 12.0 - 12.5) | :white_check_mark: (CUDA 12.4 - 12.5) | :white_check_mark: (CUDA 12.0) | :white_check_mark: (CUDA 12.0) | :white_check_mark: (CUDA 12.0) | :white_check_mark: (CUDA 12.0) | :white_check_mark: (CUDA 12.2) | :white_check_mark: (CUDA 12.3) | :white_check_mark: (CUDA 12.4 - 12.5) | :white_check_mark: (CUDA 12.4 - 12.5) | :x: | :x: | - | :x: |
CUDA (clang) | - | - | - | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | - | - |
HIP (clang) | - | - | - | :x: | :x: | :x: | :x: | :x: | :x: | :white_check_mark: (HIP 6.0 - 6.1) | :white_check_mark: (HIP 6.2) | :x: | :x: | - | - |
SYCL | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :x: | :white_check_mark: [^2] | - | :x: |
Other compilers or combinations marked with :x: in the table above may work but are not tested in CI and are therefore not explicitly supported.
[^1]: Due to an LLVM bug in debug mode only release builds are supported. [^2]: Currently, the unit tests are compiled but not executed.
Boost 1.74.0+ is the only mandatory external dependency. The alpaka library itself just requires header-only libraries. However some of the accelerator back-end implementations require different boost libraries to be built.
When an accelerator back-end using CUDA is enabled, version 11.2 (with nvcc as CUDA compiler) or version 11.2 (with clang as CUDA compiler) of the CUDA SDK is the minimum requirement. NOTE: When using clang as a native CUDA compiler, the CUDA accelerator back-end can not be enabled together with any OpenMP accelerator back-end because this combination is currently unsupported. NOTE: Separable compilation is disabled by default and can be enabled via the CMake flag CMAKE_CUDA_SEPARABLE_COMPILATION
.
When an accelerator back-end using OpenMP is enabled, the compiler and the platform have to support the corresponding minimum OpenMP version.
When an accelerator back-end using TBB is enabled, the compiler and the platform have to support the corresponding minimum TBB version.
The library is header only so nothing has to be built. CMake 3.22+ is required to provide the correct defines and include paths. Just call alpaka_add_executable
instead of add_executable
and the difficulties of the CUDA nvcc compiler in handling .cu
and .cpp
files are automatically taken care of. Source files do not need any special file ending. Examples of how to utilize alpaka within CMake can be found in the example
folder.
The whole alpaka library can be included with: #include <alpaka/alpaka.hpp>
Code that is not intended to be utilized by the user is hidden in the detail
namespace.
Furthermore, for a CUDA-like experience when adopting alpaka we provide the library cupla. It enables a simple and straightforward way of porting existing CUDA applications to alpaka and thus to a variety of accelerators.
The CI creates a single-header version of alpaka on each commit, which you can find on the single-header branch.
This is especially useful, if you would like to play with alpaka on Compiler explorer. Just include alpaka like
and enable the desired backend on the compiler's command line using the corresponding macro, e.g. via -DALPAKA_ACC_CPU_B_SEQ_T_SEQ_ENABLED
.
For a quick introduction, feel free to playback the recording of our presentation at GTC 2016:
Currently all authors of alpaka are scientists or connected with research. For us to justify the importance and impact of our work, please consider citing us accordingly in your derived work and publications:
Rules for contributions can be found in CONTRIBUTING.md. Any pull request will be reviewed by a maintainer.
Thanks to all active and former contributors.