“When a Microsecond Is an Eternity: High Performance Trading Systems in C++”
summary
Describes concrete, production-proven fixes: replacing scattered error handlers nets ~100–200 ns, avoiding virtuals via template-based configuration removes hotpath calls, a branch-predictor/cache warmup ( simulate 1,000–10,000 orders ) shaves ~5 µs, and a custom cache-friendly hash table runs ~2x faster in benchmarks. Uses Google Benchmark, perf and a packet-capture lab with nanosecond timestamps to measure wire-to-wire latency (examples cite ~2.5 µs goals). Notes real pitfalls: placement new null checks, glibc pow pathologies (~0.5 ms), and system/tuning matters.
AI-written summary · about
chapters (24)
- 0:00Introduction and overview
- 1:51What trading systems do
- 5:05The hotpath explained
- 7:17Why C++ for trading
- 10:53Speed of light and latency
- 12:18Daily low-latency techniques
- 18:37Memory allocation pitfalls
- 19:18Exceptions performance impact
- 20:21Removing branches in hotpath
- 22:26Multithreading considerations
- 23:50Data lookup optimizations
- 25:35Hash table performance
- 32:07Inlining and no-inlining
- 33:56Hardware branch predictor
- 37:58CPU cache and cores
- 40:52Placement new inefficiency
- 42:39glibc string performance
- 43:49Static local variable cost
- 44:54Standard function allocations
- 45:37glibc power function issues
- 47:02Avoiding system calls
- 48:13Profiling vs benchmarking
- 50:37Production-like benchmarking
- 52:45Summary and key takeaways
related talks
56mWrite Fast Code Like a Native
42mAdventures in Efficiency and Performance
51mDesigning for Performance
01h 02mFastware
01h 50mUnlocking Modern CPU Power - Next-Gen C++ Optimization Techniques
49mWriting better code with help from Qt and the compiler
41mAdvanced Napkin Math: Estimating System Performance from First Principles
01h 04mUnlocking Performance Through Reverse Engineering