3 ms·
Am I mis-reading this? The article keeps claiming there is no difference but the way I read it the compiler(s) are transforming mul/div to shifts. i.e. it very
by sambe 6y ago
Am I mis-reading this? The article keeps claiming there is no difference but the way I read it the compiler(s) are transforming mul/div to shifts. i.e. it very likely is faster on the hardware but it won't matter for this particular toolchain because of the conversion.
- wmf 6y agoThe point is that from the perspective of the programmer there is no performance difference between / 2 and >> 1.
- chrisseaton 6y ago> Am I mis-reading this? The article keeps claiming there is no difference but the way I read it the compiler(s) are transforming mul/div to shifts. i.e. it very likely is faster on the hardware but it won't matter for this particular toolchain because of the conversion. There is no difference... because of the conversion.
- sambe 6y agoRight: for now, in certain situations, on the tested toolchain. Even ignoring those caveats, several commentators seem to have got the impression that this applies to the CPU.
- wk_end 6y agoI wonder: do any microarchitectures detect and redirect multiplications/divisions by powers of two to the shifter?
- uluyol 6y agoThese types of transformations are simple to detect, well known, and applied by ~every compiler. Unless you have evidence otherwise (ASM differences or benchmarks), there is no use in manually transforming your arithmetic into something more complex but faster. The compiler will do it for you.
- sambe 6y agoI think that's a point which is bordering on religious - many people would debate trusting the compiler, especially over time and more complex situations. I'd certainly tend to agree with you in general but more for the reason that the compiler can abstract over hardware changes across time. I'd take that benefit over the risk of the optimisation not being applied for most code I write - non-optimisations would be considered bugs and probably/eventually fixed. I'd strongly disagree the code is more complex (in this case).
- merlincorey 6y agoIt especially seems religious to me because it's saying that somehow "/ 2" is simpler than ">> 1" because it has one less character for the symbol, and because division is a more commonly known operator to most people than bitwise shifting. It seems to me that they are equally simple if we assume that programmers dealing with low level or performance intensive code know what a bitwise shift is and ignore the extra character, then they are literally equivalently complicated expressions with 1 symbol and 1 value applied to the symbol.
- kadoban 6y agoCode does not happen in a vacuum. Which is more understandable/simple depends on the domain of the code in question. Usually that's going to be the multiply or the divide.
- merlincorey 6y agoRight, but my statement was that the domain would be low level or performance intensive code -- do you disagree that in that domain they are equally simple?
- umvi 6y ago> Am I mis-reading this? Yes, the point of the article is to convince you to stop micro-optimizing code for imagined performance benefits, and instead code for readability (the compiler will worry about optimizing).