GH-135379: Top of stack caching for the JIT. #135465
Conversation
markshannon
force-pushed
the
tier-2-tos-caching
branch
from
78489ea to
2850d72
Compare
|
Performance is in the noise, but we would need a really big speed up of jitted code for it to be more than noise overall. The nbody benchmark, which spends a lot of time in the JIT shows a 13-18% speedup, except on Mac where it shows no speedup. |
Nice. We use Apple's Compiler for the interpreter, though the JIT uses stock LLVm. Thomas previously showed that the version of the Apple compiler we use is subject to huge fluctuations in performance due to a PGO bug. |
markshannon
requested review from
brandtbucher and
savannahostrowski
as code owners
| Implement a limited form of register allocation know as "top of stack | ||
| caching" in the JIT. It works by keeping 0-3 of the top items in the stack | ||
| in registers. The code generator generates multiple versions of thos uops | ||
| that do not escape and are relatively small. During JIT compilation, the | ||
| copy that produces the least memory traffic is selected, spilling or | ||
| reloading values when needed. |
There was a problem hiding this comment.
| Implement a limited form of register allocation know as "top of stack | |
| caching" in the JIT. It works by keeping 0-3 of the top items in the stack | |
| in registers. The code generator generates multiple versions of thos uops | |
| that do not escape and are relatively small. During JIT compilation, the | |
| copy that produces the least memory traffic is selected, spilling or | |
| reloading values when needed. | |
| Implement a limited form of register allocation known as "top of stack | |
| caching" in the JIT. It works by keeping 0-3 of the top items in the stack | |
| in registers. The code generator generates multiple versions of those uops | |
| that do not escape and are relatively small. During JIT compilation, the | |
| copy that produces the least memory traffic is selected, spilling or | |
| reloading values when needed. |
| @@ -0,0 +1,3 @@ | |||
| Implement top-of-stack caching for the JIT (and tier 2 interpreter). Reduces | |||
There was a problem hiding this comment.
Why is there a second news file?
| static int | ||
| get_exit_depth(_PyUOpInstruction *inst) |
There was a problem hiding this comment.
Can you write a short snippet on what this does? It's rather confusing otherwise. IIUC, it finds what is the number of "used" registers on exit right?
| if (_PyUop_Caching[base_opcode].exit_depth_is_output) { | ||
| return input + _PyUop_Caching[base_opcode].delta; |
| static int | ||
| stack_allocate(_PyUOpInstruction *buffer, int length) | ||
| { | ||
| for (int i = length-1; i >= 0; i--) { |
There was a problem hiding this comment.
To my understanding, this is due to the possibility of needing to insert a spill between every instruction right, so you need to reserve 2N number of instructions?
| if ideal_inputs > 3: | ||
| ideal_inputs = 3 | ||
| if ideal_outputs > 3: | ||
| ideal_outputs = 3 |
There was a problem hiding this comment.
Can you move the value 3 to a global magic number so that we can play around with increasing/decreasing register counts in the future?
| #if has_exit and ideal_inputs != ideal_outputs: | ||
| # n = min(ideal_inputs, ideal_outputs) | ||
| # yield n, n | ||
| # return |
The stats need fixing and the generated tables could be more compact, but it works.