mirror of
https://github.com/python/cpython.git
synced 2025-12-08 06:10:17 +00:00
4fa80ce74c
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md . This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277 The optimizer stack space check is disabled, as it's no longer valid to deal with underflow. Pros: * Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator. * `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace. * The new JIT frontend is able to handle a lot more control-flow than the old one. * Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing. * Better handling of polymorphism. We leverage the specializing interpreter for this. Cons: * (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962 Design: * After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests. * The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering. * The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory. * The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt. * The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested. * Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace. * Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`. |
||
|---|---|---|
| .. | ||
| build | ||
| buildbot | ||
| c-analyzer | ||
| cases_generator | ||
| clinic | ||
| freeze | ||
| ftscalingbench | ||
| gdb | ||
| i18n | ||
| importbench | ||
| inspection | ||
| jit | ||
| lockbench | ||
| msi | ||
| nuget | ||
| patchcheck | ||
| peg_generator | ||
| scripts | ||
| ssl | ||
| tsan | ||
| unicode | ||
| unittestgui | ||
| wasm | ||
| README | ||
| requirements-dev.txt | ||
| requirements-hypothesis.txt | ||
This directory contains a number of Python programs that are useful
while building or extending Python.
build Automatically generated directory by the build system
contain build artifacts and intermediate files.
buildbot Batchfiles for running on Windows buildbot workers.
c-analyzer Tools to check no new global variables have been added.
cases_generator Tooling to generate interpreters.
clinic A preprocessor for CPython C files in order to automate
the boilerplate involved with writing argument parsing
code for "builtins".
freeze Create a stand-alone executable from a Python program.
ftscalingbench Benchmarks for free-threading and finding bottlenecks.
gdb Python code to be run inside gdb, to make it easier to
debug Python itself (by David Malcolm).
i18n Tools for internationalization. pygettext.py
parses Python source code and generates .pot files,
and msgfmt.py generates a binary message catalog
from a catalog in text format.
importbench A set of micro-benchmarks for various import scenarios.
inspection Tooling for PEP-678 "Safe external debugger interface for CPython".
jit Tooling for building the JIT.
lockbench Benchmarks for PyMutex and critical sections.
msi Support for packaging Python as an MSI package on Windows.
nuget Files for the NuGet package manager for .NET.
patchcheck Tools for checking and applying patches to the Python source code
and verifying the integrity of patch files.
peg_generator PEG-based parser generator (pegen) used for new parser.
scripts A number of useful single-file programs, e.g. run_tests.py
which runs the Python test suite.
ssl Scripts to generate ssl_data.h from OpenSSL sources, and run
tests against multiple installations of OpenSSL and LibreSSL.
tsan Utilities for building CPython with thread-sanitizer.
unicode Tools for generating unicodedata and codecs from unicode.org
and other mapping files (by Fredrik Lundh, Marc-Andre Lemburg
and Martin von Loewis).
unittestgui A Tkinter based GUI test runner for unittest, with test
discovery.
wasm Config and helpers to facilitate cross compilation of CPython
to WebAssembly (WASM).
Note: The pynche color editor has moved to https://gitlab.com/warsaw/pynche