Wording

Author: hugovk

peps/pep-0836.rst

@@ -20,7 +20,7 @@ explicitly deferred a number of questions about the JIT's long-term status.
 Since then, the JIT has been re-architected and matured considerably. In Python
 3.15, it delivers a measurable, reproducible speedup over the interpreter
 (about 4-12% geometric mean performance improvement across measured Tier 1
-platforms (see :ref:`Appendix <836-appendix-jit-speedup-2wk>`),
+platforms; see :ref:`Appendix <836-appendix-jit-speedup-2wk>`),
 emits frames that native debuggers can unwind through, and reduces the memory
 footprint of generated code relative to 3.14. Along the way, we have learned a
 good deal about what works for a JIT in CPython.
@@ -123,8 +123,8 @@ Python versions, extension compatibility, embedding requirements, deployment
 constraints, and tooling support.
 
 :pep:`744` did valuable work explaining the JIT's copy-and-patch approach, made
-the case for keeping the implementation in CPython ``main`` branch so that it could
-be maintained by a broader group of volunteers, and sketched some criteria
+the case for keeping the implementation in CPython's ``main`` branch so that it
+could be maintained by a broader group of volunteers, and sketched some criteria
 under which the JIT might eventually graduate from an experimental state.
 However, the original PEP for the JIT left many questions open about
 guarantees, maintenance commitments, success metrics, timelines, tooling
@@ -146,7 +146,7 @@ As of CPython 3.15, the current JIT compiler is roughly 4-12% faster geometric
 mean on the pyperformance benchmark suite compared to the interpreter across
 measured Tier 1 platforms
 (see :ref:`Appendix <836-appendix-jit-speedup-2wk>`). In order to
-achieve this, the JIT and supporting infrastructure has undergone a number of
+achieve this, the JIT and supporting infrastructure have undergone a number of
 revisions across the last four major versions of Python:
 
 * **3.12:** Introduction of the CPython bytecode DSL, and refactoring of
@@ -424,7 +424,7 @@ evolves:
 
 With all of the above, most optimizations in the JIT can be implemented as
 local rewrites. This is again, inspired by certain properties of other
-runtime's intermediate representations. Our goal is to make the JIT more
+runtimes' intermediate representations. Our goal is to make the JIT more
 traditional and teachable, without sacrificing what we can optimize. We do
 acknowledge that a method JIT requires joining control-flow. However, we
 believe this is not a large conceptual overhead, as a tracing JIT already
@@ -435,9 +435,9 @@ In terms of what code we need to achieve this frontend, most of the
 infrastructure required is already present. The main code modifications
 required are the data structures to represent a control-flow graph, and
 worklist algorithms to drive the pre-existing optimizer/analysis pass. We can
-proceed to remove most of the current tracing frontend from the JIT from the
+proceed to remove most of the current tracing frontend from the JIT and the
 interpreter, which will simplify the interpreter's core dispatch mechanism and
-simplify the main interpreter loop. We believe these are not foreign concepts
+the main interpreter loop. We believe these are not foreign concepts
 to CPython -- the current bytecode compiler in CPython already represents
 control-flow graphs and has worklist algorithms.
 
@@ -526,7 +526,7 @@ CPython.
 First-Class Support for Free-Threading
 --------------------------------------
 
-free-threading is already a part of Python's future, and the current JIT must
+Free-threading is already a part of Python's future, and the current JIT must
 be made free-threading safe as soon as possible to be a viable option for
 improved performance. This involves making the frontend and middle-end's
 optimizations free-threading safe (the backend should already be safe). We do
@@ -543,12 +543,12 @@ slight (1-2% geomean) performance hit initially.
 
 All future optimizations upon resuming JIT development will be reviewed with
 free-threading compatibility and performance impact required before merge.
-Optimizations that rely solely on the GIL build and break on the free threaded
+Optimizations that rely solely on the GIL build and break on the free-threaded
 build will be rejected.
 
 Additionally, the JIT may eventually even produce better performance versus the
 free-threading build than the current GIL build. Early experiments in the JIT
-suggest free threaded optimization may gain a few more percentage points on
+suggest free-threaded optimization may gain a few more percentage points on
 pyperformance. For example:
 
 * Reference counting on the free-threading build is more expensive than on the