RAJA: a C++ portability layer for HPC loop kernels

Portability without rewriting the algorithm

RAJA is a library of C++ software abstractions, primarily developed at Lawrence Livermore National Laboratory, that enables architecture and programming model portability for HPC applications. The two goals are stated without hedging. The first is application portability with manageable disruption to existing algorithms and programming styles, and the second is performance comparable to using common programming models such as OpenMP or CUDA directly. The mechanism is portable parallel loop execution through building blocks that extend the generally accepted parallel for idiom, and RAJA relies on standard C++20 features, so there is no compiler extension to vendor-lock yourself into. The important word in that first goal is manageable. RAJA is not asking you to restructure the code around a new programming model, it is asking you to replace a specific loop construct and keep the rest, which is a much smaller bill than a full port.

The design comes from mesh based multiphysics codes

The README explains where the abstractions come from, and the answer is more useful than a feature list. RAJA's design is rooted in decades of experience working on production mesh-based multiphysics applications, and because those applications contain a diversity of algorithms and software engineering styles, RAJA is designed to let application developers adapt its concepts and specialize them for different code implementation patterns and C++ usage. That is a design constraint you can feel in the API, since the same loop abstraction has to serve stencil-like mesh traversals, reductions, matrix operations and tiled kernels without becoming a lowest common denominator. The examples directory in the repository shows the range, with dynamic forall loops, matrix transposition, Jacobi iterations, kernel reductions, permutations of views, launch and kernel variants, and OpenMP target kernels. If your own code resembles those patterns, the abstraction will look familiar; if it does not, you will be bending the concepts rather than using them.

Building it is a standard CMake project

The quick start is a clone and three commands, and the clone is recursive for a reason, since the repository carries submodules:

git clone --recursive https://github.com/llnl/raja.git

The build then follows the usual CMake pattern, and the README is explicit that you must build out of source:

mkdir build
cd build
cmake ../
make

The parenthetical that in-source builds are not allowed is the kind of detail that saves an afternoon when a project has a strict layout. You need a C++ compiler that supports C++20, and the configuration options live in the RAJA User Guide, which the README points to as the best place to start learning the project. There is also a separate RAJA Template Project repository that shows how to consume RAJA in a CMake project, either as a Git submodule or as an installed library, and that is the reference to look at when you are wiring RAJA into an existing build rather than hacking on RAJA itself.

The Performance Suite is the measuring stick

Two companion projects tell you how the project stays honest. The RAJA Performance Suite contains a collection of loop kernels implemented in multiple RAJA and non-RAJA variants, and it is used to monitor and assess RAJA performance on different platforms with a variety of compilers. The README says it is an excellent source of RAJA usage examples where you can compare RAJA and non-RAJA variants of the same kernel and the same RAJA back ends, and it adds that many major compiler vendors use the suite to improve their support for abstractions like RAJA. That is a notable form of validation: the abstraction layer is tested against raw versions of itself, so a regression in a back end shows up as a gap between two implementations of the same loop. The RAJA Proxies repository holds RAJA versions of several important HPC proxy applications, which is the next level up, since proxy applications are real workloads rather than kernels.

CHAI handles where the data lives

A portability layer is only half of the problem, because a loop that runs on a device needs its data in the right memory space. CHAI, a separate project from the same lab, provides a managed array abstraction that works with RAJA to automatically copy the data used in RAJA kernels to the appropriate space for execution, and the README describes it as developed as a complement to RAJA. If you are evaluating RAJA, CHAI is usually the second piece you need, and the fact that it is a separate repository rather than part of RAJA means you adopt it deliberately. The same pattern of separation appears in the repository tree itself, with a blt directory for the build system, tpl/ for third party code, host-configs/ for machine configuration files, benchmark/ and test/ directories, plus reproducers/ and exercises/ that exist to keep known failures visible rather than quietly fixed.

GitFlow, a moving develop branch, and honest status

The contribution model is GitFlow, and it explains the branch layout you see. Work goes on a feature branch created from the develop branch, which contains the latest work in RAJA, and the pull request targets develop. Periodically the maintainers merge develop into main and tag a new release. The default branch in the repository is develop, which is unusual for a project most people consume as a release, and it is a direct consequence of that workflow. The status statement is honest about the state of things. Although RAJA is used in a diversity of production applications, the README says it is very much a work in progress, that the contributing community at LLNL is growing, that the released versions contain mostly well-used and well-tested features, and that the core interfaces are fairly stable while the underlying implementations are being refined. The releases follow a date based version scheme, with v2026.07.1 and v2026.07.0 in the summer of 2026 and v2025.12.2 before that, and the last push was on 2026-10-20. The licence is BSD 3-Clause, and the copyright header states that no copyright assignment is required to contribute.

CI builds several compilers with warnings as errors

The container recipe in the repository shows the discipline behind the releases. Each stage starts from an LLNL base image on Ubuntu 24.04, one per compiler, and the cmake invocation is explicit about the configuration, with a Release or Debug build type, RAJA_ENABLE_WARNINGS turned on, RAJA_ENABLE_WARNINGS_AS_ERRORS turned on, OpenMP enabled, vectorization enabled and the C++ standard set to c++20. The build then runs the test suite with ctest before the stage is cleaned, and the comment at the top of the file explains that the job counts differ between newer and older targets because that worked best for throughput on GitHub Actions. The upstream base image is the RAADIUS project, which is the same infrastructure used across several LLNL code bases, so a change in the base image can affect the build of every stage at once.

Editorial conclusion

Adopt RAJA if you maintain a production multiphysics code that has to run on several CPU and GPU backends and you want the portability work concentrated in loop constructs rather than spread across the code base, and if you can live inside C++20. Do not adopt it for a small application or a codebase that will not be ported for years, since the abstraction cost is only repaid over multiple backends, and do not expect a stable surface, because the README describes RAJA as very much a work in progress whose core interfaces are fairly stable while the underlying implementations are still refined. Verify first which back ends your build enables, read the RAJA User Guide on readthedocs, and run the RAJA Performance Suite kernels against your own loops before you commit to a migration.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. llnl/RAJA on GitHub
4. README
5. Releases