Re:Python 3.15's interpreter for Windows should be 15% faster
by jtrn on Thursday December 25, 2025 @12:16PM
(#46385702)
I wish all self-promoting scientists and sensationalizing journalists had a fraction of the honesty and dedication to actual truth and proper communication of truths as you do. You seem to feel that it’s more important to be transparent about these kinds of technical details than other people are about their claims in clinical medical research. Thank you so much for all you do and the way you communicate about it.
Also, I’m not that familiar with the whole process, but I just wanted to say that I think you were too hard on yourself during the last performance drama. So thank you again and remember not to hold yourself to an impossible standard no one else does.
Re:Python 3.15's interpreter for Windows should be 15% faster
by halflings on Thursday December 25, 2025 @01:39PM
(#46386205)
+1, reading through the post, the PR updating the documentation... thanks for being transparent, but also don't be so hard on yourself!
That was a very niche error, that you promptly corrected, no need to be so apologetic about it! And thanks for all the hard work making Python faster!
Re:Python 3.15's interpreter for Windows should be 15% faster
by kenjin4096 on Thursday December 25, 2025 @12:31PM
(#46385796)
Thank you very much for the kind words, that means a lot to me!
Also this time, I'm pretty confident because there are two perf improvements here: the dispatch logic, and the inlining. MSVC can actually convert switch-case interpreters to threaded code automatically if some conditions are met [1]. However, it does not seem to do that for the current CPython interpreter. In this case, I suspect the CPython interpreter loop is just too complicated to meet those conditions. The key point also that we would be relying on MSVC again to do its magic, but this tail calling approach gives more control to the writers of the C code. The inlining is pretty much impossible to convince MSVC to do except with `__forceinline` or changing things to use macros [2]. However, we don't just mark every function as forceinline in CPython as it might negatively affect other compilers.
[1]: https://github.com/faster-cpython/ideas/issues/183 [2]: https://github.com/python/cpython/issues/121263