Python：为什么 * 和 ** 比 / 和 sqrt() 快？答案

【问题标题】：Python: why are * and ** faster than / and sqrt()?Python：为什么 * 和 ** 比 / 和 sqrt() 快？
【发布时间】：2011-12-25 11:08:25
【问题描述】：

在优化我的代码时，我意识到以下几点：

>>> from timeit import Timer as T
>>> T(lambda : 1234567890 / 4.0).repeat()
[0.22256922721862793, 0.20560789108276367, 0.20530295372009277]
>>> from __future__ import division
>>> T(lambda : 1234567890 / 4).repeat()
[0.14969301223754883, 0.14155197143554688, 0.14141488075256348]
>>> T(lambda : 1234567890 * 0.25).repeat()
[0.13619112968444824, 0.1281130313873291, 0.12830305099487305]

还有：

>>> from math import sqrt
>>> T(lambda : sqrt(1234567890)).repeat()
[0.2597470283508301, 0.2498021125793457, 0.24994492530822754]
>>> T(lambda : 1234567890 ** 0.5).repeat()
[0.15409398078918457, 0.14059877395629883, 0.14049601554870605]

我认为这与 python 在 C 中实现的方式有关，但我想知道是否有人愿意解释为什么会这样？

【问题讨论】：

您接受的问题的答案（我假设它回答了您的真实问题）与您的问题标题没有太大关系。你可以编辑它以与不断折叠有关吗？
@ZanLynx - 嗨。你介意澄清一下吗？我发现问题标题准确地表达了我想知道的内容（为什么 X 比 Y 快）并且我选择的答案正是如此......似乎与我完美匹配......但也许我忽略了一些东西？
乘法和幂函数总是比除法和 sqrt() 函数更快，因为它们的本质。除法和根运算一般要使用一系列越来越精细的近似，不能像乘法那样直接得到正确答案。
我觉得问题标题应该说明值都是字面常量这一事实，事实证明这是答案的关键。在典型的硬件上，整数和 FP 乘法和加法/减法很便宜； integer 和 FP div 和 FP sqrt 都很昂贵（可能比 FP mul 低 3 倍的延迟和 10 倍的吞吐量）。（大多数 CPU 在硬件中将这些操作作为单个 asm 指令实现，这与 cube-root 或 pow() 之类的不同）。
但如果 Python 解释器开销仍然使 mul 和 div asm 指令之间的差异相形见绌，我不会感到惊讶。有趣的事实：在 x86 上，FP 除法通常比整数除法性能更高。 (agner.org/optimize)。 Intel Skylake 上的 64 位整数除法具有 42-95 个周期的延迟，而 32 位整数为 26 个周期，而双精度 FP 为 14 个周期。（64 位整数乘法是 3 个周期延迟，FP mul 是 4）。吞吐量差异甚至更大（int/FP mul 和 add 都至少每个时钟一个，但除法和 sqrt 没有完全流水线化。）

标签： python c performance python-2.7 python-internals

【解决方案1】：

您的结果的（有点出乎意料的）原因是 Python 似乎折叠了涉及浮点乘法和幂运算的常量表达式，而不是除法。 math.sqrt() 完全不同，因为它没有字节码并且涉及函数调用。

在 Python 2.6.5 上，以下代码：

x1 = 1234567890.0 / 4.0
x2 = 1234567890.0 * 0.25
x3 = 1234567890.0 ** 0.5
x4 = math.sqrt(1234567890.0)

编译成以下字节码：

  # x1 = 1234567890.0 / 4.0
  4           0 LOAD_CONST               1 (1234567890.0)
              3 LOAD_CONST               2 (4.0)
              6 BINARY_DIVIDE       
              7 STORE_FAST               0 (x1)

  # x2 = 1234567890.0 * 0.25
  5          10 LOAD_CONST               5 (308641972.5)
             13 STORE_FAST               1 (x2)

  # x3 = 1234567890.0 ** 0.5
  6          16 LOAD_CONST               6 (35136.418286444619)
             19 STORE_FAST               2 (x3)

  # x4 = math.sqrt(1234567890.0)
  7          22 LOAD_GLOBAL              0 (math)
             25 LOAD_ATTR                1 (sqrt)
             28 LOAD_CONST               1 (1234567890.0)
             31 CALL_FUNCTION            1
             34 STORE_FAST               3 (x4)

正如您所见，乘法和求幂完全不需要时间，因为它们在编译代码时就完成了。除法需要更长的时间，因为它发生在运行时。平方根不仅是这四个运算中计算量最大的运算，而且还会产生其他运算不会产生的各种开销（属性查找、函数调用等）。

如果你消除了常量折叠的影响，那么乘法和除法就没有什么分开的了：

In [16]: x = 1234567890.0

In [17]: %timeit x / 4.0
10000000 loops, best of 3: 87.8 ns per loop

In [18]: %timeit x * 0.25
10000000 loops, best of 3: 91.6 ns per loop

math.sqrt(x) 实际上比x ** 0.5 快一点，大概是因为它是后者的特例，因此可以更有效地完成，尽管有开销：

In [19]: %timeit x ** 0.5
1000000 loops, best of 3: 211 ns per loop

In [20]: %timeit math.sqrt(x)
10000000 loops, best of 3: 181 ns per loop

编辑 2011-11-16： 常量表达式折叠由 Python 的窥孔优化器完成。源代码 (peephole.c) 包含以下注释，解释了为什么不折叠常量除法：

    case BINARY_DIVIDE:
        /* Cannot fold this operation statically since
           the result can depend on the run-time presence
           of the -Qnew flag */
        return 0;

-Qnew 标志启用PEP 238 中定义的“真正除法”。

【讨论】：

也许是在“保护”不被零除？
@missingno：我不清楚为什么需要任何这样的“保护”，因为这两个参数在编译时都是已知的，结果也是如此（它是以下之一：+inf，-inf，南）。
常量折叠在 Python 3 中与 / 一起使用，在 Python 2 和 3 中与 // 一起使用。所以这很可能是因为/ 在 Python 中可以有不同的含义2. 可能当常量折叠完成后，还不知道from __future__ import division是否生效？
@aix - Python 2.7 中的1./0. 不会导致NaN，而是ZeroDivisionError。
@Caridorc ：Python 被编译成字节码（.pyc 文件），然后由 Python 运行时解释。字节码与汇编/机器代码（例如，C 编译器生成的代码）不同。 dis 模块可用于检查给定代码片段编译成的字节码。