Re: Contributing the Pyston jit?
Brett Cannon <[email protected]> Thu, 23 Feb 2023 13:26:42 -0800
| Newsgroups | gmane.comp.python.devel |
|---|---|
| Message-ID | <CAP1=2W6HG_bC=5NqQec+BccwYcXq=OTcv_0=VqCmLrdxSohCdQ@mail.gmail.com> |
--===============8946829621023716428== Content-Type: multipart/alternative; boundary="000000000000e592b305f564ab01" --000000000000e592b305f564ab01 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 23, 2023, 11:34 Wes Turner <[email protected]> wrote: > Please consider colesbury/nogil in rebasing? > https://github.com/colesbury/nogil > It's very premature for anyone to concern themselves with Sam's nogil work when it comes to their own work as PEP 703 has not been sent to the SC (let alone been accepted). > > On Thu, Feb 23, 2023, 1:20 PM 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/EL7O7TJNYBFH2MRAV2AZCBUWV2TVUXMW/ > Code of Conduct: http://python.org/psf/codeofconduct/ > --000000000000e592b305f564ab01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Thu, Feb 23, 2023, 11:34 Wes Turner <<a href=3D"= mailto:[email protected]">[email protected]</a>> wrote:<br></div><= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><div dir=3D"auto">Please consider colesbury/n= ogil in rebasing?=C2=A0<div dir=3D"auto"><a href=3D"https://github.com/cole= sbury/nogil" target=3D"_blank" rel=3D"noreferrer">https://github.com/colesb= ury/nogil</a></div><div dir=3D"auto"></div></div></blockquote></div></div><= div dir=3D"auto"><br></div><div dir=3D"auto">It's very premature for an= yone to concern themselves with Sam's nogil work when it comes to their= own work as PEP 703 has not been sent to the SC (let alone been accepted).= </div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quo= te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><br>= </div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_= attr">On Thu, Feb 23, 2023, 1:20 PM Kevin Modzelewski <<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:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello= all, we on the Pyston team would like to propose the contribution of our= =C2=A0<a href=3D"https://github.com/pyston/pyston/blob/pyston_main/Python/a= ot_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> _______________________________________________<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/EL7O7TJNYBFH2MRAV2AZCBUWV2TVUXMW/" rel=3D"noreferre= r noreferrer" target=3D"_blank">https://mail.python.org/archives/list/pytho= [email protected]/message/EL7O7TJNYBFH2MRAV2AZCBUWV2TVUXMW/</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></div></div> --000000000000e592b305f564ab01-- --===============8946829621023716428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline