RE: https://bsky.app/profile/did:plc:wpe35pganb6d4pg4ekmfy6u5/post/3lwf6thefx223
Python 3.14 的 tail-call interpreter 的效能提升來自於繞過 LLVM 的 regression bug
前幾天 Python 圈子蠻熱鬧的一個主題:「Performance of the Python 3.14 tail-call interpreter」。 Python 3.14 實作了 tail-call interpreter (是個 opt-in 參數),結果官方測試發現效能在 benchmark 時有巨大的提升 (9%~15%),但文章作者覺得不合理,交叉測試了許多 case 後發現這是因為 LLVM 的 regression bug 導致 computed gotos 比較慢,…
#bug #call #compiler #computed #gotos #interpreter #llvm #performance #python #python3 #regression #speed #tail #TailCall
前幾天 Python 圈子蠻熱鬧的一個主題:「Performance of the Python 3.14 tail-call interpreter」。 Python 3.14 實作了 tail-call interpreter (是個 opt-in 參數),結果官方測試發現效能在 benchmark 時有巨大的提升 (9%~15%),但文章作者覺得不合理,交叉測試了許多 case 後發現這是因為 LLVM 的 regression bug 導致 computed gotos 比較慢,而 tail-call interpreter 的實作避開了這個...
A deep dive into the performance of Python 3.14's tail-call interpreter: How the performance results were confounded by an LLVM regression, the surprising complexity of compiling interpreter loops, and some reflections on performance work, software engineering, and optimizing compilers.
While we’re on the subject, there is not reason, in the year of our Lord 2023, that any programming language should not have #TailCall #optimization.
Seriously, if there is a function call whose result is immediately passed back to the previous calling site then when you create you new stack frame (or whatever other magical BS your language does to make a function calls) substitute the calling return site for your own. I’m not asking for intensive code analysis to find hidden tail calls, but with return foo(bar) foo should not have to come back to your stack frame before moving down the stack.