| |||||||||||||
Likely unlikely()sLikely unlikely()sPosted Dec 16, 2010 6:51 UTC (Thu) by cras (guest, #7000)In reply to: Likely unlikely()s by jzbiciak Parent article: Likely unlikely()s
I was once adding likely()s and unlikely()s to heavily CPU-intensive code. I remember that adding unlikely() to a branch that was rarely executed (IIRC only a few % of calls) was slower than simply not giving any hint. Nowadays I add them only to branches where getting the branch prediction wrong just doesn't matter (error handling mostly).
(Log in to post comments)
Likely unlikely()s Posted Dec 16, 2010 13:45 UTC (Thu) by dmk (subscriber, #50141) [Link]
wouldn't it be worthwhile sometimes, to annotate a codepath with likely(), even if it wasn't true in reality, just to make that one codepath fast? For example if we are in that one codepath that decides if the world continues or not, we would want to get the decision really fast, if the world continues, else we don't care?
Likely unlikely()s Posted Dec 16, 2010 13:58 UTC (Thu) by cras (guest, #7000) [Link]
Well, if the code was like:
while (likely(!is_world_ending()) {
And the branch prediction was wrong pretty much always, that would also increase the amount of time used to update world status. So even when it finally sees the world ending and jumps immediately to saving the world, perhaps it could have done that in the previous iteration already if the inner loop had been faster.
Or something like that :)
Likely unlikely()s Posted Dec 18, 2010 20:54 UTC (Sat) by giraffedata (subscriber, #1954) [Link] dmk's basic idea seems valuable, but the example is bad. And cras seems to have misread that example. We need a better example. The problem with what dmk writes ("we would want to get the decision really fast") is that likely() doesn't affect how fast the test is. It affects how fast what you do as a result of that test is. If the test is world_continues and you want to respond quickly when it does, then the truth is the right way to go: world_continues is likely, and that's how you want to annotate it. I believe cras assumes we want to respond quickly if the world is ending, because it isn't really ending -- we can save it. That's not what dmk described: he said the world really is ending, so all we can do is say good bye, and it just won't make any difference how slowly we do that.
Likely unlikely()s Posted Dec 27, 2010 10:54 UTC (Mon) by tesarik (guest, #52705) [Link]
Well, let's give a better example of this. Consider a spinlock slow
path (ie. on contention):
while(unlikely(is_locked(lock)))
Although it's likely that the lock is held many times before we can take it,
Likely unlikely()s Posted Dec 16, 2010 19:44 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Sounds nonsensical to me... if the annotated code is not in any way performance critical, doing the extra work of annotating it is pure waste.
Likely unlikely()s Posted Dec 16, 2010 20:21 UTC (Thu) by cras (guest, #7000) [Link]
Of course. But if there are some heavily used macros and functions where it's easy to add them once and then get them used throughout the code, it's not much extra trouble even if the benefit is small.
Although now that I think about it, maybe many of those checks I used to put unlikely() in my code are nowadays pointless, because they call functions that I've since marked with __attribute__((cold)), which should put the unlikely()s there automatically. (But do they? I remember testing that the cold attribute did nothing in some gcc version.)
|
|||||||||||||