Likely and unlikely Macros in Android local code

When reading C ++ code in Android frameworks, we often encounter the use of likely and unlikely Macros in the condition judgment statement. The definitions of these two macros are as follows:

# Define likely (exp) (_ builtin_exact CT (exp )! = 0, true) <br/> # define unlikely (exp) (_ builtin_exact CT (exp )! = 0, false ))

Long _ builtin_expect (long exp, long C) is a built-in function of GCC. The parsing is as follows:

You can use _ builtin_predict CT to provide branch prediction information to the compiler. Generally, you should explicitly use this compilation option ('-fprofile-arcs '), because many programmers are very bad at predicting how the code they write is actually executed, using this macro can make it easy for the compiler to optimize the code for Branch jump.

The return value of this function is Exp: an integer expression. C must be a constant. This built-in function indicates in semantics that we expect exp = C.

Therefore, if you do not consider the efficiency of program execution, and do not add likely and unlikely macros, the execution results are the same:

If (likely (exp) <br/>{< br/>}< br/> else <br/>{< br/>}

And

1. If
   (Exp)
   
2. {
3. }
4. Else
   
   
5. {
6. }

The execution results are the same.

Why do we need to use these two macro definitions? Taking the speed of a car as an example, if the speed exceeds 200 km/hour, it indicates an exception occurred. The code can be written as follows:

1. If
   (Speed >=200 ){
   
2. // Exception Handling Code
   
   
3. .....
4. Stop ();
5. } Else
   {
   
6. // Process the code properly
   
   
7. Continue
   ();
   
8. }

You can also write as follows:

1. If
   (Speed <200 ){
   
2. // Process the code properly
   
   
3. Continue
   ();
   
4. } Else
   {
   
5. // Exception Handling Code
   
   
6. .....
7. Stop ();
8. }

These two solutions are correct after implementation, but obviously the efficiency is different, because in most cases, the speed of the car will not exceed 200 kilometers/hour. When the first solution is adopted
When the code is executed here, the CPU executes the branch jump operation, which destroys the CPU Command Execution pipeline and has obvious impact on performance. The second solution avoids this problem because
Most of the time, they are executed sequentially.

For the first solution, we can add the unlikely macro to optimize the compiler:

1. If
   (Unlikely (speed >=200 )){
   
2. // Exception Handling Code
   
   
3. .....
4. Stop ();
5. } Else
   {
   
6. // Process the code properly
   
   
7. Continue
   ();
   
8. }

After the unlikely macro is added, it is equivalent to telling the compiler that a speed greater than 200 rarely appears. In this way, the compiler will adjust the condition judgment method when compiling the Code, so that the CPU instruction execution sequence is not disrupted as much as possible, and the performance has been optimized.

Therefore, for the second solution, we can also add the likely macro:

1. If
   (Likely (speed <200 )){
   
2. // Process the code properly
   
   
3. Continue
   ();
   
4. } Else
   {
   
5. // Exception Handling Code
   
   
6. .....
7. Stop ();
8. }
   

 

Http://blog.csdn.net/DroidPhone/archive/2010/11/03/5984255.aspx