A few of points/doubts on the PEP.
First, there’s no clear statement about the memory consumption when using the JIT (compared to non-JIT, of course). It’s mentioned that the initial implementation might use more memory, but there’s no goal neither KPI(s) defined for the long run → stabilization → CPython 3.17.
Regarding this:
However, we do not plan to concentrate dedicated cycles to improving 32-bit Windows performance and would like to exclude the platform from our goals as PyPI statistics suggest 32-bit Windows builds are a vanishingly small number of downloads.
why continue spending time on a 32-bit platform/architecture? It’s more than 20 years that all sold PCs are 64-bit. Windows 11 is 64-bit only. Even if there is a percentage of people which still need to use 32-bit Python versions, IMO it doesn’t deserve investing time/resources on it.
I’m not stating, with this, that 32-bit architectures/platforms should be entirely dropped: they can be kept, but without focus from CPython developers.
Finally, this:
Some Single Static Assignment (SSA) form properties over the stack. This does not mean we need to rewrite our IR to SSA form, but rather, the optimizer should have some SSA properties. We believe this aligns more closely with other compilers (e.g. Cinder, PyPy, Chrome’s V8, CRuby’s YJIT/ZJIT), and makes understanding how to optimize in the JIT easier and more powerful. The current JIT optimizer already nearly supports this, and only requires minimal changes to have SSA properties. An IR with proper stack discipline already has many useful properties that are analogous to SSA form. SSA form will basically come for free for stack variables.
might suggest a change on the CPython parser as well, introducing X = Y BINOP Z and X = UNOP Y bytecodes to help the JIT and gain some speed also on ceval (like I did time ago on WPython).