42

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.

James Ko
  • 32,215
  • 30
  • 128
  • 239
san
  • 4,144
  • 6
  • 32
  • 50
  • 16
    Also, please include links to measurements that show how much slower it actually is, and in what areas. – Thilo Feb 15 '11 at 06:04
  • jython is *faster* than cpython for such things as `gcd()` http://stackoverflow.com/questions/4305518/why-is-equivalent-python-code-so-much-slower/4306668#4306668 – jfs Feb 15 '11 at 06:36
  • 2
    I'm actually more curious to see Jython w/invokedynamic on JDK7 – ide Feb 15 '11 at 06:45
  • 4
    "No flame wars"... and no actual hard numbers. Contradiction. If you want to avoid flame wars, please include factual measurements in your question. – S.Lott Feb 15 '11 at 10:47

1 Answers1

25

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).

ncoghlan
  • 40,168
  • 10
  • 71
  • 80
  • That seems reasonable and I expected that the lesson learned from jython would be translated to IronPython. So is it the case that Ironpython runs on DLR and not CLR and that the former has primitives better suited for dynamic languages. – san Feb 15 '11 at 07:02
  • 2
    My understanding from the IronPython keynote at PyconAU last year is that the first version of IronPython was written directly on top of the CLR. However, they then realised that much of that code was actually language neutral, so they separated that part out into the DLR, with IronPython (and similar tools like IronRuby) now being implemented as relatively thin syntactic layers over that common dynamic core. – ncoghlan Feb 15 '11 at 07:08
  • Thank you for your explanation. Is it a correct understanding of your comment that DLR is a dynamic layer above CLR and that a significant amount of DLR code actually calls CLR underneath. Wondering about this, because in that case such a layer could perhaps be written (in principle) for JVM too. But if DLR changed CLR internals then this analogy wouldnt hold. I have kept the question open in the hopes that more details of the differences will be forthcoming. I will give maybe a couple of days more, before I accept an answer. – san Feb 19 '11 at 22:03
  • My understanding is that DLR is an addition to the CLR, not a replacement for it. That's why it can allow such easy interoperability between the dynamic and static languages. – ncoghlan Feb 20 '11 at 01:41