Re: Contributing the Pyston jit?

--===============5459063311701823618==
Content-Type: multipart/alternative; boundary="000000000000c92db605f5629de4"

--000000000000c92db605f5629de4
Content-Type: text/plain; charset="UTF-8"

Please consider colesbury/nogil in rebasing?
https://github.com/colesbury/nogil

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

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

<div dir=3D"auto">Please consider colesbury/nogil in rebasing?=C2=A0<div di=
r=3D"auto"><a href=3D"https://github.com/colesbury/nogil">https://github.co=
m/colesbury/nogil</a></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 =
&lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft: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"h=
ttps://github.com/pyston/pyston/blob/pyston_main/Python/aot_ceval_jit.c" ta=
rget=3D"_blank" rel=3D"noreferrer">JIT</a>=C2=A0into CPython main. We&#39;r=
e interested in some initial feedback on this idea before putting in the wo=
rk to rebase the jit to 3.12 for a PEP and more formal discussion.<div><br>=
</div><div>Our jit is designed to be simple and to generate code quickly, s=
o we believe it&#39;s a good point on the design tradeoff curve for potenti=
al inclusion. The runtime behavior is intentionally kept almost completely =
the same as the interpreter, just lowered to machine code and with optimiza=
tions 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&#39;s hard to estimate the potential speedup of our jit rebas=
ed onto 3.12 because there is overlap between what our jit does and the opt=
imizations that have gone into the interpreter since 3.8, but there are sev=
eral optimizations that would be additive with the current performance work=
:<br>- Eliminating bytecode dispatch overhead</div><div>- Mostly-eliminatin=
g stack management overhead</div><div>- Reducing the number of reference co=
unt operations in the interpreter</div><div>- Faster function calls, partic=
ularly of C functions</div><div>- More specialization opportunities, both b=
ecause 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 cont=
ext</div><div><br></div><div>There is also room for more optimizations -- i=
n Pyston we&#39;ve co-optimized the interpreter+jit combination such as by =
doing more extensive profiling in the interpreter. Our plan would be to sub=
mit an initial version that does not contain these optimizations in order t=
o minimize the diff,=C2=A0and add them later.<br></div><div><br></div><div>=
Our jit uses the DynASM assembler library (part of LuaJIT) to generate mach=
ine 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 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 ap=
petite 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]" 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>

--000000000000c92db605f5629de4--

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