CppCon 2026

In low-latency C++, correctness is table stakes. What separates good systems from great ones is predictability — the ability to hit your deadline not just on average, but at the 99th and 99.9th percentile, where real workloads live. Latency is a feature, and if you don't design for it explicitly, you lose it accidentally.

This talk is a practitioner's guide to writing C++ that behaves predictably under load, drawn from experience building and tuning low-latency systems on Microsoft's Azure Core platform. We start from the mental models that matter most — CPU-centric thinking, the latency stack from L1 to DRAM, and why minimizing work, unpredictability, and memory movement is the foundation of everything else — and then work through the layers of the stack where latency is won or lost in practice.

Through live demos and benchmark data on both x86 and ARM, we'll cover:

STL containers as latency contracts — why most latency bugs start with the wrong container, the real cost of dynamic reallocation, and the measurable wins from reserve() and custom allocators.

Memory layout and cache behavior — struct layout and alignment (and how it differs on x86-64 vs. ARM64), AoS vs. SoA trade-offs, hot/cold data separation, false sharing, NUMA, and TLB pressure.

Atomics vs. mutexes — when atomics actually lose to mutexes, why architecture and memory model dictate the answer, and how to choose between them in real code.

Threading and scheduling — fixed vs. dynamic thread pools, context-switch and migration costs, and why understanding the OS is half the battle.

Benchmarking and observability — why microbenchmarks lie, how to avoid measurement bias and jitter, why latency histograms beat averages, and why "absolute benchmark" is a myth.

You'll leave with a practical playbook for designing and measuring low-latency C++ systems, an honest understanding of why benchmarks from one machine rarely generalize to another, and a sharper instinct for the silent killers — allocations, branches, cache misses, and synchronization primitives — that don't show up in code review but do show up in production.

Production C++ code often hides small but deeply complex algorithms inside layers of engineering: APIs, lifetimes, error handling, integration, logging, and glue code. We test classes and systems, but rarely the algorithm itself in isolation.

Off-by-one errors and broken or missing invariants can survive extensive pre-production testing. Line coverage does not imply branch coverage. Branch coverage does not imply coverage of algorithmic corner cases. Testing through a wide public API often obscures the mathematical structure of the problem, making subtle bugs difficult to discover through multiple layers of abstraction.

This talk explores how to extract an "algorithmic core" from a larger component. Its correctness is fundamentally mathematical and largely language-agnostic rather than C++-specific.

Using examples such as substring matching, topological sorting variations, and lazy evaluation on trees, we will examine how problem corner cases differ from implementation corner cases, and how easily some of them are skipped.

We will discuss:

• Recognizing when an algorithm is entangled with boilerplate
• Extracting core logic without introducing accidental complexity
• What it takes to test algorithmic code in isolation
• Raising the level of abstraction to make reasoning easier without merely relocating complexity
• Using LLMs to assist in exploring and validating implementations
• Gradual rollout and comparison of competing implementations

Zero-cost abstractions are a foundational idea in C++, promising expressive, high-level code without sacrificing performance. However, developers often encounter unexpected costs when using modern abstractions in practice, even when the code appears idiomatic and well-designed.

This talk explores the assumptions behind zero-cost abstractions and examines what happens when those assumptions no longer hold. Through concrete examples drawn from modern C++ — including ranges and views, type erasure, allocators, and other common abstractions — we will examine how factors such as optimizer visibility, inlining boundaries, allocation behavior, and runtime flexibility influence performance.

This talk treats abstraction as a powerful engineering tool, examining the limits of its zero-cost guarantees in real-world systems. We will look at how seemingly small design choices can introduce hidden costs, why those costs are often difficult to spot through inspection alone, and how to recover performance without abandoning good design or readability.

Attendees will leave with a clearer understanding of when abstractions are truly zero-cost, how to recognize situations where they are not, and how to make informed tradeoffs between expressiveness, flexibility, and performance in modern C++.

Notifiers are a critical synchronization primitive in task-parallel programming systems such as Intel TBB and Taskflow, responsible for efficiently sleeping and waking worker threads as tasks become unavailable and available over and over again, directly impacting scheduler throughput and latency. Correctness here is non-negotiable: a single missed wakeup can significantly hamper the performance of an entire program. Yet writing strong unit tests for notifiers is notoriously difficult, because the bugs they target, lost wakeups, spurious wakes, race conditions, are timing-dependent, non-deterministic, and often only surface under specific thread interleavings that are hard to force reliably.

The problem is compounded in practice. Notifier implementations evolve constantly: small algorithmic tweaks, memory ordering changes, and refactors across systems demand a fresh round of carefully constructed tests. This is tedious, expertise-heavy work that takes a lot of time and engineering effort. In this talk, we explore using Large Language Models (LLMs) to automate the generation of the unit tests for notifiers. Specifically, we will demonstrate how LLM-generated tests, guided by proper prompts can systematically stress the two-phase wait protocol across Notifiers in Taskflow. We will show this in a widely used Notifier implemented in Taskflow. We are able to find an undiscovered bug that has been existing in the project.

From our very first algorithms class, we are taught a simple rule: a better Big-O complexity means a faster algorithm. We spend years mastering asymptotic analysis, memorizing complexity tables, and losing sleep over worst-case scenarios. Big-O becomes a mental shortcut for “good” and “bad” code.

But the real world doesn’t run on whiteboards.

Modern performance is shaped far more by hardware realities than by asymptotic notation alone. CPUs have deep cache hierarchies, wide vector units, speculative execution, and memory systems that punish the “theoretically optimal” solution. GPUs thrive on massive parallelism where simple linear work can outperform asymptotically superior algorithms. Even on regular CPUs, cache-friendly linear scans often beat clever sub-linear approaches that fight memory latency.

In this talk, we will challenge the traditional Big-O mindset. We’ll look at classic algorithms through a modern lens and explore how hardware-aware designs cache-efficient layouts, SIMD/AVX vectorization, and parallel execution models can outperform algorithms with “worse” theoretical complexity. You’ll see why a higher Big-O algorithm can be faster, more scalable, and more predictable in practice.

The goal is not to dismiss Big-O, but to put it back in its proper place: as a tool, not a truth. By the end of this talk, you’ll think differently about performance and start writing code that works with the hardware, not against it.

Range views enable a "no raw loops" style of programming — not as a matter of taste, but as a pragmatic way to reuse well-tested algorithms to write code faster, express intent clearly, and avoid common bugs. In practice, however, developers often run into issues that may lead them to abandon ranges altogether: - unintuitive behavior and surprising limitations - slower compilation and runtime performance compared to raw loops - high complexity when implementing custom views

In this talk, we'll distill the core design choices behind these problems — and the alternatives that avoid them. In particular, we'll compare: - iterators and indices - external and internal iteration - transformations of nested views that overcome limitations of internal iteration

Attendees will leave with practical insights for designing and using range abstractions, along with examples of libraries that embody these ideas.

Every mature codebase carries history and technical debt. The challenge is modernizing without stopping the world or introducing big re-write failure risks.

In this talk, we’ll explore how to modernize legacy C++ codebases incrementally using a mix of deterministic code transformations and AI-assisted refactoring .

After delving into some of the common problems with legacy modernization, we'll start tackling the simple "boring" stuff that deliver huge leverage of changes via clang tooling . These represent repeatable, deterministic reviewable upgrades that can be automated and applied at scale.

Then we can look at more difficult transformations that can be AI assisted with more aggressive transformations including API improvements and how to prevent it going off the rails. This will be backed by Compiler diagnostics, static analysis and testing to keep changes maintainable and correct .

The goal is not to replace engineering judgment, but to accelerate it: turning modernization into a continuous, low-risk workflow instead of a disruptive project.

Attendees will leave with a repeatable playbook for modernizing legacy codebases incrementally, safely, and at scale—using the right tool for each class of change

Tooling Track sessions are sponsored by Optiver.

Starting from the simple objective of writing an optimized lexer we will grapple with their fundamental performance factor: branch prediction. We will investigate how lookup tables can improve (or hurt) the CPUs prediction capabilities with some unexpected results. Over time our design evolves by combining parsing and lexing into a single step in a way that is as fast as just a standalone lexer. A central aspect of the design will be a primitive parsing state machine from which the parser source code is generated.

After the talk attendees will have a better understanding of some advanced branch prediction techniques and should have some new ideas for their present or future parsing endeavors.