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

151–160 of 164 posts

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

#151

Post by eru »

int_19h wrote: post #102
kccqzy wrote: post #13

Earlier quoted context omitted.

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.

I doubt it would have a JIT a long time ago. Thing is, people have been making JIT compilers for Python for a long time now, but the semantics of the language itself is such that it's often hard to benefit from it because most of the time isn't in the bytecode interpreter itself, it's dispatching things. People like comparing Python to JavaScript, but Python is much more flexible - all "primitive" types are objects c…

> People like comparing Python to JavaScript, but Python is much more flexible - all "primitive" types are objects can be subclassed for example, and even basic machinery like attribute lookups have a bunch of customization hooks.

Most of the time, people don't use any of these customisations, don't they?

So you'd need machinery that makes the common path go fast, but can fall back onto the customised path, if necessary?

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

#152

Post by eru »

IshKebab wrote: post #60
kccqzy wrote: post #13

Earlier quoted context omitted.

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.

Your are mixing up eras.

For comparison: when Javascript was first designed, performance wasn't a goal. Later on, people who had performance as a goal worked on Javascript implementations. Thanks to heroic efforts, nowadays Javascript is one of the language with decently fast implementation around. The base design of the language hasn't changed much (though how people use it might have changed a bit).

Python could do something similar.

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

#153

Post by eru »

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".

The new `uv` is making good progress there.

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

#154

Post by eru »

peterfirefly wrote: post #140
theLiminator wrote: post #99

Earlier quoted context omitted.

This can't come soon enough. Python is great for CLIs until you build something complex and a simple --help takes seconds. It's not something easily worked around without making your code very ugly.

It's not that hard to handle --help and --version separately before importing anything.

You could, but it doesn't really seem all that useful? I mean, when are you ever going to run this in a hot loop?

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

#155

Post by eru »

mikkupikku wrote: post #142
int_19h wrote: post #103

Earlier quoted context omitted.

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.

Doesn't seem all that relevant? New games will benefit from faster Python.

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

#156

Post by eru »

nilamo wrote: post #52
pjmlp wrote: post #46

Earlier quoted context omitted.

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.

> Any other viewpoint is ignoring reality.

Eh, what about users? Games are made for windows, because that's where users (= players) are?

That's even more true for mobile and console games.

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

#157

Post by eru »

pansa2 wrote: post #65
_ZeD_ wrote: post #61

Earlier quoted context omitted.

keep in mind that, apart from the money throw at js runtime interpreters by google and others, there is also the fact that python - as a language - is way more "dynamic" than javascript. Even "simple" stuff like field access in python may refer to multiple dynamically-mapped method resolution. Also, the ffi-bindings of python, while offering a way to extend it with libraries written in c/c++/fortran/... , limit how f…

> python - as a language - is way more "dynamic" than javascript Very true, but IMO the existence of PyPy proves that this doesn't necessarily prevent a fast implementation. I think the reason for CPython's poor performance must be your other point: > the ffi-bindings of python [...] limit how freely the internals can be changed

> Very true, but IMO the existence of PyPy proves that this doesn't necessarily prevent a fast implementation.

PyPy pays for this by having slower C interaction.

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

#158

Post by eru »

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.

You could plot the cumulative distribution function to avoid these problems with histograms.

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

#159

Post by eru »

wk_end wrote: post #93
croemer wrote: post #92

2 typos in first sentence. Is this on purpose to make it obviously not-AI generated? "apology peice" and "tail caling"

If you want to make your writing appear non-AI generated, the easiest way is to write it yourself. No typos necessary. I’m sure with enough cajoling you can make the LLM spit out a technical blog post that isn’t discernibly slop - wanton emoji usage, clichés, self-aggrandizement, relentlessly chipper tone, short “punchy” paragraphs, an absence of depth, “it’s not just X—it’s a completely new Y” - but it must be at le…

> If you want to make your writing appear non-AI generated, the easiest way is to write it yourself. No typos necessary.

You can ask the AI to make typos for you.

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

#160

Post by int_19h »

eru wrote: post #151
int_19h wrote: post #102

Earlier quoted context omitted.

I doubt it would have a JIT a long time ago. Thing is, people have been making JIT compilers for Python for a long time now, but the semantics of the language itself is such that it's often hard to benefit from it because most of the time isn't in the bytecode interpreter itself, it's dispatching things. People like comparing Python to JavaScript, but Python is much more flexible - all "primitive" types are objects c…

> People like comparing Python to JavaScript, but Python is much more flexible - all "primitive" types are objects can be subclassed for example, and even basic machinery like attribute lookups have a bunch of customization hooks. Most of the time, people don't use any of these customisations, don't they? So you'd need machinery that makes the common path go fast, but can fall back onto the customised path, if necess…

Descriptors underpin some common language features like method calls (that's how `self` gets bound), properties etc. You can still do it by special casing all those, and making sure that the way you implement all those primitives works exactly as if it used descriptors, sure. But at this point it's not exactly a simple JIT anymore.
Post reply on HN