為什么 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 開發。