尽管 JVM 取得了进步，为什么 Jython 比 CPython 慢得多？答案

【问题标题】：Why is Jython much slower than CPython, despite the JVM's advances?尽管 JVM 取得了进步，为什么 Jython 比 CPython 慢得多？
【发布时间】：2011-06-27 09:17:24
【问题描述】：

请不要进行火焰战争。诚然，我不喜欢 Java，但我认为 JVM 是一个相当不错且经过良好优化的虚拟机。它支持 JIT，并且非常接近流行 CPU 架构的共同点。我假设 CPython 运行时会比相应的基于 JVM 的运行时更远离金属。

如果我的假设是正确的，有人可以向我解释为什么与 CPython 相比，Jython 的性能损失如此之大？我最初的假设是 JVM 只是为静态语言设计的，很难将动态语言移植到它上面。但是，Clojure 似乎是该论点的反例。

另一方面，IronPython 似乎做得很好。我相信这两个项目的主要开发人员是相同的，因此一个代码设计和实现明显优于另一个的论点似乎不太可能。

我不知道确切的原因是什么；任何帮助将不胜感激。

【问题讨论】：

另外，请包含指向测量结果的链接，以显示实际速度有多慢以及在哪些区域。
jython 对于gcd() stackoverflow.com/questions/4305518/… 之类的东西比 cpython 快
其实我更想知道在 JDK7 上使用带有 invokedynamic 的 Jython
“没有火焰战争”……也没有实际的硬数字。矛盾。如果您想避免激战，请在您的问题中包含事实衡量标准。

标签： python jvm jython

【解决方案1】：

请记住，IronPython 是由最初的 Jython 开发人员之一 (Jim Huginin) 启动的，目的是证明 .NET CLR 是一个糟糕的动态语言平台。他最终证明自己错了，IronPython 的核心最终变成了 .NET 动态语言运行时（使 .NET 上的其他动态语言实现，例如 IronRuby，更容易构建）。

所以这里有两个主要的不同点：

原始 .NET CLR 开发人员受益于相对于 JVM 早期版本的额外行业 VM 经验，使他们能够避免已知问题而无需担心向后兼容性
这同样适用于 Jim 根据他的 Jython 经验知道要避免哪些陷阱

加上相对于 CPython 和 IronPython 而言，Jython 的开发资源缺乏，而且 Jython 的开发优先级更侧重于使其与最新版本的 Python 具有同等的功能，而不是速度优化，Jython 将在速度方面滞后。

也就是说，Jython 与 CPython 和 IronPython 相似，因为在微基准测试中使用更好的算法通常胜过较差的性能。 JVM/CLR 还意味着，将特定组件降级到 Java 或 C# 比降级到 CPython 的 C 扩展更容易（尽管 Cython 等工具试图缩小这一差距）。

【讨论】：

这似乎是合理的，我希望从 jython 学到的教训会被翻译成 IronPython。 Ironpython 在 DLR 而不是 CLR 上运行的情况也是如此，并且前者具有更适合动态语言的原语。
我从去年 PyconAU 的 IronPython 主题演讲中了解到 IronPython 的第一个版本是直接在 CLR 之上编写的。然而，他们随后意识到大部分代码实际上是语言中立的，因此他们将这部分代码分离到 DLR 中，IronPython（以及 IronRuby 等类似工具）现在作为相对较薄的句法层在该通用动态核心上实现。跨度>
感谢您的解释。对您的评论是否正确理解 DLR 是 CLR 之上的动态层，并且大量 DLR 代码实际上在下面调用 CLR。想知道这一点，因为在那种情况下，可能也可以（原则上）为 JVM 编写这样的层。但是如果 DLR 改变了 CLR 内部，那么这个类比就不会成立。我一直保持这个问题是开放的，希望能有更多关于差异的细节。在我接受答案之前，我可能会再给出几天。
我的理解是 DLR 是对 CLR 的补充，而不是替代它。这就是为什么它可以在动态和静态语言之间实现如此简单的互操作性。