Al Nonymous (guest) 22 Jun 2012 08:27
…and now every condition is tagged with accelerate() in hopes it makes it execute faster. :)
How about prioritize() ? Sounds appropriate. Not sure what the opposite should be though.
Using likely() and unlikely() / Discussion
Forum
» Hidden / Per page discussions
» Using likely() and unlikely()
This is the discussion related to the wiki page Using likely() and unlikely().
Al Nonymous (guest) 22 Jun 2012 08:27
The trouble is the if statement without an else clause. Then the likely/unlikely doesn't even make sense. Maybe a construct that enforces the it-then-else structure would help? fast_if (x) … else_slow … (the point would be to make compilation fail if else_slow clause would not be present)
Your reasoning is wrong.
if( unlikely( … ) ) { … } makes perfect sense.
The if branch can be scheduled at the end of the function. Either it ret, call an unwind thunk, or jump back after the conditional check.
You are missing (or maybe in purposely hiding) a fundamental issue that these macros try to solve: Branch Prediction. Modern CPUs are using pipelining. When CPU predicts the wrong branch it must flush its pipe. That's pretty bad in term of performance. With these macros compiler can add hints for the CPU.
The whole cache thing is mostly hidden by instruction cache prefetching done by the CPU itself. Except if you write very sparse code…
Yes, but does that break the argument above? The goal is not to tag the code as "probable" or "unprobable", rather as "I want this branch to be faster than the alternate branch".
The most probable path may well not be on critical path and thus its performance is irrelevant. The least probable, on the other hand, can be directly on the critical path and should be optimised as much as possible.
I'm not so sure.
I think the point using __builtin_expect is branch prediction, as stated above, by jclairem.
And the problem here is not only the cache misses the code can cause, but the wasted cycles in executing the branch marked as likely (or accelerated) when this is not the most probable branch to be executed. Even though you might want to optimize an unlikely branch because its execution time is critical, if you mark it as "likely" the CPU will start processing that branch every time (or most of the time) the function is called. So, the execution will then have to be thrown away and the CPU cycles will be wasted. Then the most probable executed branch (marked as "unlikely", to optimize the other one) will have to be executed again and so, the pipeline slowed down because of the branch misprediction.
Furthermore, the CPU has a branch prediction buffer (or something like that) so, if this function is called often, it will "know" that the most probable branch (marked as "unlikely") is, in fact, the "likely" branch, making the CPU hint totally useless. In case it is not called so often, a branch misprediction will occur for every call.
My apologies for the confusion created by the words [un]likely and most/less probable. It wasn't that easy to put. :P
You are right that CPU cycles will be wasted. However, the point is that if you are not on a critical path you don't care. No time-sensitive computation is going on anyway.
As for the prediction buffer, I guess there's nothing you can do about it, but even in such case the cache miss argument holds.
I think that to avoid cache misses you just can put the code right after the if condition. The compiler will usually keep the code in that order (first the if block, then the else block; it is still free to reorder single instructions) and so, the "likely" hint will have no effect whatsoever.
I'm not an expert, I'm just thinking out loud. :)
My point here is that I am not so sure about using the __builtin_expect hint for this kind of optimization. But, of course, I might be wrong! ;)
/forum/t-511529/using-likely-and-unlikely#post-
