CppCon 2026

The architecture of legacy compilers presents limitations for modern software development. As codebases scale, developers face increased compilation times. While language complexity is often cited, key architectural bottlenecks include pointer-chasing across deeply nested ASTs (cache misses), single-threaded type resolution, and significant thread-lock contention (RwLock) during parallel semantic analysis. What happens when we discard the Abstract Syntax Tree entirely and apply strict Data-Oriented Design to the compiler itself?

In this session, we will explore the internal architecture of the Vx compiler frontend—a heterogeneous systems programming language to safely maximize utilization of available CPU cores. We will dissect how to translate complex, tree-like program semantics into flat, contiguous arrays of 256-bit bit-packed Global Identifiers (GIDs).

By stepping away from traditional recursive tree-walking and object-oriented compiler design, attendees will learn how to implement high-throughput parallel pipelines.

This talk is not just for language designers. The architectural patterns used to build the Vx compiler—flattening graphs into arrays, deferred identity, and lock-free synchronization boundaries—are directly applicable to any C++ developer building high-performance, multithreaded systems.

C++20 coroutines come with a reputation for complexity — and writing your own coroutine return type deserves that reputation. But here is the good news: you probably don't have to. With std::generator in C++23, high-quality libraries like Asio and cppcoro today, and std::task on its way in C++26, most developers can simply write co_await and move on.

There is one gap, however. Sooner or later, every developer using coroutines needs to bridge an existing asynchronous interface — a timer, an I/O operation, a thread pool callback, a legacy future — into the coroutine world. That bridge is built with awaiters and awaitables, and that is exactly what this session teaches.

We will start from first principles: what does co await actually do? We will demystify the three functions that form the awaiter protocol — await ready, await suspend, and await resume — and build a clear mental model for each. We will implement a real awaiter from scratch, then explore how symmetric control transfer keeps the call stack flat across deeply chained async operations. Next, we will learn how to make any existing type co await-able without modifying it, using operator co await, and how await transform lets you restrict or adapt awaitable behavior to a specific coroutine context. Finally, we will look at how to write cancellation-aware awaiters using std::stop token, so your coroutines respond promptly when work is no longer needed.

No prior coroutines experience is assumed. If you know what co await looks like on the surface but not what happens underneath it, this session is for you. You will leave with both the knowledge and the code to wrap any asynchronous operation into a first-class co await expression.

Modern storage hardware has evolved at a breakneck pace. PCIe Gen 5 NVMe drives can push data at 10 GB/s, yet standard C++ file abstractions often leave them starving for data. Many developers think they need to abandon portability in favor of unmaintainable, OS-specific kernel bypasses to achieve the throughput necessary to saturate these drives. This session is for developers writing high-throughput, performance-critical applications who want to hit bare-metal speeds without sacrificing clean architecture, cross-platform support, or type safety.

Using a high-throughput cryptographic hashing engine as a concrete case study, this presentation demonstrates how to design a hardware-saturating data pipeline built entirely on the idioms of C++26. We will explore how the mathematical design of an algorithm - specifically BLAKE3's binary Merkle tree structure - can be mapped directly to wide SIMD vector lanes and concurrent CPU cores. We will walk through an execution model that completely bypasses the OS page cache, orchestrates memory without heap allocations on the hot path, and unifies OS kernel quirks in a portable way.

By the end of this presentation, you will learn how to replace rigid thread pools with lock-free, asynchronous execution graphs using Sender/Receiver paradigms (std::execution) and vectorization (std::simd). Crucially, we will focus on the build engineering required to make this work today. We will cover how to use advanced CMake tooling to safely compile multi-architecture vector binaries from a single source of truth, how to prevent LTO cross-contamination, and how to structure your pipeline today to seamlessly absorb upcoming C++ features in a world of trailing vendor toolchains.

CUDA Tile C++ is a novel C++ DSL and compiler that automatically parallelizes array operations across GPU threads while presenting a single logical thread to the programmer. In CUDA Tile C++, parallelism is expressed through SIMD-style operations on arrays of data called "tiles" while memory accesses are written using structured memory abstractions. The compiler analyzes the tile and memory operations to generate an equivalent multi-threaded program that leverages the advanced hardware capabilities of modern GPUs. This allows the user to write simple programs that exploit GPU parallelism without needing to manage low level hardware concurrency.

As GPU architectures evolve to meet the demands of high performance computing, the traditional multi-threaded GPU programming model becomes increasingly unwieldy. To achieve optimal performance, the GPU programmer must manage a growing variety of hardware features including shared memory, Tensor Memory Accelerators, and Tensor Cores. Traditional CUDA code is deeply coupled to the underlying hardware resulting in complex and non-portable algorithms. The CUDA Tile C++ compiler removes the need for coordinating these low level hardware details, freeing the user to reason about their algorithm rather than asynchronous code.

The tile programming model introduces three key abstractions:

• cuda::tiles::tile - a multi-dimensional array with value semantics whose operations are parallelized across the GPU
• cuda::tiles::tensor_span - a view into a multi-dimensional in-memory array with an interface similar to std::mdspan
• Tile Views - adapters that present a uniform "chunking" of a tensor_span which gives the compiler visibility into memory access patterns

In this talk, we will explore how these abstractions allow NVIDIA's Tile C++ compiler to schedule the program across hardware threads all while preserving the illusion of a single-threaded abstract machine to the user.

What makes an async workflow readable? Not just linear control flow — you also need to see where errors go, what each step depends on, and how failures compose. This talk takes a single production workflow — multiple async RPC calls with conditional branching, parallel fan-out, and partial-failure handling — and shows it implemented in three paradigms: callbacks with thread pools, a workflow orchestration graph over futures, and coroutines with std::expected. We evaluate each through four questions: where does the control flow live, the error flow, the coupling, and the migration risk?

Coroutines restore linear control flow, but without structured error composition, the workflow drowns in manual failure checks at every step, that is more error-handling code than business logic. Task

Queues are the backbone of concurrent systems — yet most C++ developers treat them as a black box. Pick the wrong queue topology, misplace an alignas, or use the wrong memory order, and you pay for it in microseconds of latency, invisible cache thrashing, or subtle correctness bugs that only manifest under load. This talk is a rigorous, bottom-up treatment of the four canonical concurrent queue topologies: SPSC, MPSC, SPMC, and MPMC. We start with the hardware reality — how cache coherence protocols turn innocent struct layout into a performance disaster through false sharing — and build upward through the C++ memory model, atomic operations, and queue algorithm design. For each topology, we derive the minimal set of memory ordering guarantees required for correctness, show how to exploit producer/consumer asymmetry to eliminate unnecessary synchronization, and demonstrate how alignas(std::hardware destructive interference size) and deliberate padding can be the difference between 100ns and 10ns throughput. We dissect Dmitry Vyukov's MPMC ring buffer, the intrusive MPSC queue, and Michael-Scott's linked-list queue — not just their interfaces, but the why behind every memory order acquire and every phantom cache line. We then go beyond correctness into the practical engineering tradeoffs: bounded vs unbounded, throughput vs latency, contention vs coordination overhead. Real benchmark data shows how these decisions interact non-obviously — an MPMC queue can outperform MPSC under certain producer counts, and seq cst where you don't need it can quietly halve your throughput. Attendees will leave with a clear mental model for choosing and implementing the right queue for their threading topology, a checklist for false sharing audits, and battle-tested code patterns suitable for low-latency production systems.

std::atomic and std::memory_order are utterly opaque abstractions. It feels like they were put in place to hide some monstrosity that is too complex for mortals to comprehend, and inevitably when trying to understand the underlying reality, the explanations end with 'the processor does weird things' and 'think about it as if...'.

Well, 'think about it as if' no more. In this talk we'll present the gory and wonderful mechanics of cache coherence protocols, store buffers, cache invalidation queues and the in-processor load-store-queue. We'll explain how modern hardware design makes different cores have different views of memory, and what fences and read-modify-write instructions do exactly - for both x86/64 and ARM/RISC-V (which are sometimes dramatically different).

This is an advanced low-level talk located at the borderline of software development and electrical engineering, discussing topics rarely - if ever - discussed at C++ conference talks.