KaMPIng-v2

---

Calling MPI from C++ means passing raw pointers, element counts, datatypes and displacement arrays by hand, and getting one of them wrong usually crashes or hangs. KaMPIng-v2 lets you pass the objects you already have, such as a std::vector, a std::span or a Kokkos view, and works out the pointer, count and datatype for you. When you need more, you add it with a | pipe in the style of std::ranges views: a receive buffer that resizes itself, per-rank counts that are exchanged for you, or a custom datatype.

#include <kamping/v2.hpp>

namespace v2    = kamping::v2;
namespace views = kamping::v2::views;

// Point-to-point: the receiver does not need to know the message size in advance.
v2::send(data, dest, comm);
v2::recv(buf | views::resize, source, comm);

// Variable-size collectives: per-rank counts are exchanged and the receive buffer is sized for you.
auto [_, everything] = v2::allgatherv(mine, v2::auto_recv_v<int>(), comm);
v2::alltoallv(sdata | views::with_counts(scounts) | views::auto_displs, v2::auto_recv_v<double>(), comm);

// GPU and performance-portability containers are buffers, too.
v2::send(kokkos_view | views::kokkos, dest, comm);

KaMPIng-v2 is header-only and requires C++20. It is the successor of KaMPIng and is described in our EuroMPI 2026 paper (preprint).

Documentation: the user guide and API reference cover everything below in more depth.

Highlights

• Your containers are MPI buffers. Contiguous ranges of builtin types work as they are, including standard views like std::views::take(n). Other types plug in through a trait or a few member functions; no inheritance, no wrapper classes.
• Composable views. with_type, with_counts, auto_displs, resize, flatten_v, … attach exactly the MPI metadata you need, compose with each other and with std::views, and compute lazily.
• You only pay for what you use. Convenience is opt-in at the call site: a receive buffer only probes or exchanges counts if you pipe it through views::resize or ask for auto_recv_v. KaMPIng-v2 never performs communication you did not ask for.
• Memory-safe non-blocking operations. isend/irecv return an iresult that keeps an owned buffer out of reach until the operation has completed, and catches requests that are never completed.
• Ready for the HPC ecosystem. Adapters for Kokkos, Thrust, SYCL and Cereal serialization, built on the same buffer protocol as everything else.
• A standardizable core underneath. Everything is built on mpi-core, a thin C++ MPI interface you can also use on its own.

mpi-core: the foundation

KaMPIng-v2 consists of two layers, plus the ecosystem adapters:

Layer	Namespace	Role
mpi-core (mpi-core/)	mpi::experimental	The C++ core interface: MPI's own abstractions (data buffers, object handles, procedures) as C++20 concepts. One MPI call per function, MPI semantics unchanged, no hidden allocation or communication.
KaMPIng-v2 (kamping-v2/)	kamping::v2	Convenience and safety on top: buffer views, receive buffers that size themselves, ownership-aware results and iresult, and defaults for omitted arguments.
Ecosystem adapters (ecosystem/)	kamping::v2::views	Kokkos, Thrust, SYCL and Cereal, as buffers usable with both layers.

mpi-core is deliberately minimal. It mirrors the MPI standard closely, so that it can serve as a reference for standardized C++ bindings, and it is the extension point for everything above it: a type that works with mpi-core works with KaMPIng-v2 and with all views. Use it directly when you want exact MPI semantics, are building your own abstractions, or adopt C++ bindings incrementally in an existing MPI code base. It also accepts native MPI handles and your existing wrapper types.

std::vector<double> v = ...;
mpi::experimental::send(v, dest, tag, MPI_COMM_WORLD);                         // mpi-core: explicit, one MPI call
kamping::v2::recv(buf | kamping::v2::views::resize, source, comm);             // KaMPIng-v2: probes, then resizes

Buffers and customization

A type is a data buffer if ptr(), count() and type() are defined for it; variable-size operations such as alltoallv additionally need per-rank counts() and displs(). Each accessor is looked up in three steps:

1. a buffer_traits<T> specialization, for types you don't own;
2. a member function (mpi_ptr(), mpi_count(), mpi_type(), …), for types you control;
3. the standard range interface: std::ranges::data(), std::ranges::size(), and the MPI datatype of the element type.

The steps apply per accessor, so a specialization only provides what cannot be derived. A thrust::device_vector only needs its pointer:

template <typename T, typename Alloc>
struct mpi::experimental::buffer_traits<thrust::device_vector<T, Alloc>> {
    static T const* ptr(thrust::device_vector<T, Alloc> const& v) { return thrust::raw_pointer_cast(v.data()); }
    static T*       ptr(thrust::device_vector<T, Alloc>& v)       { return thrust::raw_pointer_cast(v.data()); }
};

MPI objects come in non-owning (comm_view) and owning, move-only RAII (comm) forms, and every argument that stands for an MPI object also accepts the native handle or your own wrapper type (via handle_traits). With MPI_ERRORS_RETURN, MPI errors are thrown as mpi_error.

Views

All views compose with | and live in kamping::v2::views.

This is the beginning of the README. Read the rest at the original. Read the full README ↗