
ZipPy: fast and lightweight Python 3 implementation using the Truffle framework - gjvc
https://github.com/securesystemslab/zippy
======
throwaway189262
If only Oracle would stop gimping performance on the free version of GraalVM.
The best optimizations, the ones that make it faster than OpenJDK, are $$$$$.
And they're trying to replace OpenJDK's compiler with Graal, to convert Java
back into a language where performance costs money.

Imagine if the free version of gcc or clang had gimped performance. The whole
purpose of a compiler is to build code that's as performant as possible.

I won't go near Graal

~~~
chrisseaton
> The best optimizations, the ones that make it faster than OpenJDK, are
> $$$$$.

But Twitter run free Graal and it's faster than OpenJDK (let's be more
specific and say C2) for them.

~~~
throwaway189262
They have a Scala-heavy codebase that benefits from the of the optimizations
C2 in OpenJDk doesn't do. In the general case, Oracle optimized free Graal to
the point it was just on-par with OpenJDK and made the additional
optimizations commercial only

~~~
chrisseaton
So you agree it’s on-par with OpenJDK, and admit sometimes a lot better in
practice, and it’s free... and you’re still not happy simply because there
exists something even better which isn’t free?

~~~
throwaway189262
It's an official implementation, the beginnings of a segment of the ecosystem.
A different Java compiler was what Google started with on Android... Look at
the mess they created now.

If code runs differently on official platforms Commercial Graal can build a
moat where code X doesn't work well on OpenJDK. Eventually you end up with
code that works on OpenJDK and Graal EE, and a subset that only works well on
Graal EE.

This is why, in my mind, compilers from official sources should always be
free. Since Graal EE performs better there's nothing stopping Oracle from
pulling a Chrome. Take all the market share then a few years later use your
market power to start fucking with the ecosystem

~~~
chrisseaton
It implements the same Java specification as every other Java implementation.
It's a conforming implementation.

How can an extra implementation of exactly the same standard possibly be a bad
thing? This is what we want isn't it? Multiple implementations innovating to
improve while keeping to the same spec? So if you don't want to pay for Graal
EE it doesn't matter because your code still runs everywhere, and because CE
is as good as OpenJDK you're no worse off in any case.

Or are you saying they're going to break the spec? Well that's just a baseless
speculation so not useful to talk about in my opinion.

We're really lucky that Oracle are investing so much money on pushing the
limit of Java performance, and that they make the vast majority of it open
source. Few companies have the money and institutional knowledge to do this.

------
latenightcoding
Also see:
[https://github.com/graalvm/graalpython](https://github.com/graalvm/graalpython)

~~~
skissane
Does anyone have any explanation of how ZipPy and GraalPython differ?

What is the history of these two projects? Was ZipPy abandoned in favour of
GraalPython? (And if so, why?)

~~~
cdrtz
ZipPy, the initial implementation of Python on Truffle, was an intern project
developed by Wei Zhang [1] while doing his PhD at UC Irvine, and continued by
other students for a while. It was later re-implemented from scratch by an
Oracle Labs team. I think that the main reason for a clean re-implementation
was that the Truffle framework had evolved enough where it was easier to start
from scratch than to rebase. Also, ZipPy was reusing the Jython parser,
whereas GraalPython is using ANTLR [2].

[1] [http://thezhangwei.com](http://thezhangwei.com)

[2] [https://medium.com/graalvm/how-to-contribute-to-
graalpython-...](https://medium.com/graalvm/how-to-contribute-to-
graalpython-7fd304fe8bb9)

------
Naac
Looking at this and also at
[https://github.com/graalvm/graalpython](https://github.com/graalvm/graalpython)
I can't find the answer to the one question I really want answered:

Does this get rid of the GIL?

~~~
georgewfraser
Yes

~~~
Naac
Can you link to where this is stated? I can't seem to find it.

------
Rochus
Interesting, but how fast is it, especially compared to PyPy? Didn't find this
information, neither in the top nor the other provided links.

------
pornel
It looks like the project has lost steam in 2015.

~~~
halflings
Looks like this was supported by Oracle's Zurich team, and they probably
decided to stop working on this project back then (they were responsible of
the vast majority of the contributions before then)

~~~
Twirrim
I imagine because they've been focused on GraaalPython
[https://github.com/graalvm/graalpython](https://github.com/graalvm/graalpython)
?

From what I can see in ZipPy it's leveraging Jython at least partially,
whereas graalpython wasn't (presumably written as a fairly clean
implementation?)

------
cptwunderlich
Isn't the biggest issue that alternative Python implementations (pyston, pypy)
have to implement all the quirks of CPython and compatibility with
C-Extensions? Since there is no written standard and libraries rely on CPython
behavior. Making things like Numpy etc. work, that heavily use C, seems really
hard for jitted implementations.

~~~
chrisseaton
This is why Graal languages virtualise C extensions by interpreting them,
allowing them to appear to meet a fixed C interface with quirks but really
being implemented more efficiently.

------
adenozine
Oh wow!

This is great, I'm in love with the idea of something like Jython for Python
3. I want to love python more than I already do, and with type checking sorta
creeping into the understanding of the userbase, I'm hopeful still.

I'm gonna try this out later and see what kinda numbers this thing can
actually do.

Edit: hm, this hasn't actually been touched since 2018, that's not good.

~~~
chrisseaton
GraalPython went on from where this left off.

~~~
adenozine
Thanks for telling me, Mr Seaton!

I'm glad to know, I had no idea, I thought ruby had the Graal situation
monopolized.

Where could I find out about developing for Graal? If I had a custom vm for my
own language, how could I go about moving to Graal?

Perhaps such a thing is not done, and I'm just ignorant to it.

~~~
pjmlp
You need to make use of Truffle, there are a couple of tutorials around.

[http://cesquivias.github.io/blog/2014/10/13/writing-a-
langua...](http://cesquivias.github.io/blog/2014/10/13/writing-a-language-in-
truffle-part-1-a-simple-slow-interpreter/)

[http://cesquivias.github.io/blog/2014/12/02/writing-a-
langua...](http://cesquivias.github.io/blog/2014/12/02/writing-a-language-in-
truffle-part-2-using-truffle-and-graal/)

[https://www.graalvm.org/docs/graalvm-as-a-
platform/implement...](https://www.graalvm.org/docs/graalvm-as-a-
platform/implement-language/)

------
giancarlostoro
I wonder if this will mean you can deploy Django on the JVM as you once could
with Django 2 and Jython.

------
miohtama
Note that Truffle framework is also a framework for Ethereum smart contract
development

[https://www.trufflesuite.com/](https://www.trufflesuite.com/)

The Python smart contract framework is called Brownie.

------
pansa2
“Lightweight” makes me think of something like Lua, not the JVM.

~~~
chrisseaton
GraalPython can run on the SubstrateVM, rather than the JVM, which is a lot
lighter.

------
samtregar3
Looks abandoned - last issues are from 2017 and the build system fails when
you run it, it points to resources online that no longer exist. Why did this
get posted?

