Re: Contributing the Pyston jit?

--===============0197353166928774894==
Content-Type: multipart/alternative; boundary="00000000000094605305f5670338"

--00000000000094605305f5670338
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">Ah ok thanks for the tip, I re-posted this as=C2=A0<a href=
=3D"https://discuss.python.org/t/contributing-the-pyston-jit/24195">https:/=
/discuss.python.org/t/contributing-the-pyston-jit/24195</a></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 23, =
2023 at 6:02 PM Brett Cannon &lt;<a href=3D"mailto:[email protected]">brett@=
python.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"auto"><div>FYI you will probably get more engagement=
 if you posted this to <a href=3D"http://discuss.python.org" target=3D"_bla=
nk">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:[email protected]" target=3D"_blank">[email protected]</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr">Hello all, we on the Pyston team would like to propose the con=
tribution of our=C2=A0<a href=3D"https://github.com/pyston/pyston/blob/pyst=
on_main/Python/aot_ceval_jit.c" rel=3D"noreferrer" target=3D"_blank">JIT</a=
>=C2=A0into CPython main. We&#39;re interested in some initial feedback on =
this idea before putting in the work to rebase the jit to 3.12 for a PEP an=
d more formal discussion.<div><br></div><div>Our jit is designed to be simp=
le and to generate code quickly, so we believe it&#39;s a good point on the=
 design tradeoff curve for potential inclusion. The runtime behavior is int=
entionally 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% speedu=
p on macrobenchmarks=C2=A0(similar to 3.11). It&#39;s hard to estimate the =
potential speedup of our jit rebased onto 3.12 because there is overlap bet=
ween what our jit does and the optimizations that have gone into the interp=
reter since 3.8, but there are several optimizations that would be additive=
 with the current performance work:<br>- Eliminating bytecode dispatch over=
head</div><div>- Mostly-eliminating stack management overhead</div><div>- R=
educing the number of reference count operations in the interpreter</div><d=
iv>- Faster function calls, particularly of C functions</div><div>- More sp=
ecialization opportunities, both because a jit is not limited by bytecode l=
imits, but also because it is able to do dynamic specializations that are n=
ot possible in an interpreter context</div><div><br></div><div>There is als=
o room for more optimizations -- in Pyston we&#39;ve co-optimized the inter=
preter+jit combination such as by doing more extensive profiling in the int=
erpreter. Our plan would be to submit an initial version that does not cont=
ain these optimizations in order to minimize the diff,=C2=A0and add them la=
ter.<br></div><div><br></div><div>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 suppor=
ted, 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 CP=
ython 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 CPython!</d=
iv><div><br></div><div>kmod</div></div></div>
_______________________________________________<br>
Python-Dev mailing list -- <a href=3D"mailto:[email protected]" rel=3D"=
noreferrer" target=3D"_blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]=
rg" rel=3D"noreferrer" target=3D"_blank">[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>
</blockquote></div>

--00000000000094605305f5670338--

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