By: anon (anon.delete@this.anon.com), February 18, 2013 5:12 pm
Room: Moderated Discussions
anon (anon.delete@this.anon.com) on February 18, 2013 2:05 am wrote:
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 17, 2013 5:28 pm wrote:
> > I find multiple condition registers attractive partially because such can be less expensive front-end
> > registers (future file for an OoO implementation) allowing early branch resolution. In theory,
> > branches whose conditions are set early could be resolved just after branch prediction (the predictor
> > could indicate that the branch is a candidate for early resolution and what condition register+condition
> > is tested), but even just after decode branch resolution could have some benefits.
>
> I agree with you on this. On one hand, you might say "branch prediction is very good",
> but on the other hand, you have fundamentally unpredictable branches (due to icache or
> branch prediction capacity limits, and due to branches without trivial patterns).
>
> Prediction is one way to assist with the latter, but early resolution could help with both.
^^^^^^^^^^
Err, predication. Prediction can help with unpredictable branches. Although even that is at a cost of performing speculative/unnecessary work, and introducing data dependencies. So early resolution could be significantly better.
> Branch mispredicts seem to be quite a fundamental limiter on OOOE and pipeline depth, and of
> course even before you hit performance limits, you are already paying an efficiency cost.
>
> On the other hand, I suspect quite a lot of branches will be unsuitable. And shuffling code
> around so that "something" gets done in between the comparison and the branch has the obvious
> flaw that it's effectively just putting the same kind of speculative work into the bubble.
>
> Are you aware of any papers that study this in isolation?
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 17, 2013 5:28 pm wrote:
> > I find multiple condition registers attractive partially because such can be less expensive front-end
> > registers (future file for an OoO implementation) allowing early branch resolution. In theory,
> > branches whose conditions are set early could be resolved just after branch prediction (the predictor
> > could indicate that the branch is a candidate for early resolution and what condition register+condition
> > is tested), but even just after decode branch resolution could have some benefits.
>
> I agree with you on this. On one hand, you might say "branch prediction is very good",
> but on the other hand, you have fundamentally unpredictable branches (due to icache or
> branch prediction capacity limits, and due to branches without trivial patterns).
>
> Prediction is one way to assist with the latter, but early resolution could help with both.
^^^^^^^^^^
Err, predication. Prediction can help with unpredictable branches. Although even that is at a cost of performing speculative/unnecessary work, and introducing data dependencies. So early resolution could be significantly better.
> Branch mispredicts seem to be quite a fundamental limiter on OOOE and pipeline depth, and of
> course even before you hit performance limits, you are already paying an efficiency cost.
>
> On the other hand, I suspect quite a lot of branches will be unsuitable. And shuffling code
> around so that "something" gets done in between the comparison and the branch has the obvious
> flaw that it's effectively just putting the same kind of speculative work into the bubble.
>
> Are you aware of any papers that study this in isolation?