The SAI, tracer and optimizer all contain a number of heuristics about when to optimize, how to link the optimized code and when to backoff, etc.
Almost all of these heuristics are just numbers.
We should group them together into a single "policy" object, improving consistency and enabling experimentation.
As we can see the SAI and tracer and optimizers all contains a lot of numbers which make it difficult to do any changes. And i appreciate the idea to make common policy for them such that we can pinpoint the exact area where the error is produced rather than searching here and there.
So i came up with an idea of creating a header file policy.h which will be telling what structure and functions are defined or used in the main code and along with the logic of the function will be present inside the policy.c where we will be having the function logic for when to start optimizing the function and also when to stops the function. Then we will be replacing the loop inside value with the function which return Boolean value as the and according to that the loop will stops or checking is done.
But the issue is that after that we will have to replace many function to increase the speed and make it easier to handle any changes or disturbances which is going to take long time but in other hand it is like a updated version of 3.15 which is a little bit better than it.
So i suggest that we can work on it by breaking into small segments so that will also be better and easier for us to approach this idea.
If you like this idea let me know. I will generate a pr for it.
Thanks for the feedback, @Fidget-Spinner. I'll read through the original proposal again and see if I can come up with an approach that better fits the 'single policy object' goal.
We want to be able to allow users to choose between policies at runtime, and to simplify creation of new policies and do other experiments with thresholds.
However, there are a number of invariants that must hold: certain thresholds should be higher than others, we shouldn't allow the JIT without specialization, etc.
Rather than expect users to know all these hazards, we should provide a fixed set of "policies" to choose from:
Default
JIT stress: very low thresholds for testing, specifically fuzzing
JIT on/off
Specialization off (useful when changing the bytecode compiler)
...
To do this we should group all the various thresholds and optimization flags, for both JIT and interpreter, into a single opt_config struct, one per interpreter.
@corona10 would you like to take on moving PYTHON_UOPS_OPTIMIZE as well? We should move it from optimizer.c to the policy object + env var like you did in your other PRs.
Activity
Fidget-Spinner commented on Nov 13, 2025
This sounds rather promising. It would also enable per-system configurations, like pypy which would be great.
Krishna-web-hub commented on Dec 8, 2025
Hi @markshannon , @Fidget-Spinner,
As we can see the SAI and tracer and optimizers all contains a lot of numbers which make it difficult to do any changes. And i appreciate the idea to make common policy for them such that we can pinpoint the exact area where the error is produced rather than searching here and there.
So i came up with an idea of creating a header file policy.h which will be telling what structure and functions are defined or used in the main code and along with the logic of the function will be present inside the policy.c where we will be having the function logic for when to start optimizing the function and also when to stops the function. Then we will be replacing the loop inside value with the function which return Boolean value as the and according to that the loop will stops or checking is done.
But the issue is that after that we will have to replace many function to increase the speed and make it easier to handle any changes or disturbances which is going to take long time but in other hand it is like a updated version of 3.15 which is a little bit better than it.
So i suggest that we can work on it by breaking into small segments so that will also be better and easier for us to approach this idea.
If you like this idea let me know. I will generate a pr for it.
Fidget-Spinner commented on Dec 8, 2025
@Krishna-web-hub Sorry I don't think you're on the right track. Please don't take this issue.
Krishna-web-hub commented on Dec 8, 2025
Thanks for the feedback, @Fidget-Spinner. I'll read through the original proposal again and see if I can come up with an approach that better fits the 'single policy object' goal.
Fidget-Spinner commented on Dec 8, 2025
@Krishna-web-hub I don't think this is a good issue for beginners. So you might want to try another issue
Fidget-Spinner commented on Jan 2, 2026
@corona10 and I are working on it.
pythongh-141504: Configurable JIT optimization thresholds
gh-141504: Factor out tracing and optimization heuristics into a sing…
markshannon commented on Jan 5, 2026
Apparently I wasn't clear as to what I wanted.
We want to be able to allow users to choose between policies at runtime, and to simplify creation of new policies and do other experiments with thresholds.
However, there are a number of invariants that must hold: certain thresholds should be higher than others, we shouldn't allow the JIT without specialization, etc.
Rather than expect users to know all these hazards, we should provide a fixed set of "policies" to choose from:
To do this we should group all the various thresholds and optimization flags, for both JIT and interpreter, into a single opt_config struct, one per interpreter.
pythongh-141504: Refactor policy object into a single opt_config
Merge remote-tracking branch 'upstream/main' into pythongh-141504-opt
Merge remote-tracking branch 'upstream/main' into pythongh-141504-opt
gh-141504: Refactor policy object into a single opt_config (gh-143644)
Fidget-Spinner commented on Jan 17, 2026
@corona10 would you like to take on moving PYTHON_UOPS_OPTIMIZE as well? We should move it from optimizer.c to the policy object + env var like you did in your other PRs.
corona10 commented on Jan 17, 2026
Sure!
pythongh-141504: Move PYTHON_UOPS_OPTIMIZE to policy object
gh-141504: Move PYTHON_UOPS_OPTIMIZE to policy object (GH-144082)
pythongh-141504: Factor out tracing and optimization heuristics into …
pythongh-141504: Refactor policy object into a single opt_config (pyt…
pythongh-141504: Move PYTHON_UOPS_OPTIMIZE to policy object (pythonGH…
Fidget-Spinner commented on Apr 15, 2026
This looks done. can we close it?