Likely () and unlikely ()

He gcc C compiler have a built-in directive that optimizes conditional branches as either very likely taken or very unlikel Y taken. The compiler uses the directive to appropriately optimize the branch. The kernel wraps the directive in very easy-to-use macros, likely () and unlikely ().

For example, consider an if statement such as the following:

if (foo) {/        * ... */}

To mark the branch as very unlikely taken (that's, likely not taken):

/* We predict Foo is nearly always zero ... */if (unlikely (foo)) {/        * ... */}

Conversely, to mark a branch as very likely taken:

/* We predict Foo is nearly always nonzero ... */if (likely (foo)) {/        * ... */}

You should-these directives when the branch direction was overwhelmingly a known priori or when you want to opt Imize a specific case at the cost of the other case. This was an important Point:these directives result in a performance boost when the branch was correctly predicted, but a P Erformance loss when the branch is mispredicted. A very common usage for unlikely () and likely () are error conditions. As one might expect, unlikely () finds much more use of the kernel because if statements tend to indicate A special case.

From Linux Kernel development Second Edition

---------------------------------------------------------------------------------------------

Judging statements in Linux often see likely and unlikely, for example:

if (likely (value)) {

}

else{

}

Simply look at the IF (likely (value)) = = if (value), if (unlikely (value)) = = if (value) on the surface.

That is, likely and unlikely are the same, but actually execution is different, plus likely means that value is more likely to be true, then the chance to execute if is greater, and unlikely indicates that value is a false probability, More opportunities to execute else. with this modification, when compiled into binary code likely make the EXECUTE statement after the if followed by the previous program, unlikely so that the next statement is followed by the previous program, so that the cache will be pre-read, increase the execution speed of the program, The implementation of likely and unlikely in Include/linux/compiler.h:

     #define LIKELY (x)   

     #define UNLIKELY (x) __builtin_expect ((x), 0)

__builtin_expect is a pre-processing command for GCC, which is interpreted as follows:

long __builtin_expect (long exp, long C)
__builtin_expect to provide the compiler with branch prediction information. In general, your should prefer to use actual profiles feedback for this('-fprofile-arcs '), as programmers is notoriously bad at predicting how their programs actually perform. However, there was applications in which the this data was hard to collect.
The return value is the value of exp, which should are an integral expression. The value of C must be a Compile-time constant. The semantics of the built-in is that it's expected that exp = = c. For example:
if (__builtin_expect (x, 0))
foo ();
would indicate that we don't expect to call Foo, since we expect X to is zero. Since limited to integral expressions for exp, you should use constructions such as
if (__builtin_ Expect (ptr! = NULL, 1))
Error ();
When testing pointer or floating-point values.

Transferred from: http://www.cnblogs.com/yangzd/archive/2010/09/27/1837202.html

Likely () and unlikely ()