5.3.10 · D4Advanced Microarchitecture

Exercises — Tournament and TAGE predictors

3,033 words14 min readBack to topic

These problems build from recognising the parts of a hybrid predictor up to designing one. Do each on paper before opening the solution. Everything you need was built in the parent note; where a term first appears here we re-anchor it so you never meet a symbol cold.

Two objects reappear throughout, so let's pin them down once. Figure s01 draws both side by side: the selector on the left (which predictor to trust) and the TAGE counter on the right (taken or not, and how sure). Refer back to it whenever a counter value appears.

Figure — Tournament and TAGE predictors

Level 1 — Recognition

Problem 1.1 (L1)

A tournament predictor's selector holds the value (binary ). Which component predictor does it choose, and why?

Recall Solution 1.1

The parent's mapping (and the colours in figure s01): values → predictor 1 (local), values → predictor 2 (global). , so the selector picks predictor 2 (the global predictor). Why: the top bit of the 2-bit counter is the decision. , top bit → predictor 2. The bottom bit is just "how strongly."

Problem 1.2 (L1)

In TAGE, a prediction counter reads . Taken or Not-Taken?

Recall Solution 1.2

Rule: predict Taken iff counter . Here , so predict Not-Taken. The value also tells us confidence is low (it's one step from flipping to = weakly Taken).

Problem 1.3 (L1)

TAGE has a base table and tagged tables with history lengths bits. On a lookup, tags match in and but not . Which table provides the prediction?

Recall Solution 1.3

TAGE always uses the longest matching history (most specific). Matches are () and (). Longest is ====. A gap at is fine — TAGE does not require a contiguous chain of matches, only the single longest hit.


Level 2 — Application

Throughout this level, remember the base table has history length — it is indexed by PC alone, uses no branch history, and always exists as a fallback. The tagged tables carry bits, matching Problem 1.3.

Problem 2.1 (L2)

A selector currently holds . On this branch: predictor 1 (local) is correct, predictor 2 (global) is wrong. Apply the parent's update rule. What is the new selector value, and does the chosen predictor change?

Recall Solution 2.1

Update rule (parent): Here pred 1 right, pred 2 wrong → first case: . Choice before: → predictor 1. Choice after: → predictor 1. No change — but we moved deeper into the predictor-1 region (more confident).

Problem 2.2 (L2)

Same selector at , but this time both predictors are correct. New value?

Recall Solution 2.2

Both correct → third case: selector unchanged = . Why the design does this: if both agree and are right, there's no evidence for preferring one over the other, so we don't move. The selector only learns from disagreements.

Problem 2.3 (L2)

A branch runs a repeating stream where predictor 1 is right and predictor 2 wrong on every branch. The selector starts at . Trace it over 3 branches.

Recall Solution 2.3

Every step is case 1: .

  • Branch 1:
  • Branch 2:
  • Branch 3: (saturates)

Final = ====. The chosen predictor flips from predictor 2 (at ) to predictor 1 (at ) after just one branch, then keeps sinking toward maximum confidence in predictor 1.

Problem 2.4 (L2)

In TAGE with base and tagged tables , table (the provider) mispredicts. Where does TAGE try to allocate a new entry, and why not a shorter table?

Recall Solution 2.4

Rule: on misprediction by provider , allocate in some with . Provider is , so the only longer table available is ==== (). Why not shorter? 's 8 bits of history were insufficient to distinguish this case — shorter history is strictly less specific, so it would fail too. A longer history can separate patterns conflated. If has a free (low-useful) entry, TAGE allocates there; if is full of useful entries, no allocation happens this time (TAGE waits rather than evict a proven entry).


Level 3 — Analysis

Problem 3.1 (L3)

Two component predictors have accuracies (local) and (global). The selector chooses correctly with probability . First derive the tournament error model from scratch, then plug in the numbers. Is the tournament better than either predictor alone?

Recall Solution 3.1

Deriving the model. On any branch the selector does one of two things: it points at the right predictor for that branch, or the wrong one. Let = probability it picks the better one.

  • With probability the selector nails the better choice, so our error equals the smaller of the two error rates, .
  • With probability the selector mis-chooses and we're stuck with the larger error, .

A probability-weighted average of these two outcomes gives exactly So the two terms are not arbitrary: is the reward for choosing well, is the penalty for choosing badly, each weighted by how often that happens. (An oracle with collapses this to pure — the best possible.)

Plugging in. Errors: , . So , . Best single predictor error (global). Tournament error is worse than the global-alone error here! Why: the selector is only 80% good and the two predictors are close in skill (0.85 vs 0.87). A weak selector wastes the tiny gap. Tournaments win when different branches favour different predictors (so the effective per-branch is much lower than either global average) — the single-number model above understates that structural benefit. See Problem 3.2.

Problem 3.2 (L3)

Now model the realistic case. Suppose half the branches are "local-friendly" (local 95%, global 70%) and half are "global-friendly" (local 70%, global 95%). A perfect (oracle) selector picks the best per branch. What accuracy does the oracle tournament reach, and how does it compare to using local-only or global-only across all branches?

Recall Solution 3.2

Local-only accuracy . Global-only accuracy . Oracle tournament: on each half it takes the better predictor , so . Insight: neither single predictor beats , yet the oracle hits — a point jump. This is why tournaments exist: they exploit that branches split into populations with different needs, something a single average-accuracy number hides.

Problem 3.3 (L3)

TAGE tables use geometric history lengths . Given and with 5 tables, find the common ratio and list all five lengths.

Recall Solution 3.3

Geometric: , so . Lengths: — exactly the ladder drawn in figure s02. Why geometric, not linear (2,4,6,8,10)? History-need is roughly logarithmic — a handful of branches need very long history. Doubling covers the huge range with only 5 tables; a linear ladder would need 16 tables to reach 32 in steps of 2, wasting hardware on lengths nobody uses.

Figure s02 makes the resource argument visual: each bar is a table, its length is its history depth, and the "×2" between rungs is why five short bars span from to .

Figure — Tournament and TAGE predictors

Level 4 — Synthesis

Problem 4.1 (L4)

A TAGE useful bit is incremented when the entry predicts correctly and the next-shorter matching table would have predicted incorrectly. Suppose entry in predicts Taken (correct), and the entry in that also matched would have predicted Not-Taken (incorrect). What happens to 's useful bit, and what does this mean strategically?

Recall Solution 4.1

Both conditions hold: correct and shorter table wrong → useful bit is incremented. Meaning: is earning its keep. It exists only because the longer history captured something the shorter one got wrong. A high useful bit protects from eviction; if it were , would be a candidate victim when a new allocation needs space. This is TAGE's way of asking each long-history entry: "are you actually adding information the cheaper table lacks?"

Problem 4.2 (L4)

Design trace. A branch inside a doubly-nested loop needs 8 bits of history to predict well, but TAGE currently only has an entry in (). Walk the sequence of events (mispredict → allocate → learn) that leads TAGE to the correct table. Assume tables .

Recall Solution 4.2
  1. Now: is the longest match, so it provides. With only 4 bits it conflates two different outer-loop contexts → it mispredicts.
  2. Allocate: provider is , so TAGE allocates in a longer table, → try (). New entry gets a fresh 3-bit counter, useful bit .
  3. Learn: next visits, 's 8-bit index now separates the two contexts. Its counter trains toward the correct direction; each correct-while--wrong sets its useful bit.
  4. Steady state: becomes the longest match and the provider; 's stale entry ages out. TAGE has discovered the branch needs 8 bits — nobody told it; the mispredict-then-lengthen loop found it.

Problem 4.3 (L4)

Combine both ideas. In a tournament predictor whose two components are themselves a short-history and a long-history predictor, the selector partly duplicates TAGE's longest-match logic. Give one concrete advantage TAGE has over this 2-component tournament.

Recall Solution 4.3

A 2-component tournament offers exactly two history lengths and a coin-flip selector between them. TAGE offers many lengths (4–6 tables) and, crucially, chooses the length deterministically by tag match rather than by a trained selector that can be wrong. Advantages: (1) finer granularity — a branch needing 8 bits isn't forced to a coarse 4-or-32 choice; (2) no selector misprediction penalty — the longest tag match is unambiguous, whereas a selector counter can point the wrong way for several branches after a phase change; (3) per-entry usefulness tracking lets TAGE reclaim dead history cheaply. That's why high-end TAGE exceeds tournament accuracy ( vs ).


Level 5 — Mastery

Problem 5.1 (L5)

Full pipeline reasoning. A processor fetches while a branch is unresolved (this is speculative execution). It runs at 4 GHz, retires 4 instructions/cycle, and keeps 192 instructions in flight. A misprediction discards all in-flight work and refills. Two predictors are offered: Tournament at accuracy, TAGE at . If branches are of instructions, compute the misprediction rate per instruction for each, and the ratio of wasted-work between them.

Recall Solution 5.1

Fraction of instructions that are branches . Mispredict rate per branch: Tournament ; TAGE . Misprediction rate per instruction :

  • Tournament: (1.6 mispredicts per 100 instructions).
  • TAGE: (0.8 per 100).

Each mispredict flushes up to 192 in-flight instructions, so wasted work is proportional to the mispredict count. The ratio is : the tournament predictor triggers twice as many flushes, so it throws away roughly twice as much speculative work per instruction as TAGE. Concretely, per 1000 instructions the tournament wastes about instruction-slots of work versus for TAGE. This is why the extra transistors for TAGE pay off — halving the flush rate roughly doubles useful throughput on branchy code. (The refilled front-end feeds from the branch target buffer, which supplies where to fetch once whether is predicted.)

Problem 5.2 (L5)

Corner cases. For each degenerate input, state what the predictor does and why it's safe: (a) TAGE lookup where no tagged table matches. (b) Selector at exactly the boundary — value , and predictor 1 keeps being wrong while predictor 2 is right, three branches in a row. (c) A TAGE prediction counter at its extreme that then mispredicts.

Recall Solution 5.2

(a) No tag match: fall back to the base predictor (PC-indexed 2-bit counter, history length ). always exists and always answers — TAGE is never undefined. This is the "cold branch" / capacity-miss safety net. (b) Boundary crossing: value chooses predictor 1. Each branch is case 2 (): (saturates). The choice flips to predictor 2 the instant we hit (after the first branch), then hardens. Saturation at stops runaway. (c) Extreme counter mispredicts: means "strongly Taken" but actual was Not-Taken. Being signed & saturating, it steps toward the truth: (still predicts Taken — one wrong outcome shouldn't flip a strongly-trained entry). It takes several Not-Takens () to flip the prediction. This hysteresis is deliberate: it ignores one-off noise, only flipping under sustained new behaviour.


Recall Self-test checklist

Can you now, from memory, do each of these? ::: (1) split a 2-bit selector into choice+strength; (2) apply the 3-case selector update; (3) pick TAGE's longest-matching provider and know the fallback; (4) explain allocate-longer-on-miss and the useful bit; (5) compute geometric history lengths; (6) turn accuracy into per-instruction mispredict rate and wasted work.

Related builds: 5.3.9-Gshare-and-local-predictors (the components inside the tournament), 5.3.8-Two-level-adaptive-predictors (where global history registers come from), 7.2.5-Cache-coherence-and-branch-predictors (multicore interactions).