CppCon 2026 for High-Frequency Trading: The Complete Report

CppCon 2026 ran from 12 to 18 September in Aurora, Colorado. Roughly 150 sessions were on the programme. This report covers every one of them that carries something useful for people who build trading systems, and it is organised so you can read the part you need and skip the rest.

I went through the full published schedule day by day rather than the handful of talks that made the rounds afterwards. What follows is the result: the keynotes, the standards work, the concurrency and cache material, the measurement methodology, the wire-protocol sessions, and a few talks filed under game development or robotics that turn out to be about our problems wearing someone else’s clothes.

One finding shaped how I wrote the rest. This was, to a degree I did not expect, a trading-industry conference.

Table of Contents

• Part 1: Who was actually in the room
• Part 2: The keynotes
• Part 3: What C++26 and C++29 change for latency
• Part 4: Lock-free, locks, and the argument nobody settled
• Part 5: Cache, memory, and the hardware underneath
• Part 6: Measurement, benchmarking, and compilers
• Part 7: Wire protocols, parsing, and decimal money
• Part 8: What 26 million lines of C++ looks like
• Part 9: Pricing and risk mathematics
• Part 10: The talks filed under something else
• What to do with all this

---

Part 1: Who was actually in the room

Start with the sponsor board, because it tells the story faster than the schedule does.

Susquehanna took Platinum. Gold went to Bloomberg, Citadel Securities, Hudson River Trading, Jump Trading, Optiver, and Boost. Hudson River Trading also sponsored the conference video programme. Optiver sponsored the tooling track. Qube Research and Technologies hosted a community lunch. Seven Research, which describes its own work as spanning “low-latency C++, simulation, high-performance computing and the tools that move quantitative ideas from research into production,” sponsored the networking breakfast. Susquehanna hosted the presenters’ banquet.

Compiled from the CppCon 2026 sponsor page and the published session listings.

Now the programme. Bjarne Stroustrup, who created C++, joined Susquehanna this year as a Technical Fellow and gave the opening keynote. Herb Sutter, chair emeritus of the ISO C++ committee, is a Technical Fellow at Citadel Securities and gave the closing keynote. Timur Doumler, an active committee member and a former CppCon programme chair, also works at Citadel Securities and gave both a keynote and a technical session. Kris Jusiak, another Citadel Securities engineer, presented on benchmarking. Andy Webber of Susquehanna presented on binary protocols. Matt Godbolt, who built Compiler Explorer, works at Hudson River Trading and gave a talk on compiler optimisation.

Below the headline names the pattern holds. Radoslav Zlatev and Justin Zaglio came from Tower Research Capital. Sanchit Gupta from Graviton Research Capital. Sarthak Sehgal from Maven Securities, an options market maker. Anmol Singhal spent five years as a quantitative developer at Goldman Sachs and IMC Trading. Jody Hagins is a director at LSEG’s MayStreet. Bloomberg fielded at least eight speakers across low-latency C++, lock-free scheduling, branch prediction, heap behaviour, zero-cost abstractions, and async execution.

Even the Boost sponsor copy names us directly, listing the organisations that depend on the libraries: “Aerospace, defense, high frequency trading systems, video games, large scale database engines.”

The feature set arriving in the next two versions of the language is being shaped, right now, by people who spend their working hours on the same latency and correctness problems your team has. That is the useful read here, not the prestige of the guest list. Reading what the committee prioritises has become a cheap way to see two or three years down your own roadmap.

---

Part 2: The keynotes

Stroustrup on profiles

Stroustrup opened on Monday 14 September with “Profiles for simplicity and guarantees.” The strategy he described is what he calls subset of superset: extend the language by adding libraries, then use static analysis to remove the undesirable uses, without damaging expressiveness or efficiency. Profiles are the framework that lets a codebase require or suppress specific sets of guarantees.

He demonstrated eliminating two bug classes, uninitialised objects and container invalidation, and the claim attached to that demonstration is the one worth remembering: “Both with zero run-time cost.” Where runtime checks are genuinely needed, the argument goes, static analysis can be used to minimise how many survive.

Susquehanna’s sponsorship announcement, published on cppcon.org on 7 August 2026.

Sutter on efficiency, safety, and AI

Herb Sutter closed the conference. His abstract contains the cleanest available timeline of where the standard stands: the committee completed technical work on C++26 in March 2026, and in June voted the first additions into the C++29 working draft.

Three of those items matter to us. C++26 brings reflection and an initial round of memory-safety hardening, plus std::simd and std::execution in the library. C++29 gains a new Annex cataloguing every case of core-language undefined behaviour, described as the first step toward addressing it systematically rather than one paper at a time. And the draft profiles for portable memory-safety guarantees are being prototyped now, targeted at C++29.

His framing of why this matters commercially is worth quoting, because it is the argument a CTO can take to a board: C++ is adding expressive power and fixing weaknesses “at exactly the moment when chip supply and power budgets are raising the value of what people came to C++ for in the first place: control over memory layout (space) and deterministic performance (time).”

Doumler on what changes day to day

Timur Doumler’s keynote covered the four C++26 features that change ordinary practice: std::simd, contract assertions, the sender and receiver execution library, and reflection. He deliberately avoided a firehose survey in favour of a handful of features examined properly.

Kirk on where objects live

Laurie Kirk, a researcher at Google, gave a keynote on object residency that is more relevant to trading infrastructure than its title suggests. Her opening line is the hook: “Random Access Memory is what you buy when you don’t know what your program will do next.”

Her argument is that C++ has grown vocabulary for ownership through smart pointers and for lifetime through RAII, but has no vocabulary at all for residency, meaning which tier of memory an object should live in. Alternative tiers stopped being speculative once DRAM became expensive: CXL memory pools, far memory, and high-bandwidth flash are now real options. Operating-system approaches such as Meta’s TPP and compiler approaches such as OBASE handle this transparently, which she argues makes them “blind by design,” because they cannot predict intent. Her talk introduced an open-source C++26 residency library built on reflection and annotations that puts placement back in the developer’s hands.

If your working set has outgrown what DRAM economics comfortably allow, this is the talk to watch when video appears.

The language designers panel

The conference also ran its first keynote panel: Stroustrup alongside Guido van Rossum, who created Python, and Mads Torgersen, the lead designer of C#, moderated by Emma Tracey.

The panel announcement. Note the survey figures in the second half.

One number from the announcement is worth keeping. In the Standard C++ Foundation’s annual developer survey, asked which other languages they use, C++ programmers name Python first, “consistently around 70 percent,” ahead of C at “consistently around 45 percent.” For anyone still treating the Python layer of a research stack as a second-class concern, the people writing your compiler do not see it that way.

---

Part 3: What C++26 and C++29 change for latency

This is the section to read if you track the standard from a distance and want to know what actually lands on your desk.

std::simd

Portable vectorisation becomes a standard-library facility rather than compiler-specific intrinsics or a third-party dependency. Ruslan Arutyunyan and Daniel Towner of Intel presented on it, and stated the adoption bar plainly: “a portable abstraction that costs ten percent is not a win.” Their talk worked through the library against patterns taken from real production intrinsics code and showed an implementation reaching close to the hardware ceiling.

The practical consequence is narrower vendor lock-in on a class of optimisation that trading shops have historically hand-rolled per compiler and per target CPU.

Reflection

Reflection is the C++26 feature with the widest downstream effect, and two separate trading-firm sessions put it to work on the same problem: binary wire protocols. More on that in Part 7.

Contract assertions

Doumler gave a dedicated session on contracts beyond the keynote. C++26 ships a deliberately minimal foundation: three assertion kinds, four evaluation semantics, and a user-replaceable violation handler. The four semantics are worth memorising because they are what make contracts usable on a hot path at all: ignore, observe, enforce, and quick-enforce.

Here is the shape of the idea, written as an illustration rather than taken from anyone’s slides:

// Illustrative only. The point is that the same assertion can be
// compiled out entirely, logged, or made fatal, per build.
double mid_price(const Book& b)
    pre (b.best_bid() > 0.0)          // checked in test builds
    pre (b.best_ask() > b.best_bid()) // ignored in the latency build
{
    return 0.5 * (b.best_bid() + b.best_ask());
}

You state the invariant once, in the code, and choose per build whether you pay for it. That replaces the usual mix of assertions, comments, and tribal knowledge. Doumler also previewed what is being designed for C++29 and beyond: contracts on virtual functions, grouped evaluation semantics, postconditions that can reference earlier state, and eventually class invariants.

John Lakos, who spent 2001 to 2026 at Bloomberg as a senior architect, argued in a separate session that contracts are the mechanism that makes undefined behaviour tractable without splitting the language into safe and unsafe dialects, letting teams spend runtime checking “where it is affordable or most valuable.”

std::execution, senders and receivers

The sender and receiver model gives C++ a standard vocabulary for asynchronous and parallel work. Alistair Fisher and Ivy Zhang of Bloomberg, who work on pricing and execution-management infrastructure respectively, presented it as the answer to callback-driven designs, with one property that matters for correctness: “std::execution enforces structured lifetimes so that async work cannot silently outlive its scope.”

Robert Leahy, whose background is in latency-sensitive financial systems, went further in a session on async RAII, tackling how to keep deterministic teardown when the teardown itself is asynchronous. His diagnosis of the common shortcut is exact: “just launch another task in the destructor” turns deterministic lifetime management into unstructured background activity.

Hazard pointers, out-of-thin-air values, and sockets

The annual low-latency standards update came from Paul E. McKenney, who maintains RCU in the Linux kernel, Maged Michael, who invented hazard pointers, and Michael Wong, who chairs the C++ Direction Group. Three things came out of it.

First, techniques for controlling C++26 hazard-pointer reclamation, so retirement overhead can be offloaded to asynchronous executors and thread latency stays predictable. If you use hazard pointers for lock-free reclamation, this determines whether reclamation shows up in your tail.

Second, a result rather than a proposal: they have proven that out-of-thin-air values, a long-standing hole in the formal memory model, “cannot happen on real-world production-quality computer systems.”

Third, networking. Their retrospective was titled “Twenty-One Years Without Sockets,” and the news is that networking is finally a C++29 priority under the Direction Group’s P5000.

The smaller changes that matter anyway

Sandor Dargo’s survey of the less-publicised half of C++26 is the one to read if you are planning a toolchain upgrade. Expanded constexpr including compile-time exceptions, a stricter erroneous-behaviour model for indeterminate values, standard-library hardening, std::function_ref, pack indexing, and freestanding library growth. His summary of hardening is the relevant line: C++26 “takes steps toward making incorrect usage easier to detect and harder to ignore, without sacrificing performance.”

Marc Gregoire’s tour flagged std::inplace_vector, a resizable vector with fixed capacity and therefore no heap allocation, which is an obvious fit for hot-path buffers:

// Fixed capacity, no allocator, no heap traffic on the hot path.
std::inplace_vector<Order, 64> batch;
Order order;
while (batch.size() < batch.capacity() && feed.try_pop(order))
    batch.push_back(order);

Darijo Topic put numbers on the cost of hardening in an embedded context, which is the closest thing anyone offered to a measured safety tax: hardened standard-library containers with bounds checking at “0.3% overhead,” and stack-protection options costing “single-digit bytes.”

---

Part 4: Lock-free, locks, and the argument nobody settled

Two sessions took on concurrent queue design directly, and they land in different places. That disagreement is the most useful thing the conference produced for us, so it is worth laying out properly.

My reading of the two sessions. The quoted phrases are from the speakers’ own published abstracts.

Singhal on topology

Anmol Singhal, who spent five years as a quantitative developer at Goldman Sachs and IMC Trading, gave a bottom-up treatment of the four canonical topologies: single and multiple producer crossed with single and multiple consumer. He dissected Dmitry Vyukov’s MPMC ring buffer, the intrusive MPSC queue, and the Michael-Scott linked-list queue.

Three claims from that session are worth carrying around. Padding with alignas(std::hardware_destructive_interference_size) “can be the difference between 100ns and 10ns throughput.” An MPMC queue “can outperform MPSC under certain producer counts,” which is counterintuitive if you assume a matched topology always wins. And using seq_cst where a weaker ordering would do “can quietly halve your throughput.”

The padding point is the one most codebases get wrong, and it is cheap to check:

// Producer and consumer indices on separate cache lines.
// Without this, every producer write invalidates the consumer's line.
struct alignas(std::hardware_destructive_interference_size) Head {
    std::atomic<std::size_t> value{0};
};
struct alignas(std::hardware_destructive_interference_size) Tail {
    std::atomic<std::size_t> value{0};
};

I have spent most of my career on the specifying side of this decision rather than the implementing side. When I set the ring-buffer constraint on a system I built, it was one line: a lock-free ring buffer, zero heap allocations. The half that did the work was the enforcement. An allocation gate ran on every commit and rejected anything that put a foreach loop or a captured closure on the hot path, which meant the constraint could not quietly erode release by release. A queue decision with nothing enforcing it becomes a queue decision nobody remembers making.

Pikus on contention

Fedor Pikus, a Fellow at Siemens EDA, argued something close to the opposite, and he is explicit that he is revising his own earlier position: he notes he has given several talks explaining how and why to go lock-free.

His case, built on hardware performance counters, splits by contention. Under high contention a well-written lock consistently outperforms lock-free atomics and CAS loops, because systematic backoff batches cache-line ownership and protects the shared interconnect. At low contention lock-free code decisively outperforms spinlocks, and for a reason most people get backwards: an uncontended spinlock is not free, because the implicit synchronisation it imposes is unfavourable to out-of-order pipelines, while a single atomic read-modify-write is not.

He put both findings into one design, an MPMC queue built on a dual-domain structure that segregates the contended path from the uncontended one, and benchmarked it across Intel, ARM server parts including Graviton and Grace, and Apple’s M3. His conclusion about hardware is the part that travels furthest: “ARM vs x86” is the wrong axis entirely, and what matters is the chip’s target market, not its instruction set.

He also drew the boundary of his own claim, which is why the talk is credible. Systems that strictly require progress guarantees, meaning deadlock avoidance, priority inversion, or signal-handler safety, still need traditional lock-free programming. In his words, it has not died, it has relocated.

Pikus’s abstract, stating the case against reaching for lock-free code on a contended path.

Leahy on reasoning rather than recipes

Robert Leahy’s session on synchronisation attacks the underlying problem: engineers memorise acquire and release recipes instead of deriving them. He names the failure mode precisely as “cargo-cult synchronization, where atomic operations are selected mechanically without a clear understanding of what information is actually being propagated between threads.” He then derives the real requirements for reference counting, a multi-producer publication structure, and a concurrently mutated intrusive doubly-linked list.

If your team argues about memory ordering by citing precedent rather than reasoning, this is the corrective.

Gurschi on coalescing a flood

Maxim Gurschi, a senior engineer on Bloomberg’s FXGO team, presented a lock-free timer scheduler built for exactly the problem of market data arriving faster than anything downstream needs it. The design is single-producer, multiple-consumer, and its unusual property is what he calls reverse work stealing: consumers proactively give work away and go idle, deliberately packing work onto as few cores as possible rather than spreading it evenly, which cuts idle spinning and improves cache locality.

The numbers are the most striking throughput figures published at the conference: producer throughput of approximately 50 million scheduled tasks per second, consumer processing approaching 700 million tasks per second, and migrated work items kept below 1% in typical workloads.

Gurschi’s abstract. The scheduler exists to coalesce market-data updates for human-facing displays.

Shilon on why any of this works

Ofek Shilon, a senior developer at Speedata and one of the Compiler Explorer maintainers, gave the hardware talk that sits underneath every session above: cache coherence protocols, store buffers, cache invalidation queues, and the in-processor load-store queue, and what fences and read-modify-write instructions actually do on x86-64 versus ARM and RISC-V, which he notes are sometimes dramatically different.

His framing of the gap he is closing will be familiar: explanations of std::memory_order usually end at “the processor does weird things” and “think about it as if.”

---

Part 5: Cache, memory, and the hardware underneath

Gupta on the cost of caching

Sanchit Gupta, a low-latency C++ developer at Graviton Research Capital, gave the session that goes furthest past the usual advice about cache-friendly data structures. He covered when to prefetch manually against trusting the hardware prefetcher, how MESI and MOESI coherency protocols “can silently degrade performance through false sharing, RFO stalls, and coherency storms,” how instruction and data cache behaviour differ, and how the TLB affects read latency, closing on an application-aware allocator strategy.

Gupta’s abstract. Note that coherency storms are diagnosed through hardware performance counters, not inference.

Sehgal on alignment

Sarthak Sehgal, a tech lead at Maven Securities, covered memory alignment from the ground up: how CPUs actually read memory, what unaligned access costs, how compilers lay out members and how reordering them shrinks a struct, and the alignas, alignof, and std::align facilities. He also covered packed structs for network protocols, including the undefined-behaviour risk they carry, which is Part 7’s subject.

Dathskovsky on Big-O

Alex Dathskovsky, a director of software engineering at Speedata, argued that asymptotic complexity is a poor predictor of real speed once caches, vector units, and speculative execution are involved. His concrete case is one most trading engineers have hit: “cache-friendly linear scans often beat clever sub-linear approaches that fight memory latency,” and “a higher Big-O algorithm can be faster, more scalable, and more predictable in practice.”

Arroyo on memory that never comes back

Nicolas Arroyo, a software architect at Bloomberg with two decades in low-latency financial infrastructure, presented on heap pinning, which is a failure mode most leak detectors will never show you. Long-lived and transient allocations interleave until resident set size “refuses to shrink even after significant deallocations,” leading eventually to thrashing and out-of-memory kills. His remedy is allocator-aware objects and std::pmr resources segregating allocations by lifetime, so memory actually returns to the operating system.

For any process that runs from open to close and is restarted nightly out of superstition rather than diagnosis, this is the talk that explains the superstition.

D’Souza on branch prediction

Michelle D’Souza of Bloomberg ran a game-show format session where the audience guessed which of two variants was faster before seeing the hardware counters. The substantive finding is the useful one: branchless code sometimes performs worse, and behaves differently across architectures.

Carpenter on hash maps

Kevin Carpenter’s session on std::unordered_map covered hash quality, collision handling, and load-factor-triggered rehashing, with a warning that belongs on a wall somewhere: “An average-case O(1) can quickly degrade to a catastrophic O(n) without warning.” Rehash spikes are a classic hidden source of tail latency in symbol tables and order lookup structures.

---

Part 6: Measurement, benchmarking, and compilers

Acharya on predictability

Sampad Acharya, a senior quant developer in fixed income trading at Bloomberg, gave the session closest to a general playbook. His framing is the discipline check: correctness is table stakes, and what separates good systems from great ones is predictability, meaning hitting the deadline “not just on average, but at the 99th and 99.9th percentile, where real workloads live.” He adds the sentence that should end most latency arguments: “Latency is a feature, and if you don’t design for it explicitly, you lose it accidentally.”

The session treats STL containers as latency contracts rather than conveniences, works through layout, false sharing, NUMA and TLB pressure, compares atomics against mutexes on measured behaviour rather than reputation, and covers why microbenchmarks lie. His conclusion on portability of results is blunt: the “absolute benchmark” is a myth, and benchmarks from one machine rarely generalise to another.

That matches the order I work in before touching anyone’s architecture. Years ago I sat with the CTO of a small proprietary high-frequency firm whose Python and C++ processes were scattered across the organisation, with the C++ in the sensitive path. My read was that parts of it needed a large refactor. We built the benchmark first, on the code they already had, so that afterwards we could say what a change had actually done. Then it became a loop: measure, improve, measure again. They reached under 100 microseconds, software only, and stopped there because that was enough for what they were doing.

Another engagement ran that discipline from the opposite end, governing a build instead of a refactor across a twelve-month review cadence. The benchmarking framework with deterministic replay went in beside the co-location and OMS decisions rather than after them. That system reached order-to-acknowledgement round-trips under 100 microseconds, three times the throughput of the firm’s own initial prototype, and 99.97 percent uptime across its first six months live. The firm is not named, by agreement, but the engagement and those figures are written up at hftAdvisory.com. The replay harness is what made each of those numbers a measurement rather than a claim.

Set against Acharya’s session, the point of overlap is the sequencing. He is describing what to measure; the engagements above are about measuring it before you have an opinion to defend.

Jusiak on removing the human from benchmarking

Kris Jusiak, a lead software engineer at Citadel Securities, presented an automatic benchmarking technique that combines symbolic execution of hot regions with microarchitectural state randomisation, wired into Linux perf. The goal is statistically reliable, bias-free benchmarks, on the premise that manual benchmarking hides its own biases. He grounds it in hardware performance counters, top-down microarchitecture analysis, and processor tracing.

Gomez on making regressions fail the build

Kevin Gomez presented a C++23 framework built on GoogleTest that treats latency, throughput, and contention benchmarks as first-class tests with built-in statistical analysis, medians, percentiles, and coefficient of variation, plus adaptive thresholds and CI integration that fails builds on regression. Five profiler backends sit behind one flag: perf, gperftools, bpftrace, RAPL, and callgrind.

This is the thing most trading firms build badly in-house.

Brumer on profile-guided optimisation

Eric Brumer, an engineering manager on MSVC, covered compiler optimisations and introduced sample-based profile-guided optimisation, which tunes from runtime characteristics without requiring an instrumented build. The stated gain is “typically in the 5-15% range across real world native codebases.” For a technique that needs no code change, that is worth an afternoon of somebody’s time.

Godbolt on what compilers actually do

Matt Godbolt, who works at Hudson River Trading and built the tool most of us check codegen with, distilled a 25-day series on compiler optimisations into one talk covering where optimisers are surprisingly good, where they are stubbornly bad, and how that has shifted. His own summary is the honest one: “Some surprised me. A handful caught me out completely, and some even were compiler bugs!”

Drakeford on getting the same answer twice

Andrew Drakeford, whose background includes two decades building high-performance calculation libraries and trading systems, presented reproducible parallel reduce and scan implementations that match or beat conventional library performance. The trick is specifying the exact expression computed rather than fixing the execution schedule, so thread count, vector width, and blocking can vary without changing the numeric result. He also covers the hidden sources of nondeterminism: FMA contraction, denormals, the floating-point environment, and transcendental approximations. The relevant standards papers are P4016R0 and P4229R0.

If you have ever had a risk number fail to reproduce and lost a day to it, this is the mechanism.

---

Part 7: Wire protocols, parsing, and decimal money

Three sessions converged on the same problem from different directions: getting bytes off a wire and into typed objects without undefined behaviour and without copying.

Reflection against protocol definitions

Andy Webber of Susquehanna asked whether C++26 reflection can take a binary protocol definition written in ordinary C++ terms and generate the components that interact with it, covering the techniques, gotchas, and limitations. He notes this class of protocol exists “all around the world from financial market data formats to custom hardware interaction.”

Fanchen Su approached the adjacent question: whether a type can be safely sent across a boundary as raw bytes at all. His proposal builds a compile-time layout signature covering architecture and endianness, leaf types, sizes, alignments, offsets, bit-fields, and pointer markers, then gates byte transfer on that signature matching across every target ABI. He is careful about scope: “The claim is intentionally narrow: representation compatibility, not semantic compatibility or schema evolution.”

For anyone maintaining a dozen exchange adapters by hand, these two sessions are the most directly actionable pair at the conference.

Type punning without the undefined behaviour

Lieven de Cock’s session names our exact pattern: “those bytes that came from the network, really are an array of integers, array of coordinates.” He surveys why most reinterpret_cast punning is undefined behaviour, covering alignment, strict aliasing, and object lifetime, then walks the conforming alternatives: memcpy, memmove, bit_cast, start_lifetime_as, and launder. Andreas Fertig covered the same facility from the embedded side.

The modern form is short enough to adopt immediately:

// The bytes are already in the right layout; this begins the
// object's lifetime without copying and without UB.
auto* hdr = std::start_lifetime_as<MarketDataHeader>(buffer.data());
const auto seq = hdr->sequence_number;

Parsers as state machines

Torben Thaysen built an optimised lexer and parser starting from branch-prediction behaviour, showing where lookup tables help and where they hurt prediction, then merged lexing and parsing into a single pass driven by a generated state machine. The payoff he reports is that the combined design ends up “as fast as just a standalone lexer.” That is the same technique behind fast ITCH and FIX decoders.

Decimals, because money is not binary

Matt Borland introduced Boost.Decimal, a header-only implementation of IEEE 754 decimal floating point, targeted at finance, billing, and regulatory reporting where binary rounding error is unacceptable. It opens with the question everyone has asked at least once: “Why does 0.1 + 0.2 not equal 0.3?” The library is tested natively on x86-64, ARM64, and s390x, and the design deliberately “sacrificed” floating-point exception flags to keep constexpr working.

---

Part 8: What 26 million lines of C++ looks like

Radoslav Zlatev, a principal engineer at Tower Research Capital, gave the session with the most unusual content at the conference, because he disclosed numbers that firms of his kind normally do not publish.

His abstract describes a production HFT environment where “a single core infrastructure repository may contain 26+ million lines of C++ across 100K files, organized into 250+ distinct subprojects: exchange gateways, feed handlers, protocol codecs, shared risk libraries, replay frameworks, and strategy infrastructure.” That foundation is continuously modified, rebuilt, tested, and deployed “by engineering teams across five time zones and more than 40 trading teams, each maintaining their own siloed multi-million-line client systems in C++, Rust, and Python.”

The scale disclosure, in Tower Research Capital’s own words.

His argument is that at this size the problems change category. Dependency boundaries, build-graph stability, toolchain consistency, integration latency, ownership, and deployability stop being secondary concerns and become first-order constraints, and conventional best practice stops working. His prescription is to reduce components to a minimal, composable ground state.

Two other sessions rhyme with this. Florent Castelli showed how build-graph shape determines incremental build time, with deep critical paths that “starve parallelism even on a 128-core machine.” Damien Buhl presented automatic splitting of translation units for parallel compilation. Neither is a latency topic, and both determine how fast your team can iterate on one.

---

Part 9: Pricing and risk mathematics

Automatic differentiation

Jorg Lotze, technical lead at Xcelerit and creator of the open-source XAD library, gave the session with the clearest cost numbers at the conference. Reverse-mode automatic differentiation computes exact gradients with respect to thousands of inputs in roughly the time of a single function evaluation, which is why it underpins sensitivity calculation. The naive implementation, recording every arithmetic operation onto a tape, “easily introduces 50-100x overhead, and most of that has nothing to do with calculus.” It is heap allocation per operation, cache misses walking the tape backward, branch mispredictions at chunk boundaries, and recording entries for operations where no operand is even being differentiated.

A series of techniques brings that “down to around 4x on production code in finance.” Two carry most of the improvement: a chunked arena allocator with cache-line alignment and branch-prediction hints that reduces the recording hot path to a pointer bump and a store, and expression templates that collapse an entire right-hand side into one tape push. He benchmarks each technique separately across “four numerical workloads ranging from 8 to 161 sensitivities.”

Lotze’s abstract, with the 50-100x and 4x figures in context.

Read as a budget line, the gap between those two numbers is a 12 to 25 fold reduction in the compute a full sensitivity run consumes. For a desk revaluing a book intraday, the same arithmetic reads as how many revaluations fit inside the window before the market has moved underneath the answer.

---

Part 10: The talks filed under something else

A few sessions were programmed under game development, robotics, or compilers, and are about our problems anyway.

Aryan Naraghi optimised chess move generation from “20+ nanoseconds” to “~1 nanosecond” using magic bitboards, a perfect-hashing technique, comparing the hardware PEXT instruction against a portable software path. Nanosecond-budget perfect hashing is directly reusable for symbol and instrument lookup.

Cyril Tissier of Ubisoft presented a plugin architecture where modules self-register at link time and polymorphic dispatch collapses into a branchless array lookup rather than a vtable, reporting “33 GiB/s sustained throughput” and “a per-dispatch tax of approximately 1.5 nanoseconds.” That is a template for order routing.

Tom Tesch built a Game Boy emulator running Tetris at “roughly 100 times original speed, about 6,000 frames per second,” and describes the work correctly: “This is not a victory-lap performance talk. It is a measurement-driven engineering investigation.”

Ken Jin Ooi described CPython 3.14 adopting [[musttail]] for its interpreter loop, reporting a “2%–15% performance improvement” over the computed-goto approach, with a draft C++29 proposal behind it. Tail-call-enforced dispatch is the same technique used in hand-tuned event loops.

Aditya Kumar discarded the abstract syntax tree in a compiler frontend in favour of flat contiguous arrays, targeting pointer-chasing cache misses and lock contention during parallel analysis. The patterns transfer to any graph-shaped structure on a hot path.

John Pavan of Bloomberg made the transfer explicit in a session on idiomatic code, observing that embedded engineers adopted CRTP with tagged-union dispatch to avoid the heap, while “high frequency trading firms, driven by latency rather than memory constraints, adopted the same combination to avoid indirect branches and allocator contention.” He notes data-oriented design is making the same journey now, “moving from game engines… to financial systems, where the same CPU architecture imposes the same penalties.”

---

What to do with all this

Five questions, each answerable without commissioning new work.

1. Which queue topology does each hot path actually use, and does it match its contention regime? Singhal’s axis and Pikus’s axis are independent, and your order-entry path and market-data fan-out path rarely sit in the same place on both. If one shared queue template covers both, one of them is paying for it.

2. Does your latency reporting show percentiles, or an average wearing a percentile’s clothes? Acharya’s line is the standard: the 99th and 99.9th are where real workloads live. A mean tells a risk committee nothing.

3. Has anyone checked the padding? alignas(std::hardware_destructive_interference_size) on your producer and consumer indices is a ten-minute change, and the reported difference is between 100ns and 10ns.

4. If you compute sensitivities in C++, which side of the 50-100x to 4x gap are you on? That is a measurable fact currently sitting unmeasured in most risk engines.

5. Are std::simd, reflection, contracts, and profiles on a near-term roadmap, or filed as standards trivia? Given who is writing them and where they work, that filing decision deserves a second look.

Then the one that is not a question. Whatever you measure, wire it into the change process so a later merge cannot silently undo it. On the engagements where I have built a benchmark before a refactor, that wiring is what made the result durable, and the absence of it is what quietly returns a system to where it started.

The takeaway

The through-line of CppCon 2026 is that the centre of gravity in C++ standardisation has moved toward people who ship trading systems, and the features moving through C++26 and C++29 are aimed at the problems this industry has been solving by hand for twenty years.

The part nobody resolved is worth more than the part everybody agreed on. Singhal and Pikus point trading architects toward opposite defaults, both brought benchmarks, and both are describing real systems. The answer for most systems is that each is right in a different part of the same box, and the only way to find out which is which is to measure your own hot paths on your own silicon.

When a measurement like that contradicts what a team believed about its own system, the useful next step is usually an outside read of the architecture around it, which is the work I do at hftAdvisory.com.

---

Compiled from the complete CppCon 2026 session listings at cppcon2026.sched.com and the announcements and sponsor pages at cppcon.org, retrieved 22 September 2026. All quoted phrases are from speakers’ own published abstracts and bios. Session images are screenshots of those pages. Code samples are my own illustrations of the concepts discussed, not excerpts from any speaker’s slides. Header photograph by Albert Stoynov via Unsplash.