它是否真的更快取决于实际使用的硬件和编译器。

用say (i<<3)+(i<<1)乘10是否比直接用i*10更快?

它可能在您的机器上，也可能不在您的机器上——如果您关心的话，请在您的实际使用情况中进行测量。

一个案例研究——从486到core i7

Benchmarking is very difficult to do meaningfully, but we can look at a few facts. From http://www.penguin.cz/~literakl/intel/s.html#SAL and http://www.penguin.cz/~literakl/intel/i.html#IMUL we get an idea of x86 clock cycles needed for arithmetic shift and multiplication. Say we stick to "486" (the newest one listed), 32 bit registers and immediates, IMUL takes 13-42 cycles and IDIV 44. Each SAL takes 2, and adding 1, so even with a few of those together shifting superficially looks like a winner.

如今，随着酷睿i7的出现:

(来自http://software.intel.com/en-us/forums/showthread.php?t=61481)

整数加法的延迟为1个周期，整数乘法的延迟为3个周期。您可以在“Intel®64 and IA-32架构优化参考手册”的附录C中找到延迟和吞吐量，该手册位于http://www.intel.com/products/processor/manuals/。

(来自英特尔的宣传)

使用SSE，酷睿i7可以同时发出加法和乘法指令，导致每个时钟周期有8个浮点运算(FLOP)的峰值速率

That gives you an idea of how far things have come. The optimisation trivia - like bit shifting versus * - that was been taken seriously even into the 90s is just obsolete now. Bit-shifting is still faster, but for non-power-of-two mul/div by the time you do all your shifts and add the results it's slower again. Then, more instructions means more cache faults, more potential issues in pipelining, more use of temporary registers may mean more saving and restoring of register content from the stack... it quickly gets too complicated to quantify all the impacts definitively but they're predominantly negative.

源代码中的功能vs实现

More generally, your question is tagged C and C++. As 3rd generation languages, they're specifically designed to hide the details of the underlying CPU instruction set. To satisfy their language Standards, they must support multiplication and shifting operations (and many others) even if the underlying hardware doesn't. In such cases, they must synthesize the required result using many other instructions. Similarly, they must provide software support for floating point operations if the CPU lacks it and there's no FPU. Modern CPUs all support * and <<, so this might seem absurdly theoretical and historical, but the significance thing is that the freedom to choose implementation goes both ways: even if the CPU has an instruction that implements the operation requested in the source code in the general case, the compiler's free to choose something else that it prefers because it's better for the specific case the compiler's faced with.

示例(使用假设的汇编语言)

source           literal approach         optimised approach
#define N 0
int x;           .word x                xor registerA, registerA
x *= N;          move x -> registerA
                 move x -> registerB
                 A = B * immediate(0)
                 store registerA -> x
  ...............do something more with x...............

像exclusive or (xor)这样的指令与源代码没有关系，但是用自身进行xor-ing会清除所有的位，所以它可以用来将一些东西设置为0。暗示内存地址的源代码可能不需要使用任何内存地址。

These kind of hacks have been used for as long as computers have been around. In the early days of 3GLs, to secure developer uptake the compiler output had to satisfy the existing hardcore hand-optimising assembly-language dev. community that the produced code wasn't slower, more verbose or otherwise worse. Compilers quickly adopted lots of great optimisations - they became a better centralised store of it than any individual assembly language programmer could possibly be, though there's always the chance that they miss a specific optimisation that happens to be crucial in a specific case - humans can sometimes nut it out and grope for something better while compilers just do as they've been told until someone feeds that experience back into them.

因此，即使移动和添加在某些特定的硬件上仍然更快，那么编译器编写者可能已经准确地计算出什么时候它既安全又有益。

可维护性

如果你的硬件改变了，你可以重新编译，它会查看目标CPU并做出另一个最佳选择，而你不太可能想要重新审视你的“优化”或列出哪些编译环境应该使用乘法，哪些编译环境应该移位。想想10多年前编写的所有非2位移位的“优化”，现在它们在现代处理器上运行时减慢了它们所使用的代码……!

值得庆幸的是，像GCC这样的优秀编译器通常可以在启用任何优化时用直接乘法替换一系列位移位和算术(即. ...main(…){return (argc << 4) + (argc << 2) + argc;} -> imull $ 21,8 (%ebp)， %eax)所以重新编译可能有帮助，即使不修复代码，但这是不保证的。

实现乘法或除法的奇怪位移代码远不能表达您在概念上试图实现的目标，因此其他开发人员会对此感到困惑，而困惑的程序员更有可能引入错误或删除一些必要的东西，以努力恢复表面上的理智。如果你只做那些不明显的事情，但它们确实是有实际好处的，然后好好记录它们(但不要记录其他直观的东西)，每个人都会更快乐。

通解和部分解

如果你有一些额外的知识，比如你的int将只存储值x, y和z，那么你可能能够制定出一些指令，适用于这些值，并更快地得到你的结果，而不是编译器没有洞察，需要一个实现，适用于所有int值。例如，考虑你的问题:

乘法和除法可以使用位运算符实现…

你演示了乘法，那除法呢?

int x;
x >> 1;   // divide by 2?

根据c++标准5.8:

-3—E1 >> E2为E1位右移E2位位置。如果E1为无符号类型，或者E1为有符号类型且值为非负值，则结果值为E1的商除以2的E2次方的积分部分。如果E1具有符号类型和负值，则结果值是由实现定义的。

因此，当x为负时，位移位有一个实现定义的结果:在不同的机器上可能不会以相同的方式工作。但是，/工作起来更容易预测。(它也可能不是完全一致的，因为不同的机器可能有不同的负数表示，因此即使构成表示的位数相同，范围也不同。)

You may say "I don't care... that int is storing the age of the employee, it can never be negative". If you have that kind of special insight, then yes - your >> safe optimisation might be passed over by the compiler unless you explicitly do it in your code. But, it's risky and rarely useful as much of the time you won't have this kind of insight, and other programmers working on the same code won't know that you've bet the house on some unusual expectations of the data you'll be handling... what seems a totally safe change to them might backfire because of your "optimisation".

有没有什么输入是不能用这种方法乘或除的?

是的……如上所述，负数在被位移“分割”时具有实现定义的行为。

不要这样做，除非你绝对需要这样做，并且你的代码意图是移位而不是乘法/除法。

在典型的日子里，你可能会节省一些机器周期(或松弛，因为编译器更知道优化什么)，但成本并不值得——你把时间花在小细节上而不是实际的工作上，维护代码变得更加困难，你的同事会诅咒你。

对于高负载计算，您可能需要这样做，其中每个节省的周期意味着几分钟的运行时。但是，您应该一次优化一个地方，并每次都进行性能测试，看看您是否真的使它更快了，还是破坏了编译器逻辑。

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

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

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中这样做)而改变。

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

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

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