Python测试对相同的随机数执行相同的乘法1亿次。

>>> from timeit import timeit
>>> setup_str = 'import scipy; from scipy import random; scipy.random.seed(0)'
>>> N = 10*1000*1000
>>> timeit('x=random.randint(65536);', setup=setup_str, number=N)
1.894096851348877 # Time from generating the random #s and no opperati

>>> timeit('x=random.randint(65536); x*2', setup=setup_str, number=N)
2.2799630165100098
>>> timeit('x=random.randint(65536); x << 1', setup=setup_str, number=N)
2.2616429328918457

>>> timeit('x=random.randint(65536); x*10', setup=setup_str, number=N)
2.2799630165100098
>>> timeit('x=random.randint(65536); (x << 3) + (x<<1)', setup=setup_str, number=N)
2.9485139846801758

>>> timeit('x=random.randint(65536); x // 2', setup=setup_str, number=N)
2.490908145904541
>>> timeit('x=random.randint(65536); x / 2', setup=setup_str, number=N)
2.4757170677185059
>>> timeit('x=random.randint(65536); x >> 1', setup=setup_str, number=N)
2.2316000461578369

因此，在python中做移位而不是用2的幂来做乘法/除法，会有轻微的改进(~10%用于除法;~1%的乘法)。如果它不是2的幂，可能会有相当大的放缓。

同样，这些#将根据你的处理器、编译器(或解释器——为了简单起见，在python中这样做)而改变。

和其他人一样，不要过早地优化。编写可读性非常强的代码，如果不够快就进行分析，然后尝试优化慢的部分。请记住，编译器在优化方面比您做得更好。

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

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

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

除了所有其他好的答案，让我指出当你指除法或乘法时不使用shift的另一个原因。我从未见过有人因为忘记乘法和加法的相对优先级而导致错误。我曾经见过，当维护程序员忘记了通过移位的“乘法”在逻辑上是乘法，但在语法上与乘法的优先级不同时，就会引入错误。X * 2 + z和X << 1 + z非常不同!

如果你处理的是数字，那就使用算术运算符，比如+ - * / %。如果您正在处理比特数组，请使用& ^ | >>这样的比特旋转操作符。不要把它们混在一起;一个表达式如果同时具有位旋转和算术，那么这个表达式就是一个等待发生的错误。

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

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

移位通常比指令级的乘法快得多，但你可能会浪费时间做过早的优化。编译器可以在编译时很好地执行这些优化。自己做会影响可读性，而且可能对性能没有影响。如果您已经进行了概要分析并发现这是一个瓶颈，那么这样做可能是值得的。

实际上，这种被称为“魔法除法”的除法技巧实际上可以产生巨大的收益。同样，你应该首先分析它是否需要。但是如果你真的使用它，周围有一些有用的程序可以帮助你弄清楚相同的除法语义需要什么指令。这里有一个例子:http://www.masm32.com/board/index.php?topic=12421.0

我从MASM32上的OP线程中引用了一个例子:

include ConstDiv.inc
...
mov eax,9999999
; divide eax by 100000
cdiv 100000
; edx = quotient

会产生:

mov eax,9999999
mov edx,0A7C5AC47h
add eax,1
.if !CARRY?
    mul edx
.endif
shr edx,16

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

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