Description

markshannon

opened on Dec 19, 2025

Issue body actions

JIT coverage is still quite variable. For some benchmarks, e.g. richards it is close to 100%.
For others, much lower:

https://github.com/savannahostrowski/pyperf_bench/blob/main/profiling/jit.svg

Note: A fair bit of the time attributed to the interpreter is frame cleanup, so makes the interpreter fractions look larger than they are.

We can increase JIT coverage, by:

• Treating dynamic exits, like side exits: warming up and compiling a new side trace.
• Adding possible jit entry points at function entries, as well as backward edges.

Linked PRs

• gh-142982: Specialize CALL_FUNCTION_EX #143391
• gh-142982 Implement _SEND_NON_GEN specialization #143977

Activity

1. StanFromIreland

   added

   type-featureA feature request or enhancementA feature request or enhancement

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   topic-JIT

   on Dec 19, 2025
2. Fidget-Spinner commented on Dec 23, 2025

   

   Fidget-Spinner

   on Dec 23, 2025

   Member

   More actions

   For context, we increased JIT coverage by 50% just with trace recording alone. This was the old chart prior to trace recording https://github.com/faster-cpython/benchmarking-public/blob/main/profiling/jit.svg
3. markshannon

   self-assigned this

   on Dec 23, 2025
4. Fidget-Spinner commented on Dec 25, 2025

   

   Fidget-Spinner

   on Dec 25, 2025

   Member

   More actions

   @markshannon which one have you decided to work on? I can take up this issue if you aren't too far in yet, as I don't want to touch the JIT assembly parser in #143158 :).
5. Fidget-Spinner

   self-assigned this

   on Dec 29, 2025
6. Fidget-Spinner commented on Dec 31, 2025

   

   Fidget-Spinner

   on Dec 31, 2025

   Member

   More actions

   Seems like tracing from RESUME doesn't help much. Considering the complexity, it might not be worth to implement it for RESUME:

   0.2% faster on Linux s86-64: https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251231-3.15.0a3%2B-564677c-JIT/bm-20251231-vultr-x86_64-Fidget%252dSpinner-resume_tracing-3.15.0a3%2B-564677c-vs-base.md

   0.4% slower on macOS AArch64: https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251231-3.15.0a3%2B-564677c-JIT/bm-20251231-macm4pro-arm64-Fidget%252dSpinner-resume_tracing-3.15.0a3%2B-564677c-vs-base.md
7. Fidget-Spinner commented on Jan 2, 2026

   

   Fidget-Spinner

   on Jan 2, 2026

   Member

   More actions

   In the last pystats, CALL_FUNCTION_EX was the 3rd highest call op that called Python frames after CALL_PY_EXACT_ARGS and CALL_ALLOC_AND_ENTER_INIT https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251019-3.15.0a1%2B-bedaea0-JIT/bm-20251019-vultr-x86_64-python-bedaea05987738c4c6b9-3.15.0a1%2B-bedaea0-pystats.md

   We should specialize for it.
8. Fidget-Spinner commented on Jan 3, 2026

   

   Fidget-Spinner

   on Jan 3, 2026

   Member

   More actions

   Things we need to specialize for:

   • CALL_FUNCTION_EX
   • SEND
   • CALL_ALLOC_AND_ENTER_INIT_SLOT

   SEND has one of the worst specialization failures of any opcode https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251019-3.15.0a1%2B-bedaea0-JIT/bm-20251019-vultr-x86_64-python-bedaea05987738c4c6b9-3.15.0a1%2B-bedaea0-pystats.md#send-1

   This should also speed up the interpreter slightly. It's blocking us optimizing generators/frames in the JIT.
9. Fidget-Spinner

   added a commit that references this issue on Jan 6, 2026

   gh-142982: Specialize CALL_FUNCTION_EX (GH-143391)

   df35534
10. Fidget-Spinner

    marked JIT/Tier 2 tracing: plans for function-entry hotness triggers (hot callbacks from C loops)? #143778 as a duplicate of this issue on Jan 13, 2026
11. thunder-coding

    added a commit that references this issue on Feb 15, 2026

    pythongh-142982: Specialize CALL_FUNCTION_EX (pythonGH-143391)

    72fbae4

Issue actions