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

11–20 of 193 posts

Re: State of Python 3.13 performance: Free-threading

#11

Post by sneed_chucker »

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…

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

Re: State of Python 3.13 performance: Free-threading

#12

Post by wormlord »

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 did that, and trying to find the combination of packages that would work for the version of Python I needed-- wondering why there was so much goddamn churn in this stupid [expletive] scripting language.

But then I took a step back and realized that, actually, I should be glad about the churn because it means that there is a community of developers who care enough about the language to add new features and maintain this language so that I can just pipe PyQt and Numpy into each other and get paid.

I don't have any argument, just trying to give an optimistic perspective.

Re: State of Python 3.13 performance: Free-threading

#13

Post by dagmx »

eigenspace wrote: post #9
the__alchemist wrote: post #6

Earlier quoted context omitted.

This is a good question, and I think about it as well. My best guess for a simple explanation: Python is very popular; it makes sense to improve performance for python users, given many do not wish to learn to use a more performant language, or to use a more performant Python implementation. Becoming proficient in a range of tools so you can use the right one for the right job is high enough friction that it is not t…

Oh yeah, I totally get the motivation behind it. It's always very tempting to want to make things faster. But I can't help but wondering if these attempts to make it faster might end up just making it worse. On the other hand though, Python is so big and there's so many corps using it with so much cash that maybe they can get away with just breaking shit every few releases and people will just go adapt packages to th…

Python famously has a community that does NOT adapt to changes well. See the Python 2 to 3 transition.

Re: State of Python 3.13 performance: Free-threading

#14

Post by ijl »

Performance for python3.14t alpha 1 is more like 3.11 in what I've tested. Not good enough if Python doesn't meet your needs, but this comes after 3.12 and 3.13 have both performed worse for me.

3.13t doesn't seem to have been meant for any serious use. Bugs in gc and so on are reported, and not all fixes will be backported apparently. And 3.14t still has unavoidable crashes. Just too early.

Re: State of Python 3.13 performance: Free-threading

#15

Post by eigenspace »

dagmx wrote: post #13
eigenspace wrote: post #9

Earlier quoted context omitted.

Oh yeah, I totally get the motivation behind it. It's always very tempting to want to make things faster. But I can't help but wondering if these attempts to make it faster might end up just making it worse. On the other hand though, Python is so big and there's so many corps using it with so much cash that maybe they can get away with just breaking shit every few releases and people will just go adapt packages to th…

Python famously has a community that does NOT adapt to changes well. See the Python 2 to 3 transition.

Python's community was significantly smaller and less flushed with cash during the 2 to 3 transition. Since then there has been numerous 3.x releases that were breaking and people seem to have been sucking it up and dealing with it quietly so far.

The main thing is that unlike the 2 to 3 transition, they're not breaking syntax (for the most part?), which everyone experiences and has an opinion on, they're breaking rather deep down things that for the most part only the big packages rely on so most users don't experience it much at all.

Re: State of Python 3.13 performance: Free-threading

#16

Post by jerf »

sneed_chucker wrote: post #11
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…

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.

Re: State of Python 3.13 performance: Free-threading

#17

Post by Yossarrian22 »

dagmx wrote: post #13
eigenspace wrote: post #9

Earlier quoted context omitted.

Oh yeah, I totally get the motivation behind it. It's always very tempting to want to make things faster. But I can't help but wondering if these attempts to make it faster might end up just making it worse. On the other hand though, Python is so big and there's so many corps using it with so much cash that maybe they can get away with just breaking shit every few releases and people will just go adapt packages to th…

Python famously has a community that does NOT adapt to changes well. See the Python 2 to 3 transition.

Are there communities that handle such a change well? At least that went better than Perl and Raku

Re: State of Python 3.13 performance: Free-threading

#18

Post by dagmx »

eigenspace wrote: post #15
dagmx wrote: post #13

Earlier quoted context omitted.

Python famously has a community that does NOT adapt to changes well. See the Python 2 to 3 transition.

Python's community was significantly smaller and less flushed with cash during the 2 to 3 transition. Since then there has been numerous 3.x releases that were breaking and people seem to have been sucking it up and dealing with it quietly so far. The main thing is that unlike the 2 to 3 transition, they're not breaking syntax (for the most part?), which everyone experiences and has an opinion on, they're breaking ra…

I disagree with this entire comment.

The Python community consisted of tons of developers including very wealthy companies. At what point in the last few years would you even say they became “rich enough” to do the migration? Because people are STILL talking about trying to fork 2.7 into a 2.8.

I also disagree with your assertion that 3.x releases have significant breaking changes. Could you point to any specific major breaking changes between 3.x releases?

2 to 3 didn’t break syntax for most code either. It largely cleaned house on sensible API defaults.

Re: State of Python 3.13 performance: Free-threading

#19

Post by yunohn »

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…

> I guess getting loops in Python to run 5-10x faster will still save some people time

I would recommend being less reductively dismissive, after claiming you “don’t really have a dog in this race”.

Edit: Lots of recent changes have done way more than just loop unrolling JIT stuff.

Re: State of Python 3.13 performance: Free-threading

#20

Post by dagmx »

Yossarrian22 wrote: post #17
dagmx wrote: post #13

Earlier quoted context omitted.

Python famously has a community that does NOT adapt to changes well. See the Python 2 to 3 transition.

Are there communities that handle such a change well? At least that went better than Perl and Raku

Anything where the language frontend isn’t tied to the ABI compatibility of the artifacts I think. They can mix versions/editions without worry.

I think it’s a larger problem with interpreted languages where all the source has to be in a single version. In that case I cant think of much.

Post reply on HN