Python JIT project was asked to pause development(discuss.python.org) |
Python JIT project was asked to pause development(discuss.python.org) |
lol
>> For example, rather than proposing one single concrete JIT implementation, it may make more sense for the PEP to describe a JIT infrastructure that can support multiple implementation strategies.
poison-pill requirement
>> We are setting a window of six months for a PEP to be submitted and resolved. If no such PEP is accepted within that window, the JIT code must be removed from the main branch
so it's going to be removed from the main branch
Python JIT history is full of drama, and no, Smalltalk, Common Lisp, Interlisp-D, SELF are just as dynamic if not more.
Er, doesn't that depend on how leaky the abstraction is? How often have you seen a JITted language be unable to swap in a new JITter due to some sort of unintended coupling?
What forever are you talking about? Python removes stuff every single release.
I didn't notice the current PEP was a provisional one. Hope the new one gets approved. The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
[1] https://fidget-spinner.github.io/posts/jit-on-track.html
Thank You. As someone who don't follow python closely I thought their JIT would be similar to what Ruby has.
Not that Ruby YJIT or ZJIT is anywhere close to what JVM provides, but in this case it seems to be quite far ahead of Python.
Which is surprising given how many major companies are using Python. May be because those using Python are not using it as critical part of work unlike Shopify and Stripe which is their core language?
To leave their experimental phase they have to define some goals to meet and that requires making some architectural choices that still aren't decided.
Development hasn't been paused (with negative implications).
It's now considered significant enough that they've requested feature freeze in CPython main until governance/process questions are settled.
If it is, is it not documented somewhere? Maybe as a formal PEP?
If it is not and it is still in heavy experimentation phase (which is fine), it should not be part of the mainline CPython no matter how much more effort it is for the team to experiment with.
And yet, I have a hunch it will piss off a lot of people nonetheless and lead to much outrage and wailing and gnashing of teeth. Hopefully it all works out in the long run.
To be fair, the apparent lack of progress of the JIT before was in part due to the same team improving the base interpreter by 40-50% between 3.10 and 3.14. The JIT implementation was pursuing a moving target. It was not some static milestone. Kudos for them.
They should perhaps have kept it in a separate branch back then, but now is the next best time.
CPython's selling point was that it is simple, fast enough with C extensions and the code was accessible. Complicating the code base for occasional 50% speedups (and regressions ...) just isn't worth it. There are so many other languages that fill that need.
Now, I hope that the PEP does not overpromise again and is accepted because of Instagram pressure. Instagram can keep its own JIT fork or switch to PHP, Go or whatever.
As for performance, Python 3.x was not even as fast as Python 2.x in the beginning, but with the correct mindset, it's eventually faster.
By now it should be clear to anybody working on Python JIT that the probability of failure is 90%.
The future is probably rewriting performance critical Python code in Rust instead of trying to fix Python.
Or maybe a future LLM could add a JIT to Python in an effort-run.
This will require minor tweaks to the language and perhaps a forked interpreter (a forked parser already exists).
Then you solve the two language problem with a combination of probabilistic and deterministic translation.
If I were a contributor I would read such language as saying "we have no respect for you or your intelligence, so we'll just straight up gaslight you and expect you to accept it."
The dictum can't be read literally - it has to be read like the manipulative, narcissist-speak that it is. And what it's telling you is - get out.
I hope they are proud of themselves.
JIT should be a top priority given popularity of Python. It should significantly reduce carbon footprint of Python driven applications.
It would be nice if cpython opened up a bit, pluggable GC and JIT would go along way towards reducing this manufactured drama.
It wasn't cool to see PyPy or Stackless getting sidelined.
> pluggable GC and JIT would go along way
One of the points mentioned in the linked discussion is explicitly about ensuring that the JIT design enables multiple implementations.
The flippant attitude of cpythons wrt the standard library is also unfortunate.
Please with your substantive comment comment.
I assume you might mean to ask "why wasn't PyPy adopted in some formal way into CPython" rather than a separate project, for which the answer is at least partially likely to be because it's a completely separate implementation.
At the time I posted it, both were pretty lacking in attention, so it made sense to direct to the earlier of the two.
> For example, rather than proposing one single concrete JIT implementation,
> it may make more sense for the PEP to describe a JIT infrastructure that
> can support multiple implementation strategies.
> Since many different and promising JIT tracing approaches continue to be proposed,
> we believe the infrastructure should make it easy to experiment with and evaluate
> those approaches within CPython rather than be highly coupled with a single strategy.
out of curiosity, why not?
I mean it seems like they want to get a full spec of what JIT should look like in main? given the faff that hapened with the GC removal, I can sort see why they'd want to do this properly. Especially now that it seems like its practical.
That's a very strong claim. I'm not seeing that at all. What causes you to interpret it that way?
I did click on your link, it was a waste of time and that wasn't very nice.
> Please with your substantive comment comment.
I think binning things as drama isn't substantive, particularly when noting about the linked conversation seems dramatic. I also think they're actually talking about the thing you want (pluggable JIT), so the objection seems incongruous.
I assumed Python 2 was pretty much ubiquitous and that the world wasn't adopting Python 3 very quickly for a long time, but I do wonder if the applications I was working with a decade and a half ago (ArcGIS, Blender, Civ4, lots of Red Hat system tools, etc.) biased that viewpoint.
Data science, and then ofc DL being done through python just when python 3 was kinda usable (around 3.3/3.4) was a struck of luck timing-wise.
What I don't understand is "what is your position?" Is is that writing a PEP is unnecessary because adding a JIT to Python could trivially meet the goals you state?
My position is simple: adding a JIT is a major change to the language, so of course it should undergo a PEP and answer the major questions that the steering committee put forward. If you think those questions are trivial, then that's ok. Just answer them in the PEP.
> And if it has to be approved by someone who responds like this, it clearly wouldn't be fun either.
I really don't see why you'd think I would be representative of the steering committee's opinions or attitudes. Do I share a name with one of the members?
Of course the counterargument is that they'll improve it and maybe in future it will be 100% faster... But that seems pretty dubious given the progress so far.
It is nice to have the speed, always. But in Python, it would be a mistake to do it at the expense of flexibility. Same for typing: it is great to have it. I use it. But Python should be dynamic and the rest and extension that does not compromise everything else.
If a JIT can make Python 2 or 3x faster, or even 10x for some workloads, that is nice. But the language itself should support same idioms, reflection, dynamic typing, etc at the same level.
No need to do the annoying if x is None.
If you declare a function inside a for loop with the default argument set to a list, it will be re-declared at every iteration of the loop and the list of the default argument will be a new instance every time.
I understand as much.
> It's not really a design choice.
That explains it then. Pretty damning though, no?
All of them support changing anything at anytime, killing all JIT assumptions, and forcing it to redo the world.
Stop execution, land into the debugger, change whatever code you feel like during the debugging session and then redo last statement, continuing execution.
There are also ways to do this on fly, without necessarily using the debugger.
My assumption just makes sense when all the function really gets is "a list of positional arguments and a dict of keyword arguments" (ala `*args, **kwargs`) that is "deconstructed" to the named variables on the function side. Then the function never gets the default value passed and fills it in before executing the body. Therefore it needs some value to assign and that value is determined when parsing the function definition.
So effectively I want to say that I think instead of the default value being passed at the call site (which is how C++ for example does it by inserting the expression inplace of a specified value) it is filled in by the function before executing the body.
In the end this is just a guess, but that is my working hypothesis.
You can try it in the REPL:
>>> def f(foo=print("Executing def statement!")):
... print("Executing function body.")
...
Executing def statement!
>>> f()
Executing function body.
"Default parameter values are evaluated from left to right when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call."
> So it will join PyPy and GraalPy in the corner.
If you cannot understand what that means, I am not a English professor.
Not even remotely the same context.
We have been here several times, versus the other dynamic languages, and it has nothing to do with the usual excuse how dynamic Python happens to be.
What’s your position? That we should allow an extremely complex system into Python with:
- No clear design goal?
- No maintenance plan?
- No discussion with the steering committee?
PyPy and Jython, and others are not built by the Python team and there has never been a suggestion that any of these systems would be part of CPython.
So again, I still don’t see how different implementations of Python are relevant to the discussion about CPython.