a tournament predictor

Imagine you have two weather forecasters: one is great at predicting steady seasonal patterns, the other is great at picking up on this-week-affects-next-week correlations. Rather than trusting one all the time, you keep score of which forecaster has been right for each kind of day, and you go with whichever has the better recent track record for the situation at hand. A tournament predictor does exactly this for branches: it runs two different predictors in parallel and uses a third 'chooser' to pick, per branch, which one to believe.

Concretely, a tournament (hybrid) predictor combines, for example, a local predictor — which bases its guess on the past behavior of this specific branch — with a global predictor — which bases its guess on the recent pattern of all branches (capturing correlations between branches). A small selector table, itself made of saturating counters, tracks for each branch which of the two components has lately been more accurate, and routes the final prediction to that component. When the chosen predictor is wrong but the other was right, the selector nudges toward the other for next time. This adaptivity lets the predictor get the best of both worlds across very different branch behaviors in the same program.

Tournament predictors (pioneered in the Alpha 21264 in the late 1990s) were a major accuracy leap and remain the conceptual ancestor of today's elaborate predictors. They matter because real programs mix branch types — tight loops that a local predictor nails, and if-chains whose outcomes correlate, which a global predictor catches — and no single scheme is best for all. The honest note is that this accuracy costs storage and update logic, and even tournament predictors cannot help truly unpredictable, data-random branches; they just make sure that wherever a pattern exists, some component will find it.