Portable branch prediction hints

懵懂的女人 提交于 2019-11-26 22:44:56

问题


Is there any portable way of doing branch prediction hints? Consider the following example:

  if (unlikely_condition) {
    /* ..A.. */
  } else {
    /* ..B.. */
  }

Is this any different than doing:

  if (!unlikely_condition) {
    /* ..B.. */
  } else {
    /* ..A.. */
  }

Or is the only way to use compiler specific hints? (e.g. __builtin_expect on GCC)

Will compilers treat the if conditions any differently based on the ordering of the conditions?


回答1:


The canonical way to do static branch prediction is that if is predicted not-branched (i.e. every if clause is executed, not else), and loops and backward-gotos are taken. So, don't put the common case in else if you expect static prediction to be significant. Getting around an untaken loop isn't as easy; I've never tried but I suppose putting it an an else clause should work pretty portably.

Many compilers support some form of #pragma unroll, but it will still be necessary to guard it with some kind of #if to protect other compilers.

Branch prediction hints can theoretically express a complete description of how to transform a program's flow-control graph and arrange the basic blocks in executable memory… so there are a variety of things to express, and most won't be very portable.

As GNU recommends in the documentation for __builtin_expect, profile-guided optimization is superior to hints, and with less effort.




回答2:


In most cases, the following code

if (a)
{
   ...
}
else
{
    ...
}

is actually

evaluate(A)

if (!A)
{
   jmp p1
}

... code A

   jmp p2

p1:

... code !A

p2:

Note that if A is true, "code A" is already in the pipeline. The processor will see the "jmp p2" command ahead, and will load p2 code to the pipeline.

If A is false, the "code !A" may not be in the pipleline, therefore it may be slower.

Conclusions:

  1. do If(X) if X is more likely than !X
  2. try to evaluate A as early as possible, so that the CPU can dynmically optimize the pipeline.

:

evaluate(A)

do more stuff

if (A)
   ...



回答3:


Optimization is inherently a compiler thing, so you have to use compiler functionality to help it. The language itself doesn't care about (or mandate) optimizations.

So the best you can do without compiler-specific extensions is organize your code in such a way where your compilers will "do the right thing" without help. But if you want to be sure, tap in to compiler extensions. (You might try abstracting them behind the preprocessor, so your code remains portable.)




回答4:


Just be consistant with what you do. I like to use

if (!(someExpression))

But the compiler should treat this equally.




回答5:


What's wrong with checking for a specific compiler via #ifdef and hiding these things behind a custom macro? You can #define it to expand to the plain expression in cases you don't have a compiler that supports these optimization hints. I recently did something similar with explicit cache prefetches which GCC supports via an intrinsic function.



来源:https://stackoverflow.com/questions/3702903/portable-branch-prediction-hints

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!