Where does the speedup come from? And my own experiences

Posted Feb 28, 2025 4:09 UTC (Fri) by NYKevin (subscriber, #129325)
In reply to: Where does the speedup come from? And my own experiences by anton
Parent article: Python interpreter adds tail calls

> because all these small tail-calling functions can tail-call any other of these functions, and can be called from any other of these functions, so realisitically no code can be moved between these functions, and I doubt that any useful data-flow information survives these calls

That sounds a bit pessimistic to me. All of this C code is ultimately generated by what looks to be very convoluted Python code. Logically, there are really only two reasons to write that sort of thing:

* The C code is even more convoluted, to the point that it is easier to maintain the Python code than the C code.
* The C code is not particularly convoluted, but it is very long, boring, and repetitive, so that the Python code can be justified as reducing code duplication and boilerplate.

If we suppose the latter, i.e. that the C code is highly repetitive but otherwise straightforward, then you're not just tail calling between arbitrary C functions. You're tail calling between *highly similar* C functions. That opens up optimization opportunities that might not arise in the general case of "lots of C functions tail calling each other."

Regardless, I find it hard to believe that a huge function with lots of computed indirect jumps can possibly be any *faster* than a bunch of tiny functions tail-calling each other (the compiler knows what a function is, the compiler does not know what your computed jumps are), so at the very least, it can't be significantly worse than the goto implementation.