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

31–40 of 193 posts

Re: State of Python 3.13 performance: Free-threading

#31

Post by klysm »

andai wrote: post #24
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…

There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experi…

So pin your deps? Language backwards compatibility and an API from some random package changing are completely distinct.

Re: State of Python 3.13 performance: Free-threading

#32

Post by kmeisthax »

refdl wrote: post #25

[flagged]

> people are kept in line with CoC threats

Can you point to an example of someone claiming that a particular feature's performance claims were misleading, and then getting threatened with a ban or other sanctions for it, where they did not otherwise violate CoC?

Re: State of Python 3.13 performance: Free-threading

#33

Post by dbsmith83 »

dagmx wrote: post #23
eigenspace wrote: post #21

Earlier quoted context omitted.

Fair enough. You may be totally right here, as I mentioned I don't use Python much at all since like 2017 and haven't paid it much attention in a while. I retract my comment. Regarding breakage in 3.x, all I know is that I recall several times where I did a linux system update (rolling release), and that updated my Python to a newly released version which broke various things in my system. I'm pretty sure one of thes…

To your last point: it’s neither the language nor the packages but rather it’s the ABI. Python isn’t fully ABI stable (though it’s improved greatly) so you can’t just intermix compiled dependencies between different versions of Python. This is true for many packages in your distro as well.

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

Re: State of Python 3.13 performance: Free-threading

#34

Post by adamc »

andai wrote: post #24
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…

There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experi…

It's hard to comment on this without knowing more about the dependencies and when/how they changed their APIs. I would say if it was a major version change, that isn't too shocking. For a minor version change, it should be.

Stuff that is actually included with Python tends to be more stable than random Pypi packages, though.

NPM packages also sometimes change. That's the world.

Re: State of Python 3.13 performance: Free-threading

#35

Post by adamc »

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…

There are different definitions of slow, though. You might want arbitrary precision numbers but want it to be reasonable fast in that context.

I don't agree that it is "insane stuff", but I agree that Python is not where you go if you need super fast execution. It can be a great solution for "hack together something in a day that is correct, but maybe not fast", though. There are a lot of situations where that is, by far, the preferred solution.

Re: State of Python 3.13 performance: Free-threading

#36

Post by wruza »

dagmx wrote: post #18
eigenspace wrote: post #15

Earlier quoted context omitted.

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

Could you point to any specific major breaking changes between 3.x releases?

I can not, but I can tell you that anything AI often requires finding a proper combination of python + cuXXX + some library. And while I understand cu-implications, for some reason python version is also in this formula.

I literally have four python versions installed and removed from PATH, because if I delete 3.9-3.11, they will be needed next day again and there’s no meaningful default.

Re: State of Python 3.13 performance: Free-threading

#37

Post by adamc »

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.

That was, in many ways, a crazy difficult transition. I don't think most languages have gone through such a thing. Perl tried and died. So I don't agree that it reflects poorly on the community; I think the plan itself was too ambitious.

Re: State of Python 3.13 performance: Free-threading

#38

Post by eigenspace »

adamc wrote: post #35
eigenspace wrote: post #30

Earlier quoted context omitted.

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

There are different definitions of slow, though. You might want arbitrary precision numbers but want it to be reasonable fast in that context. I don't agree that it is "insane stuff", but I agree that Python is not where you go if you need super fast execution. It can be a great solution for "hack together something in a day that is correct, but maybe not fast", though. There are a lot of situations where that is, by…

There are ways to design languages to be dynamic while still being friendly to optimizing compilers. Typically what you want to do is promise that various things are dynamic, but then static within a single compilation context.

julia is a great example of a highly dynamic language which is still able to compile complicated programs to C-equivalent machine code. An older (and less performant but still quite fast) example of such a language is Common Lisp.

Python makes certain choices though that make this stuff pretty much impossible.

Re: State of Python 3.13 performance: Free-threading

#39

Post by adamc »

dagmx wrote: post #18
eigenspace wrote: post #15

Earlier quoted context omitted.

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

2 to 3 broke lots of code. Print became a function. Imports moved around. And there were subtle changes in the semantics of some things. Famously, strings changed, and that definitely affected a lot of packages.

Quite a bit of that could be fixed by automated tooling, but not all of it, and the testing burden was huge, which meant a lot of smaller packages did not convert very quickly and there were ripple effects.

Re: State of Python 3.13 performance: Free-threading

#40

Post by rfoo »

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…

> Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible

Scientific computing community have a bunch of code calling numpy or whatever stuff. They are pretty fast because, well, numpy isn't written in Python. However, there is a scalability issue: they can only drive so many threads (not 1, but not many) in a process due to GIL.

Okay, you may ask, why not just use a lot of processes and message-passing? That's how historically people work around the GIL issue. However, you need to either swallow the cost of serializing data over and over again (pickle is quite slow, even it's not, it's wasting precious memory bandwidth), or do very complicated dance with shared memory.

It's not for web app bois, who may just write TypeScript.

Post reply on HN