> This is visible with block size 64 breaking at 3072 mark 307264=196K, and for block 32 at 6144: 614432=196K.
You mean 192K.
Branch predictor: How many “if”s are too many?
41–50 of 109 posts
Re: Branch predictor: How many “if”s are too many?
#42Are there any rules-of-thumb for avoiding branch mispredictions, other than reducing the number of conditional branches?
For example (not that I expect this to be true), something of the same sort as "your if block should contain the rare condition".
Re: Branch predictor: How many “if”s are too many?
#43Are there any rules-of-thumb for avoiding branch mispredictions, other than reducing the number of conditional branches? For example (not that I expect this to be true), something of the same sort as "your if block should contain the rare condition".
I might be off base here, but you would probably do best to not overthink this and let the compiler do its job. Attempting to pre-optimize if statements relative to a branch predictor (a very hardware-specific thing) is probably a massive fool's errand.
Re: Branch predictor: How many “if”s are too many?
#44If you care about performance and the number of if's you should look into profile guided optimization. This can help the compiler to arrange the code such that branches like the "if (debug)" in the example, are never taken and so don't occupy precious resources. This will also make instruction fetch faster and if the body of the if is placed on another cache line it can also improve instruction cache performance (and even TLB performance and IO performance if the unused code is placed into another page).
Re: Branch predictor: How many “if”s are too many?
#45Are there any rules-of-thumb for avoiding branch mispredictions, other than reducing the number of conditional branches? For example (not that I expect this to be true), something of the same sort as "your if block should contain the rare condition".
My rule of thumb is to partition my data sets, to make sure the conditional has the same result in as long a row as possible.
Re: Branch predictor: How many “if”s are too many?
#46Are there any rules-of-thumb for avoiding branch mispredictions, other than reducing the number of conditional branches? For example (not that I expect this to be true), something of the same sort as "your if block should contain the rare condition".
You can use the __builtin_expect keyword on GCC and clang.
It does make a difference (HPC code uses it quite a bit because of this), but as it's done manually, results obviously vary depending on processor, and there's a limit to how far you can take it. Trying not to branch (not always possible) is best...
Basically, it's like manually doing profile-guided optimisation - you look at perf or vtune, and add the above to branches which have a high penalty and which are rarely or often taken, and see if it makes a difference.
Re: Branch predictor: How many “if”s are too many?
#47Why don't processors fetch and decode both branches?
Re: Branch predictor: How many “if”s are too many?
#48Are there any rules-of-thumb for avoiding branch mispredictions, other than reducing the number of conditional branches? For example (not that I expect this to be true), something of the same sort as "your if block should contain the rare condition".
Branch prediction works predictably well when the branch is heavily biased towards one outcome, typically follows a repeating pattern of a short length (eg. taken once every three iterations), or is strongly correlated with another preceding (not necessarily local) branch. Conversely, branch prediction works badly when they are data dependent on irregular data.
Re: Branch predictor: How many “if”s are too many?
#49Are there any rules-of-thumb for avoiding branch mispredictions, other than reducing the number of conditional branches? For example (not that I expect this to be true), something of the same sort as "your if block should contain the rare condition".
You can use the __builtin_expect keyword on GCC and clang. It does make a difference (HPC code uses it quite a bit because of this), but as it's done manually, results obviously vary depending on processor, and there's a limit to how far you can take it. Trying not to branch (not always possible) is best... Basically, it's like manually doing profile-guided optimisation - you look at perf or vtune, and add the above…
Note that this is not targeted to branch prediction, but compiler optimizations. It should be done carefully, because it tends to have a larger downside than its upside, and the changes the compiler makes based on it can be unpredictable, and unstable.
> Trying not to branch (not always possible) is best...
Branches are often faster than branch-free methods, since they can speculate certain data dependencies away.
Re: Branch predictor: How many “if”s are too many?
#50Why don't processors fetch and decode both branches?
Because doing so would require twice the cache and execution bandwidth. It is usually better to take the gamble and fetch just one branch. If you don't want to gamble you could stop the current thread and continue with the execution of another thread (if you have simultaneously multithreading/hyper threading).
In some cases the compiler may decide to evaluate both paths and then "undo" the path that was wrong. This is very common on VLIW architectures like Itanium which have hardware support for this (predicates), but it can also be done with other instruction sets.