c#和python哪个效率更高,关于C#：Python：为什么*和**比/和sqrt（）更快？

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

>>> 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]

号

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

你为你的问题接受的答案(我认为答案是你真正的问题)与你的题目没有太多关系。你能把它编辑成和不断的折叠有关吗？

@赞林克斯-嗨。你介意澄清一下吗？我发现题目准确地表达了我想知道的(为什么x比y快)，而我选择的答案准确地表达了…看起来和我很配…但也许我忽略了什么？

由于乘法和幂函数的性质，它们总是比除法和sqrt()函数快。除法和根运算通常必须使用一系列更精细的近似，不能像乘法那样直接得出正确的答案。

我觉得问题的标题应该说明一个事实，即这些值都是文字常量，这是答案的关键。在典型的硬件上，integer和fp乘法和加法/减法都很便宜；integer和fp div以及fp sqrt都很昂贵(可能比fp mul的延迟时间差3倍，吞吐量差10倍)。(大多数CPU以单个ASM指令的形式在硬件中实现这些操作，这与cube-root或pow()等指令不同)。

但是，如果python解释器开销仍然使mul和div asm指令之间的差异相形见绌，我不会感到惊讶。有趣的事实：在x86上，fp除法的性能通常比整数除法高。(agner.org/optimize)。IntelSkylake上的64位整数除法的延迟为42-95个周期，32位整数为26个周期，双精度FP为14个周期。(64位整数乘法为3周期延迟，fp mul为4)。吞吐量差异甚至更大(int/fp mul和add每个时钟至少有一个，但是division和sqrt并没有完全流水线)。

您的结果(有些意外)的原因是，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、nan之一)。

也许from __future__ import division测试使用了类似的方法。

持续折叠在python 3中与/一起工作，在python 2和3中与//一起工作。所以这很可能是由于/在python 2中有不同的含义。也许当不断折叠时，还不知道from __future__ import division是否有效？

@python 2.7中的aix-1./0.不会产生NaN，而是产生ZeroDivisionError。

@绕道而行：很好，谢谢！我不认为这会使到目前为止所说的任何东西失效，除了我关于无穷大和NaNs的评论。

既然在编译代码时就完成了，那么就解释python，对吗？

@caridorc:python被编译成字节码(.pyc文件)，然后由python运行时解释。字节码与程序集/机器代码不同(例如，C编译器生成的代码)。DIS模块可以用来检查给定代码片段编译到的字节码。