ZipPy – a Python 3 implementation on the JVM | Hacker News Reader

ZipPy – a Python 3 implementation on the JVM

bitbucket.org

69 pointsnickmain21 comments

Open articleView on HN

This uses the Truffle framework and GraalVM. (http://openjdk.java.net/projects/graal/)

Related discussion about JRuby with Truffle: https://news.ycombinator.com/item?id=10817110

If anyone wants to get started with Truffle - I found these links helpful:

> 3 hour Intro + Tutorial: https://www.youtube.com/watch?v=N_sOxGkZfTg

> Blog Post Series: http://cesquivias.github.io/tags/truffle.html https://github.com/cesquivias/mumbler

I remember the researchers at Oracle mention in their presentation that not all languages can be ported to GraalVM. Do you know what language runtimes can and cannot be implemented on GraalVM?

I don't know the answer to that, but currently they have: Java, JavaScript, C, Ruby, Python, R, and a simplified SmallTalk.

Thank you for the list. I really hope the VM can enable porting language runtimes that are not available in JVM, C#, Swift, Go...

Truffle is intended primarily to speed up scripting languages. It works with C too, which is impressive, but it does it by treating C as a scripting language and then aggressively optimising it until it's back to being as fast as what GCC would do. But for instance, you need the source code at runtime, like a script. You can't compile C to a bytecode file in a JAR like with traditional Java.

The issue with porting C# would be that C# exposes low level features that the JVM doesn't have, like value types.

Swift and Go probably could run on the JVM and Go in particular would probably benefit from it a lot. I've often thought that a Go for the JVM would make a nice little commercial project for a startup somewhere.

> It works with C too, which is impressive, but it does it by treating C as a scripting language and then aggressively optimising it until it's back to being as fast as what GCC would do. But for instance, you need the source code at runtime, like a script.

I think Graal can do AOT compilation (and optimization). The quality of the resulting code depends on the information it has at the time of compilation. So for C, as Graal has the same information as gcc, there is no reason it should produce any less optimal code than gcc, even when working AOT. The reasons for the current differences (so I've heard from the Graal team), is simply that they have not put in all the effort they can, but they have little doubt that Graal can match gcc when working AOT, and exceed it if run JIT.

I think that the decision of whether to treat a language "like a script" (i.e. rely on JIT compilation) or not is up to the language implementation. Graal supports both.

> You can't compile C to a bytecode file in a JAR like with traditional Java.

No (although you could in theory), but you can compile C (or Java) to a native binary with Graal. AOT compilation of Java to binary is how SubstrateVM works.

> Go for the JVM would make a nice little commercial project for a startup somewhere.

Sadly, there's very little money to be made in developing a programming language, especially if the language is not specialized for safety-critical and/or realtime applications.

Slides: http://socalpls.org/2013nov/slides/zippy.pdf

It is probably the fastest Python implementation (on or off the JVM). It beats PyPy by a large margin on most benchmarks:

http://thezhangwei.com/documents/oopsla113-zhang.pdf

I'm always feeling very disappointed when I see Python 2 and Python 3 performance compared. :-(

pypy3 is quite a bit slower than pypy for 2.7

>ZipPy is a fast and lightweight Python 3 implementation built using the Truffle framework.

Since the build seems nontrivial it would be nice if there were some numbers comparing to CPython performance :)

Or Jython?

Jython is still Python 2.7, so it's not an apples-to-apples comparison.

http://thezhangwei.com/documents/oopsla113-zhang.pdf

See Figure 17

I took a look at the source, and this is some of the cleanest Java I've seen yet. Certainly nothing like https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Excuse me, are you saying that enterprise-ready, battle-tested, unit-tested fizzbuzz implementation is not clean??

Enterprise-ready, battle-tested and unit-tested have little to nothing to do with clean code. Clean code is really talking about readability here.

The enterprise fizzbuzz does exactly what is asked of in the spec, allow room for expansion, split all responsibilities into modules which could be concurrently worked on by many different people/teams, and the testing ensures that miscommunication doesn't ruin a code base. In my books, that's clean.

That joke went really far above your head...

A baroque nightmare !

Does it support C APIs and/or Numpy / Scipy?

Probably not yet. But I am sure that they are looking at this option that was used by JRuby+Truffle: http://chrisseaton.com/rubytruffle/cext/. Where they use the same technique but then on C. Although I heard that they will replace that approach with one where they directly work on LLVM IR instead. So that they can get all the LLVM supported languages in one go.

Reply on news.ycombinator.com