Python:为什么*和**比/和sqrt()更快?

mac*_*mac 79 c python performance python-2.7 python-internals

在优化我的代码时,我意识到以下内容:

>>> 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]
Run Code Online (Sandbox Code Playgroud)

并且:

>>> 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]
Run Code Online (Sandbox Code Playgroud)

我假设它与C实现python的方式有关,但我想知道是否有人会解释为什么会如此?

NPE*_*NPE 113

结果的(有些出乎意料的)原因是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)
Run Code Online (Sandbox Code Playgroud)

编译为以下字节码:

  # 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)
Run Code Online (Sandbox Code Playgroud)

正如您所看到的,乘法和取幂完全没有时间,因为它们是在编译代码时完成的.分区需要更长时间,因为它在运行时发生 平方根不仅是四者中计算量最大的操作,它还会产生其他人没有的各种开销(属性查找,函数调用等).

如果你消除了常量折叠的影响,那么将乘法和除法分开几乎没有:

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
Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

编辑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;
Run Code Online (Sandbox Code Playgroud)

-Qnew标志启用PEP 238中定义的"真正划分" .

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