Question

Is there any performance difference (in C++) between the two styles of writing if-else, as shown below (logically equivalent code) for the likely1 == likely2 == true path (likely1 and likely2 are meant here as placeholders for some more elaborate conditions)?

// Case (1):
if (likely1) {
  Foo();
  if (likely2) {
    Bar();
  } else {
    Alarm(2);
  }
} else {
  Alarm(1);
}

vs.

// Case (2):
if (!likely1) {
  Alarm(1);
  return;
}
Foo();
if (!likely2) {
  Alarm(2);
  return;
}
Bar();

I’d be very grateful for information on as many compilers and platforms as possible (but with gcc/x86 highlighted).

Please note I’m not interested in readability opinions on those two styles, neither in any “premature optimisation” claims.

EDIT: In other words, I’d like to ask if the two styles are at some point considered fully-totally-100% equivalent/transparent by a compiler (e.g. bit-by-bit equivalent AST at some point in a particular compiler), and if not, then what are the differences? For any (with a preference towards “modern” and gcc) compiler you know.

And, to make it more clear, I too don’t suppose that it’s going to give me much of a performance improvement, and that it usually would be premature optimization, but I am interested in whether and how much it can improve/degrade anything?

Answer 1

I have no answers for specific platforms, but I can make a few general points:

• The traditional answer on non-modern processors without branch prediction, is that the first is likely to be more efficient since in the common case it takes fewer branches. But you seem interested in modern compilers and processors.

• On modern processors, generally speaking short forward branches are not expensive, whereas mispredicted branches may be expensive. By “expensive” of course I mean a few cycles

• Quite aside from this, the compiler is entitled to order basic blocks however it likes provided it doesn’t change the logic. So when you write if (blah) {foo();} else {bar();}, the compiler is entitled to emit code like:

 

  evaluate condition blah
  jump_if_true else_label
  bar()
  jump endif_label
else_label:
  foo()
endif_label:

On the whole, gcc tends to emit things in roughly the order you write them, all else being equal. There are various things which make all else not equal, for example if you have the logical equivalent of bar(); return in two different places in your function, gcc might well coalesce those blocks, emit only one call to bar() followed by return, and jump or fall through to that from two different places.

• There are two kinds of branch prediction – static and dynamic. Static means that the CPU instructions for the branch specify whether the condition is “likely”, so that the CPU can optimize for the common case. Compilers might emit static branch predictions on some platforms, and if you’re optimizing for that platform you might write code to take account of that. You can take account of it either by knowing how your compiler treats the various control structures, or by using compiler extensions. Personally I don’t think it’s consistent enough to generalize about what compilers will do. Look at the disassembly.

• Dynamic branch prediction means that in hot code, the CPU will keep statistics for itself how likely branches are to be taken, and optimize for the common case. Modern processors use various different dynamic branch prediction techniques: http://en.wikipedia.org/wiki/Branch_predictor. Performance-critical code pretty much is hot code, and as long as the dynamic branch prediction strategy works, it very rapidly optimizes hot code. There might be certain pathological cases that confuse particular strategies, but in general you can say that anything in a tight loop where there’s a bias towards taken/not taken, will be correctly predicted most of the time

• Sometimes it doesn’t even matter whether the branch is correctly predicted or not, since some CPUs in some cases will include both possibilities in the instruction pipeline while it’s waiting for the condition to be evaluated, and ditch the unnecessary option. Modern CPUs get complicated. Even much simpler CPU designs have ways of avoiding the cost of branching, though, such as conditional instructions on ARM.

• Calls out of line to other functions will upset all such guesswork anyway. So in your example there may be small differences, and those differences may depend on the actual code in Foo, Bar and Alarm. Unfortunately it’s not possible to distinguish between significant and insignificant differences, or to account for details of those functions, without getting into the “premature optimization” accusations you’re not interested in.

• It’s almost always premature to micro-optimize code that isn’t written yet. It’s very hard to predict the performance of functions named Foo and Bar. Presumably the purpose of the question is to discern whether there’s any common gotcha that should inform coding style. To which the answer is that, thanks to dynamic branch prediction, there is not. In hot code it makes very little difference how your conditions are arranged, and where it does make a difference that difference isn’t as easily predictable as “it’s faster to take / not take the branch in an if condition”.

• If this question was intended to apply to just one single program with this code proven to be hot, then of course it can be tested, there’s no need to generalize.