为什么 JITted Python 实现仍然很慢？
我理解为什么解释开销很昂贵，但为什么 JITted Python 实现（Psyco 和 PyPy）仍然比其他 JITted 语言（如 C# 和 Java）慢得多？
编辑：我也明白一切都是对象，动态类型的成本很高，等等。但是，对于可以推断类型的函数，我不确定为什么这很重要。
I understand why interpretation overhead is expensive, but why are JITted Python implementations (Psyco and PyPy) still so much slower than other JITted languages like C# and Java?
Edit: I also understand that everything is an object, dynamic typing is costly, etc. However, for functions where types can be inferred, I'm not sure why this matters.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
最简单的可能答案是，PyPy 根本还没有热点那么快，而 Psyco 永远不会。
编写合理的 JIT 是一个漫长而乏味的过程，例如，热点花了很多年才达到现在的水平（也需要大量资金）。语言越复杂、越动态，所需的时间就越长。从好的方面来说，我们有很好的例子说明动态语言的 JIT 可以非常快，以 LuaJIT 为例，它在许多例子中可以击败 C 或 JVM。
不过，也有好消息：根据 速度中心 PyPy 在过去 100 次修订中平均速度提高了 27%，所以最终会发生。
The simplest possible answer is that PyPy is simply not yet as fast as hotspot and Psyco never will.
Writing a reasonable JIT is a long and tedious process and it took for example many years for hotspot to get where it is (with a lot of funding as well). The more complex and dynamic the language is, the longer it takes. On the bright side, we have good examples how JITs for dynamic languages can be very fast, take LuaJIT for one, which can beat C or JVM on many examples.
There are good news however: According to speed center PyPy got 27% faster on average in the past 100 revisions, so it'll happen eventually.
人们已经指出了技术细节，所以我再补充一个因素：钱。
在过去几年中，Javascript VM（Google 的 V8、Mozilla 的 Tracemonkey 和 Jaegermonkey、Apple 的 Nitro）为另一种动态语言带来了巨大的速度提升。这在很大程度上是由于谷歌希望让网络应用程序变得更强大。没有一家大公司能够通过将 Python 速度提高 50 倍来获益。
哦，无论如何，与 numpy 等 C 扩展的集成意味着速度对于 Python 代码来说并不重要。
People have already pointed out the technical details, so I'll add another factor: money.
In the last few years, Javascript VMs (Google's V8, Mozilla's Tracemonkey & Jaegermonkey, Apple's Nitro) have delivered a huge speed increase for another dynamic language. That's been driven in large part by Google's desire to make web apps more powerful. Python just doesn't have a big company standing to gain by making it 50x faster.
Oh, and the integration with C extensions like numpy means that speed is rarely critical for Python code, anyway.
Python 是一种动态语言。
这意味着其他静态语言（如 C# 和 Java）在编译时完成的大部分工作都是在运行时完成的，这会降低性能。
编辑：
此外，像Python这样的动态语言的JIT编译器可以对代码执行更少的优化，因为由于代码的动态性，它不能做很多假设。
例如
动态类型可以防止对字段/变量/参数类型的假设...，因此涉及此的任何优化几乎是不可能的。
编辑2：
只是一个澄清：
当我说编译时时，我指的是 JIT 编译时，因为实际上 JIT 是一个编译器。
将其应用到我的第一句话中，结果表明 Python 在 JIT 时间执行的工作比 C# 或 Java 少得多......
Python is a dynamic language.
This means that much of the work that other static languages (like C# and Java) do at compile time, is done at runtime and this reduces performances.
EDIT:
Furthermore, JIT compiler for a dynamic language like python, can perform much less optimisations on the code because it can't do many assumptions due to the dynamicity of the code.
e.g.
Dynamic typing prevents assumptions about type of fields/variables/parameters... , thus any optimisation involving that is almost impossible.
EDIT2:
just a clarification:
when I say compile time, I mean also JIT compile time, because actually JIT is a compiler.
Applying this to my first sentence, yields that Python can perform much less work at JIT time than C# or Java...
一个非常好的问题。我无法给你一个完整的答案，但我认为原因之一是“一切都是对象，对象可以是任何东西”的概念。在 Java 中，如果您尝试“1.getClass()”，除非您先显式或隐式地对它进行装箱，否则它将不起作用。在 Python 中，它是开箱即用的。但对象肯定比原始类型更重量级，而 Python 似乎不具备这一点。
“对象可以是任何东西”部分甚至更重要。如果您用 Java 编写“someobject.somefield”，它会在编译时知道“somefield”到底是什么，并生成直接访问它的代码。好吧，可能有一些技巧可以提供更好的二进制兼容性，但这与 Python 完全不同，Python 实际上在运行时执行某种字典查找，以找出在特定时刻“somefield”到底是什么，因为字段可以动态添加和删除。
简而言之，Python 更强大，但这种强大是有代价的。
A really good question. I can't give you a complete answer, but I think one of the reasons is the "everything is objects and an object could be anything" concept. In Java, if you try "1.getClass()", it won't work unless you box it first, either explicitly or implicitly. In Python, it works out of the box. But objects are definitely more heavyweight than primitive types, which Python just doesn't seem to have.
The "an object can be anything" part is even more important. If you write "someobject.somefield" in Java, it knows at compile time what exactly is "somefield" and generates code that accesses it directly. Well, there are probably some tricks to give better binary compatibility, but that's nothing like Python, where it actually performs some sort of dictionary look-up at run time to figure out what exactly is "somefield" at that particular moment, as fields can be added and deleted dynamically.
To put it short, Python is more powerful, but that power has its cost.
您无法真正将动态语言与企业级静态语言进行比较。 Sun 花费大量资金来优化语言、VM 和 JIT。微软在虚拟机方面也做得相当不错。
比较 jit'ed 动态语言更有趣。是不是 JavaScript 的某些原因让 google 的 V8 比两者都更快 PyPy 和 ruby 1.9 或者它只是一个人投资的金额？
You can't really compare dynamic languages to enterprise-level static languages. Sun spent a lot of money optimizing the language, VM and JIT. Microsoft also did a fair job with their VM.
It is more interesting to compare jit'ed dynamic languages. Is it something about JavaScript that let google make their V8 faster than both PyPy and ruby 1.9 or it is just amount of money one invests?
比较那些Python实现 到非 JIT 解释模式 Java 并再次考虑你的问题。
Compare those Python implementations to non-JIT interpreted-mode Java and think about your question again.
到了 2014 年，整个问题不再那么清晰了。Google 的 V8 JS 引擎做了一些相当繁重的工作来优化 js。
如果有足够的资金，PyPy 的速度可能会快得多。 Python 的执行速度基本上并不重要，因此没有人大量投资 PyPy。
这确实不再是一个技术问题了。看看Java的InvokeDynamic指令。当然，这些调用在第一次被调用时会花费更多，但是一旦这些调用开始启动，JVM 就可以做一些神奇的事情。也就是说：JVM 可以做假设，并且可以在运行代码时了解代码。如果某个方法始终返回 int，则该方法可能始终返回 int。事实上，JVM 的作用远不止于此。
2014 年，就性能而言，确实没有动态与静态之分。当然，C++ 永远是最快的工具，但动态语言并不像几年前那样慢“数量级”。
再等几年，我敢打赌静态分析在 2016 年或 2017 年会更强。现在有一些非常有趣的研究项目正在运行。
理论上：
您基本上可以使用静态类型分析来推断每种类型，您必须在代码执行操作之前了解代码正在做什么。这并非不可能。
当静态分析变得更加强大时，您真的不再需要静态类型系统。所有静态类型系统，甚至 Haskell 的系统，都会限制正确程序的数量。因此，本质上：如果您有一个分析器，可以通过分析程序来证明程序的正确性，那么它作为只能在边界内运行的静态类型系统要强大得多。关于代码重用：没有什么比动态类型更好的了。
有些人会说动态类型对于大型应用程序来说是不好的，但是如果静态分析变得更强大，您实际上将拥有与静态类型系统所能提供的相同或可能更加经过验证的正确性。当然，静态类型语言也可以进行静态分析，但静态类型系统就没用了。
所以本质上：我知道，这里有很多如果。但 10 年前，如果你告诉人们 js 变得如此之快，以至于你可以轻松地用它编写繁重的 3D opengl 应用程序，人们会嘲笑他们。
永远不要低估未来。
The whole issue is not so clear anymore in 2014. Google's V8 JS engine does some pretty heavy stuff to optimize the hell out of js.
PyPy could be much faster if only enough money would be available. Python's execution speed mostly does not matter so nobody heavily invests in PyPy.
It's really not a technical issue anymore. Look at Java's InvokeDynamic instruction. Sure, those invocations cost more the first time they are called, but the JVM can do magic stuff once those invocations start to start up. That is: The JVM can do assumptions and can learn about the code while running it. If a method always returns an int, it's possible that this method always returns an int. In reality the JVM does much more.
In 2014 it's really not dynamic vs static in terms of performance. Sure C++ will always be the fastest tool around, but jitted dynamic languages are not "magnitudes" slower as they used to be a few years ago.
Wait a few more years, I bet static analysis is much stronger in 2016 or 2017. There are a few very interesting research projects running right now.
In Theory:
You can basically infer every type using static type analysis, you have to understand what the code is doing before it does it. That's not impossible.
When static analysis becomes more powerful, you really do not need a static type system anymore. All static type systems, even haskell's, limit the number of correct programs. So in essence: If you have an analyzer which can proof the correctness of a program by analyzing it is much more powerful as a static type system which only can act within boundaries. And concerning code re-usage: Nothing can beat dynamic typing.
There are a few who would say that dynamic typing is bad for large applications but if static analysis becomes more powerful, you would actually have the same or maybe much more proven correctness as a static type system could ever offer. Of course statically typed languages could also be statically analyzed, but than the static type system would be useless.
So in essence: Here are a lot of if's, i know. But 10 years ago people would have laughed if you would have told them that js becomes the so fast, that you could easily write heavy 3d opengl applications in it.
Never underestimate the future.