4 ms·

>The speed hierarchy of operations is: > > comparisons > (u)int add, subtract, bitops, shift > floating point add, sub (separate unit!) > ... >

>The speed hierarchy of operations is: > > comparisons > (u)int add, subtract, bitops, shift > floating point add, sub (separate unit!) > ... > (u)int division, remainder This can't be right. A comparison necessitates either a branch or a cmov, and there's no way that either of those is faster than a basic ALU operation.

flebron 12y ago
I'm guessing he doesn't mean branching on a result, he means just comparing two things via cmp.
- deleted 12y ago
  [deleted]
stephencanon 12y ago
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.
axylone 12y ago
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).
thwest 12y ago
bool b = x < y;
- nkurz 12y ago
  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%22%3A%7B%22labels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue%7D%2C%22compilers%22%3A%5B%7B%22sourcez%22%3A%22JYOwLgBANgpgznA%2BmAFgQxAClJAHgGghwgE8BKCAbwCgIIAjAe0agYgF4JcIAeUgbloQATjDABXYSAaCAvtWpAAA%22%2C%22compiler%22%3A%22%2Fusr%2Fbin%2Fg%2B%2B-4.8%22%2C%22options%22%3A%22-O3%20%20%22%7D%5D%7D http://gcc.godbolt.org/#%7B%22version%22%3A3%2C%22filterAsm%...
  - thwest 12y ago
    Oh interesting. Thanks.
jerven 12y 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.

flebron 12y ago

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

deleted 12y ago
[deleted]

stephencanon 12y ago

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.

axylone 12y ago

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).

thwest 12y ago

bool b = x < y;

nkurz 12y ago
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%22%3A%7B%22labels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue%7D%2C%22compilers%22%3A%5B%7B%22sourcez%22%3A%22JYOwLgBANgpgznA%2BmAFgQxAClJAHgGghwgE8BKCAbwCgIIAjAe0agYgF4JcIAeUgbloQATjDABXYSAaCAvtWpAAA%22%2C%22compiler%22%3A%22%2Fusr%2Fbin%2Fg%2B%2B-4.8%22%2C%22options%22%3A%22-O3%20%20%22%7D%5D%7D http://gcc.godbolt.org/#%7B%22version%22%3A3%2C%22filterAsm%...
- thwest 12y ago
  Oh interesting. Thanks.

jerven 12y 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.