Pyston-lite: our Python JIT as an extension module
blog.pyston.org
blog.pyston.org
I use pipenv, so I ran this:
pipenv shell --python=python3.8
pip install pyston_lite_autoload
And it worked: I got a small but material speed improvement from a tiny benchmark I ran against my own project: https://simonwillison.net/2022/Jun/8/pyston-lite/Realistic loads might have the same routines run more intensely and might see more benefit from the JIT compiler.
Is this project public? I'd love to investigate
The only downside is it’s a 3.8 fork, which fortunately isn’t an issue for us.
[1]: https://peps.python.org/pep-0523/ [2]: https://github.com/python/cpython/blob/main/Python/ceval.c
The autoload module at https://github.com/pyston/pyston/blob/96d5d33186b81f96ce3d9a... just calls:
__import__("pyston_lite").enable()
It took some digging, but it looks like that enable() method is defined in the C code here: https://github.com/pyston/pyston/blob/96d5d33186b81f96ce3d9a...It calls jit_start() which I think is here and does more of the interesting work: https://github.com/pyston/pyston/blob/69b190003f14dfd2f6d276...
The predecessor of Pypy is called Psyco http://psyco.sourceforge.net/
To enable JIT in Python2.x, simply `import psyco; psyco.full()`
It was fun while it lasted.
For Pypy3, check out https://github.com/fijal/jitpy
But if you're asking about performance and use cases, there are a lot of Python compilers and alternative implementations out there now!
Not just MyPyC, but also Nuitka, Shedskin (not sure if still in development), GraalPython, PyPy, Cinder, Pyjion, IronPython (not sure if still in development), and even Stackless Python (yes it's still in develoment). Not to mention Cython and, for specific numerical tasks, Numba.
I think Microsoft also recently announced a CPython JIT extension that's analogous to Pyston-Lite.
A benchmark or comprehensive comparison suite would be pretty cool, but I'm not aware of one. Personally I think CPython plugins are the most user-friendly option, because they require the fewest changes in your deployment setup and runtime environment. PyPy isn't that bad but isn't perfect either. Whereas ahead-of-time compilation is a pretty big change from the usual Python developer workflow and might not be easy to convince a team to adopt it.
Seems easier to use the C functions to do this, rather than rely on system commands.
(Also, IMO, it is much easier to install Pyston-lite than upgrade a whole Python version, which is an absolute nightmare on some of my specific scenarios with somewhat embedded hardware)
They are currently stuck on 3.8, but believe they will be able to support multiple versions easily because pyston-lite is much easier to develop for than pyston (because it is an extension and not a whole CPython fork).
They also present benchmarks at the very end comparing Pyston, Pyston-lite and the latest CPython 3.11.0b3, all compared to Ubuntu's default Python 3.8.10. It shows that while CPython offers ~8-15% improvements (macro-micro benchmarks), Pyston-Lite offers 8-27% improvements and "OG" Pyston offers 35-65% improvements.
So compared to regular CPython you might get an extra 10% or so, which might or not be worth it depending on your case. Excited to see what happens if they port Pyston to Python 3.11, though!
Not a rhetorical question BTW. A pluggable JIT for Python could be a boon for some projects at my dayjob, but if it's proprietary that would put a bit of a damper on things.
[0]: https://blog.pyston.org/2021/05/05/pyston-v2-2-faster-and-op...
[1]: https://github.com/pyston/pyston/blob/pyston_main/LICENSE
So now there is legitimate incentive to develop and get adoption for your own "faster Python" project, which (if successful) could end up being used by millions of developers around the world. Imagine the clout and name recognition that would come with being the company that finally made Python fast after 20+ years of failed attempts. Not to mention all the free labor (bug reports and PRs) from the open-source community, all while optimizing the tool to serve their own internal technical needs above all else.
That's my only explanation for why these companies are all DIYing their own project and not contributing to existing efforts like PyPy and HPy. I think ultimately this work is all good for the Python ecosystem, but clearly I'm a bit cynical and skeptical of large tech companies' motivations in general.
Open sourcing things increases the likelihood it'll be upsteamed (the use case is more obvious) and increases the likelihood you'll get support (although you now have a community to support). In addition, it's easier to plead your case if upstream breaks something (here's my source vs vague statements about an internal thing at company x)
Didn't Microsoft also recently announce something similar? I could have sworn I saw a thread about it here recently, but i couldn't find it again. Or was that the Facebook project Cinder?
There are so many "high performance Python" projects now (and in the past) that it's hard to keep track!
Sometimes you have a Python project already, you aren't planning to write a new project. In fact there's a ton of non cython python in existence, every time I use a new library, your solution is to rewrite it in cython?
Lots of ways to speed up python. It's great to have this option, which will work for some without having to change much of anything. Cython, Numba, C (etc.) extensions, ... All are good, too, where they fit into a project and development cycle.