Comment by miguelgrinberg

Comment by miguelgrinberg 5 days ago

4 replies

The build of Python that I used has tail calls enabled (option --with-tail-call-interp). So that was in place for the results I published. I'm not sure if this optimization applies to recursive tail calls, but if it does, my Fibonacci test should have taken advantage of the optimization.

ufo 5 days ago

The tail calls in question are C tail calls inside the inner interpreter loop. They have nothing to do with Python function calls.

  • miguelgrinberg 5 days ago

    That tells you how much I know about the feature. :) But in any case, I'm positive that the flag was enabled, so my results are with tail calls. I suppose part of the difference between 3.13 and 3.14 could be thanks to this.

    • haberman 4 days ago

      Good to know! Thanks for confirming. Yes, I would guess that the tail call interpreter explains part of the difference between 3.13 and 3.14. Previously the overall improvement to the interpreter has been measured at 1-5%, or even 10-15% depending on the compiler version you are using: https://blog.nelhage.com/post/cpython-tail-call/

      If your benchmark setup is easy to re-run, it would be awesome to see numbers that compare the tail call interpreter to the build where it is disabled, to isolate how much improvement is due to that.

emil-lp 5 days ago

It wouldn’t have, since

    fib(n-1) + fib(n-2)
isn’t a tail call—there’s work left after the recursive calls, so the tail call interpreter can’t optimize it.