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

41–50 of 164 posts

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

#41

Post by Calavar »

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?

Quite to the contrary, I'd say this update is evidence of the inner loop being hyperoptimized!

MSVC's support for musttail is hot off the press:

> The [[msvc::musttail]] attribute, introduced in MSVC Build Tools version 14.50, is an experimental x64-only Microsoft-specific attribute that enforces tail-call optimization. [1]

MSVC Build Tools version 14.50 was released last month, and it only took a few weeks for the CPython crew to turn that around into a performance improvement.

[1] https://learn.microsoft.com/en-us/cpp/cpp/attributes?view=ms...

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

#42

Post by loeg »

pjc50 wrote: post #34
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?

This is (a) wildly over expectations for open source and (b) a massive pain to maintain, and (c) not even the biggest timewaster of python, which is the packaging "system".

> not even the biggest timewaster of python, which is the packaging "system".

For frequent, short-running scripts: start-up time! Every import has to scan a billion different directories for where the module might live, even for standard modules included with the interpreter.

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

#43

Post by loeg »

WD-42 wrote: post #35
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?

Probably because anyone concerned with performance wasn’t running workloads on Windows to begin with.

They weren't using Python, anyway.

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

#45

Post by pjmlp »

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.

Microsoft was the one hiring Guido out of retirement, and alongside Facebook finally kicking off the CPython JIT efforts.

Python is one of the Microsoft blessed languages on their devblogs.

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

#46

Post by pjmlp »

WD-42 wrote: post #35
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?

Probably because anyone concerned with performance wasn’t running workloads on Windows to begin with.

Games and Proton.

Apparently people that care about performance do run Windows.

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

#47

Post by kenjin4096 »

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…

So it seems I was wrong, [[msvc::musttail]] is documented! I will update the blog post to reflect that.

https://news.ycombinator.com/item?id=46385526

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

#48

Post by forrestthewoods »

Is there a Clang based build for Windows? I’ve been slowly moving my Windows builds from MSVC to Clang. Which still uses the Microsoft STL implementation.

So far I think using clang instead of MSVC compiler is a strict win? Not a huge difference mind you. But a win nonetheless.

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

#49

Post by jtrn »

kenjin4096 wrote: post #37
jtrn wrote: post #27

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 ha…

Thanks :), that was indeed my intention. I think the previous 3.14 mistake was actually a good one on hindsight, because if I didn't publicize our work early, I wouldn't have caught the attention of Nelson. Nelson also probably wouldn't have spent one month digging into the Clang 19 bug. This also meant the bug wouldn't have been caught in the betas, and might've been out with the actual release, which would have bee…

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.

Post reply on HN