CPU Design · All levels
Branch Prediction & Speculation: Tricky Q&A
Senior interview and review questions for Branch Prediction & Speculation.
Section Q&A bank
Use these drills after completing all topics in Branch Prediction & Speculation. Answer with workload framing, mechanism proof, owner, and release decision.
How do you close Predictor Types and Accuracy when global prediction accuracy, MPKI, and confidence calibration error regresses?
diagram
[INT][CPU][BRANCH-SPECULATION]
Q: How do you close Predictor Types and Accuracy when global prediction accuracy, MPKI, and confidence calibration error regresses?
A:
Name the failing workload, isolate first stage loss, explain mechanism (Local, global, hybrid, and neural-style predictors trade storage, latency, and aliasing behavior; tuning confidence and update policy determines real-world stability under changing branch patterns.), request predictor-type comparison matrix, accuracy-by-workload plot, and confidence histogram, assign owners (branch predictor architect, predictor RTL owner, perf modeling lead), and define bounded fix plus rollback-safe validation.
FOLLOW-UP TRAP: Giving generic CPU tuning without workload evidence, owner, or risk controls.How do you close BTB and Return Stack when BTB hit rate, RAS accuracy, and target redirect latency regresses?
diagram
[INT][CPU][BRANCH-SPECULATION]
Q: How do you close BTB and Return Stack when BTB hit rate, RAS accuracy, and target redirect latency regresses?
A:
Name the failing workload, isolate first stage loss, explain mechanism (BTBs predict branch targets while return stacks recover call/return targets; capacity pressure and aliasing in either structure inflate wrong-path fetch and front-end bubbles.), request BTB residency report, RAS underflow trace, and redirect latency timeline, assign owners (target prediction owner, microcode/firmware owner, verification lead), and define bounded fix plus rollback-safe validation.
FOLLOW-UP TRAP: Giving generic CPU tuning without workload evidence, owner, or risk controls.How do you close Indirect Branch Prediction when indirect target accuracy, aliasing rate, and security hardening overhead regresses?
diagram
[INT][CPU][BRANCH-SPECULATION]
Q: How do you close Indirect Branch Prediction when indirect target accuracy, aliasing rate, and security hardening overhead regresses?
A:
Name the failing workload, isolate first stage loss, explain mechanism (Indirect targets depend on history, call context, and pointer flow; predictor indexing and tagging must reduce aliasing while respecting security mitigations for speculative attacks.), request indirect branch trace corpus, target-alias map, and mitigation cost report, assign owners (CPU security architect, predictor RTL owner, compiler/runtime owner), and define bounded fix plus rollback-safe validation.
FOLLOW-UP TRAP: Giving generic CPU tuning without workload evidence, owner, or risk controls.How do you close Mispredict Penalty and Recovery when average mispredict penalty cycles, pipeline flush depth, and recovered IPC regresses?
diagram
[INT][CPU][BRANCH-SPECULATION]
Q: How do you close Mispredict Penalty and Recovery when average mispredict penalty cycles, pipeline flush depth, and recovered IPC regresses?
A:
Name the failing workload, isolate first stage loss, explain mechanism (When branch resolution invalidates wrong-path work, control logic must flush, restore checkpoints, and refill fetch rapidly; recovery bandwidth dictates how quickly IPC rebounds.), request flush-sequence trace, replay queue state log, and recovery slope chart, assign owners (front-end recovery owner, OoO control owner, silicon debug lead), and define bounded fix plus rollback-safe validation.
FOLLOW-UP TRAP: Giving generic CPU tuning without workload evidence, owner, or risk controls.Q&A drill guide
diagram
WORKLOAD -> STAGE LOSS -> METRIC -> MECHANISM -> FIX -> REGRESSIONSketch while answering
diagram
SPECULATION LOOP
predict direction/target -> speculative fetch/decode -> resolve -> flush/recoverKey takeaways
Always connect microarchitectural counter changes to product workload outcomes.
Lock binary, compiler, firmware, and thermal metadata before comparing CPU traces.
Common pitfalls
Treating average IPC as sufficient proof while ignoring latency tails and outliers.
Applying predictor or prefetch tweaks without first-failing-stage attribution.
Declaring closure without reproducible perf, correctness, and power gates.