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

81–90 of 164 posts

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

#81

Post by pjmlp »

throw1ahs wrote: post #78
pjmlp wrote: post #45

Earlier quoted context omitted.

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.

The project was first suggested by Mark Shannon. Van Rossum inserted himself into the project. Faster CPython people have been fired by Microsoft last year. Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat. I think the project started in 3.10, so 3.9 is the last version to compare to. The improvements aren't that great, I don't think any other la…

I know what happened last year, my point was the prior history that lead to that effort.

https://thenewstack.io/guido-van-rossums-ambitious-plans-for...

Agree with the sentiment, Python is the only dynamic language where it seems a graveyard from efforts.

And nope it isn't the dynamism per se, Smalltalk, Self, Common Lisp are just as dynamic, with lots of possibilities to reboot the world and mess up JIT efforts, as any change impacts the whole image.

Naturally those don't have internals exposed to C where anything goes, and the culture C libraries are seen as the language libraries.

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

#82

Post by halfcat »

DrewADesign wrote: post #68

After years of admonition discouraging me, I’m using Python for a Windows GUI app over my usual C#/MAUI. I’m much more familiar with Python and the whole VS ecosystem is just so heavy for lightweight tasks. I started with tkinter but found it super clunky for interactions I needed heavily, like on field change, but learning QT seemed like more of a lift than I was interested in. (Maybe a skill issue on both fronts?)…

Wait until you see ImGui bindings for Python [1]. It’s immediate mode instead of retained mode like Tkinter/Qt/Wx. It might not be what you’d want if you’re shipping a thick client to customers, but for internal tooling it’s awesome.

    imgui.text(f"Counter = {counter}")
    if imgui.button("increment counter"):
        counter += 1

    _, name = imgui.input_text("Your name?", name)
    imgui.text(f"Hello {name}!")
[1] https://github.com/pthom/imgui_bundle

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

#83

Post by IshKebab »

gozzoo wrote: 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.

Even though Javascript is quite dynamic, Python is much worse. Basically everything involves a runtime look-up. It's pretty much the language you'd design if you were trying to make it as slow as possible.

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

#84

Post by boulos »

pjmlp wrote: post #81
throw1ahs wrote: post #78

Earlier quoted context omitted.

The project was first suggested by Mark Shannon. Van Rossum inserted himself into the project. Faster CPython people have been fired by Microsoft last year. Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat. I think the project started in 3.10, so 3.9 is the last version to compare to. The improvements aren't that great, I don't think any other la…

I know what happened last year, my point was the prior history that lead to that effort. https://thenewstack.io/guido-van-rossums-ambitious-plans-for... Agree with the sentiment, Python is the only dynamic language where it seems a graveyard from efforts. And nope it isn't the dynamism per se, Smalltalk, Self, Common Lisp are just as dynamic, with lots of possibilities to reboot the world and mess up JIT efforts, as…

Ehh, PHP fits that bill and is clearly optimizable. All sorts of things worked well for PHP, including the original HipHop, HHVM, my own work, and the mainline PHP runtime.

Python has some semantics and behaviors that are particularly hostile to optimization, but as the Faster Python and related efforts have suggested, the main challenge is full compatibility including extensions plus the historical desire for a simple implementation within CPython.

There are limits to retrofitting truly high performance to any of these languages. You want enough static, optional, or gradual typing to make it fast enough in the common case. That's why you also saw the V8 folks give up and make Dart, the Facebook ones made Hack, etc. It's telling that none of those gained truly broad adoption though. Performance isn't all that matters, especially once you have an established codebase and ecosystem.

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

#85

Post by gsnedders »

boulos wrote: post #84
pjmlp wrote: post #81

Earlier quoted context omitted.

I know what happened last year, my point was the prior history that lead to that effort. https://thenewstack.io/guido-van-rossums-ambitious-plans-for... Agree with the sentiment, Python is the only dynamic language where it seems a graveyard from efforts. And nope it isn't the dynamism per se, Smalltalk, Self, Common Lisp are just as dynamic, with lots of possibilities to reboot the world and mess up JIT efforts, as…

Ehh, PHP fits that bill and is clearly optimizable. All sorts of things worked well for PHP, including the original HipHop, HHVM, my own work, and the mainline PHP runtime. Python has some semantics and behaviors that are particularly hostile to optimization, but as the Faster Python and related efforts have suggested, the main challenge is full compatibility including extensions plus the historical desire for a simp…

> Performance isn't all that matters, especially once you have an established codebase and ecosystem.

And this is no small part of why Java and JS have frequently been pushing VM performance forward — there’s enough code people very much care about continuing to work on performance. (Though the two care about different things mostly: Java cares much more about long-term performance, and JS cares much more about short-term performance.)

It doesn’t hurt they’re both languages which are relatively static compared with e.g. Python, either.

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

#86

Post by NetMageSCW »

DrewADesign wrote: post #68

After years of admonition discouraging me, I’m using Python for a Windows GUI app over my usual C#/MAUI. I’m much more familiar with Python and the whole VS ecosystem is just so heavy for lightweight tasks. I started with tkinter but found it super clunky for interactions I needed heavily, like on field change, but learning QT seemed like more of a lift than I was interested in. (Maybe a skill issue on both fronts?)…

Depending on how important the GUI is to you, I would look into LINQPad for stuff that is scripting but too heavy.

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

#87

Post by everforward »

pansa2 wrote: post #67
everforward wrote: post #57

Earlier quoted context omitted.

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…

> I would also say there’s generally less impetus to optimize CPython Nonetheless, Microsoft employed a whole "Faster CPython" team for 4 years - they targeted a 5x speedup but could only achieve ~1.5x. Why couldn't they make a significantly faster Python implementation, especially given that PyPy exists and proves it's possible?

Pypy has much slower C interop than CPython, which I believe is part of the tradeoff. Eg data analysis pipelines are probably still faster in numpy on CPython than pypy.

Not an expert here, but my understanding is that Python is dynamic to the point that optimizing is hard. Like allowing one namespace to modify another; last I used it, the Stackdriver logging adapter for Python would overwrite the stdlib logging library. You import stackdriver, and it changes logging to send logs to stackdriver.

All package level names (functions and variables) are effectively global, mutable variables.

I suspect a dramatically faster Python would involve disabling some of the more unhinged mutability. Eg package functions and variables cannot be mutated, only wrapped into a new variable.

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

#88

Post by __turbobrew__ »

pjmlp wrote: post #45
publicdebates wrote: post #15

Earlier quoted context omitted.

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.

How to stay employed for life: create a programming language which is pretty good, but with some fatal flaws (GIL, typing, slow) and you are set for life.

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

#89

Post by pansa2 »

canucker2016 wrote: post #77
bheadmaster wrote: post #51

Earlier quoted context omitted.

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

Don't forget that there was a Google attempt at making a faster Python - Unladen Swallow. It got lots of PR but never merged with mainline CPython (wikipedia says a dev branch was released). see https://en.wikipedia.org/wiki/Unladen_Swallow

Unladen Swallow got a lot of hype but was only a very small project. IIRC the only people working on it were two interns.

V8 was a much higher priority - Google hired many of the world’s best VM engineers to develop it.

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

#90

Post by mhh__ »

kccqzy wrote: post #13
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?

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.

Python is full of decisions like this / or rather full of "if you just did some more work it'd be 10x better"
Post reply on HN