Re: Contributing the Pyston jit?

--===============5686157589083229858==
Content-Type: multipart/alternative; boundary="00000000000060e25b05f5660182"

--00000000000060e25b05f5660182
Content-Type: text/plain; charset="UTF-8"

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/
>

--00000000000060e25b05f5660182
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>FYI you will probably get more engagement if you pos=
ted this to <a href=3D"http://discuss.python.org">discuss.python.org</a> .<=
br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Thu, Feb 23, 2023, 10:18 Kevin Modzelewski &lt;<a href=3D"mailto:kevmod@gma=
il.com">[email protected]</a>&gt; 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 propos=
e the contribution of our=C2=A0<a href=3D"https://github.com/pyston/pyston/=
blob/pyston_main/Python/aot_ceval_jit.c" target=3D"_blank" rel=3D"noreferre=
r">JIT</a>=C2=A0into CPython main. We&#39;re interested in some initial fee=
dback on this idea before putting in the work to rebase the jit to 3.12 for=
 a PEP and more formal discussion.<div><br></div><div>Our jit is designed t=
o be simple and to generate code quickly, so we believe it&#39;s a good poi=
nt on the design tradeoff curve for potential inclusion. The runtime behavi=
or is intentionally kept almost completely the same as the interpreter, jus=
t 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 1=
0% speedup on macrobenchmarks=C2=A0(similar to 3.11). It&#39;s hard to esti=
mate the potential speedup of our jit rebased onto 3.12 because there is ov=
erlap between what our jit does and the optimizations that have gone into t=
he interpreter since 3.8, but there are several optimizations that would be=
 additive with the current performance work:<br>- Eliminating bytecode disp=
atch overhead</div><div>- Mostly-eliminating stack management overhead</div=
><div>- Reducing the number of reference count operations in the interprete=
r</div><div>- Faster function calls, particularly of C functions</div><div>=
- More specialization opportunities, both because a jit is not limited by b=
ytecode limits, but also because it is able to do dynamic specializations t=
hat are not possible in an interpreter context</div><div><br></div><div>The=
re is also room for more optimizations -- in Pyston we&#39;ve co-optimized =
the interpreter+jit combination such as by doing more extensive profiling i=
n the interpreter. Our plan would be to submit an initial version that does=
 not contain these optimizations in order to minimize the diff,=C2=A0and ad=
d them later.<br></div><div><br></div><div>Our jit uses the DynASM assemble=
r library (part of LuaJIT) to generate machine code. Our jit currently supp=
orts Mac and Linux, 64-bit ARM and x86_64. Now that we have two architectur=
es supported, adding additional ones is not too much work.</div><div><br></=
div><div>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.</div><div><br></div><div><br></div><div>As mentioned, we&#39;=
d love to get feedback about the overall appetite for including a jit in CP=
ython!</div><div><br></div><div>kmod</div></div></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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/" rel=3D"noreferre=
r noreferrer" target=3D"_blank">https://mail.python.org/archives/list/pytho=
[email protected]/message/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/</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>

--00000000000060e25b05f5660182--

--===============5686157589083229858==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline