Can you show what a typical tail-calling sequence looks like? Does it combine tail-calling with a computed goto as in this example from the protobuf blog post?

    MUSTTAIL return op_table[op](ARGS);

Mark gives a pretty good example here faster-cpython/ideas#642 (comment)

Neat, thank you!

How much performance is attributed to __attribute__((preserve_none)) alone?

@diegorusso I did some experiments on WASI and esmcriptem (which do not support preserve_none). No speedup at all on those platforms which do not support (in fact, up to a 2x slowdown). So this is a negative without it.

FYI from Clang docs

preserve_none’s ABI is still unstable, and may be changed in the future.

@WolframAlph I think that doesn't matter because we're only using this on _PyEval_EvalFrameDefault's opcode handlers which are not external-facing. This is an internal implementation detail.

Anyway I pinged the GCC team at Arm and a ticket has been created to implement preserve_none in GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328

@diegorusso I did some experiments on WASI and esmcriptem (which do not support preserve_none). No speedup at all on those platforms which do not support (in fact, up to a 2x slowdown). So this is a negative without it.

This is what I was expecting. The tail call but itself is not enough (actually I was expecting similar performance to computed goto) and you need preserve_none (like for the JIT) to make the difference.

Have you tested it on AArch64 as well?

Have you tested it on AArch64 as well?

Not yet. I want to test it on the Faster CPython build bot for macOS (that has clang-19, so it's a fair comparison), but I do not have access to it. If you could run some benchmarks for this I would be really grateful! If you want a quick-and-dirty check that it's working, try just running the pystones benchmark. I got a 25% speedup with tail calls and LTO and PGO on (make sure you enable those, because it contributes like half the perf win for some reason). https://gist.github.com/Fidget-Spinner/e7bf204bf605680b0fc1540fe3777acf

And pass CC=clang-19 and all that.

@Fidget-Spinner If I understand correctly, the whole trick is:

1. musttail guarantees to jump to the next subroutine (if their signatures are the same), thus getting rid of call overhead (prologue, epilogue, stack space reservation, etc..).
2. preserve_none puts burden of preserving registers on the caller. But every subsequent tail call is performed to the function with preserve_none attribute, therefore none of the opcode handlers spill registers (because we instructed so and because it won't need them anymore because of tail call) and just forward function arguments in registers through whole chain of calls.

Do I get it right?

@WolframAlph

Do I get it right?

Yeah. Also I suspect most of the speedup is there because the current interpreter loop is too big to optimize properly, so all the pre-existing compilers perform not-so-well for it.

For example, PGO gives this roughly another 10% speedup over just -O3. LTO roughly another 10% over PGO and -O3. Normally if we compare equally, PGO and LTO should optimize both the old interpreter and new one similarly, but I guess the new interpreter is easier to optimize so it produces better quality code.

Also I suspect most of the speedup is there because the current interpreter loop is too big to optimize properly, so all the pre-existing compilers perform not-so-well for it.

Makes sense. By splitting cases into functions, compiler can optimize each one of them better individually rather than one giant chunk I assume. Same was mentioned in the protobuf article you linked.

Here is the result for cross-checking bm_pystones with @Fidget-Spinner on macOS aarch64
The only difference between tail-calling and baseline is the dispatch technique.
I pinned the compiler version and compiler optimization policies.

Baseline: 2228e92

Configure

CC=clang-19 ./configure --enable-optimizations --with-lto=thin

Result

➜  cpython git:(2228e92da31) ✗ ./python.exe bm_pystones.py
Pystone(1.1) time for 50000 passes = 0.0763571
This machine benchmarks at 654818 pystones/second

Tail-calling https://github.com/Fidget-Spinner/cpython/tree/tail-call

Configure

CC=clang-19 ./configure --enable-optimizations --with-lto=thin --enable-tail-call-interp

Result

➜  cpython git:(tail-call) ✗ ./python.exe bm_pystones.py
Pystone(1.1) time for 50000 passes = 0.0548847
This machine benchmarks at 911001 pystones/second

cc @diegorusso

According to Donghee's comment above, Pystones is nearly 50% faster on macOS AArch64 vs 25% faster on my Ubuntu AMD64 machine. I suspect it might be because AArch64 has more registers. However, who knows at this point :)?

Reading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328, I have not tested on GCC trunk. This is pure speculation on my part that perf is bad on there. I can try with GCC eventually after the PR lands and we can test it from there. However, testing with clang with just musttail and no preserve_none, the performance was quite bad.