4 ms·

When did CMOVs become efficient again? The x86 optimization guide used to warn people not to use them, around 2008.

10000truths 5y ago
https://www.agner.org/optimize/optimizing_assembly.pdf#page=70 https://www.agner.org/optimize/optimizing_assembly.pdf#page=... TL;DR rule of thumb is that conditional jump is better than CMOV if the code is part of a dependency chain and the prediction rate is better than 75%.
- mirker 5y ago
  Are dependency chains complex functions or a few instructions? For example, I see people using ternary expressions “a > b : c ? d”. I’m trying to understand if this is an algorithmic problem or a microarchitecture problem. Are “c” and “d” simple? If both are heavy-duty and approximately the same complexity, evaluating both would be 2x slower than evaluating one, but then you’d have to account for probability of misprediction. Meanwhile, if they are simple, I could imagine the CPU tracking both branch register-level states simultaneously with minimal impact on performance (using register-renaming, for example). In other words, how much better would CMOV be if the hardware was given more micro architecture resources?
wolf550e 5y ago
CMOVs were terrible on Pentium 4 but ok on PPro, Pentium M, Core, Core 2, Sandybridge, Skylake, etc. Also ok on Atom and on AMD chips.
- speed_spread 5y ago
  At that point, we might just simplify this to "Pentium 4 was terrible"
ncmncm 5y ago
Cmov is, and was, efficient whenever branch prediction is unreliable. Clang will turn eligible ?: expressions into cmov. Gcc will do no more than one of those per basic block, subject to fragile conditions. Gcc got its fingers badly burned by overuse of cmov. [Edit: I am wrong! Gcc would not do it when I was trying. More research needed.] Generally, branches break dependency chains, enabling more implicit speculative parallelism. Older cores stuck cmov ops onto dependency chains, where more recently they are treated more like branches. That gives you less speculative evaluation, but consumes less state that would be discarded on a mis-predicted branch.

https://www.agner.org/optimize/optimizing_assembly.pdf#page=70 https://www.agner.org/optimize/optimizing_assembly.pdf#page=... TL;DR rule of thumb is that conditional jump is better than CMOV if the code is part of a dependency chain and the prediction rate is better than 75%.

mirker 5y ago
Are dependency chains complex functions or a few instructions? For example, I see people using ternary expressions “a > b : c ? d”. I’m trying to understand if this is an algorithmic problem or a microarchitecture problem. Are “c” and “d” simple? If both are heavy-duty and approximately the same complexity, evaluating both would be 2x slower than evaluating one, but then you’d have to account for probability of misprediction. Meanwhile, if they are simple, I could imagine the CPU tracking both branch register-level states simultaneously with minimal impact on performance (using register-renaming, for example). In other words, how much better would CMOV be if the hardware was given more micro architecture resources?

wolf550e 5y ago

CMOVs were terrible on Pentium 4 but ok on PPro, Pentium M, Core, Core 2, Sandybridge, Skylake, etc. Also ok on Atom and on AMD chips.

speed_spread 5y ago
At that point, we might just simplify this to "Pentium 4 was terrible"

ncmncm 5y ago

Cmov is, and was, efficient whenever branch prediction is unreliable. Clang will turn eligible ?: expressions into cmov. Gcc will do no more than one of those per basic block, subject to fragile conditions. Gcc got its fingers badly burned by overuse of cmov. [Edit: I am wrong! Gcc would not do it when I was trying. More research needed.] Generally, branches break dependency chains, enabling more implicit speculative parallelism. Older cores stuck cmov ops onto dependency chains, where more recently they are treated more like branches. That gives you less speculative evaluation, but consumes less state that would be discarded on a mis-predicted branch.