Hacker News Reader

Comment by orf | Hacker News Reader

Comments like this are so misguided and yet so common on HN. Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility.

Python 4 will just be the next release after Python 3.9.

View on HN

Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility.

The problem isn't just breaking compatibility, it's performance. There have been a number of experiments with removing the GIL going back (I think) to python 1.4. However every attempt has led to significant performance degradation in some part of the language.

> Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons.

That's a bold statement. Can you elaborate on what those reasons are?

It's not a bold statement, it's one made time and time again by the cPython developers. In short:

1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic.

2. cPython is the reference implementation. It's source should be as simple as possible.

3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry

and finally,

4. If you want/need a JIT then use PyPy, in all it's glory with all its upsides and downsides.

PyPy is a big project with a lot of very very very smart people working on it. They've done an excellent job at JITting Python (and creating an impressive interpreter framework) but even they couldn't make a JIT that is anywhere near suitable for inclusion in cPython. A bunch of cPython hackers on python-dev have no chance.

tldr: Want a JIT? Use PyPy.

By "bold" I'm also referring to your use of the words "freaking" and "ridiculous".

1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't "we can't make a JIT for python" rather than "nobody can make one"? Because that's how it turned out with JS.

2. If given the choice, do you think the community would turn down a JIT to avoid making the reference implementation more complex? To whose benefit is that requirement? I've never heard people complain about other languages that they didn't have an easy-to-read reference implementation.

3. I've not heard this reported as a problem in practice for languages that have a JIT. It's usually toy programs where the JIT overhead is significant and they're so small and short-running that neither slowdown or extra memory is usually an issue.

4. Not everything that runs on cPython runs on PyPy so that's not a choice I'm necessarily able to make.

I'm not saying there aren't reasons to not have a JIT in cPython. But it's a choice not a natural law. And it's not ridiculous to suggest that they could make a different choice if they wanted, as JS eventually did.

JITs for Javascript aren't comparable; at the time, nobody had C-based extensions for Javascript. It makes it a radically simpler problem.

Remove the "maintaining compatibility for C-based extensions" requirement, and you get, well, PyPy. And you also get a community split that makes 2/3 look trivial. Vast swathes of core Python code and libraries are really not "Python", but Python C-based bindings to custom code or C libraries.

Sure there were C-based extensions for JavaScript, that's how it integrates with the DOM. It makes it a little trickier but not a whole lot.

Sorry, perhaps I was unclear. I mean, there were no C-based extensions not under the control of the same project as controlled the JS engine, so one entity can both JIT a JS engine and simultaneously make whatever modifications it took to make them work under the new engine. Python has an enormous amount of external C-based extensions not controlled by any one entity, which constitute huge swathes of core (in importance, not in "under control of the core team") Python libraries. It's difficult to imagine what a JIT looks like that still works with those. You don't have one entity doing both the JIT and all the C extensions.

1. By people you mean "Google", and with a whole lot of money and a room full of some of the smartest people they could find. V8 is a whole department working full time, not a open source community-led effort. JS is also a different beast in a whole lot of ways. No, I am definitely saying "we can't make a JIT for Python that doesn't significantly impact single threaded scripts, retains significant backwards compatibility and doesn't massively complicate the cPython code". Obviously someone can make one, PyPy did, and it would be insane to ignore all of the HUGE problems they encountered (and overcame) while writing a JIT for Python. What makes you think cPython could do better?

2. It would make the reference implementation insanely more complex, to the point where it is no longer a reference implementation but a JIT implementation of Python. That's not cPython's role. For whos benefit is the requirement of a JIT? My apps run fine without them, and I don't need the memory bloat or startup cost associated with a JIT. If the community really wants another JIT they could fork cPython, find a room full of JIT experts and re-do all of the work PyPy has done, with all of the tradeoffs and problems they encountered. Nice idea.

3. "so small and short-running that neither slowdown or extra memory is usually an issue." - this is exactly the situation where a JIT adds a lot of overhead and becomes an issue.

4. So you want the best of both worlds, with no clear idea as to what magical person can make this happen (or even how) and you won't be happy until you can have your cake and eat it?

You're making it sound like you're disagreeing with me but it sounds like we're in complete agreement on the main point: it's not impossible to create a cPython JIT. It's a choice whether to do it or not. (And by the way, creating a JIT is a piece of engineering, it's not black magic). It's fair enough if people think that would be the wrong choice, I might even agree actually, but if the cPython developers say, time and time again, that python is inherently unsuitable to be JITted then that's wrong and it prevents that discussion from taking place.

Few things are impossible to code. It's hard to create a JIT for Python and the reference implementation for Python is not the right place to add such a JIT for the reasons stated in the comments above.

It's not that the Python developers preventing discussion, it's just this discussion is always fruitless, has been had many times before and the people invoking the discussion often blame the cPython developers for their response. Nobody wins, it's a waste of time.

"tldr: Want a JIT? Use PyPy."

or spend some time helping with Pyjion to add a C API to CPython for plugging in a JIT of your choice

- https://github.com/Microsoft/Pyjion

> Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. > > Python 4 will just be the next release after Python 3.9.

Really? Why even change the major version then, when there are no breaking changes?

Given that many Python programmers seem to be traumatized by the last major version switch, why even bother?

Or is this just for setting up Python 5 can have breaking changes if the switch to 4 is painless?

> Really? Why even change the major version then, when there are no breaking changes?

Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.

> If Linus can bump the kernel to 4.0 because he felt like it so can Python.

"Can" is not "should": I mean, Python can go from 3.x to Python 2020, go with year numbers for a while, then have Python XP, then go Python 7, Python 8, Python 8.1, and then skip to Python 10. But there's no good reason to do that.

It may very well never happen, that's a completely possible outcome.

We'll see what it does to Python's popularity.

Reply on news.ycombinator.com