Speaker
Description
In this presentation, we’ll introduce our work on Krokkos, an experimental library designed to bridge the gap between Kokkos and Rust.
Rust, a modern systems programming language, excels in multi-threaded and memory-safe applications. Its ownership model guarantees that data races are caught at compile time, making it an attractive choice for scientific software development on shared‑memory architectures. However, Rust’s ecosystem still lags behind when it comes to vendor‑agnostic GPU support for general‑purpose computations. Most of the available GPU backends are either experimental, tied to a single vendor, or require cumbersome unsafe wrappers that erode Rust’s safety guarantees.
Kokkos, on the other hand, is a well‑established solution for shared‑memory parallel programming across CPU and accelerators. It achieves performance portability by providing an abstract way to express loops, automatically generating tailored kernels for the chosen backend—whether that be a multi‑core CPU or an GPU. A key feature of Kokkos is its custom data structures, Kokkos::Views, which encapsulate multi‑dimensional arrays with a layout that adapts to the execution platform. This abstraction allows developers to write code once and run it efficiently on a wide range of hardware without manual tuning.
Our project’s goal is to enable interoperability between Rust applications and Kokkos kernels. One initial use case involves creating a hybrid application that uses Rust for the general architecture—handling I/O, orchestration, and high‑level logic—but delegates compute‑intensive regions to Kokkos routines in order to leverage GPU hardware. Another use case demonstrates interoperability in the opposite direction: a C++ application built on Kokkos calls Rust routines to populate or manipulate Kokkos data structures, thereby taking advantage of Rust’s safety and expressive type system for parts of the codebase that are less compute intensive (e.g. IO, interactions).
The primary technical challenge in both scenarios is interfacing Rust and C++, especially given Kokkos’ extensive use of templates. Templates in C++ allow for compile‑time specialisation and zero‑overhead abstractions, but they also mean that the generated binary contains many distinct instantiations of a single generic function. Rust’s foreign‑function interface (FFI) traditionally relies on C‑style ABI, which does not natively support templated types or overloaded functions. Consequently, we must devise a strategy that preserves Kokkos’ strongly typed data structures and compile‑time layout selection while exposing them safely to Rust.
To better align with Kokkos’ logic and strongly typed data structures, which allow for memory representation selection at compile time, we’ve opted for a direct wrapper between Rust and C++. We have extended interoperability libraries such as the cxx crate to work with Kokkos. The cxx crate provides a safe, type‑checked bridge between Rust and C++ by generating bindings that respect ownership semantics. By leveraging this crate, we can expose Kokkos::Views and kernel launch functions to Rust without resorting to raw pointers or manual memory management. The wrapper also handles the translation of Kokkos’ execution policies into Rust enums, ensuring that the user can select the desired backend in a type‑safe manner.
An alternative solution would have been to use a lingua franca with a stable ABI like C. However, this approach involves fully opaque data exchanges: the Rust side would receive a "void*" pointer and would have to perform runtime checks or casts to interpret the data correctly. Such opaque exchanges can degrade performance because they force the compiler to generate generic code that cannot be optimised as aggressively, and they also reintroduce potential safety pitfalls that Rust is designed to avoid.
We’ll spend time explaining the design of the translated Kokkos API in Rust, particularly its memory safety features. Our goal is to create a Rust API that doesn’t expose unsafe code to users. For example, we wrap Kokkos::Views in a struct that implements Rust’s Deref and Index traits, allowing idiomatic indexing while guaranteeing that the underlying memory remains valid for the lifetime of the view.
We’ll then delve into the limitations of our work using more advanced concepts like subviews. Subviews allow a user to create a view into a subset of an existing Kokkos::View, which is essential for algorithms that operate on slices or blocks of data. In C++, subviews are implemented as templated types that inherit from the parent view, leading to a combinatorial explosion of instantiations. In Rust, however, function overloading is disallowed, and generic functions must be monomorphized at compile time. This makes it difficult to provide a clean, ergonomic API for subviews without generating an unmanageable number of functions. We discuss potential workarounds, such as using trait objects or a macro‑based approach to generate the necessary boilerplate, and we evaluate their trade‑offs in terms of compile time and binary size.
This project is aiming at integrating the HPSF Kokkos project, adding portable GPU support for Rust. By contributing our wrapper back to the upstream repository, we can broadly expose Rust bindings, thereby paving the way for wider adoption of a more productive and secure language that is compatible with modern HPC hardware. This integration will also allow Rust developers to benefit from Kokkos’ mature performance tuning tools, such as profiling and auto‑tuning, while maintaining the safety guarantees that Rust provides.
