Re: Branch prediction

rkrayhawk@aol.com (RKRayhawk)
20 Jun 2000 02:32:32 -0400

          From comp.compilers

Related articles
Re: Branch prediction bonzini@gnu.org (2000-05-20)
Re: Branch prediction djimenez@cs.utexas.edu (2000-05-21)
Re: Branch prediction anton@mips.complang.tuwien.ac.at (2000-05-21)
Re: Branch prediction freitag@alancoxonachip.com (Andi Kleen) (2000-05-21)
Re: Branch prediction sci0627@ccrd200.cdc.polimi.it (2000-05-28)
Re: Branch prediction anton@mips.complang.tuwien.ac.at (2000-05-31)
Re: Branch prediction qed@pobox.com (2000-06-03)
Re: Branch prediction rkrayhawk@aol.com (2000-06-20)
| List of all articles for this month |

From: rkrayhawk@aol.com (RKRayhawk)
Newsgroups: comp.compilers
Date: 20 Jun 2000 02:32:32 -0400
Organization: AOL http://www.aol.com
References: 00-06-025
Keywords: architecture

The branch prediction problem can be viewed as a general problem,
amenable to a general solution. Our vocabulary and early technology
lead us to focus on a specific branch (direct or indirect) and try to
optimize the heck out of it, with reference to prefetch.


That original orientation is really not expressed in the unit of
measure that counts. What really counts is how are we doing overall in
branch prediction.


Some variations of the PPC branch address register array (not a
specific technical term) are the equivalent of hashes. They answer the
question, "if viewed through this glass onion, on average mind you,
would such a branch be taken or not."


Because it is based upon a blurring of detail, such a deployment is
not per se related to a static prediction, encoded or
defaulted. Instead it relates to dynamic adjustment.


I regret that I am at a remote site and can not pull the exact
nomenclature out of the hat here. Someone maybe can chime in with the
IBM / Motorola parlance. Interestingly this strategy is not evident
in all models of PPC (and it would certainly be interesting to know
what is going into the 64 bit devices).


Another factor, not emphasized in earlier dialog, but worth
considering, is that the larger the number of bits in a dynamic
predictor, the longer it takes to adjust. (longer counted in number of
mispredictions). Thus there is a kind of tight loop in the situation.
If you have a pattern that swings back and forth in a full
osciallation, then the predictor is hurting you as much at the peak as
the trough... you end up needing a predictor to predict if the dynamic
predictor is likely to be cool for a particular branch, and that
naturally varies. That is not meant as a reducio, either. If you had
your choice you would glue a data item onto a branch point to throttle
the domain of the predictor (lots of luck toting that around for
free). Grok it or not, prediction has barriers, they are regretaly
near to just a few bits of width.


Hope that adds something to the discussion,




Robert Rayhawk
RKRayhawk@aol.com


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.