Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

fidget-spinner.github.io

Post reply on HN
Print view View original

21–30 of 164 posts

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#21

Post by furyofantares »

monster_truck wrote: post #19
mananaysiempre wrote: post #10

The money shot (wish this were included in the blog post): # if defined(_MSC_VER) && !defined(__clang__) # define Py_MUSTTAIL [[msvc::musttail]] # define Py_PRESERVE_NONE_CC __preserve_none # else # define Py_MUSTTAIL __attribute__((musttail)) # define Py_PRESERVE_NONE_CC __attribute__((preserve_none)) # endif https://github.com/python/cpython/pull/143068/files#diff-45b... Apparently(?) this also needs to be attached…

[flagged]

That's not where the term comes from https://en.wikipedia.org/wiki/Money_shot

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#22

Post by andix »

publicdebates wrote: post #15
mananaysiempre wrote: post #10

The money shot (wish this were included in the blog post): # if defined(_MSC_VER) && !defined(__clang__) # define Py_MUSTTAIL [[msvc::musttail]] # define Py_PRESERVE_NONE_CC __preserve_none # else # define Py_MUSTTAIL __attribute__((musttail)) # define Py_PRESERVE_NONE_CC __attribute__((preserve_none)) # endif https://github.com/python/cpython/pull/143068/files#diff-45b... Apparently(?) this also needs to be attached…

Important enough, or benefits them directly? I have no good guesses how improving Python's performance would benefit them, but I would guess that's the real reason.

I guess there are some Python workloads on Azure, Microsoft provides a lot of data analysis and LLM tools as a service (not paid by CPU minutes). Saving CPU cycles there directly translates to financial savings.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#23

Post by abacuss »

monster_truck wrote: post #19
mananaysiempre wrote: post #10

The money shot (wish this were included in the blog post): # if defined(_MSC_VER) && !defined(__clang__) # define Py_MUSTTAIL [[msvc::musttail]] # define Py_PRESERVE_NONE_CC __preserve_none # else # define Py_MUSTTAIL __attribute__((musttail)) # define Py_PRESERVE_NONE_CC __attribute__((preserve_none)) # endif https://github.com/python/cpython/pull/143068/files#diff-45b... Apparently(?) this also needs to be attached…

[flagged]

I don't understand why your mind went immediately to pornography. Kind of creepy tbh.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#24

Post by LtWorf »

redox99 wrote: post #7

This seems like very low hanging fruit. How is the core loop not already hyper optimized? I'd have expected it to be hand rolled assembly for the major ISAs, with a C backup for less common ones. How much energy has been wasted worldwide because of a relatively unoptimized interpreter?

If you want fast just use pypy and forget about cpython.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#27

Post by jtrn »

Im a bit out of the loop with this, but hope its not like that time with python 3.14, when it was claimed a geometric mean speedup of about 9-15% over the standard interpreter when built with Clang 19. It turned out the results were inflated due to a bug in LLVM 19 that prevented proper "tail duplication" optimization in the baseline interpreter's dispatch loop. Actual gains was aprox 4%.

Edit: Read through it and have come to the conclusion that the post is 100% OK and properly framed: He explicitly says his approach is to "sharing early and making a fool of myself," prioritizing transparency and rapid iteration over ironclad verification upfront.

One could make an argument that he should have cross-compiler checks, independent audits, or delayed announcements until results are bulletproof across all platforms. But given that he is 100% transparent with his thinking and how he works, it's all good in the hood.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#28

Post by ambicapter »

abacuss wrote: post #23
monster_truck wrote: post #19

Earlier quoted context omitted.

[flagged]

I don't understand why your mind went immediately to pornography. Kind of creepy tbh.

You're overreacting, see the wikipedia article posted above.

> By 1977[2][3] the phrase had entered American usage as slang for the cum shot in a pornographic film

https://en.wikipedia.org/wiki/Money_shot

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#29

Post by bluecalm »

metaltyphoon wrote: post #26
bgwalter wrote: post #25

MSVC mostly generates slower code than gcc/clang, so maybe this trick reduces the gap.

Is this backed by real evidence?

My experience is 10%-15% slower than GCC. That was 10 years ago though.

Re: Python 3.15’s interpreter for Windows x86-64 should hopefully be 15% faster

#30

Post by kccqzy »

Hendrikto wrote: post #4

TLDR: The tail-calling interpreter is slightly faster than computed goto. > I used to believe the the tailcalling interpreters get their speedup from better register use. While I still believe that now, I suspect that is not the main reason for speedups in CPython. > My main guess now is that tail calling resets compiler heuristics to sane levels, so that compilers can do their jobs. > Let me show an example, at the…

I think in the protobuf example the musttail did in fact benefit from better register use. All the functions are called with the same arguments, so there is no need to shuffle the registers. The same six register-passed arguments are reused from one function to the next.
Post reply on HN