Comments for page "Using likely() and unlikely()"

(no title)

Sat, 25 May 2013 00:39:31 +0000

In general you wouldn't want to accelerate a reactor leak more than you consider it to be likely…

Just saying :).

(no title)

Mon, 03 Sep 2012 11:59:57 +0000

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! ;)

(no title)

Mon, 03 Sep 2012 10:30:12 +0000

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.

(no title)

Mon, 03 Sep 2012 10:03:41 +0000

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

(no title)

Fri, 31 Aug 2012 13:35:52 +0000

Sure I'm not saying otherwise and that is a good argument.

I was just pointing out that the underlying performance issue is more related to branch mispredictions than cache misses.

(no title)

Fri, 31 Aug 2012 12:37:19 +0000

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.

(no title)

Fri, 31 Aug 2012 12:23:24 +0000

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…

(no title)

Mon, 13 Aug 2012 07:39:57 +0000

Oops. You are right.

(no title)

Wed, 08 Aug 2012 15:11:13 +0000

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.

(no title)

Fri, 22 Jun 2012 08:48:45 +0000

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)

(no title)

Fri, 22 Jun 2012 08:27:59 +0000

…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.