In an if-else C statement, should a condition that is more likely to be true come first?

I had to write an if-else statement, the condition would be false at the most time (mark the static pointer or not). Which one is best optimized for the compiler? Or are they just equal ?. A function will be called so many times, so it is very important to optimize its performance.

void foo() { static int * p = NULL; if (p == NULL) { p = (int *) malloc( SIZE * sizeof(int)); } //do something here } void foo() { static int * p = NULL; if (p != NULL) { //do something here } else { p = (int *) malloc( SIZE * sizeof(int)); //do something } } 
+6
source share
6 answers

Some compilers may allow the developer to indicate which condition is more likely or unlikely. This is heavily used in the Linux kernel.

There are probable (x) or unlikely (x) macros in gcc. Example:

 if (unlikely(p == NULL)) { p = malloc(10); } 
+6
source

If the function is called often enough not to leave the branch predictor, then the predictor will take care of everything for you, as it will learn very quickly, which is a likely branch.

Some compilers allow you to decorate legend with prediction tips. Check your supplier’s documentation and add a hint if you can.

Specific platforms document the default behavior of the predictor (for example, see Intel Optimization Guide for x86), but it is best to leave it to the compiler to implement this using the above tips. In fact, you really have no choice, since you still do not control the generation of compiler code, so the only last step left to you would be to write the code in machine code yourself and implement the default forecasting platform advice.

+2
source

In the end, it depends on the compiler and its optimization, which varies from the version of the compiler, processor, family of compilers ...

My rule of thumb on these topics is to test your actual platform by doing extensive profiling. I usually also correctly follow the rule "code, optimize correctly later, if necessary." Trying to optimize advances often leads to less readable code and design (and sometimes even higher performance).

+1
source

Conditions are checked in order from left to right, this is in the C standard, which allows the use of conditions such as

 if( ptr != NULL && ptr->member == value ) 

It also means that it makes sense to place a condition that is likely to be false first.

http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx

0
source

If you are looking for performance, I would not use malloc at all. Take a huge chunk of RAM and use it directly without a wrapper to highlight packages. Also think that using macro code will be more, but performance will also increase.

 #define ASSURE_PTR(a) if (!a){ \ a = (int *) malloc (SIZE * sizeof(int)); \ } 
0
source

If a function is called frequently, any worthy branch predictor will learn to predict the general path very quickly. Note that the code may be compiled differently than you expect, as some compilers rely on static branch prediction and may recognize this pattern.

0
source

Source: https://habr.com/ru/post/959154/


All Articles