PEP 744: Additional updates from discussion thread (#3861)
This commit is contained in:
parent
b0ed14cf9d
commit
a9242b65d4
|
@ -622,7 +622,7 @@ peps/pep-0740.rst @dstufft
|
||||||
peps/pep-0741.rst @vstinner
|
peps/pep-0741.rst @vstinner
|
||||||
peps/pep-0742.rst @JelleZijlstra
|
peps/pep-0742.rst @JelleZijlstra
|
||||||
peps/pep-0743.rst @vstinner @encukou
|
peps/pep-0743.rst @vstinner @encukou
|
||||||
peps/pep-0744.rst @brandtbucher
|
peps/pep-0744.rst @brandtbucher @savannahostrowski
|
||||||
peps/pep-0745.rst @hugovk
|
peps/pep-0745.rst @hugovk
|
||||||
peps/pep-0746.rst @JelleZijlstra
|
peps/pep-0746.rst @JelleZijlstra
|
||||||
peps/pep-0747.rst @JelleZijlstra
|
peps/pep-0747.rst @JelleZijlstra
|
||||||
|
|
|
@ -99,10 +99,11 @@ physical hardware registers).
|
||||||
|
|
||||||
Since much of this data varies even between identical runs of a program and the
|
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 and would be a
|
||||||
demonstrated for many other dynamic languages (`and even Python itself
|
substantial redesign of the existing specification and micro-op tracing infrastructure
|
||||||
<https://www.pypy.org>`__), the most promising approach is to compile the
|
that has already been implemented. As has been demonstrated for many other dynamic
|
||||||
optimized micro-ops "just in time" for execution.
|
languages (`and even Python itself <https://www.pypy.org>`__), the most promising
|
||||||
|
approach is to compile the optimized micro-ops "just in time" for execution.
|
||||||
|
|
||||||
Rationale
|
Rationale
|
||||||
=========
|
=========
|
||||||
|
@ -138,8 +139,10 @@ code and 500 lines of runtime C code.
|
||||||
Specification
|
Specification
|
||||||
=============
|
=============
|
||||||
|
|
||||||
The JIT will become non-experimental once all of the following conditions are
|
The JIT is currently not part of the default build configuration, and it is
|
||||||
met:
|
likely to remain that way for the foreseeable future (though official binaries
|
||||||
|
may include it). That said, the JIT will become non-experimental once all of
|
||||||
|
the following conditions are met:
|
||||||
|
|
||||||
#. It provides a meaningful performance improvement for at least one popular
|
#. It provides a meaningful performance improvement for at least one popular
|
||||||
platform (realistically, on the order of 5%).
|
platform (realistically, on the order of 5%).
|
||||||
|
@ -525,7 +528,10 @@ 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>`__. We may consider
|
||||||
|
exposing configurable parameters for limiting memory consumption in the
|
||||||
|
future, but no official APIs will be exposed until the JIT meets the
|
||||||
|
requirements to be considered non-experimental.
|
||||||
|
|
||||||
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
|
||||||
|
|
Loading…
Reference in New Issue