Why is Jython much slower than CPython, despite the JVM's advances?
Question:
No flame wars please. I am admittedly no fan of Java, but I consider the JVM to be a fairly decent and well-optimized virtual machine. It’s JIT-enabled and very close to the common denominator of the prevalent CPU architectures. I’d assume that the CPython runtime would be farther from the metal than a corresponding JVM-based runtime.
If my assumptions are correct, could someone explain to me why Jython suffers such a major loss in performance compared to CPython? My initial assumption was that the JVM was simply designed for static languages, and it was difficult to port a dynamic one to it. However, Clojure seems to be an counterexample to that line of argument.
On the other hand, IronPython seems to be doing fine. I believe the the lead developer on both projects were/are the same, so the argument that code design and implementation in one is significantly better than the other does not seem likely.
I can’t figure out what the precise reason is; any help will be appreciated.
Answers:
Keep in mind that IronPython was started by one of the original Jython devs (Jim Huginin) in an attempt to prove that the .NET CLR was a poor platform for dynamic languages. He ended up proving himself wrong and the core of IronPython eventually became the .NET Dynamic Language Runtime (making other dynamic language implementations on .NET, such as IronRuby, significantly easier to build).
So there’s two major points of difference there:
- the original .NET CLR devs benefited from additional industry VM experience relative to the early versions of the JVM, allowing them to avoid known problems without backwards compatibility concerns
- the same applied for Jim in knowing what traps to avoid based on his Jython experience
Add in a simple lack of development resources devoted to Jython relative to both CPython and IronPython, and Jython development priorities that focused on bringing it up to feature parity with recent versions of Python moreso than speed optimisations and it’s quite understandable that Jython would lag when it came to speed.
That said, Jython is similar to both CPython and IronPython, in that the use of better algorithms often trumps poorer performance at microbenchmarks. The JVM/CLR also mean that dropping down to Java or C# for particular components is easier than dropping down into a C extension for CPython (although tools like Cython try to close that gap a bit).
No flame wars please. I am admittedly no fan of Java, but I consider the JVM to be a fairly decent and well-optimized virtual machine. It’s JIT-enabled and very close to the common denominator of the prevalent CPU architectures. I’d assume that the CPython runtime would be farther from the metal than a corresponding JVM-based runtime.
If my assumptions are correct, could someone explain to me why Jython suffers such a major loss in performance compared to CPython? My initial assumption was that the JVM was simply designed for static languages, and it was difficult to port a dynamic one to it. However, Clojure seems to be an counterexample to that line of argument.
On the other hand, IronPython seems to be doing fine. I believe the the lead developer on both projects were/are the same, so the argument that code design and implementation in one is significantly better than the other does not seem likely.
I can’t figure out what the precise reason is; any help will be appreciated.
Keep in mind that IronPython was started by one of the original Jython devs (Jim Huginin) in an attempt to prove that the .NET CLR was a poor platform for dynamic languages. He ended up proving himself wrong and the core of IronPython eventually became the .NET Dynamic Language Runtime (making other dynamic language implementations on .NET, such as IronRuby, significantly easier to build).
So there’s two major points of difference there:
- the original .NET CLR devs benefited from additional industry VM experience relative to the early versions of the JVM, allowing them to avoid known problems without backwards compatibility concerns
- the same applied for Jim in knowing what traps to avoid based on his Jython experience
Add in a simple lack of development resources devoted to Jython relative to both CPython and IronPython, and Jython development priorities that focused on bringing it up to feature parity with recent versions of Python moreso than speed optimisations and it’s quite understandable that Jython would lag when it came to speed.
That said, Jython is similar to both CPython and IronPython, in that the use of better algorithms often trumps poorer performance at microbenchmarks. The JVM/CLR also mean that dropping down to Java or C# for particular components is easier than dropping down into a C extension for CPython (although tools like Cython try to close that gap a bit).