ZipPy: fast and lightweight Python 3 implementation using the Truffle framework(github.com)
github.com
ZipPy: fast and lightweight Python 3 implementation using the Truffle framework
https://github.com/securesystemslab/zippy
36 comments
> 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.
But Twitter run free Graal and it's faster than OpenJDK (let's be more specific and say C2) for them.
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
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?
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
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
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.
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.
So what? Developers need money as well.
Imagine if the free version of gcc or clang had some of the performance improvements that only come with forked versions available from OEMs.
This free beer mentality is damaging for software tools, thankfully one can still work for corporations where money is no problem and thus have access to nice tools.
Imagine if the free version of gcc or clang had some of the performance improvements that only come with forked versions available from OEMs.
This free beer mentality is damaging for software tools, thankfully one can still work for corporations where money is no problem and thus have access to nice tools.
When tooling is tucked behind glass doors, your chances of getting a useless SAP guy is much higher. From a business perspective, I'd rather have all the tools available for anyone.
Free beer tooling is what gives us the performance of JIT and GC implementations on MRI Ruby and CPython, or the RAD capabilities of native toolkits aimed at GNU/Linux desktop, because living from donations and Patreon can only do so much for a few selected lucky souls.
I rather prefer that fellow developers get paid the same way I enjoy being paid as well, and yes I don't have any issues being that SAP guy if it much be so.
Being useless or not, is a matter or perspective, and I find sad that in forum tailored for creating new business, so few people are willing to pay for their tools.
I rather prefer that fellow developers get paid the same way I enjoy being paid as well, and yes I don't have any issues being that SAP guy if it much be so.
Being useless or not, is a matter or perspective, and I find sad that in forum tailored for creating new business, so few people are willing to pay for their tools.
I'm down with paying for tools when creating value, not when learning. We probably even agree. I do not expect many experts to appear at my doorstep if the tool is proprietary. SAP was an example of that.
This talk was formative for my opinion of Oracle: https://www.youtube.com/watch?v=-zRN7XLCRhc (the good bit starts at 32 minutes)
Also see: https://github.com/graalvm/graalpython
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?)
What is the history of these two projects? Was ZipPy abandoned in favour of GraalPython? (And if so, why?)
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
[2] https://medium.com/graalvm/how-to-contribute-to-graalpython-...
[1] http://thezhangwei.com
[2] https://medium.com/graalvm/how-to-contribute-to-graalpython-...
Yes this should really be the link. GraalPython is being very actively developed. The submitted link gives a false impression.
Looks like it supports pandas and numpy. That's cool!
Looking at this and also at 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?
Does this get rid of the GIL?
Interesting, but how fast is it, especially compared to PyPy? Didn't find this information, neither in the top nor the other provided links.
It looks like the project has lost steam in 2015.
Not unlike Topaz[0], a Ruby on RPython started in 2013 which has seen no activity in 3 years.
[0] https://github.com/topazproject/topaz
[0] https://github.com/topazproject/topaz
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)
I imagine because they've been focused on GraaalPython 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?)
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?)
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.
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.
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.
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.
GraalPython went on from where this left off.
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.
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.
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/12/02/writing-a-langua...
https://www.graalvm.org/docs/graalvm-as-a-platform/implement...
http://cesquivias.github.io/blog/2014/10/13/writing-a-langua...
http://cesquivias.github.io/blog/2014/12/02/writing-a-langua...
https://www.graalvm.org/docs/graalvm-as-a-platform/implement...
I wonder if this will mean you can deploy Django on the JVM as you once could with Django 2 and Jython.
Note that Truffle framework is also a framework for Ethereum smart contract development
https://www.trufflesuite.com/
The Python smart contract framework is called Brownie.
https://www.trufflesuite.com/
The Python smart contract framework is called Brownie.
“Lightweight” makes me think of something like Lua, not the JVM.
GraalPython can run on the SubstrateVM, rather than the JVM, which is a lot lighter.
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?
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