Branch Prediction Basics for Throughput — Extended Case Study

Extended case study

A review is called because a workload regresses after a Branch Prediction Basics for Throughput change.

Background

A stable baseline existed until a Pipeline Fundamentals change improved one benchmark and regressed a product workload on Branch MPKI + recovery latency report.

Symptoms observed

• Regression in Branch MPKI + recovery latency report

• Sim vs silicon disagreement

• Pressure to revert or ship risk

Investigation timeline

1. Freeze tags

2. Reproduce

3. Cluster

4. Experiment

5. Validate

6. Memo

Root cause

A hidden assumption in Branch Prediction Basics for Throughput failed under an unrepresented workload phase.

Fix and validation

• Confirm MPKI shift is consistent across phases, not benchmark warm-up artifact.

• Break down mispredicts by branch type: conditional, indirect, return, loop.

• Correlate recovery cycles with branch resolution stage and squash fanout delay.

• Inspect fetch bandwidth saturation to detect hidden front-end bottlenecks.

• Validate predictor update correctness after context-switch and interrupt events.

Lessons learned

• Workload coverage beats clever microarchitecture

• Every change needs rollback triggers

BRANCH PREDICTION KPI
workload: web_frontend_latency
branch_mpki_before: 7.8
branch_mpki_after: 6.1
global_accuracy_pct: 93.6 -> 94.9
avg_recovery_cycles: 11.4 -> 11.2
wrong_path_uops_pct: 16.0 -> 15.4
ipc_before: 1.27
ipc_after: 1.30
action: reduce predictor lookup latency in fetch by one cycle to unlock gain

Architecture deep dive

Pipeline depth and width are bets on branch predictability and cache behavior.

Concept diagram

PIPELINE VIEW

Fetch ──► Decode ──► Rename ──► Issue ──► Execute ──► Memory ──► Commit
  │         │          │          │          │          │          │
  ▼         ▼          ▼          ▼          ▼          ▼          ▼
I-cache   decode     ROB/RS     wakeup     ALU/BR     LSU       retire
miss      bubbles    full       select     latency    miss      bandwidth

Every pipeline discussion should name where bubbles enter and where they retire.

Metric graph

STALL STACK EXAMPLE

cycles (%)
frontend       ██████████████  28
branch         ████████        16
backend        ████████████    24
memory         █████████       18
retire/other   ██████          12

Read this before saying "make the pipe wider."

Metrics and artifacts

• IPC/CPI breakdown

• stall cycles by stage

• branch mispredict rate

• frontend vs backend bound

Mini case study

IPC drops after widening decode but branch-heavy workload shows frontend stalls unchanged. The correct read: backend was not the bottleneck — branch prediction and fetch bandwidth need investment first.

Debug branches

• If IPC flat after deeper pipeline, check branch MPKI and cache miss stalls.

• If hold timing fails on critical path, architecture may need shorter pipeline stage — link PD.

Senior review question

Ask: what single metric would prove this concept is working or failing on your workload?

Key takeaways

• Connect every architecture claim to a workload and measurable metric.

• State verification and PPA impact before proposing design changes.

Common pitfalls

• Feature-driven design without MPKI/IPC/bandwidth evidence.

• Ignoring coherency and NoC traffic in cache and accelerator sizing.

Study notes

Re-read this topic with one concrete workload.