据我所知，在一些机器上，乘法运算可能需要16到32个机器周期。是的，根据机器类型，位移运算符比乘除运算符快。

然而，某些机器确实有它们的数学处理器，其中包含乘法/除法的特殊指令。

我同意德鲁·霍尔的明确回答。不过，答案可能需要一些额外的注释。

对于绝大多数软件开发人员来说，处理器和编译器已经不再与问题相关。我们大多数人远远超出了8088和MS-DOS。它可能只与那些仍在开发嵌入式处理器的人有关……

在我的软件公司，Math (add/sub/mul/div)应该用于所有数学。 当数据类型之间转换时应该使用Shift。字节长度为n>>8，而不是n/256。

这取决于处理器和编译器。一些编译器已经通过这种方式优化代码了，其他的还没有。 因此，每次需要以这种方式优化代码时，您都需要检查。

除非您迫切需要优化，否则我不会为了节省汇编指令或处理器周期而打乱源代码。

I think in the one case that you want to multiply or divide by a power of two, you can't go wrong with using bitshift operators, even if the compiler converts them to a MUL/DIV, because some processors microcode (really, a macro) them anyway, so for those cases you will achieve an improvement, especially if the shift is more than 1. Or more explicitly, if the CPU has no bitshift operators, it will be a MUL/DIV anyway, but if the CPU has bitshift operators, you avoid a microcode branch and this is a few instructions less.

I am writing some code right now that requires a lot of doubling/halving operations because it is working on a dense binary tree, and there is one more operation that I suspect might be more optimal than an addition - a left (power of two multiply) shift with an addition. This can be replaced with a left shift and an xor if the shift is wider than the number of bits you want to add, easy example is (i<<1)^1, which adds one to a doubled value. This does not of course apply to a right shift (power of two divide) because only a left (little endian) shift fills the gap with zeros.

在我的代码中，这些乘/除2和2的幂运算被大量使用，因为公式已经很短了，每条可以消除的指令都可以获得很大的收益。如果处理器不支持这些位移操作符，就不会有增益，也不会有损失。

Also, in the algorithms I am writing, they visually represent the movements that occur so in that sense they are in fact more clear. The left hand side of a binary tree is bigger, and the right is smaller. As well as that, in my code, odd and even numbers have a special significance, and all left-hand children in the tree are odd and all right hand children, and the root, are even. In some cases, which I haven't encountered yet, but may, oh, actually, I didn't even think of this, x&1 may be a more optimal operation compared to x%2. x&1 on an even number will produce zero, but will produce 1 for an odd number.

再深入一点，如果x和3是0，我就知道4是这个数的因数，x%7是8，以此类推。我知道这些情况可能有有限的效用，但很高兴知道你可以避免模运算而使用按位逻辑运算，因为按位运算几乎总是最快的，而且对编译器来说不太可能是模糊的。

我在很大程度上发明了密集二叉树的领域，所以我预计人们可能不会理解这个评论的价值，因为很少有人想只对2的幂进行因数分解，或者只对2的幂进行乘/除。

只是一个具体的衡量点:许多年前，我对两个进行了基准测试 我的哈希算法的版本:

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和迭代器。)

Shift和整数乘法指令在大多数现代cpu上具有相似的性能——在20世纪80年代，整数乘法指令相对较慢，但通常情况下不再是这样。整数乘法指令可能有更高的延迟，所以仍然可能有移位更可取的情况。同样的情况下，你可以让更多的执行单元忙(尽管这是有利有弊)。

整数除法仍然相对较慢，所以使用shift代替2的幂除法仍然是一种胜利，大多数编译器将其作为一种优化来实现。但是请注意，要使这种优化有效，红利需要是无符号的，或者必须已知是正的。对于负红利，移位和除法是不相等的!

#include <stdio.h>

int main(void)
{
    int i;

    for (i = 5; i >= -5; --i)
    {
        printf("%d / 2 = %d, %d >> 1 = %d\n", i, i / 2, i, i >> 1);
    }
    return 0;
}

输出:

5 / 2 = 2, 5 >> 1 = 2
4 / 2 = 2, 4 >> 1 = 2
3 / 2 = 1, 3 >> 1 = 1
2 / 2 = 1, 2 >> 1 = 1
1 / 2 = 0, 1 >> 1 = 0
0 / 2 = 0, 0 >> 1 = 0
-1 / 2 = 0, -1 >> 1 = -1
-2 / 2 = -1, -2 >> 1 = -1
-3 / 2 = -1, -3 >> 1 = -2
-4 / 2 = -2, -4 >> 1 = -2
-5 / 2 = -2, -5 >> 1 = -3

所以如果你想帮助编译器，那么确保变量或表达式在被除数显式无符号。