8.2 High-Performance C++ for Trading

Basic Prerequisites: Low-Latency Systems Architecture and High-Performance C++ for Trading (single-page overview). Working knowledge of modern C++ (C++17) and the memory hierarchy. (these are the folder-level prerequisites for pages 02–06; page 01 states its own, smaller, entry requirements)

1. Intuition & Practical Objective

A strategy’s edge is a function of when you act, not only what you compute. In the tick-to-trade path, microseconds are money: a signal that is correct but slow is a signal someone else trades first, leaving you with adverse selection. High-performance C++ for trading is the discipline of making the hot path deterministic and cache-local - same work, measured in tens of nanoseconds, with no unbounded tail latency.

This folder is a hub. It (a) gives the fast lookup tables below (job #1 of this pillar: memorise the cost hierarchy and the layouts), and (b) routes you to six sub-pages that walk from raw intuition through memory, abstraction, failure modes, and tooling.

The one-sentence essence. “The CPU is not a calculator you feed numbers - it is a machine that stalls on memory. Speed comes from fitting the working set in cache, never allocating in the hot path, and never doing unpredictable control flow, and C++ wins because it lets you state those guarantees in the type system at zero runtime cost.”

The three laws of the hot path (each is a first principle, not a style preference):

1. Latency is dominated by memory, not arithmetic - a DRAM miss is ~200–300 cycles against a ~4-cycle L1 hit; the multiply you were worried about is a rounding error.
2. Determinism beats average speed - a fast mean with a slow tail loses to a slightly slower constant (see §4, the GC tail).
3. No hidden work - allocation, virtual dispatch, exceptions, and locking all hide OS- or allocator-level latency inside an innocent-looking line of code.

2. Mathematical Ground Truth & Lookups

Quick-reference lookup (job #1). All numbers below are order-of-magnitude figures from the memory hierarchy and from the runnable models in §3 / the sub-pages; each is reproduced by a verified script.

Notation: $f$ clock frequency (Hz), $c$ memory latency in cycles, $t$ latency in time. The conversion is one line:

The stall inequality (why layout is everything). For a working set of $N$ records of size $s$ bytes scanning one field, the number of 64-byte lines touched is

and the effective per-field traffic is $W=64L/N$ bytes. For the 24-byte order record of §3 (Array-of-Structures) the arithmetic collapses to a clean ratio:

Latency–throughput separation (Little’s law). Throughput and latency are different quantities; concurrency is the bridge:

A 2.00 µs tick-to-trade budget gives a pipelined ceiling of $1/2.00\mu \text{s}=500,000$ msg/s - but a single reaction still pays the full 2.00 µs of decay.

Alpha decay model (why every microsecond counts): if short-horizon edge halves every $h$ microseconds, the fraction surviving $t$ µs of reaction delay is

Allocation / growth cost (amortised ≠ bounded). Appending $N$ elements to a doubling vector copies

Critical caveat. These are cost magnitudes, not guarantees. Real numbers depend on microarchitecture, NUMA placement, and SMT contention - always re-measure on the target box (see 06 · Advanced Extensions).

3. Computational Implementation - the cost models

This hub ships one self-contained model that ties the whole folder together: a tick-to-trade latency budget with alpha decay and a pipelined throughput ceiling. Standard library only.

Read it as an engineering target: the strategy signal is 40% of the budget, so if profiling says a cache miss or an allocation is hiding there, the whole business case is at stake.

4. Failure Modes & First-Principles Breakdowns

Hub signposts - the folder’s fault analysis lives in 05 · Failure Modes & Practice. In one line each:

1. Hidden allocation in the hot path - a push_back, make_unique, std::function, or shared_ptr copy triggers an allocator lock; mean latency barely moves but the p99.9 spikes (this is the mechanism behind the $96\times$ GC tail below).
2. Cache-locality blindness - an OO layout (Array-of-Structures) makes the memory system fetch 3× the bytes it needs; the algorithm is “fast” but starves on lines.
3. Undefined behaviour - signed overflow, strict-aliasing violations, and data races are not “unspecified results”; they let the optimiser delete or reorder the code you were measuring, so the benchmark lies.

5. References

• Meyers, Scott: Effective Modern C++ (O’Reilly, 2014)
• Ghosh, Sourav: Building Low Latency Applications with C++ (Packt, 2023)
• Bryant & O’Hallaron: Computer Systems: A Programmer’s Perspective (CS:APP)
• Williams, Anthony: C++ Concurrency in Action (2nd ed., 2019)
• Fog, Agner: Optimizing Software in C++

6. Connected Graph Bridges

• Sibling topic: Low-Latency Systems Architecture (kernel bypass, CPU isolation, NIC tuning - the OS layer beneath this one)
• Sibling topic: Concurrency & Lockless Programming (what happens when the hot path spans threads)
• Sibling topic: Production Risk Guards & Kill Switches (the pre-trade check lives inside this latency budget)
• Base: Numerical Methods (floating-point precision and rounding, §02/§05)
• Sub-pages (in-folder): 01 From Zero · 02 Why C++ · 03 Memory & Cache · 04 Zero-Cost Abstraction · 05 Failure Modes · 06 Advanced Extensions

Beginner: start at 01 · Practitioner: start at 05

• Absolute beginner (zero systems background): 01 · From Zero - why latency is the business.
• Engineering core (undergrad / job-seeking): 02 · Why C++ → 03 · Memory & Cache → 04 · Zero-Cost Abstraction.
• Robustness & tooling (practitioner / graduate): 05 · Failure Modes → 06 · Advanced Extensions.
• Forward links: Lockless Programming · Hardware Acceleration & FPGA