[libre-riscv-dev] GPU design

[Jacob Lifshay]

There are simpler branch predictors that work well enough.

Note that the following stats are just what I remember, they are probably
inaccurate.

Branch prediction is essential as it reduces the average cycles per branch
from more than 5 to less than 1. Branches are easily a large fraction of
the executed operations in integer programs (20% i think) and a smaller but
still large fraction of fp programs.

Going with those stats, assuming that the rest of the instructions average
to 1 cycle per instruction, having a branch predictor about doubles the ipc.

The branch predictor you proposed wouldn't be sufficient since it would
only work for the smallest loops.

We can combine several branch predictors to make a decent predictor:
call/return predictor -- important as it can predict calls and returns with
around 99.8% accuracy
loop predictor -- basically counts loop iterations
some kind of global predictor -- handles everything else

We will also want a btb, a smaller one will work, it reduces average branch
cycle count from 2-3 to 1 since it predicts which instructions are taken
branches while the instructions are still being fetched, allowing the fetch
to go to the target address on the next clock rather than having to wait
for the fetched instructions to be decoded.

Jacob

On Tue, Dec 4, 2018, 02:47 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> https://www2.eecs.berkeley.edu/Pubs/TechRpts/2018/EECS-2018-151.html
>
> also to take into account, chapter 4: branch prediction looks horribly
> expensive.  i'm very tempted to make the suggestion to only focus on
> tight loops.  "if within same 16 instructions && seen 1 time before,
> assume going to loop again".
>
> sound reasonable?
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>