Live data from Hacker News

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

fidget-spinner.github.io

51–60 of 164 posts

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

#51
post #50

I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.

I can think of two possible reasons:

First is the Google's manpower. Google somehow succeeds in writing fast software. Most Google products I use are fast in contrast to the rest of the ecosystem. It's possible that Google simply did a better job.

The second is CPython legacy. There are faster implementations of Python that completely implement the API (PyPy comes to mind), but there's a huge ecosystem of C extensions written with CPython bindings, which make it virtually impossible to break compatibility. It is possible that this legacy prevents many possible optimizations. On the other hand, V8 only needs to keep compatibility on code-level, which allows them to practically switch out the whole inside in incremental search for a faster version.

I might be wrong, so take what I said with a grain of salt.

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

#52
post #46
post #35

Earlier quoted context omitted.

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.

Games are made for windows because that's where the device drivers have historically been. Any other viewpoint is ignoring reality.

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

#53
post #46
post #35

Earlier quoted context omitted.

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.

None of those games, or a very small amount of them, are written in python. None of the ones that need to be performant for sure.

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

#54
post #49

Earlier quoted context omitted.

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. Al…

Thank you very much for the kind words, that means a lot to me!

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

#55
post #18

Really nice results on MSVC. The idea that tail calls effectively reset compiler heuristics and unblock inlining is pretty convincing. One thing that worries me though is the reliance on undocumented MSVC behavior — if this becomes widely shipped, CPython could end up depending on optimizer guarantees that aren’t actually stable. Curious how you’re thinking about long-term maintainability and the impact on debugging/…

Profile of llm generated comments

ust to clarify, I’m writing these comments myself. I use grammar llm plugin though to clean up phrasing, but the substance is mine.

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

#57
post #50

I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.

I know of a couple reasons offhand.

JavaScript is JIT’ed where CPython is not. Pypy has JIT and is faster, but I think is incompatible with C extensions.

I think Pythons threading model also adds complexity to optimizing where JavaScripts single thread is easier to optimize.

I would also say there’s generally less impetus to optimize CPython. At least until WASM, JavaScript was sort of stuck with the performance the interpreter had. Python had more off-ramps. You could use pypy for more pure Python stuff, or offload computationally heavy stuff to a C extension.

I think there are some language differences that make JavaScript easier to optimize, but I’m not super qualified to speak on that.

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

#58
post #42
post #34

Earlier quoted context omitted.

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.

In the near future we will use lazy imports :) https://peps.python.org/pep-0810/

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

#59
post #50

I have quetion - slightly off topic, but related. I was wandering why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.

[dead]

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

#60
post #13
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?

Python’s goal is never really to be fast. If that were its goal, it would’ve had a JIT long ago instead of toying with optimizing the interpreter. Guido prioritized code simplicity over speed. A lot of speed improvements including the JIT (PEP 744 – JIT Compilation) came about after he stepped down.

If performance was a goal... hell if it was even a consideration then the language would be very different.
Post reply on HN