6 ms·
Python's implementation is focused on code readability. One of Guido's initial goals was that no matter how insane the input, the interpreter must never crash.
by jd 18y ago
Python's implementation is focused on code readability. One of Guido's initial goals was that no matter how insane the input, the interpreter must never crash. His emphasis on simple and clear code (and an intuitive bytecode) gets in the way of performance.
The Ruby interpreter is quite terrible, but a lot of people are trying to make it better. Give it a couple of years.
Also, you imply that both implementations are really naive. They're not. With languages such as Python and Ruby there is much less to gain with JIT compilation than with Java. Suppose you have this Python program:
def trivial(a, b):
return a + b
What can the JIT optimize? The function call? Not always, because the function can be redefined during runtime (unlike with Java and .NET). Can the function be inlined? No. Can the function call frame be stack-allocated? Well, maybe, at a significant complexity cost: most scopes in Python are essentially closures so you have to treat carefully there too (upward funarg problems). Obviously the "+" function call can't be optimized much, because you don't know the types of "a" and "b". And even if you did it wouldn't help much.
Not done yet!
Even IF you optimize everything using the NBOCK (Non Braindead Omniscient Compiler Kit). Now you know that you're dealing with integers, and you know where the function is defined, and you know the function's definition is not going to change, and you know all function arguments can be declared locally and you know only integers will be passed to and returned from the function. Can you now transform it into a few MOV instructions? Alas, no.
Maybe the integers will overflow. And if they overflow you either want to throw an exception or allocate additional space and transform the integer to a heap-allocated large integer. (And you have to do all the necessary cache invalidation.)
So even if you are omniscient there is no low-hanging fruit. In the end even the logic of adding two integers is sufficiently complex that it warrants its own C function and inclining becomes only marginally useful.
When you take mundane issues such as maintainability, flexibility, and portability into account there are very few reasons left for building a JIT compiler for Python. Note that all these optimizations are viable (to an extent) with languages such as Haskell, C# and Java.
- marcher 18y agoThe PyPy folks are working on a JIT, apparently with great speedups. They've been detailing their work on their blog: http://morepypy.blogspot.com/ http://morepypy.blogspot.com/ Also, are JavaScript and Python really that dissimilar? Everyone's working on tracing JITs for JavaScript now, with great results.
- jmtulloss 18y agoMy impression is that Python's interpreter is pretty good, so it wouldn't benefit as much from JITing. That being said, it would certainly help, and the same library used in TraceMonkey (nanojit) could probably be used in Python.
- jd 18y agoTake a look at the PyPy FAQ. They're using annotations, type inference assumptions, and so on. PyPy seems to be focused on a Jit-able subset of Python. It's not a project that can one day be transparently included in the new Python release. JavaScript and Python are not that dissimilar. So we see similar results with JavaScript. People want performance, so a lot of projects are started where people attempt to JIT JavaScript - but in the 14 or so years of JS's existence JavaScript is still several orders of magnitude slower than less dynamic languages. Java and C# have never been as slow as JavaScript is today. Will JIT-ing JavaScript help? Sure. But -great- results? I wouldn't go that far.
- jey 18y agoNo, PyPy is a full Python implementation that uses program analysis to identify and JIT the JITable parts of the code. The FAQ says that PyPy is a drop-in replacement for CPython unless you depend on a CPython extension module. http://codespeak.net/pypy/dist/pypy/doc/faq.html#is-pypy-a-drop-in-replacement-for-cpython http://codespeak.net/pypy/dist/pypy/doc/faq.html#is-pypy-a-d...
- jd 18y agoThe drop in replacement is slower than CPython. Likely to change in the future, but still.
- thorax 18y agoDon't forget psyco's JIT which gives some impressive performance gains for a lot of different code. We use it while embedding Python in Counter-Strike Source and it performs admirably.
- gruseom 18y agoWhen you take mundane issues such as maintainability, flexibility, and portability into account there are very few reasons left for building a JIT compiler for Python. Note that all these optimizations are viable (to an extent) with languages such as Haskell, C# and Java. You seem to imply that they're viable because those languages aren't as dynamic as Python. Yet Smalltalk and Lisp (edit: and Javascript) are at least this dynamic, and have implementations that go far beyond this. In fact Java's (edit: and V8's) JIT technology came from the Smalltalk world.
- jd 18y agoI've heard this claim several times, but there seems to be very little evidence to support it. The fast native code Lisp compilers such as SBCL and Lispworks sacrifice correctness for speed. You can fully expect the VM to crash when you give incorrect hints to the compiler. This is obviously unacceptable for languages such as Ruby and Python. I don't know of any serious Lisp JIT compilers. Smalltalk has never had decent performance as far as I know - not even with a JIT backend. Not compared to Java/C# with JIT compilation at least. So yes, my claim is that languages such as Python and Ruby are inherently slower than languages such as C# and Java. The less information the compiler has to work with, the fewer optimizations can be made.
- amix 18y ago"Smalltalk has never had decent performance as far as I know - not even with a JIT backend. Not compared to Java/C# with JIT compilation at least." This is largely because the team that did a JIT enabled Smalltalk dropped it and started to work on a JIT enabled VM for Java. This team got bought by Sun in the 90's and their Java VM was HotSpot, which is used in Java today. As somebody else notes, a lot of the optimizations used in JVM come from dynamic languages such as Smalltalk and Self...
- gruseom 18y agoSmalltalk has never had decent performance as far as I know I don't know what you mean by "decent". Strongtalk was widely regarded as highly performant in its day, certainly far beyond what had been thought possible for a Smalltalk. Its techniques are now being applied to produce impressive gains in contemporary dynamic languages (Maglev, V8). Given that Python and Ruby are in loosely the same class of dynamicness as Smalltalk and JS, I think that's plenty of evidence. Point taken about native Lisp compilation, though.
- nailer 18y agoThanks jd - I found out a few months ago that Python JITs weren't as fast as Java JITs, but had never quite grasped that there was solid reason why.
- amix 18y agoWhy is Java faster than Python? Because Sun has invested m(b)illions in optimization of Java. They for example have around 50 people+ working full-time on JVM right now.
- tocomment 18y agoYou sound pretty knowledgeable on this stuff. Maybe use your smarts to offer solutions too? :-)