iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 744: Add Discussions-To and Post-History (#3752) 

* Add discussion links, and inline make links anonymous

* Fix links
This commit is contained in:
Brandt Bucher 2024-04-11 18:08:14 -07:00 committed by GitHub
parent 0c92bbf551
commit 71e8fd3dbe
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 22 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
peps/pep-0744.rst
View File

@ -1,16 +1,18 @@
PEP: 744 PEP: 744
Title: JIT Compilation Title: JIT Compilation
Author: Brandt Bucher <brandt@python.org> Author: Brandt Bucher <brandt@python.org>
Discussions-To: https://discuss.python.org/t/pep-744-jit-compilation/50756
Status: Draft Status: Draft
Type: Informational Type: Informational
Created: 11-Apr-2024 Created: 11-Apr-2024
Python-Version: 3.13 Python-Version: 3.13
Post-History: `11-Apr-2024 <https://discuss.python.org/t/pep-744-jit-compilation/50756>`__
Abstract Abstract
======== ========
Earlier this year, an `experimental "just-in-time" compiler Earlier this year, an `experimental "just-in-time" compiler
<https://github.com/python/cpython/pull/113465>`_ was merged into CPython's <https://github.com/python/cpython/pull/113465>`__ was merged into CPython's
``main`` development branch. While recent CPython releases have included other ``main`` development branch. While recent CPython releases have included other
substantial internal changes, this addition represents a particularly substantial internal changes, this addition represents a particularly
significant departure from the way CPython has traditionally executed Python significant departure from the way CPython has traditionally executed Python
@ -27,22 +29,22 @@ introduction.
Readers interested in learning more about the new JIT are encouraged to consult Readers interested in learning more about the new JIT are encouraged to consult
the following resources: the following resources:
- The `presentation <https://youtu.be/HxSHIpEQRjs>`_ which first introduced the - The `presentation <https://youtu.be/HxSHIpEQRjs>`__ which first introduced the
JIT at the 2023 CPython Core Developer Sprint. It includes relevant JIT at the 2023 CPython Core Developer Sprint. It includes relevant
background, a light technical introduction to the "copy-and-patch" technique background, a light technical introduction to the "copy-and-patch" technique
used, and an open discussion of its design amongst the core developers used, and an open discussion of its design amongst the core developers
present. present.
- The `open access paper <https://dl.acm.org/doi/10.1145/3485513>`_ originally - The `open access paper <https://dl.acm.org/doi/10.1145/3485513>`__ originally
describing copy-and-patch. describing copy-and-patch.
- The `blog post <https://sillycross.github.io/2023/05/12/2023-05-12>`_ by the - The `blog post <https://sillycross.github.io/2023/05/12/2023-05-12>`__ by the
paper's author detailing the implementation of a copy-and-patch JIT compiler paper's author detailing the implementation of a copy-and-patch JIT compiler
for Lua. While this is a great low-level explanation of the approach, note for Lua. While this is a great low-level explanation of the approach, note
that it also incorporates other techniques and makes implementation decisions that it also incorporates other techniques and makes implementation decisions
that are not particularly relevant to CPython's JIT. that are not particularly relevant to CPython's JIT.
- The `implementation <#reference-implementation>`_ itself. - The `implementation <#reference-implementation>`__ itself.
Motivation Motivation
========== ==========
@ -53,7 +55,7 @@ direct translation of the source code: it is untyped, and largely unoptimized.
Since the Python 3.11 release, CPython has used a "specializing adaptive Since the Python 3.11 release, CPython has used a "specializing adaptive
interpreter" (:pep:`659`), which `rewrites these bytecode instructions in-place interpreter" (:pep:`659`), which `rewrites these bytecode instructions in-place
<https://youtu.be/shQtrn1v7sQ>`_ with type-specialized versions as they run. <https://youtu.be/shQtrn1v7sQ>`__ with type-specialized versions as they run.
This new interpreter delivers significant performance improvements, despite the This new interpreter delivers significant performance improvements, despite the
fact that its optimization potential is limited by the boundaries of individual fact that its optimization potential is limited by the boundaries of individual
bytecode instructions. It also collects a wealth of new profiling information: bytecode instructions. It also collects a wealth of new profiling information:
@ -63,7 +65,7 @@ what paths through the program are being executed the most. In other words,
Since the Python 3.12 release, CPython has generated this interpreter from a Since the Python 3.12 release, CPython has generated this interpreter from a
`C-like domain-specific language `C-like domain-specific language
<https://github.com/python/cpython/blob/main/Python/bytecodes.c>`_ (DSL). In <https://github.com/python/cpython/blob/main/Python/bytecodes.c>`__ (DSL). In
addition to taming some of the complexity of the new adaptive interpreter, the addition to taming some of the complexity of the new adaptive interpreter, the
DSL also allows CPython's maintainers to avoid hand-writing tedious boilerplate DSL also allows CPython's maintainers to avoid hand-writing tedious boilerplate
code in many parts of the interpreter, compiler, and standard library that must code in many parts of the interpreter, compiler, and standard library that must
@ -98,7 +100,7 @@ Since much of this data varies even between identical runs of a program and the
existing optimization pipeline makes heavy use of runtime profiling information, existing optimization pipeline makes heavy use of runtime profiling information,
it doesn't make much sense to compile these traces ahead of time. As has been it doesn't make much sense to compile these traces ahead of time. As has been
demonstrated for many other dynamic languages (`and even Python itself demonstrated for many other dynamic languages (`and even Python itself
<https://www.pypy.org>`_), the most promising approach is to compile the <https://www.pypy.org>`__), the most promising approach is to compile the
optimized micro-ops "just in time" for execution. optimized micro-ops "just in time" for execution.
Rationale Rationale
@ -168,7 +170,7 @@ Support
The JIT has been developed for all of :pep:`11`'s current tier one platforms, The JIT has been developed for all of :pep:`11`'s current tier one platforms,
most of its tier two platforms, and one of its tier three platforms. most of its tier two platforms, and one of its tier three platforms.
Specifically, CPython's ``main`` branch has `CI Specifically, CPython's ``main`` branch has `CI
<https://github.com/python/cpython/blob/main/.github/workflows/jit.yml>`_ <https://github.com/python/cpython/blob/main/.github/workflows/jit.yml>`__
building and testing the JIT for both release and debug builds on: building and testing the JIT for both release and debug builds on:
- ``aarch64-apple-darwin/clang`` - ``aarch64-apple-darwin/clang``
@ -202,7 +204,7 @@ failures on tier one and tier two platforms should block releases. Though it's
not necessary to update :pep:`11` to specify JIT support, it may be helpful to not necessary to update :pep:`11` to specify JIT support, it may be helpful to
do so anyway. Otherwise, a list of supported platforms should be maintained in do so anyway. Otherwise, a list of supported platforms should be maintained in
`the JIT's README `the JIT's README
<https://github.com/python/cpython/blob/main/Tools/jit/README.md>`_. <https://github.com/python/cpython/blob/main/Tools/jit/README.md>`__.
Since it should always be possible to build CPython without the JIT, removing Since it should always be possible to build CPython without the JIT, removing
JIT support for a platform should *not* be considered a backwards-incompatible JIT support for a platform should *not* be considered a backwards-incompatible
@ -253,7 +255,7 @@ This JIT, like any JIT, produces large amounts of executable data at runtime.
This introduces a potential new attack surface to CPython, since a malicious This introduces a potential new attack surface to CPython, since a malicious
actor capable of influencing the contents of this data is therefore capable of actor capable of influencing the contents of this data is therefore capable of
executing arbitrary code. This is a `well-known vulnerability executing arbitrary code. This is a `well-known vulnerability
<https://en.wikipedia.org/wiki/Just-in-time_compilation#Security>`_ of JIT <https://en.wikipedia.org/wiki/Just-in-time_compilation#Security>`__ of JIT
compilers. compilers.
In order to mitigate this risk, the JIT has been written with best practices in In order to mitigate this risk, the JIT has been written with best practices in
@ -282,7 +284,7 @@ Apple Silicon
Though difficult to test without actually signing and packaging a macOS release, Though difficult to test without actually signing and packaging a macOS release,
it *appears* that macOS releases should `enable the JIT Entitlement for the it *appears* that macOS releases should `enable the JIT Entitlement for the
Hardened Runtime Hardened Runtime
<https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon#Enable-the-JIT-Entitlement-for-the-Hardened-Runtime>`_. <https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon#Enable-the-JIT-Entitlement-for-the-Hardened-Runtime>`__.
This shouldn't make *installing* Python any harder, but may add additional steps This shouldn't make *installing* Python any harder, but may add additional steps
for release managers to perform. for release managers to perform.
@ -322,7 +324,7 @@ Choose the sections that best describe you:
- ...if you don't wish to build the JIT, you can simply ignore it. Otherwise, - ...if you don't wish to build the JIT, you can simply ignore it. Otherwise,
you will need to `install a compatible version of LLVM you will need to `install a compatible version of LLVM
<https://github.com/python/cpython/blob/main/Tools/jit/README.md>`_, and <https://github.com/python/cpython/blob/main/Tools/jit/README.md>`__, and
pass the appropriate flag to the build scripts. Your build may take up to a pass the appropriate flag to the build scripts. Your build may take up to a
minute longer. Note that the JIT should *not* be distributed to end users or minute longer. Note that the JIT should *not* be distributed to end users or
used in production while it is still in the experimental phase. used in production while it is still in the experimental phase.
@ -446,7 +448,7 @@ Support multiple compiler toolchains
Clang is specifically needed because it's the only C compiler with support for Clang is specifically needed because it's the only C compiler with support for
guaranteed tail calls (|musttail|_), which are required by CPython's guaranteed tail calls (|musttail|_), which are required by CPython's
`continuation-passing-style `continuation-passing-style
<https://en.wikipedia.org/wiki/Continuation-passing_style#Tail_calls>`_ approach <https://en.wikipedia.org/wiki/Continuation-passing_style#Tail_calls>`__ approach
to JIT compilation. Without it, the tail-recursive calls between templates could to JIT compilation. Without it, the tail-recursive calls between templates could
result in unbounded C stack growth (and eventual overflow). result in unbounded C stack growth (and eventual overflow).
@ -481,7 +483,7 @@ Add GPU support
The JIT is currently CPU-only. It does not, for example, offload NumPy array The JIT is currently CPU-only. It does not, for example, offload NumPy array
computations to CUDA GPUs, as JITs like `Numba computations to CUDA GPUs, as JITs like `Numba
<https://numba.pydata.org/numba-doc/latest/cuda/overview.html>`_ do. <https://numba.pydata.org/numba-doc/latest/cuda/overview.html>`__ do.
There is already a rich ecosystem of tools for accelerating these sorts of There is already a rich ecosystem of tools for accelerating these sorts of
specialized tasks, and CPython's JIT is not intended to replace them. Instead, specialized tasks, and CPython's JIT is not intended to replace them. Instead,
@ -495,12 +497,12 @@ Speed
----- -----
Currently, the JIT is `about as fast as the existing specializing interpreter Currently, the JIT is `about as fast as the existing specializing interpreter
<https://github.com/faster-cpython/benchmarking-public/blob/main/configs.png>`_ <https://github.com/faster-cpython/benchmarking-public/blob/main/configs.png>`__
on most platforms. Improving this is obviously a top priority at this point, on most platforms. Improving this is obviously a top priority at this point,
since providing a significant performance gain is the entire motivation for since providing a significant performance gain is the entire motivation for
having a JIT at all. A number of proposed improvements are already underway, and having a JIT at all. A number of proposed improvements are already underway, and
this ongoing work is being tracked in `GH-115802 this ongoing work is being tracked in `GH-115802
<https://github.com/python/cpython/issues/115802>`_. <https://github.com/python/cpython/issues/115802>`__.
Memory Memory
------ ------
@ -509,7 +511,7 @@ Because it allocates additional memory for executable machine code, the JIT does
use more memory than the existing interpreter at runtime. According to the use more memory than the existing interpreter at runtime. According to the
official benchmarks, the JIT currently uses about `10-20% more memory than the official benchmarks, the JIT currently uses about `10-20% more memory than the
base interpreter base interpreter
<https://github.com/faster-cpython/benchmarking-public/blob/main/memory_configs.png>`_. <https://github.com/faster-cpython/benchmarking-public/blob/main/memory_configs.png>`__.
The upper end of this range is due to ``aarch64-apple-darwin``, which has larger The upper end of this range is due to ``aarch64-apple-darwin``, which has larger
page sizes (and thus, a larger minimum allocation granularity). page sizes (and thus, a larger minimum allocation granularity).
@ -522,7 +524,7 @@ likely to be a real concern.
Not much effort has been put into optimizing the JIT's memory usage yet, so Not much effort has been put into optimizing the JIT's memory usage yet, so
these numbers likely represent a maximum that will be reduced over time. these numbers likely represent a maximum that will be reduced over time.
Improving this is a medium priority, and is being tracked in `GH-116017 Improving this is a medium priority, and is being tracked in `GH-116017
<https://github.com/python/cpython/issues/116017>`_. <https://github.com/python/cpython/issues/116017>`__.
Earlier versions of the JIT had a more complicated memory allocation scheme Earlier versions of the JIT had a more complicated memory allocation scheme
which imposed a number of fragile limitations on the size and layout of the which imposed a number of fragile limitations on the size and layout of the
@ -547,7 +549,7 @@ since installing the required tools is not prohibitively difficult for most
people building CPython, and the build step is not particularly time-consuming. people building CPython, and the build step is not particularly time-consuming.
Since some still remain interested in this possibility, discussion is being Since some still remain interested in this possibility, discussion is being
tracked in `GH-115869 <https://github.com/python/cpython/issues/115869>`_. tracked in `GH-115869 <https://github.com/python/cpython/issues/115869>`__.
Footnotes Footnotes
========= =========