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

141–150 of 164 posts

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

#141

Post by IshKebab »

bboreham wrote: post #91

Matt Godbolt was saying recently that using tail-calls for an interpreter suits the branch predictor inside the cpu. Compared to a single big switch / computed jump.

I would have thought it actually helps the branch target predictor rather than the branch predictor. If you assume a simple predictor where the predicted target is just the last taken one then it's going to be wrong almost every time for a single switch. It will only be right for repeats of the exact same instruction.

If you have a separate switch at the end of each instruction then it will be right any time an instruction is followed by the same instruction as last time, which can probably happen quite a lot for short loops.

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

#142

Post by mikkupikku »

int_19h wrote: post #103
WD-42 wrote: post #53

Earlier quoted context omitted.

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.

Games aren't written in Python as a whole, but Python is used as a scripting language. It's definitely less popular now than it used to be, mostly thanks to Lua, but it still happens.

How many games use python for scripting and stay up to date with the version of python they're embedding? My guess is zero.

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

#143

Post by DrewADesign »

pjmlp wrote: post #137
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?)…

Well, using MAUI instead of Avalonia or Uno was the mistake.

Yeah I’d have made a more deliberate choice if it took up more of my dev time. I haven’t looked at Uno really though.

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

#144

Post by stinos »

halfcat wrote: post #82
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/p…

ImGui has been on my watchlist for years and recently I finally had an application which seemed I could put it to use. It essentially delivered on all points I hoped it would. After decades in software, it doesn't happen often anymore I'm impressed but now I was.

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

#145

Post by pwarner »

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?

I remember a former colleague, (may he RIP) ported a similar optimization to our fork of Python 2.5, circa 2007. We were running Linux on PPC and it gave us that similar 10-15% boost at the time.

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

#146

Post by throw-12-16 »

pjmlp wrote: post #75
nilamo wrote: post #52

Earlier quoted context omitted.

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

Sure, keep believing that while loading Proton.

Gladly.

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

#147

Post by igouy »

pjmlp wrote: post #129
everforward wrote: post #87

Earlier quoted context omitted.

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

See Smalltalk, Self and Common Lisp, and you will find languages that are even more dynamic than Python, and are in the genesis of high performance JIT research.

fwiw

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#148

Post by eesmith »

Tarq0n wrote: post #96
eesmith wrote: post #38

Earlier quoted context omitted.

Are you referring to the violin plot? https://en.wikipedia.org/wiki/Violin_plot and in Matplotlib as https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.... It's in essence a histogram for the distribution, with smoothing, and mirrored on each side. It looks nice, but is not without well-deserved opposition because 1) the use of smoothing can hide the actual distribution, 2) mirroring contains no extra inform…

Histograms aren't necessarily a true depiction of the distribution. Bin count or width has a large impact on what details get shown.

Sure. Very few distributions have lovely square edges, which otherwise indicate some very high frequencies in the distribution, or quantized values.

But that also means we are used to seeing histograms and their bin count and widths in order to estimate possible variances from the true distribution;.

While it's much harder to do the same with violin plots.

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

#150

Post by eru »

g947o wrote: post #3

> This has caused many issues for compilers in the past, too many to list in fact. I have a EuroPython 2025 talk about this. Looks like it refers to this: https://youtu.be/pUj32SF94Zw (wish it's a link in the article)

> (wish it's a link in the article)

I've asked Ken. He said he'll update the article.

Post reply on HN