OK, fair enough. I wanted to update my previous post updating the reason I said the current implementation but then decided to reply here.
The main reason is to avoid ambiguity of the main components that make the CPython JIT and to establish a common vocabulary around that. Of course this doesn’t have to be on a PEP but I guess that documentation on the CPython repo could be more than enough.
If the PEP will be divided in two or more parts, each PEP must be approved before JIT will return back to main?
While I’m obviously supportive of resuming work on the JIT, I have a few concerns about PEP 836.
Why is changing to a method-based front-end so important that it justifies stalling JIT development for a whole year?
Ruby did much the same switch, changing from a tracing to a method front-end, with the switch from YJIT to ZJIT.
Despite working on ZJIT for over a year now, it is still slower than YJIT, despite YJIT development being largely stalled; one can only speculate how much faster YJIT would be if development on it had continued.
I don’t think should region selection should be in the PEP at all.
No one, outside of those of us working on the JIT, should care about region selection, any more than they need to care about the type lattice, optimization buffer management, or other internals.
As a JIT becomes more advanced, region selection becomes more complex, no longer simply traces vs methods.
In a trace based optimizer, traces can be merged and re-optimized.
In a method based optimizer, calls can be inlined, and stubs generated for cold paths.
Ultimately, the goal of both is to create regions that reflect the execution of the program,and the
final regions produced by either front-end will, to some degree, converge.
Changing to a method front-end doesn’t give us better regions; it just gives us a different starting point to evolve toward good regions.
While I think a tracing front end is better, it isn’t that much better.
If Brandt and Ken Jin can produce a compelling prototype that is easier to maintain and test and doesn’t significantly degrade performance, then it would make sense to switch the front-end. But it doesn’t need to be in the PEP. Having it in the PEP merely limits our options to change the front-end if some alternative or hybrid front-end becomes the best option, or to switch to a method front-end in a year or two, instead of right now.
I should also say, that if we already had a method front-end and a tracing front-end PEP were proposed, I would be oppose that change for much the same reason: it is too disruptive.
Finally, while I think a tracing front-end is superior to a method front-end, both are much better than no JIT at all.
It doesn’t. We have many other goals during this initial phase. From the PEP:
I suspect that the transition to a method frontend will actually be one of the quicker, easier, and more genuinely fun/interesting/rewarding parts.
(Also, all of these “year 1” goals have a deadline of 3.16 beta 1, which is currently less than 9 months away. By the time the PEP is accepted, it may realistically be much less.)
It doesn’t limit our final options, it just sets our current direction. The PEP even says that the method frontend “may be rolled back to the current tracing frontend if the approach does not meet the project’s goals in the first year”. We’re not saying it will always be better, we’re saying it seems best for us right now, given our goals.
I’d definitely love to see the prototype (stated in the PEP and earlier comments), it would be much more convincing. Definitely don’t want to rush anything, but what is the state of it?
Bit of a silly question - I’ve been stalking this forum to see the current status of the JIT, and as far as I can tell, they’re mostly happening in the Steering Committee meetings.
However, the last meeting was apparently on August 13th, but the meeting were published yesterday.
In it, they said that the next meeting would be when they would make their final decision on the JIT stuff (2026-08-13 Python Steering Council meeting summary), but that would mean that that meeting has already happened (Assuming it was on August 20th)?
I’m a bit confused here.
I wouldn’t assume that meeting happened due to summer vacations, or if it did it would not have everyone available to vote. As well, just because the SC thinks they will make a decision in the next meeting, it does not means that will actually happen (there were plenty of meetings when I was on the SC we thought we would make a call on something, someone would bring something up on the topic that would cause the discussion to consume the rest of the meeting, and it would take until the next meeting to make a decision). Add on that the core dev sprints are in September and there might be some prep for it, and it could mean the SC just hasn’t had the time to make a decision yet.
okay that makes sense!
I’m just worried because things seemed to have stalled out (and I think the deadline for the all the stuff this PEP needs to do in time for the beta of 3.17 is coming up) , but also I’m not exactly part of the core committers community so I don’t know how things work 
Sorry if that sounded like a dumb question, I’m new here.
First, a point of order: the Steering Council has not been formally asked to pronounce on PEP 836.
Instead, the authors came to Steering Council Office Hours to have a discussion about the direction and scope of the PEP, and whether it answered the questions we raised about the JIT. At the time of the SCOH, we hadn’t yet had the chance to read the PEP individually so we didn’t have any official feedback.
We’ve all had time to read the PEP and form our opinions, and have over the last several meetings, had a chance to discuss and converge on a response. We’ve been a bit delayed due to absences, but we’re pretty close to convergence on our official feedback, which we’ll post here soon.
Then the PEP authors can take our feedback, and of course ask questions and clarifications, etc. make whatever changes or edits they want to make in response, and post an update. When the authors are ready, they’ll open an issue on the Steering Council tracker asking for official pronouncement.
I hope that sheds a bit of light on the process in general, and where we are in particular for PEP 836. It can take some time for a complex PEP like this to work it’s way through our agenda[1].
other things do come up, and you’d be surprised how quickly our weekly 90 minute meeting goes by, and maybe equally surprised how often we blow through that schedule with another 30, 60, or 90 minutes! ↩︎
Gotcha, thanks so much!
a lot of this stuff seems pretty opaque to me, so thanks for providing some clarity!
so much of open source development seems to be customer service and dealing with people…
I often joke that the job is 50% diplomat, 50% politician, 50% therapist, 50% publicist, 50% engineer, and 100% volunteer.
Development of 3.17 hasn’t even started yet. Python 3.15 will be released in about a month but is in a feature freeze and will definitely not be affected by this PEP. Python 3.16 is the first version to worry about, and its feature freeze is several months away, so there’s no great hurry. (Until, of course, suddenly there is a great hurry.)
(Posting for the Steering Council, minus Savannah as PEP co-author)
A few weeks ago the PEP 836 authors (Brandt, Ken Jin and Savannah) attended Steering Council office hours to talk about the PEP, any concerns the SC might have, and whether the PEP adequately addresses all the concerns we raised in our request for a PEP. The SC didn’t have an answer ready at the time (we hadn’t really discussed the PEP among ourselves yet) so we agreed to discuss it and give feedback on the PEP before it’s sent to the SC for consideration. We don’t normally handle PEPs this way for a variety of reasons, but given that this is a special case in response to a specific request from us, it makes sense. Some of our feedback is about getting more community input on certain topics, so it also makes sense to post this response publicly. (We shared it with the PEP authors directly before posting it here.)
In the request for a PEP, the SC highlighted a few specific questions, which we’ll paraphrase as:
The PEP does answer all of these questions, although perhaps some less convincingly than others, and we’ll get to some points we’d like to see discussed in more detail. One thing we want to make clear is that what we’re evaluating here is whether we want to continue with the JIT as an experiment in main. Part of the problem with allowing experimentation in main is the lack of unified design, and the uncertainty that core developers, package maintainers and users face as the experimentation changes behaviours and API surfaces. We are worried about both of those with the JIT, and the PEP does address this by proposing a design to continue as a specific experiment in main (rather than arbitrary experimentation in main).
We’re not evaluating, at this point, whether the JIT should be declared a supported feature, and we’re not setting the specific criteria the JIT needs to meet in order to be considered supported. Having realistic and aspirational goals on performance and user impact up front is important to make sure the design is even viable, but we don’t consider them necessarily hard requirements for a future “supported status” discussion.
The PEP is also a little vague about the long-term support plans and the performance criteria by which to judge the JIT. Both of those are understandable. Support is a community matter and difficult to dictate (by the JIT team or the SC), but the JIT team is doing the work to broaden the team, share knowledge and document the design and implementation. Committing to exact performance criteria is difficult because of the lack of good, representative performance measurements and benchmarks. The best we have is pyperformance, which can severely underrepresent common uses of Python. It is, however, the best we have available, and we’ll have to make do with it until something better comes along. It means we may have to reconsider the performance goals (and claims) in the future, and we (the SC, and the community) will have to be flexible in that.
There are a few things the SC thinks the PEP is too vague or optimistic about, which we’d like to see either spelled out in the PEP, or at least discussed and rejected. (To be clear, these are not all hard criteria blocking acceptance of the PEP, they’re things we would like to see considered.)
Bottom line, the PEP mostly answers the questions we asked, and there are no significant missing pieces… but we do hope for a bit more discussion on a few topics so we can gauge community support and consensus before we’re asked to pronounce on this PEP.
(Posted for the SC.)
I used the Codex OSS Program to explore two approaches: further optimizing the tracing JIT and switching to a method JIT.
I am not a JIT expert, so I cannot comment on which approach is better, but I hope these implementations produced by Codex will be useful as a reference for future improvements to the JIT.
Thanks for taking the time to write such a detailed feedback! We will work on it!
If the JIT is not approved are there any other viable projects/ideas for further speedups of cpython?