为什么 Python 比 Ruby 快？

Question

它们似乎有很多相同的特征，但据我所知，Python 2.5 比 1.8.7 快很多。

这背后是否有更深层次的原因？

Answer 1

没什么深奥的，我很确定——这完全是实现选择和成熟度的问题。 毕竟不久前，Python 在许多方面都慢了很多！ 考虑例如：

$ py24 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 10.8 usec per loop
$ py25 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 9.83 usec per loop
$ py26 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 8.12 usec per loop
$ py27 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 6.35 usec per loop

是的，都在同一台机器上（Macbook Pro，2.4 GHz Intel Core 2 Duo，OSX 10.5），所有来自 python.org 的“官方”Mac 版本（ 2.x系列中每个x最新版本）。 我没有 2.3 可供检查，但我希望它比 2.4 慢一点。

这正是在几乎相同的底层架构的连续版本中，许多充满爱心、艰苦的工作可以实现的加速。 不像添加feechurz那么华而不实，但在现实世界中通常更有用！-)

因此，我很确定 Ruby 也可以稳定在一个健全的、性能稳健的底层架构上，然后多年来开始进行稳定的底层性能调整以获得（例如）40% 左右在过去的几年中，我们在此处观察到的（至少是某些部分的）Python 发生了进一步的改进。

Answer 2

一个原因是 Python 被编译成字节码，然后由高度优化的 VM 执行。 AFAIK Ruby 在 1.8 及更早版本中不能以这种方式工作 - 但会动态解释树。

可以这样想：

Python：

1. 将代码解析为 AST
2. 将 AST 转换为字节码
3. 在 VM 上运行字节码

Ruby（1.9 之前）：

1. 将代码解析为 AST
2. 通过递归遍历直接解释 AST

无需过多赘述，旧 Ruby 中的第 2 步有很多重复，因为它每次看到 AST 时都必须“理解”它们（这在内部循环中很多）。 Python 只“理解”AST 一次，然后 VM 会尽可能快地运行字节码（这与 Java 和 .NET VM 的工作方式原则上没有区别）。

Ruby 1.9 移至YARV ，这也是一种基于 VM 的方法。 Ruby 1.9 比 1.8 快。 这 是 YARV 的创建者Koichi Sasada 的 一句话：

起初，YARV 是运行伪顺序指令的简单堆栈机器。 旧解释器 (matzruby) 天真地遍历抽象语法树 (AST)。 显然它很慢。 YARV 将该 AST 编译为 YARV 字节码并运行它。

需要注意的一个有趣点是 Python VM 也是基于堆栈的，就像 YARV 一样。

Answer 3

因为 Ruby 1.8 的设计并没有真正考虑性能，而 Python 则更加优化。 特别是，Ruby 1.8 进行了真正的解释，而不是像当今大多数语言那样为虚拟机进行编译。 Ruby 1.9（带有 YARV VM）大约与 Python 3 一样快（可能慢一点，但更接近），其他实现甚至更快。

Answer 4

我阅读了答案，我看到大多数人都在说“哦，您不应该与 Ruby 1.8 进行比较，您应该使用 1.9，它要快得多”。 好吧，为什么不看看一些基准呢？

所以这里是 Ruby 1.9 (YARV) 与 Ruby 1.8 (MRI) 的对比： http ://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=ruby

以下是 Ruby 1.9 与 Python 2.x 的比较： http ://shootout.alioth.debian.org/u32/benchmark.php?test = all&lang = yarv&lang2 = python

总结一下，Ruby 1.9 比 Ruby 1.8快大约 2倍- 但仍然比 Python慢- 慢 2倍。

---

附注。 我想我需要在 Chuck 的反对意见之后澄清：我不认为计算机语言大战是生命、宇宙和一切问题的最终答案。 离得很远。 我很高兴被提及其他客观来源。

我也很高兴听到 S/O 上人们的非正式/主观结果，前提是他们参与了 50 多次关于 Python 或 Ruby 的讨论，并且他们的 Ruby/Python 偏差在 +/-5dB（Ruby/Python 比率计算为RPR=10*log10(numTags('Ruby')/numTags('Python')) dB；因此对于用户 Chuck 来说，这将是 10*log10(225/13) = 12dB，我的是 -10 - 我们都不能信赖在公正的意见) :-)

Answer 5

更多的人从事Python开发工作多年，所以做了更多的优化。 这些语言同样灵活且富有表现力，因此当所有好的优化思想都用于两者时，它们的性能应该会趋于一致。 如上所述，Ruby 1.9 大大缩小了与 Python 的性能差距。

Answer 6

这取决于实现。 Crystal 基本上是 C 编译的 Ruby，甚至可以调用 C 库。 然后你在 Beam 端也有 Elixir，不要忘记 Java 和 C# 对应物。 但是是的，事实上的标准 Ruby 确实比 Python 慢，而且还针对 Web 开发。