Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Python 3.13 performance: Free-threading

codspeed.io

Post reply on HN
Print view View original

111–120 of 193 posts

Re: State of Python 3.13 performance: Free-threading

#111

Post by the5avage »

nas wrote: post #106
the5avage wrote: post #104

Can someone share insight into what was technically done to enable this? What replaced the global lock? Is the GC stopping all threads during collection or an other locking mechanism?

The key enabling tech is thread safe reference counting. There are many other problems that Sam Gross solved in order to make it happen but the reference counting was one of the major blockers.

Is this implemented with lockless programming? Is it a reason for the performance drop in single thread code?

Does it eliminate the need for a GC pause completely?

Re: State of Python 3.13 performance: Free-threading

#112

Post by nas »

the5avage wrote: post #111
nas wrote: post #106

Earlier quoted context omitted.

The key enabling tech is thread safe reference counting. There are many other problems that Sam Gross solved in order to make it happen but the reference counting was one of the major blockers.

Is this implemented with lockless programming? Is it a reason for the performance drop in single thread code? Does it eliminate the need for a GC pause completely?

You should probably just read the PEP, which explains these things:

https://peps.python.org/pep-0703/#reference-counting

If by GC you mean the cyclic GC, free-threaded Python currently stops all threads while the cyclic GC is running.

Re: State of Python 3.13 performance: Free-threading

#113

Post by lmm »

vosper wrote: post #67
epistasis wrote: post #55

Earlier quoted context omitted.

Pinning deps is discouraged by years of Python practice. And going back to a an old project and finding versions that work, a year or more later, might be nigh on impossible. Last week I was trying to install snakemake via Conda, and couldn't find any way to satisfy dependencies at all, so it's not just pypi, and pip tends to be one of the more forgiving version dependency managers. It's not just Python, trying to ge…

> Pinning deps is discouraged by years of Python practice. I'm not sure it is discouraged so much as just not what people did in Python-land for a long time. It's obviously the right thing to do, it's totally doable, it's just inertia and habit that might mean it isn't done.

> I'm not sure it is discouraged so much as just not what people did in Python-land for a long time. It's obviously the right thing to do, it's totally doable, it's just inertia and habit that might mean it isn't done.

Pinning obviously the wrong thing, it only works if everyone does it and if everyone does it then making changes becomes very hard. The right thing is to have deterministic dependency resolution so that dependencies don't change under you.

Re: State of Python 3.13 performance: Free-threading

#114

Post by lmm »

eigenspace wrote: post #30
jillesvangurp wrote: post #29

Earlier quoted context omitted.

Why does python have to be slow? Improvements over the last few releases have made it quite a bit faster. So that kind of counters that a bit. Apparently it didn't need to be quite as slow all along. Other languages can be fast. So, why not python? I think with the GIL some people are overreacting: most python code is single threaded because of the GIL. So removing it doesn't actually break anything. The GIL was just…

> Why does python have to be slow? Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc. The list of stuff l…

> Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc.

> The list of stuff like this goes on and on and on. You fundamentally just cannot compile most python programs to efficient machine code without making (sometimes subtle) changes to its semantics.

People said the same thing about JavaScript, where object prototypes can change at any time, dramatically changing everything. But it turned out JavaScript can run fast if you try hard enough. I suspect the same would be true for Python if a similar amount of resources was poured into it (probably with a similar "try the fast path, abort and fall back to a slow path in the extremely rare case that someone actually is doing funky metaprogramming" approach).

Re: State of Python 3.13 performance: Free-threading

#115

Post by dbsmith83 »

maleldil wrote: post #103
dbsmith83 wrote: post #33

Earlier quoted context omitted.

There have been many breaking changes throughout python 3.x releases: - standard library modules removed - zip error handling behaves differently - changes to collections module - new reserved keywords (async, await, etc.) You can argue how big of a deal it is or isn't, but there were definitely breakages that violate semantic versioning

Python doesn't follow SemVer, that's why. https://peps.python.org/pep-2026/

Clearly, which is what I was showing. A poor design decision imo

Re: State of Python 3.13 performance: Free-threading

#116

Post by lmm »

wormlord wrote: post #12
eigenspace wrote: post #3

I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "re…

> On the other hand, a lot of these changes to try and speed up the base language are going to be highly disruptive. E.g. disabling the GIL will break tonnes of code, lots of compilation projects involve changes to the ABI, etc. Kind of related, the other day I was cursing like a sailor because I was having issues with some code I wrote that uses StrEnum not working with older versions of Python, and wondering why I…

Meh. Anyone can improve a language if they don't care about keeping backward compatibility, just like new programming languages and new codebases always look gloriously clean. The part that requires actual discipline and expertise is improving it while keeping the breakages under control.

Re: State of Python 3.13 performance: Free-threading

#117

Post by lmm »

jerf wrote: post #16
sneed_chucker wrote: post #11

Earlier quoted context omitted.

If JavaScript (V8) and PyPy can be fast, then CPython can be fast too. It's just that the CPython developers and much of the Python community sat on their hands for 15 years and said stuff like "performance isn't a primary goal" and "speed doesn't really matter since most workloads are IO-bound anyway".

In this context, V8 and PyPy aren't fast. Or at least, not generally; they may actually do well on this task because pure number tasks are the only things they can sometimes, as long as you don't mess them up, get to compiled language-like performance. But they don't in general to compiled language performance, despite common belief to the contrary.

Do you have any objective evidence for that claim, or is this just you guessing?

Re: State of Python 3.13 performance: Free-threading

#118

Post by WillDaSilva »

lmm wrote: post #113
vosper wrote: post #67

Earlier quoted context omitted.

> Pinning deps is discouraged by years of Python practice. I'm not sure it is discouraged so much as just not what people did in Python-land for a long time. It's obviously the right thing to do, it's totally doable, it's just inertia and habit that might mean it isn't done.

> I'm not sure it is discouraged so much as just not what people did in Python-land for a long time. It's obviously the right thing to do, it's totally doable, it's just inertia and habit that might mean it isn't done. Pinning obviously the wrong thing, it only works if everyone does it and if everyone does it then making changes becomes very hard. The right thing is to have deterministic dependency resolution so tha…

When they suggest you pin your dependencies, they don't just mean your direct dependencies, but rather all transitive dependencies. You can take this further by having a lock file that account for different Python versions, operating systems, and CPI architectures – for instance , by using UV or Poetry – but a simple `pip freeze` is often sufficient.

Re: State of Python 3.13 performance: Free-threading

#120

Post by kaanyalova »

qaq wrote: post #91
runjake wrote: post #47

If it were ever open sourced, I could see Mojo filling the performance niche for Python programmers. I'm hopeful because Lattner certainly has the track record, if he doesn't move on beforehand. https://en.wikipedia.org/wiki/Mojo_(programming_language)

https://github.com/modularml/mojo/blob/main/LICENSE

The source code for the compiler hasn't released yet
Post reply on HN