Bug report
Bug description:
When building with the normal interpreter (computed goto), the impact of frame pointers should only be around 2% geomean max.
However, it seems the impact on the tail calling interpreter is higher. This is likely because each bytecode handler on the tail calling interpreter is now a function, which means they each have a frame pointer prologue and epilogue.
There is a fix on Clang 21 and higher (though I don't know if GCC 16 has it): omit the frame pointer, but reserve it so it doesn't get clobbered only for the bytecode handlers, leave the rest building with frame pointers. The flags are "-fomit-frame-pointer -momit-leaf-frame-pointer -mreserve-frame-pointer-reg". The key observation is that since we tail call, we only need the first entry into a tail calling handler to have the frame pointer prologue (ie LABEL(start_frame) needs the prologue), but all other tail calling function pointers do not. This practically eliminates the entire prologue/epilogue overhead for the interpreter, while keeping register allocation good and not clobbering frame pointers. Unfortunately, clang does seem not have custom per-function attributes for this option, so we have to move the non-starter bytecode handlers to their own compilation unit (ie, move them to their own C file).
This seems to affect anything with per-function overhead as well, such as CET/BTI changes. We can fix those incrementally, as the approacha re the same.
Here are some geometric mean results on Sam's fastmark (pyperformance subset) from my laptop (i7-12700H x86-64) with clang 22:
- Baseline (FP on, tail calling interpreter): 0% slowdown
- FP off, tail calling interpreter: 2.7% speedup
- FP on, tail calling interpreter, reserve register patch (meowl + garbage + oiia): 2.5% speedup
TLDR: WIth this patch, the tail calling interpreter's overhead for frame pointer enabling drops from 2.7% to just 0.2%!!!! Frame pointers are practically free on the tail calling interpreter!!! Meanwhile, computed goto interpreter has a 1.5% hit (the i7-12700h machine is mine from PEP 831)
@pablogsal @markshannon @stratakis
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Bug report
Bug description:
When building with the normal interpreter (computed goto), the impact of frame pointers should only be around 2% geomean max.
However, it seems the impact on the tail calling interpreter is higher. This is likely because each bytecode handler on the tail calling interpreter is now a function, which means they each have a frame pointer prologue and epilogue.
There is a fix on Clang 21 and higher (though I don't know if GCC 16 has it): omit the frame pointer, but reserve it so it doesn't get clobbered only for the bytecode handlers, leave the rest building with frame pointers. The flags are
"-fomit-frame-pointer -momit-leaf-frame-pointer -mreserve-frame-pointer-reg". The key observation is that since we tail call, we only need the first entry into a tail calling handler to have the frame pointer prologue (ieLABEL(start_frame)needs the prologue), but all other tail calling function pointers do not. This practically eliminates the entire prologue/epilogue overhead for the interpreter, while keeping register allocation good and not clobbering frame pointers. Unfortunately, clang does seem not have custom per-function attributes for this option, so we have to move the non-starter bytecode handlers to their own compilation unit (ie, move them to their own C file).This seems to affect anything with per-function overhead as well, such as CET/BTI changes. We can fix those incrementally, as the approacha re the same.
Here are some geometric mean results on Sam's fastmark (pyperformance subset) from my laptop (i7-12700H x86-64) with clang 22:
TLDR: WIth this patch, the tail calling interpreter's overhead for frame pointer enabling drops from 2.7% to just 0.2%!!!! Frame pointers are practically free on the tail calling interpreter!!! Meanwhile, computed goto interpreter has a 1.5% hit (the i7-12700h machine is mine from PEP 831)
@pablogsal @markshannon @stratakis
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response