Heads up: if CPython is JIT faster, it may then be (even more) vulnerable to branch prediction vulns like Spectre and Meltdown: https://groups.google.com/g/dev-python/c/67Et2KtpzG4
There's not a PEP for this work either, and one will need to be rebased first, and are there even merge collisions?
On Thu, Feb 23, 2023, 9:00 PM Kevin Modzelewski email@example.com wrote:
Ah ok thanks for the tip, I re-posted this as https://discuss.python.org/t/contributing-the-pyston-jit/24195
On Thu, Feb 23, 2023 at 6:02 PM Brett Cannon firstname.lastname@example.org wrote:
FYI you will probably get more engagement if you posted this to discuss.python.org .
On Thu, Feb 23, 2023, 10:18 Kevin Modzelewski email@example.com wrote:
Hello all, we on the Pyston team would like to propose the contribution of our JIT https://github.com/pyston/pyston/blob/pyston_main/Python/aot_ceval_jit.c into CPython main. We're interested in some initial feedback on this idea before putting in the work to rebase the jit to 3.12 for a PEP and more formal discussion.
Our jit is designed to be simple and to generate code quickly, so we believe it's a good point on the design tradeoff curve for potential inclusion. The runtime behavior is intentionally kept almost completely the same as the interpreter, just lowered to machine code and with optimizations applied.
Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10% speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the potential speedup of our jit rebased onto 3.12 because there is overlap between what our jit does and the optimizations that have gone into the interpreter since 3.8, but there are several optimizations that would be additive with the current performance work:
- Eliminating bytecode dispatch overhead
- Mostly-eliminating stack management overhead
- Reducing the number of reference count operations in the interpreter
- Faster function calls, particularly of C functions
- More specialization opportunities, both because a jit is not limited
by bytecode limits, but also because it is able to do dynamic specializations that are not possible in an interpreter context
There is also room for more optimizations -- in Pyston we've co-optimized the interpreter+jit combination such as by doing more extensive profiling in the interpreter. Our plan would be to submit an initial version that does not contain these optimizations in order to minimize the diff, and add them later.
Our jit uses the DynASM assembler library (part of LuaJIT) to generate machine code. Our jit currently supports Mac and Linux, 64-bit ARM and x86_64. Now that we have two architectures supported, adding additional ones is not too much work.
We think that our jit fits nicely in the technical roadmap of the Faster CPython project, but conflicts with their plan to build a new custom tracing jit.
As mentioned, we'd love to get feedback about the overall appetite for including a jit in CPython!
kmod _______________________________________________ Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/7HTSM36G... Code of Conduct: http://python.org/psf/codeofconduct/
Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/TUTSBGG7... Code of Conduct: http://python.org/psf/codeofconduct/