Out-of-order execution - what can it do for me?
summary
Explains how modern x86 CPUs decode instructions into microops, use a reorder buffer and memory-disambiguation to run loads/stores out of order, and how that both boosts IPC and causes costly recoveries when mispredicted. Uses microbenchmarks (objdump, no-op padding, perf and pmu-tools) to discover a reorder buffer = 512 on a Raptor Cove core, to show a machine clear ≈ 30–40 cycles when load-speculation fails at a specific iteration, and to prove branchless/conditional-move and layout fixes work — e.g. Google Propeller 4% runtime win measured with perf + pmu-tools.
AI-written summary · about
chapters (23)
- 0:00Out-of-order execution intro
- 1:11Why CPU knowledge matters now
- 5:10What to expect
- 6:15Out-of-order benefits example
- 9:09How CPUs execute out-of-order
- 12:06Branch speculation in OoO
- 15:39Handling wrong predictions
- 17:30Measuring reorder buffer
- 21:03Memory disambiguation
- 24:41Reverse engineering memory disambiguation
- 29:44OoO advantages and power costs
- 31:09Limitations of out-of-order execution systems
- 35:53Top-down CPU workload analysis
- 36:36Front-end bound optimizations
- 39:00Code layout for performance
- 41:53Branch prediction efficiency
- 43:39Why untaken branches are faster
- 45:03Google’s Propeller function splitting
- 46:28Code layout impact
- 50:02Binary search bad speculation
- 53:42Branchless binary search
- 54:49Memory locality with I-singer
- 56:59Summary of CPU techniques
related talks
43mWhat Every Programmer Should Know about How CPUs Work
17mPutting Weak Memory in Order via a Promising Intermediate Representation
59mA Relaxed Guide to memory_order_relaxed
58m“No Sane Compiler Would Optimize Atomics"
19mDo nothing fast: How to scale idle cpus?
43mC++ Atomics...
01h 11mProgramming language memory models: Problems, solutions, and directions
21mSome things I wish I hadn’t seen