python
Factor out tracing and optimization heuristics into a single "policy" object.
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.
Linked PRs
- gh-143381
This sounds rather promising. It would also enable per-system configurations, like pypy which would be great.
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.
@Krishna-web-hub Sorry I don't think you're on the right track. Please don't take this issue.
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.
@Krishna-web-hub I don't think this is a good issue for beginners. So you might want to try another issue
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:
- 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.