C++ performance engineering,
measured.

Sorted vs unsorted: a branch-prediction deep dive

Same code. Same data. Three variants. Why does one run 7× faster — and why does the branchless version close most of the gap without sorting anything?

False sharing: a 15× throughput gap from two missing bytes

Same algorithm. Same fill stream. Same machine. The only variable is struct layout — and it dominates.

Black-Scholes: same model, four implementations, ~10× spread

Polynomial approximations buy 12% on their own — but they're the gate to a 9× SIMD win that libm's erfc can't reach.

Same queue API. Different tail by orders of magnitude.

End-to-end enqueue→dequeue, market-data thread to strategy thread. Lock-free SPSC vs mutex + condvar. At moderate offered load, all three variants look similar at the median. The tail and the breakdown rate are where they diverge.

Allocators: cross-thread order pipeline

Cross-thread Order lifecycle benchmarked across three allocator strategies — malloc, freelist with return queue, and arena with batch handoff. The result that survives contact with the data isn't the one the design discussion would lead you to expect.

AoS vs SoA: bandwidth amplification, not a crossover

Scanning a 128 B option-quote struct across the Zen 2 cache hierarchy. The AoS-vs-SoA gap is 7× when one field per element is hot and vanishes when every field is — and the SIMD win lands largest where memory bandwidth is smallest.

No crossover: absl::flat_hash_map wins at every N and workload mix

Five map implementations swept from N=8 to N≈4M on a Zen 2 CCX. The 'small map → flat structure' folklore expected a crossover; the data found none. absl::flat_hash_map is fastest at every N, in both pure-lookup and modify-mixed workloads, and the sorted-vector primitives collapse under any modify load at non-trivial N.

The sorting shootout: going around the comparison wall