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

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

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

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

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

简单回答:不太可能。

长一点的回答: 你的编译器有一个优化器，它知道如何像你的目标处理器体系结构一样快速地进行乘法运算。最好的办法是清楚地告诉编译器你的意图(即i*2而不是i << 1)，让它决定最快的汇编/机器码序列是什么。甚至有可能处理器本身已经将乘法指令实现为微码中的移位和加法序列。

总之，不要花太多时间担心这个。如果你想换，那就换。如果你想乘，那就乘。做语义上最清楚的事情——你的同事以后会感谢你的。或者，更有可能的是，如果你不这样做，之后会诅咒你。

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

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

用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".

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

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

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