Please consider colesbury/nogil in rebasing? https://github.com/colesbury/nogil
On Thu, Feb 23, 2023, 1:20 PM Kevin Modzelewski <kev...@gmail.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 -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EL7O7TJNYBFH2MRAV2AZCBUWV2TVUXMW/ Code of Conduct: http://python.org/psf/codeofconduct/
