Python 3.15's Ultra-Low Overhead Interpreter Profiling Mode – Ken Jin's Blog

4 comments

• NeutralForest an hour ago

  Here are explanation on how to use it from one of the people working on it: https://www.youtube.com/watch?v=f1x4X83CDSA and the chunky docs that go with it in the beta of 3.15: https://docs.python.org/3.15/library/profiling.sampling.html

• evomassiny 2 hours ago

  Could you duplicate `RECORD_INST` before each `INSTRUCTION_N`, so that:

  ```

     INSTRUCTION_1:
       // subroutine 1
       ip++;
       goto *dispatch_var[*ip];
  
     INSTRUCTION_2:
       // subroutine 2
       ip++;
       goto *dispatch_var[*ip];
  

  ```

  becomes: ```

     RECORD_INST_1:
       // record logic
     INSTRUCTION_1:
       // subroutine 1
       ip++;
       goto *dispatch_var[*ip];
  
     RECORD_INST_2:
       // record logic
     INSTRUCTION_2:
       // subroutine 2
       ip++;
       goto *dispatch_var[*ip];

  ```

  This way you could directly swap `dispatch_var` with an array populated with the `RECORD_INST_*` labels, and remove one step at runtime.

  Or maybe this is what you are trying to avoid to reduce the binary size ?

  [-]
  • drob518 4 minutes ago

    Typically, the inner loop of an interpreter is all about keeping the branch predictor happy and trying to fit in L1 cache as much as possible. So, falling through makes sense. I’m also curious whether a simple check of a flag and a conditional branch (which is highly predictable for a mode flag like whether you’re tracing or not) wouldn’t be faster than one of the indirect branches. That would keep the tracing code out of L1 when not in use (you can locate it in a remote function).

  • kzrdude 2 hours ago

    That sounds smart, maybe worth testing, but I think it bloats the instruction cache even when not tracing.