PEP 744: Add link to slides and clarification about LLVM dependency

[savannahostrowski]

After going through the themes in the discussion thread, the biggest warranted update was to clarify the LLVM build time dependency. Some topics discussed go beyond the scope of the informational PEP (e.g., going more into how the inner workings of the JIT, details about tier 1 and 2 interpreters, existing/expired patents, comparison with PyPy) or are, in my opinion, sufficiently covered (e.g., copy-and-patch compilation) by linked content.

I've also added a link to the slides for the first talk covering the JIT for easier reading. I found a few different versions on your GitHub @brandtbucher but chose to link the slides from when the talk was originally given. Let me know if you'd like to update the links to reflect the most recent talk and/or want to host the slides somewhere else.

I will keep this in draft to give folks a couple more days to reply to the thread in case there are other points they'd like to see clarified.

---

📚 Documentation preview 📚: https://pep-previews--3850.org.readthedocs.build/

[hugovk]

Looks like this is ready to merge, @brandtbucher feel free to merge if you've no comments.

@savannahostrowski Congratulations on your first PEP co-authorship, and thanks for all your CPython work in this area as well! 🎉

[brandtbucher]

Looks great, Thanks!

After a quick skim through the thread, I think there may be more opportunities to clarify a few things. I don't know if all of these need to be addressed, but I think they're good questions that we might consider answering.

• Clarifying that GC of cold traces is something that we're currently exploring. We may expose tunable parameters for limiting memory usage in the future, but no "official" APIs will be exposed until the feature is stable.
• Clarifying in the top level of the specification that it will always be possible to build CPython without the JIT, and that this will likely remain the default build configuration for the forseeable future (though official binaries may in fact include it).
• Calling out PYTHON_JIT=0 as a way of disabling the JIT, even on builds where it is enabled by default.
• I'm still on the fence about a high-level design comparison with PyPy. If you're motivated to dig into this, we can maybe add a section (since it's a natural question), but I also think the PEP doesn't necessarily need it. I know enough about PyPy to evaluate the correctness of any comparison, but lack the motivation to actually write it right now. :)
• It might be worth elaborating on the general direction of performance improvements (covered in the second half of this comment).
• Itamar's questions here are interesting and, in my opinion, relevant. I'm not sure I 100% agree with Mark's responses, so this may take a bit more thought before putting in "official" PEP form.
• A comment explaining that the current approach would probably not work well for ahead-of-time compilation, and that it's not something we're pursuing.

I'll leave these up to you for future PRs, if you think any of them belong in the PEP. :)

(@hugovk, do CODEOWNERS entries work for non-committers? If so, Savannah should probably add herself so she gets review requests for changes.)

[JelleZijlstra]

do CODEOWNERS entries work for non-committers

Only people with commit access to the repo can be CODEOWNERS. But I think that includes triagers now, so it should be possible to add Savannah.

[savannahostrowski]

Thanks for the feedback @brandtbucher. I'll take a look at some additional updates early next week!