CppCon 2026

A chess engine must search millions of positions per second. Move generation is often a bottleneck. Generating moves for knights, kings, and pawns are computationally cheap (~1 nanosecond). However, rooks, bishops, and queens (aka "sliding pieces") present a unique challenge: their movement depends on the placement of other pieces. This makes on-demand generation too slow (20+ nanoseconds) and naively-implemented lookup tables impractical (requiring zettabytes of RAM).

We will start by reviewing the core data structures in a chess engine and the logic behind move generation. Then, we will explore "magic bitboards", a perfect hashing technique that enables sliding piece move generation in ~1 nanosecond. We will look at how to implement this in modern C++, comparing hardware-specific instructions like PEXT (Parallel Bits Extract) against a portable software approach. Finally, we will discuss the practical challenges of generating the data structures required for magic bitboards, including the limitations of consteval and how to integrate build-time table generation into the build process using Bazel.

To ground these concepts, we will be referencing implementation details and code from my C++ chess engine, FollyChess.

Are you smarter than a branch predictor? In this interactive, game-show-themed session, the audience becomes the branch predictor: participants vote on which of two C++ snippets will run faster before we examine what actually happens on real hardware. The snippets are drawn from real-world production code, and correct answers are rewarded with unique specialty erasers (no two are the same!). Through these examples, we build a practical mental model of how modern CPUs handle control flow and why even small branching decisions can have a significant impact on performance. Using annotated assembly, performance-counter data, and cross-platform comparisons, this talk explores branch prediction, misprediction costs, indirect calls and virtual dispatch, and the trade-offs between branches and conditional moves. We examine how different compilers (GCC, Clang, and MSVC) transform code and highlight non-obvious cases where “branchless” code performs worse or behaves differently across architectures. The examples are intentionally small microbenchmarks, but each exposes patterns that appear in real-world systems when control flow becomes the bottleneck. Whether you're a systems engineer or just curious about what your branch predictor is doing behind your back, this session will give you a concrete mental model of control flow. You'll leave with the tools to profile your code, interpret assembly, and make informed decisions about when to rely on compiler heuristics versus manual optimization.

What does it take to build a real-time embedded control system in modern C++, simulate its environment, command it from a browser, and watch it fly in 3D — all from the same open source ecosystem? This talk follows that pipeline end-to-end: from a C++23 real-time framework that schedules deterministic control loops across POSIX hosts and bare-metal microcontrollers, to GPU-accelerated simulation with CUDA, to web-based operations and telemetry, to live 3D visualization in Unreal Engine.

Attendees will see how a unified runtime architecture can span embedded control, simulation, diagnostics, operations, and visualization without fragmenting into separate software stacks. The talk explores deterministic scheduling, zero-allocation real-time design, cross-platform deployment, and integrating CUDA compute kernels directly into scheduled control loops without blocking execution. It also covers tooling for validating deterministic real-time behavior, along with techniques for streaming telemetry and sensor data between simulation and visualization layers in real time.

The presentation includes live demonstrations of a quadcopter simulation flying a programmed trajectory with lidar feedback, and a full-fidelity aircraft simulation with closed-loop autopilot, engine dynamics, and atmospheric turbulence — both running through the same real-time framework and rendered live in Unreal Engine. Whether you build flight software, robotics systems, industrial controllers, or simulation infrastructure, this talk presents practical architectural patterns for modern real-time systems in C++ that bridge embedded devices, GPU compute, and interactive visualization.

Floating point has a reputation for betrayal. Change the thread count, vector width, compiler flags, reduction tree, or target architecture, and the low bits can move. Parallel algorithms make this worse: the standard often specifies the operation, but not the numerical expression whose result must be reproduced. This talk asks a provocative question: what if reproducible numerics did not have to be slow?

We will show reproducible, deterministic implementations of reduce and scan that exhibit better error behavior on hostile floating-point workloads and can match or beat conventional standard-library implementations on realistic workloads. The trick is not to freeze the execution schedule. It is to specify the expression being computed, then let the implementation use SIMD, threading, blocking, tiling, and platform-specific strategies to compute that expression efficiently.

The key idea, developed through C++ standardization work such as P4016R0 and P4229R0, is reproducibility by reproducing the computation. Instead of asking the implementation to promise a particular schedule, we give the calculation a named expression. Once that expression is chosen, changing the thread count, vector width, chunking, or blocking strategy does not silently change the answer.

A reproducible scan makes this harder than reduce because it does not expose only one final value. It exposes every prefix. A reproducible final sum is not enough if the intermediate results still drift. We will show how expression and observation contracts make those prefixes reproducible without forcing the computation back into a slow sequential order.

Then we go below the algorithm layer, to the places where bits usually escape: FMA contraction, denormals, floating-point environment choices, math-library approximations, and vectorized transcendental functions. The goal is not to get the same answer by turning off the hardware. We will show reproducible vectorized primitives, including transcendental functions, running at speeds comparable to established vector math libraries while preserving a cross-platform numerical contract.

Finally, we put the whole stack under stress: a heterogeneous numerical pipeline across x86-64, Apple Silicon, and CUDA. The data is deliberately hostile, with high cancellation rates and fragile intermediate states. The aim is not to pass friendly benchmark cases, but to reproduce the specified computation, including the same intermediate failures, not just the same final answer, bit for bit, across CPUs, GPUs, and toolchains.

Embedded systems have to operate within real limits. We care about timing, memory usage, reliability, and what happens when something fails. But storage is often treated differently. We write a file, call an API, and assume the operation will finish when it finishes. That works for a lot of systems, but it becomes harder to accept when storage is part of a real-time workload.

That led me to a fairly simple question: what would change if storage had to be predictable too?

In this talk, I'll use an embedded filesystem I built in C++20 to explore that question. We'll start with the system requirements and work our way down into the filesystem, looking at where unpredictable work can come from and what design choices can make that work easier to understand and bound.

Instead of focusing only on average execution time, we'll look at what an operation actually has to do: searching for space, accessing metadata, reading and writing blocks, handling failures, and recovering from interrupted operations. We'll also look at how those costs change as the filesystem fills up or becomes fragmented. This kind of reasoning is familiar in real-time systems—we routinely think about bounded work in schedulers, queues, synchronization, and memory management. Storage deserves the same scrutiny.

The filesystem is intentionally constrained. It uses fixed resources and bounded searches where practical, explicit ownership, and a block-device interface that keeps the filesystem separate from the underlying storage hardware. I'll also show how fault injection and instrumentation can be used to exercise failure paths and measure the work being performed instead of relying only on timing measurements.

Modern C++ is useful here, but not because using C++ automatically makes a system deterministic. It gives us tools for making some of these design decisions explicit. We'll look at std::span, std::string_view, fixed-size containers, RAII, compile-time configuration, and small abstractions that can still make sense on a resource-constrained microcontroller.

There are tradeoffs. Fixed limits give up some flexibility. Simpler allocation strategies may use storage less efficiently. Recovery requires additional work and writes. In some systems those costs are worth paying for behavior that is easier to reason about. In others, a general-purpose filesystem is the better choice. We'll look at both sides.

We'll also separate the work performed by the filesystem from the timing behavior of the storage device itself. That gives us a way to take the same filesystem design and evaluate it across different storage backends and embedded targets. Rather than asking only, “How fast did this run?”, we can start asking, “How much work did the software perform, what did the hardware contribute, and did the system behave the way we expected?”

By the end of the talk, attendees should have a practical way to think about predictable storage in embedded C++ systems and, more broadly, how to reason about resource limits, failure handling, ownership, hardware interfaces, and timing when predictability matters more than peak performance.

Building on the recent work of improving the quality of Sea of Thieves' codebase by upgrading from C++14 to C++20, this talk will focus on the work that has went into enabling warnings as errors on the game, and more.

Rare will discuss the motivations behind wanting to crank up the warning level, and to flick the "warnings as errors" switch after 10 years of development in their multi-million line Unreal Engine code base.

What were the challenges? How much effort did it take? Was it worth it? Did we find any bugs? Did we stop at just "/W4 /WX"? What warnings did we find the most useful? What warnings were deemed unhelpful? All of these questions and probably more will be answered throughout this session.

For thirty years, SIMD has been the preserve of experts. Writing the fastest C++ has meant hand-written intrinsics, locking code to one architecture, and parallel implementations maintained across every instruction set you ship to. Auto-vectorization can help, but optimizers may give up in complex scenarios where iteration independence isn't obvious. C++26 changes that by putting SIMD in the hands of every C++ programmer, bringing portable, expressive data parallelism into the standard library.

For the engineers who have spent decades writing intrinsics in telecoms, finance, HPC, and embedded systems, migration to std::simd is only worthwhile if it preserves the performance they have fought to achieve. Every cycle counts when code runs tens of thousands of times per second, for years on end, and a portable abstraction that costs ten percent is not a win. The bar for adoption is therefore high: the abstraction must be measurably cheap, the generated code must match hand-written intrinsics, and the tricks and techniques those engineers rely on must all be expressible in the library, not lost in translation.

This talk takes the practitioner's view, aimed squarely at the engineers who write real intrinsics code today and need to know whether std::simd can replace it. It starts with what modern SIMD hardware actually offers, grounding std::simd in real silicon. It then works through the main features of C++26's std::simd with worked examples drawn from the patterns that recur in production intrinsics code, accessible to programmers new to the library and detailed enough for intrinsics veterans to map against their own kernels with all their accumulated tricks and techniques. A look under the hood at our implementation shows how careful API design and aggressive use of hardware features make the abstraction as cheap as the target architecture allows, and how the library fills the gaps on weaker targets with implementations that an expert library author can write once on behalf of every user. The talk closes with a preview of the C++29 proposals being written now to close the remaining gaps, so that std::simd becomes a clear win even for the most performance-critical code.

Choosing cache-friendly data structures is a well-known optimization, but it's rarely the whole story. This talk goes deeper, exploring the hardware mechanics that dictate real-world performance and showing where significant gains are still left on the table.

We'll start from the ground up: what actually happens inside the cache hierarchy when your code issues a memory read or a software prefetch? Understanding the hardware lets us answer, when you should prefetch manually, and when you should trust the hardware prefetcher.

From there, we'll examine the invisible cost of multi-core C++. Cache coherency protocols (MESI/MOESI) can silently degrade performance through false sharing, RFO stalls, and coherency storms. We'll walk through how to diagnose these issues using hardware performance counters and how to eliminate them.

Additionally, we will contrast these behaviors across the data cache (DCache) and instruction cache (ICache), and analyze how Translation Lookaside Buffers (TLBs) impact overall memory read latency.

Finally, we'll tie it all together by combining hardware insight with application profiling data to arrive at practical strategies for low latency C++, packaged as an application-aware memory allocator.

For C++ developers building modular applications or performance-critical loops, modern architecture often forces a painful compromise: you either build heavily decoupled systems that thrash the CPU cache, or you write rigid, tightly coupled code. Distributed builds mask the compile-time symptom — but the underlying coupling bleeds into the runtime hot path.

This talk presents the Capability Routing Grid (CRG), an architecture that refuses this compromise. CRG enables a zero-registry plugin system where modules self-register at link time, and polymorphic dispatch is reduced to an O(1) branchless array lookup — with no central registry, no Init() function, and no runtime search.

Three independent pillars, each usable standalone:

Pillar 1 — Linker-Driven Discovery: Build a fully decoupled plugin system without central registries or Init() boilerplate. Modules self-register via standard C++ static initialization — entirely automatic in monolithic builds, and requiring a single explicit sync-point call at DLL load time.

Pillar 2 — State and Behavior Separation: Enforce a strict architectural boundary between pure data structs and stateless capability objects. This separation — not a framework — is what keeps the hot path flat. Type erasure is available as an optional cold-path utility for cross-boundary routing, but is never required for performance.

Pillar 3 — O(1) Branchless Dispatch: Map multi-dimensional contextual states into a single flat lookup table using basic polynomial math. Because this layout never changes, the CPU branch predictor and hardware prefetcher maintain peak efficiency.

The final payoff: by collapsing capabilities into raw function pointers, the system hits the memory bandwidth ceiling — 33 GiB/s sustained throughput, with a per-dispatch tax of approximately 1.5 nanoseconds.

Data-Oriented Design is defined from scratch. A brief hardware cache primer precedes every performance claim. The entire architecture compiles on C++17 — no language extensions, no experimental flags, on any mainstream toolchain. The audience will leave thinking, "I could have written this" — because they can.

Attendees will learn how to: - Build self-registering plugins with zero shared headers, using standard static initialization across both monolithic and DLL builds - Apply state/behavior separation as an architectural discipline — keeping capabilities stateless and the hot path free of virtual overhead - Replace vtable dispatch with a flat array lookup across N behavioral dimensions — O(1) regardless of dimensionality - Cache resolved logic as raw function pointers and call them directly, reaching memory-bound throughput

Building embedded systems wastes time on infrastructure instead of features. Before running application logic, developers lose hours bootstrapping init systems, wiring services, debugging startup failures, and fighting tooling never designed for constrained or early-boot environments. AEMBER is a developer-first PID1 (init system) that eliminates this overhead by providing a modern C++ runtime for process supervision, container orchestration, and service management - letting you focus on your application, not your plumbing.

This talk demonstrates how C++23 enables robust embedded systems without sacrificing performance. We'll explore std::expected for exception-free error handling, if consteval for compile-time optimization paths, and deducing this for zero-overhead policy classes. You'll see how monadic operations compose system calls into clean pipelines, and how modern C++ features build type-safe APIs for namespaces, cgroups, and process management.

Starting from main(), we'll trace AEMBER's architecture: how components compose, how errors propagate through std::expected chains, and how C++23 patterns enable embedded systems to be both safe and fast. We'll wrap up with a live demo showing AEMBER managing containers and services in real-time. You'll leave with concrete techniques for building maintainable embedded infrastructure using cutting-edge C++.

Scripting in a C++ game engine should not cost you the engine's native performance. This talk shows how C++26 static reflection and std::meta::substitute in particular can lift a scripting language's bytecode into C++ template structures that the compiler optimizes away entirely, collapsing the interpreter dispatch loop into the same machine code you'd write by hand. Scripting languages like AngelScript and Lua are invaluable in C++ engines: they give designers a fast iteration loop without rebuilding the engine. But they come with a paradox. The engine you chose for raw performance now spends cycles on every frame interpreting a slower language, juggling a software stack and checking types at runtime. We will walk through the technique step by step, starting from a plain bytecode interpreter and ending at a fully reflected program where a scripted sum(0..10) compiles to mov eax, 45; ret. Along the way you'll learn the core C++26 reflection primitives (^^, [: :], std::meta::substitute), how to assemble bytecode into structural templates like block<> and loop<>, and how these techniques generalize to embedding any stack or register based scripting language in your engine with zero runtime overhead.

For almost 30 years, Visual Studio has been a core part of the C++ developer's toolkit on Windows. This year, we're building on that foundation with investments across three themes: making the IDE faster and more responsive for large codebases, advancing compiler conformance and runtime performance, and integrating AI-powered workflows that help you debug, refactor, and optimize more effectively. Beyond the IDE, we'll show you how AI-powered command-line tools can become a natural part of your development process. This session combines demos and practical guidance so you can get the most out of these tools right away. Come with curiosity, leave with new techniques you can apply immediately.