Why is a conditional move not vulnerable to Branch Prediction Failure?

by

Mis-predicted branches are expensive

A modern processor generally executes between one and three instructions each cycle if things go well (if it does not stall waiting for data dependencies for these instructions to arrive from previous instructions or from memory).

The statement above holds surprisingly well for tight loops, but this shouldn’t blind you to one additional dependency that can prevent an instruction to be executed when its cycle comes:
for an instruction to be executed, the processor must have started to fetch and decode it 15-20 cycles before.

What should the processor do when it encounters a branch? Fetching and decoding both targets does not scale (if more branches follow, an exponential number of paths would have to be fetched in parallel). So the processor only fetches and decodes one of the two branches, speculatively.

This is why mis-predicted branches are expensive: they cost the 15-20 cycles that are usually invisible because of an efficient instruction pipeline.

Conditional move is never very expensive

Conditional move does not require prediction, so it can never have this penalty. It has data dependencies, same as ordinary instructions. In fact, a conditional move has more data dependencies than ordinary instructions, because the data dependencies include both “condition true” and “condition false” cases. After an instruction that conditionally moves r1 to r2, the contents of r2 seem to depend on both the previous value of r2 and on r1. A well-predicted conditional branch allows the processor to infer more accurate dependencies. But data dependencies typically take one-two cycles to arrive, if they need time to arrive at all.

Note that a conditional move from memory to register would sometimes be a dangerous bet: if the condition is such that the value read from memory is not assigned to the register, you have waited on memory for nothing. But the conditional move instructions offered in instruction sets are typically register to register, preventing this mistake on the part of the programmer.

More Related Contents:

  1. What setup does REP do?
  2. What is the best way to set a register to zero in x86 assembly: xor, mov or and?
  3. Why is the loop instruction slow? Couldn’t Intel have implemented it efficiently?
  4. Why are loops always compiled into “do…while” style (tail jump)?
  5. Enhanced REP MOVSB for memcpy
  6. How many CPU cycles are needed for each assembly instruction?
  7. Adding a redundant assignment speeds up code when compiled without optimization
  8. Is performance reduced when executing loops whose uop count is not a multiple of processor width?
  9. Understanding the impact of lfence on a loop with two long dependency chains, for increasing lengths
  10. How are x86 uops scheduled, exactly?
  11. Why does breaking the “output dependency” of LZCNT matter?
  12. What methods can be used to efficiently extend instruction length on modern x86?
  13. 32-byte aligned routine does not fit the uops cache
  14. Is ADD 1 really faster than INC ? x86 [duplicate]
  15. Size of store buffers on Intel hardware? What exactly is a store buffer?
  16. Avoid stalling pipeline by calculating conditional early
  17. Can modern x86 implementations store-forward from more than one prior store?
  18. Assembly – How to score a CPU instruction by latency and throughput
  19. Unexpectedly poor and weirdly bimodal performance for store loop on Intel Skylake
  20. Performance optimisations of x86-64 assembly – Alignment and branch prediction
  21. Relative performance of x86 inc vs. add instruction
  22. How can the rep stosb instruction execute faster than the equivalent loop?
  23. Performance optimization strategies of last resort [closed]
  24. Why does C++ code for testing the Collatz conjecture run faster than hand-written assembly?
  25. Google app script timeout ~ 5 minutes?
  26. What is the purpose of the EBP frame pointer register?
  27. Is it safe to read past the end of a buffer within the same page on x86 and x64?
  28. When, if ever, is loop unrolling still useful?
  29. x86_64: is IMUL faster than 2x SHL + 2x ADD?
  30. Why does this code execute more slowly after strength-reducing multiplications to loop-carried additions?

Leave a Comment