这是一个愚蠢的有趣问题：

假设我们必须执行一个简单的操作，其中我们需要变量值的一半。 通常有两种方法可以执行此操作：

假设我们正在使用该语言提供的标准运算符，那么哪一个具有更好的性能？

我猜想乘法通常更好，所以我在编码时会尽量坚持下去，但是我想确认一下。

尽管我个人对Python 2.4-2.5的答案很感兴趣，但是也可以发布其他语言的答案！ 而且，如果您愿意，也可以发布其他更奇特的方式(例如使用按位移位运算符)。

Python：

乘法快33％

卢阿：

=>没有真正的区别

LuaJIT：

=>仅快5％

结论：在Python中，乘法要快于除法，但是当您使用更高级的VM或JIT接近CPU时，优势就会消失。将来的Python VM很可能会使其变得无关紧要

始终使用最清晰的东西。您所做的任何其他操作都试图使编译器的性能超越智能。如果编译器是完全智能的，它将尽最大努力优化结果，但是没有什么可以使下一个男人不讨厌您讨厌的位移解决方案(顺便说一下，我喜欢位操作，很有趣。但是很有趣！=可读) )

过早的优化是万恶之源。永远记住优化的三个规则！

如果您是专家并且可以证明需要，那么请使用以下过程：

同样，执行诸如在不需要时删除内部循环或在数组中为插入排序选择链表之类的操作也不是优化，而只是编程。

我认为这变得太挑剔了，您最好做任何使代码更具可读性的事情。除非您执行该操作数千次(甚至数百万次)，否则我怀疑有人会注意到这种差异。

如果您真的必须做出选择，则基准测试是唯一的选择。查找哪些功能给您带来了问题，然后找出功能中出现问题的位置，并修复这些部分。但是，我仍然怀疑单个数学运算(甚至重复多次，多次)是否会引起任何瓶颈。

乘法更快，除法更准确。如果您的数字不是2的幂，则将失去一些精度。

即使让编译器找出倒数常量以达到最佳精度，答案也可能有所不同。

速度问题仅可能在C / C ++或JIT语言中才有关系，即使只有在瓶颈处循环运行的情况下，速度问题才算重要。

如果您想优化代码但仍要保持清晰，请尝试以下操作：

编译器应该能够在编译时进行除法，因此您可以在运行时获得乘法。我希望精度与y = x / 2.0情况下的精度相同。

LOT可能在嵌入式处理器中需要浮点仿真来计算浮点算术，这点很重要。

只是要为"其他语言"选项添加一些内容。 C：由于这只是一项学术活动，实际上没有任何区别，所以我想我会有所作为。

我没有进行任何优化就编译为汇编，并查看了结果。 编码：

用gcc tdiv.c -O1 -o tdiv.s -S编译

除以2：

乘以0.5：

但是，当我将这些int更改为double s(这可能是python可能要做的)时，我得到了：

师：

乘法：

我没有对任何代码进行基准测试，但是仅通过检查代码就可以看到，使用整数，除以2的时间比乘以2的时间短。使用双精度，乘法的时间更短，因为编译器使用处理器的浮点操作码，即可能比不使用它们进行相同的操作运行得更快(但实际上我不知道)。因此，最终的答案表明，乘以0.5与除以2的性能取决于语言的实现及其运行的平台。最终，差异几乎可以忽略不计，除了可读性以外，您几乎永远不必担心。

作为附带说明，您可以看到在我的程序中main()返回a + b。当我拿掉volatile关键字时，您将永远不会猜出程序集的样子(不包括程序设置)：

它在一条指令中完成了除法，乘法和加法运算！显然，如果优化程序是任何受人尊敬的，您都不必为此担心。

抱歉，答案太长了。

首先，除非您使用C或ASSEMBLY进行工作，否则您可能使用的是高级语言，其中内存停滞和常规调用开销将使相乘和相除之间的差异绝对相形见to。因此，只需选择在这种情况下更好的方法即可。

如果您是从很高的级别进行交谈，那么您可能会用它来衡量任何事情的速度都不会太慢。您还会在其他答案中看到，人们需要做一百万次乘/除，才能测量两者之间的亚毫秒差异。

如果您仍然好奇，请从低级优化的角度来看：

除法往往具有比乘积更长的流水线。这意味着要花费更长的时间才能得到结果，但是如果您可以让处理器忙于执行非相关任务，那么最终花费的成本不会超过乘法运算。

流水线差异有多长完全取决于硬件。我使用的最后一个硬件是FPU乘法的9个周期和FPU除法的50个周期。听起来很多，但随后您将因内存丢失而丢失1000个周期，因此可以将其视为现实。

打个比方，就是在看电视节目时将馅饼放在微波炉里。使您离开电视节目的总时间是将其放入微波炉中并从微波炉中取出要花费多长时间。剩下的时间，您仍然看电视节目。因此，如果该饼花了10分钟而不是1分钟来煮，那么它实际上并没有用完电视上的观看时间。

在实践中，如果您要关注乘法和除法之间的差异，则需要了解管道，缓存，分支停顿，无序预测和管道依赖性。如果这听起来不像您打算解决的问题，那么正确的答案就是忽略两者之间的区别。

许多(很多)年前，绝对重要的是要避免使用除法，并且始终使用乘法，但是在那时，内存命中率就不那么重要了，除法更糟。如今，我对可读性的评价更高，但是如果没有可读性差异，我认为选择乘数是一个好习惯。

写下更清晰的陈述您的意图。

程序运行后，找出缓慢的地方，并加快速度。

不要反过来做。

做您需要的任何事情。首先考虑您的读者，在确定性能问题之前，不要担心性能。

让编译器为您完成性能。

如果您使用整数或非浮点类型，请不要忘记您的移位运算符：>

在此示例中，您可以看到，当值变小时，几乎相等的数字之间的差会产生非零结果，其中正确答案为零。

有所不同，但这取决于编译器。最初在vs2003(c ++)上，我对双精度类型(64位浮点数)没有明显的不同。但是在vs2010上再次运行测试时，我发现了巨大的差异，乘法运算的速度提高了4倍。追根溯源，似乎vs2003和vs2010会生成不同的fpu代码。

在奔腾4，2.8 GHz和vs2003上：

在Xeon W3530和vs2003上：

在Xeon W3530和vs2010上：

似乎在vs2003上，循环中的除法(因此多次使用了除数)被转换为与逆的乘法。在vs2010上，不再应用此优化(我想是因为两种方法之间的结果略有不同)。还请注意，分子为0.0时，CPU会更快地执行除法运算。我不知道芯片中硬连接的精确算法，但也许它取决于数字。

编辑18-03-2013：vs2010的观察

与第24个帖子(乘法更快)和第30个帖子一样，但有时它们都一样容易理解：

?我发现它们都一样容易阅读，并且不得不重复数十亿次。因此了解乘法通常会更快是很有用的。

这是一个愚蠢的有趣答案：

x / 2.0不等于x * 0.5

假设您在2008年10月22日编写了此方法。

十年后的今天，您了解到可以优化这段代码。 在整个应用程序中，数百种公式中都引用了该方法。 因此，您对其进行了更改，并获得了显着的5％性能提升。

更改代码是正确的决定吗？ 在数学中，这两个表达式的确相等。 在计算机科学中，并不总是如此。 有关更多详细信息，请阅读最小化准确性问题的影响。 如果您的计算值在某些时候与其他值进行了比较，则将更改边缘工况的结果。 例如。：

底线是; 一旦您解决了这两个问题中的任何一个，那就坚持下去吧！

我读过某个地方，乘法在C / C ++中更有效。没有关于解释语言的想法-由于其他所有开销，差异可能微不足道。

除非它成为一个问题，否则请坚持更可维护/更易理解的内容-当人们告诉我这是事实时，我讨厌它。

在Samsung GT-S5830上分析的Java android