Kokkos: A C++ Programming Model for Portable Parallel Execution

What Kokkos Core solves, and who it is written for

Kokkos Core implements a programming model in C++ for writing performance portable applications targeting all major HPC platforms. That sentence from the README is the whole pitch, and it is narrower than it sounds. The problem it addresses is that parallel code written directly against CUDA, HIP, SYCL or OpenMP does not move between them without a rewrite. Kokkos puts an abstraction layer between the application and the backend so the same source compiles against different execution models.

The intended user is an HPC application developer working in C++. The README lists CUDA, HIP, SYCL, HPX, OpenMP and C++ threads as backends, with several others in development. That list is the real audience definition. If you ship a solver to machines that differ in accelerator vendor, or you expect the machine you run on today to be replaced by one with different hardware, the abstraction has value. If you own one cluster with one GPU vendor and no plan to change, the layer is mostly overhead.

The repository itself signals the scope. Top-level directories include core/, containers/, algorithms/ and simd/, so the project is not a single header. It is a set of libraries with a programming guide, an API reference organized by category, and a lecture series with hands-on exercises.

The mechanism: parallel dispatch and memory abstraction

Kokkos provides abstractions for both parallel execution of code and data management. Those are two separate problems and the project treats them separately.

On the execution side, the model is parallel dispatch: the application writes a loop body, and the backend decides how to map it onto threads, warps or work items. The README points to Views and parallel dispatch as the main building blocks described in the programming guide. The backend is chosen at build or configure time, not at runtime by the application author, which is why one source tree produces different binaries for different machines.

On the memory side, Kokkos is designed to target complex node architectures with N-level memory hierarchies and multiple types of execution resources. A View is the data abstraction that sits above those levels. The point of the design is that the layout and the memory space are properties of the View, so moving data between host and device is expressed in the model rather than hand-written per backend.

The repository layout reflects that split: core/ holds the execution and memory machinery, containers/ and algorithms/ build on top of it, and simd/ covers explicit vectorization. The example/ directory contains separate build trees for in-tree builds, installed builds, installed builds with a different compiler, and installed builds that treat Kokkos as a language or use modules. Those directories are the clearest statement of what the project expects you to do in practice: build it, install it, then consume it from another project.

Installing Kokkos and running a first build

The README gives three ways to obtain a release: curl, wget, or a shallow git clone pinned to a tag. The example below uses the tag named in the README. Note that the README's own text says the current release is 5.1.0 while the releases page lists newer tags, so check the releases page rather than trusting the prose.

curl -OJ -L https://github.com/kokkos/kokkos/releases/download/5.1.0/kokkos-5.1.0.tar.gz
# Or with wget
wget https://github.com/kokkos/kokkos/releases/download/5.1.0/kokkos-5.1.0.tar.gz
# Or with git
git clone --depth=2 --branch 5.1.0 https://github.com/kokkos/kokkos.git

For the development branch, the README gives this instead:

git clone --branch develop  https://github.com/kokkos/kokkos.git

Building requires a C++ compiler that supports C++20 or later. The README directs you to the requirements page for minimum and primary tested compiler versions, and to the building-from-source page for the actual configure and build instructions. The repository ships a top-level CMakeLists.txt and a cmake/ directory, and the example/ tree contains several build_cmake_* directories that show how the project expects Kokkos to be consumed after installation.

If you would rather not build it yourself, the README states that Kokkos can be installed using Spack:

spack install kokkos

Configuration options are listed with spack info kokkos. The README does not reproduce the CMake configure commands inline, so the exact backend flags are not in the repository README; they live on the building-from-source page it links to. Treat that page as required reading before your first build, because the backend selection is the decision that determines whether the library is useful to you at all.

Kokkos vs CUDA, SYCL, OpenMP and RAJA

The search data around this project is dominated by backend comparisons, and the honest answer is that Kokkos is not a replacement for most of the things it is compared against.

Against CUDA and SYCL, the difference is layer, not capability. CUDA and SYCL are the things Kokkos compiles down to. Choosing Kokkos means accepting an abstraction over the vendor API in exchange for source that also compiles against a different vendor API. You give up direct access to vendor-specific features that the abstraction does not expose. If your kernel needs a CUDA feature Kokkos does not model, the abstraction is in your way.

Against OpenMP, the difference is the memory model. OpenMP offload and Kokkos both target multiple devices, but Kokkos pairs execution with an explicit data abstraction and a memory hierarchy model, while OpenMP's model is directive-based over existing arrays. Teams with large existing OpenMP code often find the directive approach cheaper to adopt incrementally.

Against RAJA, the difference is scope. Both are C++ performance portability layers, but Kokkos ships containers, algorithms and a SIMD component alongside the core execution model, while a loop-abstraction library leaves data structures to the application. The repository layout here (core/, containers/, algorithms/, simd/) shows which side of that line Kokkos sits on. If you want only loop abstractions and you already have your own array types, a narrower library is less to adopt.

Where Kokkos is the wrong tool

The clearest limitation is the compiler floor. C++20 or later is required, and that rules out older toolchains outright. HPC sites often have a preferred compiler version pinned across a whole machine, and if that compiler predates C++20, Kokkos is not an option until the site upgrades.

The second limitation is build and packaging cost. Kokkos is not a header-only library you drop into a source tree. It is built, installed, and then consumed, and the example/ directory enumerates the variants: in-tree builds, installed builds, installed builds with a different compiler, installed builds that treat Kokkos as a language, and multi-language builds. Each combination is a separate configuration to get right. The README defers the actual instructions to the wiki building-from-source page, which tells you the README alone is not enough to complete a build.

The third is language. The README describes Kokkos as a programming model in C++. The search data shows people asking about Kokkos with Fortran, and the README does point to examples covering Fortran interoperability, but interoperability is not the same as writing your application in Fortran. If your codebase is Fortran-first, Kokkos is a component you interoperate with, not a model you adopt wholesale.

Finally, the abstraction is not free at the source level. Code has to be written in terms of Views and parallel dispatch to benefit. A codebase that calls vendor APIs directly throughout cannot be switched over by changing a build flag.

Maintenance, releases and the licence

The repository is not archived, and the last push was on 2026-09-23. Releases in the 5.2 series landed on 2026-07-24, 2026-08-17 and 2026-09-10, so the project is publishing on a short cadence. The default branch is develop, which is also the branch the README tells you to clone if you want the latest development version. That is a deliberate split: develop moves, tags are what you ship against.

Upgrade cost is the part to plan for. Because the backend is selected at build time, a Kokkos version bump is not a library swap; it is a rebuild of Kokkos and then a rebuild of everything that links it, per platform and per backend. The CHANGELOG.md at the repository root is where the project records what changed between releases, and it is the file to read before moving a production code between 5.2.x tags.

The licence is worth reading carefully rather than assuming. The README badge says Apache-2.0 WITH LLVM-exception, while the repository metadata reports NOASSERTION. The full licence statement used in all headers is published on the wiki and in the LICENSE file at the repository root. If your organisation has rules about which licences it accepts, read the LICENSE file itself rather than the badge, and take your own advice on what it permits.

Editorial conclusion

Adopt Kokkos if you maintain a long-lived C++ HPC codebase that must run on more than one accelerator backend and you are willing to build the library per platform, per compiler and per backend. Do not adopt it if your project is short-lived, single-vendor, or written in a language other than C++. Before committing, verify three things: that your compiler meets the C++20 requirement, that your target backend appears in the supported list for your release, and that you can reproduce the release tarball build with the backend you actually intend to ship.

Frequently asked questions

Official sources

1. Issues
2. kokkos/kokkos on GitHub
3. Project website
4. README
5. Releases