|Pyston To Merge With CPython?|
|Written by Mike James|
|Tuesday, 28 February 2023|
Pyston is a fast JIT compiler and now the suggestion is that adding it to CPython - the "standard" Python - will make the language faster. Is this good?
Most Python programmers just use Python. They don't really bother wondering if there is more than one implementation of Python - there are. Even if you know about other versions of Python, then most will stick with what they know. CPython is the standard implementation of Python in the sense that if it runs on CPython then it is Python and if it doesn't there is something strange about your program.
CPython is an interpreter, but don't let that label fool you. What exactly an interpreter is isn't an easy question to answer. Its really big advantage is that it is C based and it is easy to write extensions in C for it and to use existing C libraries. For all that we might go on about how clever Python is from a syntax point of view, not to mention the zen point of view, its ability to suck up existing C code to get the job done is one of the reasons that it was an early success story.
The one problem is that Python can be slow - sometimes too slow for the job. As a result the language has been re-implemented in a range of other ways to make it faster or sometimes to make it work better with other languages. There are a lot - the Python wiki currently lists more than 15, but it all depends on what you count as a Python implementation. One of the best known is Pyston - like Piston get it?
Pyston is a fork of Python 3.8 which puts it a few releases behind CPython. It was originally a Dropbox project, but now it's a community-based open source project. Its claim to attention is that it is a JIT - Just In Time - compiler. JITs were, and still are, very fashionable as a way of making languages go faster.
The main idea is that the source code is compiled to machine code not in a separate step where all of the code is converted before it starts running. A JIT takes little bits of code as the program is running and converts them to machine code and then lets them do their stuff. JITs can be sophisticated - for example, keeping track of what they have already compiled so they don't have to do it again. The downside of a JIT is that the time to compile the code is part of the time to run the code, rather than being an additional step. The advantage of a JIT is that it makes the many dynamic features of an interpreter easy to implement.
Recently the Pyston team seem to have been thinking about what to do with their creation:
Hello all, we on the Pyston team would like to propose the contribution of our JIT into CPython main. We’re interested in some initial feedback on this idea before putting in the work to rebase the jit to 3.12 for a PEP and more formal discussion.
At the moment the reception to the idea is mostly warm and fraternal, but it's not overwhelming. Part of the reason is that there are moves to make CPython faster and these are still underway and there is suggestion that a homegrown JIT is in the works. Currently the Pyston site claims that it is 30% faster than CPython, and it certainly is faster, but CPython has speeded up since this comparison. The amount of work involved in merging Pyston into the development branch would also be quite large and I can imagine that many of the CPython programmers might be worried.
It also throws an interesting light on the way open source works. There is no company making a decision about how the projects should go - how to maximize profit. Projects are free to start, free to stagnate and free to merge. A lot of work has gone into Pyston, but it might be too late to offer the accumulated wealth to a parent project. It raises the question why now and why so late?
or email your comment to: email@example.com
|Last Updated ( Tuesday, 28 February 2023 )|