You can’t reasonably even talk about the “speed” of operations in isolation. You can discuss their latency in isolation (in which case a branch or cmov, on average, really is faster than some ALU operations), but that has essentially nothing to do with their actual impact on performance in situ, except for in the most unusual cases.

Throughput is somewhat more reasonable, but then large parts of the hierarchy collapse entirely. A more reasonable approach is to think about resource (ALU, LSU, branch, cache, etc) pressure, but that doesn’t fit nicely into a soundbite and requires actual thought.

I'm guessing he doesn't mean branching on a result, he means just comparing two things via cmp.

If the branch is predictable, and the cpu guesses correctly, then it is faster than integer arithmetic.

A branch miss on the other hand is much more expensive, about 14 cycles last time I was testing (on a core i5 desktop cpu from a few years ago).

For the vast majority of code there is a branch anyway because the comparison result is used in an conditional statement. This means a good inlining compiler probably generates one branch for the comparison plus conditional.

i.e. this is why measuring the whole is so important in isolation it is slower but in more complicated code it is likely to be faster.

bool b = x < y;

It's a matter of semantics, but this does not contradict the parent. Under-the-hood in assembly, this is split into two operations: a comparison (cmp), and then a second operation that sets 'b'. This could be done with a branch (jl), a conditional move (cmovl), or a conditional set (setl). You can see the various solutions used by different compilers with mattgodbolt's GCC explorer: http://gcc.godbolt.org/#%7B%22version%22%3A3%2C%22filterAsm%...

Oh interesting. Thanks.