例如，乘法和除法可以使用位运算符来实现
i*2 = i<<1
i*3 = (i<<1) + i;
i*10 = (i<<3) + (i<<1)
等等。
用say (i<<3)+(i<<1)乘10是否比直接用i*10更快?有没有什么输入是不能用这种方法乘或除的?
当前回答
我同意德鲁·霍尔的明确回答。不过，答案可能需要一些额外的注释。
对于绝大多数软件开发人员来说，处理器和编译器已经不再与问题相关。我们大多数人远远超出了8088和MS-DOS。它可能只与那些仍在开发嵌入式处理器的人有关……
在我的软件公司，Math (add/sub/mul/div)应该用于所有数学。 当数据类型之间转换时应该使用Shift。字节长度为n>>8，而不是n/256。
其他回答
只是一个具体的衡量点:许多年前，我对两个进行了基准测试 我的哈希算法的版本:
unsigned
hash( char const* s )
{
unsigned h = 0;
while ( *s != '\0' ) {
h = 127 * h + (unsigned char)*s;
++ s;
}
return h;
}
and
unsigned
hash( char const* s )
{
unsigned h = 0;
while ( *s != '\0' ) {
h = (h << 7) - h + (unsigned char)*s;
++ s;
}
return h;
}
在我对它进行基准测试的每台机器上，第一台机器的速度至少和 第二。有些令人惊讶的是，它有时更快(例如在一个 Sun Sparc)。当硬件不支持快速乘法(和 大多数当时没有)，编译器将转换乘法 转换成移位和加/减的适当组合。因为它 知道了最终的目标，它有时可以在少于指令的情况下这样做 当你明确地写出移位和加法/减法时。
请注意，这是15年前的事了。希望编译器 从那以后就越来越好了，所以你可以指望 编译器做正确的事情，可能比你做的更好。(另外, 这段代码看起来如此C'ish的原因是因为它是15年前的事情了。 显然，我今天会使用std::string和迭代器。)
不要这样做，除非你绝对需要这样做，并且你的代码意图是移位而不是乘法/除法。
在典型的日子里，你可能会节省一些机器周期(或松弛，因为编译器更知道优化什么)，但成本并不值得——你把时间花在小细节上而不是实际的工作上，维护代码变得更加困难，你的同事会诅咒你。
对于高负载计算，您可能需要这样做，其中每个节省的周期意味着几分钟的运行时。但是，您应该一次优化一个地方，并每次都进行性能测试，看看您是否真的使它更快了，还是破坏了编译器逻辑。
我同意德鲁·霍尔的明确回答。不过，答案可能需要一些额外的注释。
对于绝大多数软件开发人员来说，处理器和编译器已经不再与问题相关。我们大多数人远远超出了8088和MS-DOS。它可能只与那些仍在开发嵌入式处理器的人有关……
在我的软件公司，Math (add/sub/mul/div)应该用于所有数学。 当数据类型之间转换时应该使用Shift。字节长度为n>>8，而不是n/256。
如果在gcc编译器上比较x+x, x*2和x<<1语法的输出，那么在x86汇编中会得到相同的结果:https://godbolt.org/z/JLpp0j
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-4], edi
mov eax, DWORD PTR [rbp-4]
add eax, eax
pop rbp
ret
因此，您可以认为gcc足够聪明，可以独立于您输入的内容确定自己的最佳解决方案。
简单回答:不太可能。
长一点的回答: 你的编译器有一个优化器，它知道如何像你的目标处理器体系结构一样快速地进行乘法运算。最好的办法是清楚地告诉编译器你的意图(即i*2而不是i << 1)，让它决定最快的汇编/机器码序列是什么。甚至有可能处理器本身已经将乘法指令实现为微码中的移位和加法序列。
总之，不要花太多时间担心这个。如果你想换，那就换。如果你想乘，那就乘。做语义上最清楚的事情——你的同事以后会感谢你的。或者，更有可能的是，如果你不这样做，之后会诅咒你。
