例如，乘法和除法可以使用位运算符来实现
i*2 = i<<1
i*3 = (i<<1) + i;
i*10 = (i<<3) + (i<<1)
等等。
用say (i<<3)+(i<<1)乘10是否比直接用i*10更快?有没有什么输入是不能用这种方法乘或除的?
当前回答
这取决于处理器和编译器。一些编译器已经通过这种方式优化代码了，其他的还没有。 因此，每次需要以这种方式优化代码时，您都需要检查。
除非您迫切需要优化，否则我不会为了节省汇编指令或处理器周期而打乱源代码。
其他回答
据我所知，在一些机器上，乘法运算可能需要16到32个机器周期。是的，根据机器类型，位移运算符比乘除运算符快。
然而，某些机器确实有它们的数学处理器，其中包含乘法/除法的特殊指令。
简单回答:不太可能。
长一点的回答: 你的编译器有一个优化器，它知道如何像你的目标处理器体系结构一样快速地进行乘法运算。最好的办法是清楚地告诉编译器你的意图(即i*2而不是i << 1)，让它决定最快的汇编/机器码序列是什么。甚至有可能处理器本身已经将乘法指令实现为微码中的移位和加法序列。
总之，不要花太多时间担心这个。如果你想换，那就换。如果你想乘，那就乘。做语义上最清楚的事情——你的同事以后会感谢你的。或者，更有可能的是，如果你不这样做，之后会诅咒你。
它是否真的更快取决于实际使用的硬件和编译器。
In the case of signed integers and right shift vs division, it can make a difference. For negative numbers, the shift rounds rounds towards negative infinity whereas division rounds towards zero. Of course the compiler will change the division to something cheaper, but it will usually change it to something that has the same rounding behavior as division, because it is either unable to prove that the variable won't be negative or it simply doesn't care. So if you can prove that a number won't be negative or if you don't care which way it will round, you can do that optimization in a way that is more likely to make a difference.
不要这样做，除非你绝对需要这样做，并且你的代码意图是移位而不是乘法/除法。
在典型的日子里，你可能会节省一些机器周期(或松弛，因为编译器更知道优化什么)，但成本并不值得——你把时间花在小细节上而不是实际的工作上，维护代码变得更加困难，你的同事会诅咒你。
对于高负载计算，您可能需要这样做，其中每个节省的周期意味着几分钟的运行时。但是，您应该一次优化一个地方，并每次都进行性能测试，看看您是否真的使它更快了，还是破坏了编译器逻辑。
