In the reference example, a cycle is specified for the Q_LIKELY macro and a situation is considered when the false state can occur, as they say, in one case per million:

 // the condition inside the "if" will be successful most of the times for(int i = 1; i <= 365; i++) { if(Q_LIKELY(isWorkingDay(i))) { ... } ... }

In general, this benefit can be seen, taking into account not uncommon situations when a value is checked in a cycle, meaning that it is only in one of two states, and one of them will almost always be in the overwhelming majority of cases.

But the example for Q_UNLIKELY , although, judging by the name, it is just the opposite:

 bool readConfiguration(const QFile &file) { // We expect to be asked to read an existing file if(Q_UNLIKELY(!file.exists())) { qWarning() << "File not found"; return false; } ... return true; }

What can there be "help to the compiler" in optimizing the code, and if it does take place, will it be fair for Q_LIKELY ? Maybe there are some criteria for determining the characteristic situations in which the use of these macros makes sense?

  • one
    Roughly speaking, Q_LIKELY to use when false happens rarely, Q_UNLIKELY when true rarely happens. This helps the compiler build faster code. - Mikalai Ramanovich
  • one
    The idea of ​​this Q_LIKELY is not very new. Here you can read what the essence is: kernelnewbies.org/FAQ/LikelyUnlikely - Alexey Esaulenko

1 answer 1

The text of the answer presents my subjective opinion.

I believe that these macros are useless in 99.99% of cases and should be applied only after measurements, which showed that their use is justified. Why? Because what is “likely” today may become “unlikely” tomorrow, and programmers very often forget to change things that are clearly not reflected in the program. Thus, we may have some kind of check labeled Q_LIKELY , whereas in fact the opposite is true. And it will confuse the programmer, who will continue to read it.

“But how is it, this is optimization ?!” - a rather controversial statement, in fact, because The predictors of branching (CPU predictors) in the CPU are very good, and the compiler really cannot help here. Here we take a cycle from the question, after the first iteration, it is most likely that the CPU will begin to select instructions for the branch that was in the first iteration. What will give us a clear indication of the potential gain in the first iteration? Ridiculous.

All this is so nano-optimized that, I repeat, it is worth resorting to them only after finding a problem with branching, but not before. Programmers, in addition to bad memory, are still not very good at determining what will most likely be executed.

  • 2
    I would add: such nano-optimization makes sense only inside the often (say, a million times per second) run cycle, where predictor accuracy is extremely important. Tips for a predictor next to a file operation look ridiculous, like saving on napkins when launching a space rocket. - VladD
  • @VladD, and how it will help a million operations? The CPU itself will do well there. - ixSci
  • Well, for example, if the check “in the opposite direction” is performed one instruction faster in a typical case, then the hint to the compiler makes sense for him to choose the more efficient of the two implementations. (I do not know if there is any hint for the processor itself.) - VladD
  • @VladD, just a “typical case” will be just “predicted” by the CPU and it will begin to choose the appropriate instructions on its own - it doesn’t need a hint (unless it is the first iteration, in it, it might be useful). Branch predictor, as far as I know, is one of the most secret modules in the CPU, whose secrets are very well kept, because it gives a competitive advantage - this is a very clever and complicated thing, the help of which, in general, is not needed. - ixSci
  • Well, this is if the predictor is smart and not mistaken. And what if he is stupid somewhere? For example, at first there is a 1000 “no”, the predictor is tuned, and then millions of “yes”, but the predictor cannot dynamically adjust? Well, do not discount the simpler architecture, whose predictor is not as good as that of Intel. - VladD