GeezerVison

Alright, I think I've addressed everyone's comments. Thanks for the reviews... this PR is looking better than ever!

If anyone is planning on reviewing this, please do so now. Otherwise, my plan is to merge this first thing on Monday.

(I've confirmed that the two CI failures are failing on main too, and aren't JIT-related).

Well, due to a GitHub UI glitch, the merge button errored out when I pushed it, leaving the PR open. But never fear... it was indeed merged (twice)!

Thanks again, everybody. :)

Congrats! Well done.

As Release Manager, and after talking this through with the Steering Council, I'm going to have to ask: where is the PEP for this, or some other kind of document explaining the design decisions and the discussions around it? Why was it merged now, without a PEP or wide discussion among Core Developers, especially since the immediate performance benefit is pretty much non-existent?

We have the PEP process for a reason. For longevity of CPython, it's important to not just add new features, but also bring along other Core Developers in their design -- especially since we all implicitly adopt the maintenance of it. Even optional bits, because they are all part of the support surface (especially when they're desirable features). We also have a standing policy not to experiment in main, and while I understand the upside of merging this early and then iterating on it, especially given how it meshes with other improvements to uops and what not, this feels like it's close to doing just that: experimenting in main. Merging it and iterating makes it much harder to revert it later, should that turn out to be necessary. That's not to say that it mustn't be merged, but it should be considered an exception and done with some deliberation with the RM or the SC.

How much follow-up work relies on this being merged, now? How difficult would it be to revert now and merge again later?

Thanks for voicing your concerns.

As Release Manager, and after talking this through with the Steering Council, I'm going to have to ask: where is the PEP for this, or some other kind of document explaining the design decisions and the discussions around it? Why was it merged now, without a PEP or wide discussion among Core Developers, especially since the immediate performance benefit is pretty much non-existent?

There isn't a PEP for this. If I were to write one today, it would basically cover all of the same points as the talk I gave at the October sprint (slides, paper, blog post).

Despite the absence of a PEP, I feel that this was widely-discussed with core devs. Just to recap the timeline...

I first introduced this patch at the core dev sprint last year, on October 10th, in a 48-minute talk and Q&A. During the Q&A, I said:

If this is something people would like to see in main, off by default, we can get it in main very easily. I know we aren't crazy about experiments in main, which is kind of why I'm floating the idea now.

The video was shared with all core devs that same day. In both the in-person and follow-up Discourse discussion, I personally perceived the feedback to be very positive (much more positive than I anticipated). Maybe I misread the room, but the response convinced me that this wasn't very hard-to-understand or controversial (except for parts of the build process, in particular the LLVM requirement).

Twenty days later, on October 30th, I made the following comment on Discourse, visible to all committers:

An update: my current goal is to merge this initial implementation (behind a build flag, off by default) before the American Thanksgiving holiday. That’s on Thursday, November 23rd… which means I’ll probably be opening the PR around Friday the 17th. Active development can then continue on main (which seemed okay with people at the sprint).

Nobody objected. That deadline came and went, and a month later the PR itself was published as a draft for 24 days, then open for an additional 11 days before merging (which I announced 3 days in advance).

Merging it and iterating makes it much harder to revert it later, should that turn out to be necessary. That's not to say that it mustn't be merged, but it should be considered an exception and done with some deliberation with the RM or the SC.

How much follow-up work relies on this being merged, now? How difficult would it be to revert now and merge again later?

Part of the reason why there's a negligible performance impact right now is because it purposefully omits lots of "obvious" performance improvements in order to keep the initial JIT implementation as small and easy-to-review as possible. I'd rather have each one of them be reviewed on their own merits than develop a more-and-more sophisticated JIT that we all feel pressure to merge before the beta freeze.

I don't believe these changes would make reverting any more difficult, since they'll probably be isolated to new files (git revert f6d9e59 works fine right now on main).

Should one of us open an issue on the SC tracker?

I'm glad to hear you think the discussion was wide-spread enough. I'm not really concerned that the JIT wasn't researched or reviewed enough, although I will say that I tuned out the discussion about your presentation on discuss.python.org because I was expecting a PEP once it was fleshed out (and I don't believe I was the only one).

I do believe a PEP is warranted, even at this stage. A PEP isn't just for making decisions, it's also for recording the history of the decisions (and the process around it), and to set boundaries and limitations to a particular feature. It's where people (core developers and others) will look for answers to questions they have about this feature. A PEP that summarises (or links to) arguments previously made is fine. I (and the SC) would like it to address questions like:

• What's the story for inspecting the runtime with the JIT enabled, like with perf or C debuggers (not PEP 669 debuggers, which I assume are unaffected)?
• What are the effects on and limitations of the JIT in terms of code size, binary size, memory use, etc? I remember in October we talked about 32-bit offsets which I know is going to be problematic in certain situations.
• What other downsides, negative effects and subtle semantic differences can people expect when they enable this in their builds?
• How are we going to determine whether this should be promoted from an experimental feature to one we recommend, or even one we make the default?

Okay, makes sense. I'll start on a PEP.

At long last, the PEP is up: https://discuss.python.org/t/pep-744-jit-compilation