[Python-Dev] A new JIT compiler for a faster CPython?
glyph at twistedmatrix.com
Tue Jul 17 21:43:33 CEST 2012
On Jul 17, 2012, at 11:38 AM, Victor Stinner <victor.stinner at gmail.com> wrote:
> IMO PyPy is complex and hard to maintain. PyPy has a design completly
> different than CPython and is much faster and has a better memory
> footprint. I don't expect to be as fast as PyPy, just faster than
I think this criticism is misguided.
Let's grant for the moment that you're right, and PyPy is complex and hard to maintain. If a high-level Python parser and JIT compiler written in Python came out as complex and unmaintainable, why do you believe that they'll be easy to write in C?
You are correct that it has a different architecture than CPython: it has a different architecture because CPython's architecture is limiting because of its simplicity and makes it difficult to do things like write JIT compilers. The output of the Unladen Swallow project was illuminating in that regard. (Please note I said "output" and not "failure", the Unladen Swallow folks did the community a great service and produced many useful artifacts, even if they didn't meet their original goal.)
Polluting the straightforward, portable architecture of CPython with significant machine-specific optimizations to bolt on extra features that are already being worked on elsewhere seems like a waste of effort to me. You could, instead, go work on documenting PyPy's architecture so it seems less arcane to newcomers. Some of the things in there which look like hideous black magic are actually fairly straightforward when explained, as I have learned by being lucky enough to receive explanations in person from Maciej, Benjamin and Alex at various conferences.
I mean, don't get me wrong, if this worked out, I'd love a faster CPython, I do still use use many tools which don't support PyPy yet, so I can see the appeal of greater runtime compatibility with CPython than CPyExt offers. I just think that it will end up being a big expenditure of effort for relatively little return.
If you disagree, you should feel no need to convince me; just go do it and prove me wrong, which I will be quite happy to be. I would just like to think about whether this is the best use of your energy first.
But definitely listen to Maciej's suggestion about concentrating efforts with other people engaged in similar efforts, regardless :). As your original message shows, there has already been enough duplication of effort in this area.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev