Re: Contributing the Pyston jit?
Wes Turner <[email protected]> Mon, 27 Feb 2023 06:40:37 -0500
| Newsgroups | gmane.comp.python.devel |
|---|---|
| Message-ID | <CACfEFw_gL9_qzU7mytVBK0bgUyQx2tj9nW6EEik7ixo=7si4nQ@mail.gmail.com> |
--===============2523398998160724054== Content-Type: multipart/alternative; boundary="0000000000003d902705f5acf378" --0000000000003d902705f5acf378 Content-Type: text/plain; charset="UTF-8" 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 protected]> 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 <[email protected]> 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 protected]> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> https://mail.python.org/mailman3/lists/python-dev.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/[email protected]/message/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/TUTSBGG7D7HW6MFHVX46IQDWAF3MJJLS/ > Code of Conduct: http://python.org/psf/codeofconduct/ > --0000000000003d902705f5acf378 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Heads up: if CPython is JIT faster, it may then be (even = more) vulnerable to branch prediction vulns like Spectre and Meltdown:<div = dir=3D"auto"><a href=3D"https://groups.google.com/g/dev-python/c/67Et2KtpzG= 4">https://groups.google.com/g/dev-python/c/67Et2KtpzG4</a></div><div dir= =3D"auto"><br></div><div dir=3D"auto">There's not a PEP for this work e= ither, and one will need to be rebased first, and are there even merge coll= isions?</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D= "gmail_attr">On Thu, Feb 23, 2023, 9:00 PM Kevin Modzelewski <<a href=3D= "mailto:[email protected]">[email protected]</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"><div dir=3D"ltr">Ah ok thanks for the tip, I re-post= ed this as=C2=A0<a href=3D"https://discuss.python.org/t/contributing-the-py= ston-jit/24195" target=3D"_blank" rel=3D"noreferrer">https://discuss.python= .org/t/contributing-the-pyston-jit/24195</a></div><br><div class=3D"gmail_q= uote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 23, 2023 at 6:02 PM= Brett Cannon <<a href=3D"mailto:[email protected]" target=3D"_blank" rel= =3D"noreferrer">[email protected]</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div dir=3D"auto"><div>FYI you will probab= ly get more engagement if you posted this to <a href=3D"http://discuss.pyth= on.org" target=3D"_blank" rel=3D"noreferrer">discuss.python.org</a> .<br><b= r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, = Feb 23, 2023, 10:18 Kevin Modzelewski <<a href=3D"mailto:[email protected]= m" target=3D"_blank" rel=3D"noreferrer">[email protected]</a>> wrote:<br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">He= llo all, we on the Pyston team would like to propose the contribution of ou= r=C2=A0<a href=3D"https://github.com/pyston/pyston/blob/pyston_main/Python/= aot_ceval_jit.c" rel=3D"noreferrer noreferrer" target=3D"_blank">JIT</a>=C2= =A0into 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 mo= re formal discussion.<div><br></div><div>Our jit is designed to be simple a= nd to generate code quickly, so we believe it's a good point on the des= ign tradeoff curve for potential inclusion. The runtime behavior is intenti= onally kept almost completely the same as the interpreter, just lowered to = machine code and with optimizations applied.<br><div><br></div><div>Our jit= currently targets Python 3.7-3.10, and on 3.8 it achieves a 10% speedup on= macrobenchmarks=C2=A0(similar to 3.11). It's hard to estimate the pote= ntial 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 interprete= r since 3.8, but there are several optimizations that would be additive wit= h the current performance work:<br>- Eliminating bytecode dispatch overhead= </div><div>- Mostly-eliminating stack management overhead</div><div>- Reduc= ing the number of reference count operations in the interpreter</div><div>-= Faster function calls, particularly of C functions</div><div>- More specia= lization opportunities, both because a jit is not limited by bytecode limit= s, but also because it is able to do dynamic specializations that are not p= ossible in an interpreter context</div><div><br></div><div>There is also ro= om for more optimizations -- in Pyston we've co-optimized the interpret= er+jit combination such as by doing more extensive profiling in the interpr= eter. Our plan would be to submit an initial version that does not contain = these optimizations in order to minimize the diff,=C2=A0and add them later.= <br></div><div><br></div><div>Our jit uses the DynASM assembler library (pa= rt 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.</div><div><br></div><div>We t= hink that our jit fits nicely in the technical roadmap of the Faster CPytho= n project, but conflicts with their plan to build a new custom tracing jit.= </div><div><br></div><div><br></div><div>As mentioned, we'd love to get= feedback about the overall appetite for including a jit in CPython!</div><= div><br></div><div>kmod</div></div></div> _______________________________________________<br> Python-Dev mailing list -- <a href=3D"mailto:[email protected]" rel=3D"= noreferrer noreferrer" target=3D"_blank">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]= rg" rel=3D"noreferrer noreferrer" target=3D"_blank">python-dev-leave@python= .org</a><br> <a href=3D"https://mail.python.org/mailman3/lists/python-dev.python.org/" r= el=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://mail.pyth= on.org/mailman3/lists/python-dev.python.org/</a><br> Message archived at <a href=3D"https://mail.python.org/archives/list/python= [email protected]/message/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/" rel=3D"noreferre= r noreferrer noreferrer" target=3D"_blank">https://mail.python.org/archives= /list/[email protected]/message/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/</a><b= r> Code of Conduct: <a href=3D"http://python.org/psf/codeofconduct/" rel=3D"no= referrer noreferrer noreferrer" target=3D"_blank">http://python.org/psf/cod= eofconduct/</a><br> </blockquote></div></div></div> </blockquote></div> _______________________________________________<br> Python-Dev mailing list -- <a href=3D"mailto:[email protected]" target= =3D"_blank" rel=3D"noreferrer">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]= rg" target=3D"_blank" rel=3D"noreferrer">[email protected]</a><br= > <a href=3D"https://mail.python.org/mailman3/lists/python-dev.python.org/" r= el=3D"noreferrer noreferrer" target=3D"_blank">https://mail.python.org/mail= man3/lists/python-dev.python.org/</a><br> Message archived at <a href=3D"https://mail.python.org/archives/list/python= [email protected]/message/TUTSBGG7D7HW6MFHVX46IQDWAF3MJJLS/" rel=3D"noreferre= r noreferrer" target=3D"_blank">https://mail.python.org/archives/list/pytho= [email protected]/message/TUTSBGG7D7HW6MFHVX46IQDWAF3MJJLS/</a><br> Code of Conduct: <a href=3D"http://python.org/psf/codeofconduct/" rel=3D"no= referrer noreferrer" target=3D"_blank">http://python.org/psf/codeofconduct/= </a><br> </blockquote></div> --0000000000003d902705f5acf378-- --===============2523398998160724054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline