CppCon 2026

This talk presents some design choices, compromises, and optimisations of the implementations of std::flat map and std::flat set. It will cover a brief design history of the original paper regarding the class layout, libc++'s best effort to provide strong exception guarantee on those containers, compromise on the iterator choices between SCARY and more strongly typed, some optimisations on various operations and some tips about avoiding running some issues with these containers.

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.

Reverse-mode automatic differentiation (AD) computes exact gradients with respect to thousands of inputs in roughly the time of a single function evaluation. If you write numerical C++ for finance, scientific computing, or ML and you care about performance, this talk will show you where AD overhead actually comes from and what to do about it.

A straightforward operator-overloading implementation records every arithmetic operation onto a tape and replays it backward to propagate derivatives. On real numerical code this easily introduces 50-100x overhead, and most of that has nothing to do with calculus. It is heap allocation on every operation. It is cache misses walking the tape backward. It is branch mispredictions at memory chunk boundaries. It is recording tape entries for operations where none of the operands are even being differentiated.

We work through a series of C++ techniques that bring this down to around 4x on production code in finance. The two that matter most: a chunked arena allocator with cache-line alignment and branch-prediction hints that turns the recording hot path into a pointer bump and a store, and expression templates that collapse an entire right-hand side into one tape push with all derivatives accumulated in a compile-time-sized stack buffer. We pull up compiler output to show the abstraction really does compile away.

After the big two, we get into the smaller wins that are still worth knowing about: skipping zero adjoints during the backward sweep to exploit sparsity, picking derivative formulas at compile time that reuse the forward result instead of recomputing it, and demoting active-times-passive operations from binary to unary to halve their tape footprint. We also show how a should-record check propagated through the expression tree lets the tape skip entire statements when no operand is active, and how aggressive inlining lets the compiler eliminate these checks entirely for passive subexpressions, so the cost of asking is zero when the answer is no. We benchmark each one in isolation on four numerical workloads ranging from 8 to 161 sensitivities, so you can see what each technique is actually worth.

Atomic memory ordering is often taught operationally: Use acquire here, release there, and perhaps add a fence “to be safe.” This approach tends to produce cargo-cult synchronization, where atomic operations are selected mechanically without a clear understanding of what information is actually being propagated between threads. In practice, memory ordering is not about memorizing enum values, but about establishing which facts become visible to which observers, and when.

This talk approaches atomic synchronization from first principles. Beginning with the fundamental ideas of publication, visibility, ownership transfer, and synchronization edges, the talk incrementally develops several concurrent structures drawn from real asynchronous systems. Case studies include outstanding-work reference counting, a multi-producer singly-linked publication structure, a concurrently-mutated doubly-linked intrusive list, and the coordination machinery underlying a concurrent operation with multiple concurrent completion modalities. Each structure is used to derive the synchronization requirements imposed by its invariants, rather than selecting memory orderings mechanically.

Along the way, the talk explores the practical meaning of relaxed operations, acquire/release synchronization, and atomic thread fences. Particular attention is paid to understanding what each actually does, when it is necessary, and when it has become a decorative synchronization cargo cult. The goal is not simply to present lock-free algorithms, but to develop a principled way of reasoning about memory visibility and synchronization in real concurrent systems.

According to VGInsights, about 10% of games released on Steam in 2024 used a custom engine, but those games represent 41% of units sold. Most "how an engine works" talks come from the AAA end of that distribution. This one comes from the other end of that distribution: a teaching-scale engine, where every system has to be small enough to understand from first principles. The problems are the same as in a big engine, but the smaller surface is what makes the architecture legible.

In this talk, we'll walk the spine of the engine in modern C++: allocators and handles in the core, the job system, the graphics abstraction question, the asset pipeline split between pipeline-time and runtime, and scene representation including ECS. We finish on serialization, where C++26 reflection (P2996) offers a path past today's reliance on macros and external code generators.

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.

Applications that present rapidly changing market data to human users face a practical challenge: updates may arrive thousands of times per second, but humans only benefit from periodic refreshes. Efficiently coalescing and scheduling that work without overwhelming CPU resources becomes a concurrency problem rather than simply a rendering problem.

This talk demonstrates how modern C++ atomics can be used to build a lock-free timer scheduler optimized for extremely high update rates. The scheduler follows a single-producer, multiple-consumer design in which work items represent recurring tasks that must execute periodically. Consumers process scheduled work and re-schedule it for future execution without relying on traditional locks or centralized coordination.

The most unusual aspect of the design is its “reverse work stealing” behavior: consumers can proactively give away work to other consumers and become idle themselves. Rather than distributing work evenly across all threads, the scheduler attempts to pack work onto as few cores as possible, reducing idle spinning, lowering CPU utilization, and improving cache locality. Because tasks may have highly variable execution times, the scheduler must also prevent pathological cases where work is endlessly redistributed between consumers.

Attendees will learn how atomics, lock-free forward lists, and memory ordering can be combined to implement high-throughput schedulers with predictable latency characteristics. The talk also discusses practical tradeoffs, implementation challenges, and performance measurements from production-inspired workloads, including producer throughput of approximately 50 million scheduled tasks per second and consumer processing throughput approaching 700 million tasks per second, while keeping migrated work items below 1% in typical workloads.

Your system has interchangeable strategies chosen at runtime, but the hot path runs millions of times per second. Runtime polymorphism has virtual dispatch overhead. Templates give you performance but lock you at compile time.

This workshop shows how to leverage inheritance for extensibility while avoiding vtable overhead, using a layered architecture of compile-time patterns. We'll build them up through OpenJDK's GC barrier system, where different GC algorithms compose different barriers on one of the hottest paths in the JVM.

We will also discuss trade-offs against alternatives like std::variant, function pointers, and plain virtual dispatch throughout. No JVM knowledge required.

Practical HPC — Forcing the Compiler's Hand with Modern C++

Achieving near-peak FLOPs on modern CPUs requires exploiting SIMD, register files, and cache hierarchies — yet the levers that matter most (loop unrolling, vectorization width, tile sizes, register tiling) are largely outside the programmer's direct control. Autovectorization is fragile, #pragma unroll is advisory and non-portable, and the information the compiler needs most — loop bounds, problem shapes, working-set sizes — is typically only available at runtime. The result is a familiar gap between theoretical peak and delivered performance, bridged in practice only by hand-written intrinsics or inline assembly, fragile macro forests, or external code generators that sacrifice maintainability and type safety.

Modern C++ is, sometimes surprisingly, an excellent language for closing that gap without leaving the host language. We walk through the concrete features that make this possible and how to use them in practice — templates and constexpr to promote runtime values into compile-time constants, if constexpr and parameter packs for shape-specialized kernels, generic and template lambdas for loop bodies that are unrolled and inlined by construction, and concepts to turn silent performance cliffs into compile-time errors. Together, these give the programmer precise control over what the compiler emits: compile-time dispatch that specializes kernels per shape and target, guaranteed static unrolling that unlocks ILP and register tiling without relying on optimizer heuristics, and hardware-aware specialization parameterized on register count, SIMD width, and cache sizes.

Looking forward, C++26 and static reflection push this approach considerably further, turning today's disciplined metaprogramming into something closer to first-class, in-language code generation — and squarely aligning the language with the goal of making inline assembly unnecessary, even at the highest performance tiers.

These patterns are powerful but verbose and reappear across kernels, so we briefly introduce POET (Performance Optimized Excessive Templates), a header-only library usable from C++17 onward that packages the most common cases as ready-to-use building blocks, alongside xsimd for portable SIMD.

As a concrete case study, we walk through a real scientific-computing kernel — a workload of the kind that has historically demanded hand-tuned assembly — and show how these abstractions get within a small fraction of theoretical peak throughput while keeping the source readable, portable, and maintainable, with no inline assembly, no compiler builtins, and no external code-generation step. Scientific computing does not have to choose between performance and engineering quality, and with the right abstractions, development becomes dramatically more effective.