
ZipPy – a Python 3 implementation on the JVM - nickmain
https://bitbucket.org/ssllab/zippy
======
sumukh1
This uses the Truffle framework and GraalVM.
([http://openjdk.java.net/projects/graal/](http://openjdk.java.net/projects/graal/))

Related discussion about JRuby with Truffle:
[https://news.ycombinator.com/item?id=10817110](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](https://www.youtube.com/watch?v=N_sOxGkZfTg)

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

~~~
namelezz
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?

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

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

~~~
mike_hearn
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.

~~~
pron
> 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.

------
pron
Slides:
[http://socalpls.org/2013nov/slides/zippy.pdf](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](http://thezhangwei.com/documents/oopsla113-zhang.pdf)

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

------
moonchrome
>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 :)

~~~
mixmastamyk
Or Jython?

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

------
imbellish
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...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

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

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

~~~
chii
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.

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

~~~
jerven
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/](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.

