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

61–70 of 193 posts

Re: State of Python 3.13 performance: Free-threading

#61

Post by pjmlp »

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…

Since Python has become the new Lisp, the minimum is to have the performance tooling Common Lisp has had for several decades, in native code generation and multithreading (yes I know that in CL this is implementation specific).

Re: State of Python 3.13 performance: Free-threading

#62

Post by andai »

almostgotcaught wrote: post #28
andai wrote: post #24

Earlier quoted context omitted.

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…

> I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). ... > I wrote last year and it turned out that a bunch of my dependencies had changed their APIs these two things have absolutely nothing to do with each other - couldn't be a more apples to oranges comparison if you tried

I ran into both of these things in the same context, which is "the difficulty involved in getting old code working on the latest Python environment", which I understood as the context of this discussion.

Re: State of Python 3.13 performance: Free-threading

#63

Post by klysm »

epistasis wrote: post #55
klysm wrote: post #31

Earlier quoted context omitted.

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

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…

That doesn’t match my experience at all. I have many Python projects going back years that all work fine with pinned dependencies

Re: State of Python 3.13 performance: Free-threading

#64

Post by bastawhiz »

ijl wrote: post #14

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.

> 3.13t doesn't seem to have been meant for any serious use.

I don't think anyone would suggest using it in production. The point was to put something usable out into the world so package maintainers could kick the tires and start working on building compatible versions. Now is exactly the time for weird bug reports! It's a thirty year old runtime and one of its oldest constraints is being removed!

Re: State of Python 3.13 performance: Free-threading

#65

Post by dagmx »

wruza wrote: post #36
dagmx wrote: post #18

Earlier quoted context omitted.

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

Those are ABI changes and not changes to the language.

Re: State of Python 3.13 performance: Free-threading

#66

Post by dagmx »

adamc wrote: post #39
dagmx wrote: post #18

Earlier quoted context omitted.

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.

Yes 2 to 3 changed things. We’re discussing what changed in between different versions of 3.

Re: State of Python 3.13 performance: Free-threading

#67

Post by vosper »

epistasis wrote: post #55
klysm wrote: post #31

Earlier quoted context omitted.

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

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.

Re: State of Python 3.13 performance: Free-threading

#68

Post by dagmx »

adamc wrote: post #37
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.

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.

Many languages have. There were significant breaks in C++ when stringabi changed, Swift has had major language changes, rust has editions.

The difference is in what motivates getting to the other end of that transition bump and how big the bump is. That’s why it took till past 2.7’s EOL to actually get people on to 3 in a big way because they’d drag their feet if they don’t see a big enough change.

Compiled languages have it easier because they don’t need to mix source between dependencies, they just have to be ABI compatible.

Re: State of Python 3.13 performance: Free-threading

#69

Post by dagmx »

hawski wrote: post #41
dagmx wrote: post #18

Earlier quoted context omitted.

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…

Most of those are some old long deprecated things and in general those are all straight up improvements. Python is not my main thing so I'm not really good to answer this, but I listed a few that I am sure triggered errors in some code bases (I'm not saying they are all major ). Python's philosophy makes most of those pretty easy to handle, for example instead of foo now you have to be explicit and choose either foo_…

Thanks. That’s a good list, though I think the majority of the changes were from deprecations early in the 3.x days and are API changes, whereas the OP was talking about syntax changes for the most part.

Re: State of Python 3.13 performance: Free-threading

#70

Post by notatallshaw »

refdl wrote: post #25

[flagged]

You seem to be conflating problems and different groups of people that aren't directly related.

To clarify some different groups:

* The faster-cpython project, headed by Guido and his team at Microsoft, is continuing fine, most of the low hanging fruit was accomplished by 3.11, further improvements were moved to medium term goals and they were delayed further by the free threaded project which broke assumptions that were made to optimize CPython, they have adapted but it has pushed big optimizations out to later released (think probably 3.15ish)

* The free threaded project, initiated by Sam Gross at Meta, is continuing fine, it was never intended to be ready by 3.13, the fact there is even a build officially published is very fast progress. There isn't yet a plan to make it default, depending on the compatibility of the free threaded build it could be a quick transition or a 5+ year switch over.

* The PSF, the Steering Council, and the CoC WG are all different groups that have different responsibilities and aren't typically involved in day-to-day choices of committing certain features.

* The release manager is a core developer in charge of making the final choice on whether a particular feature is stable or not. It was the 3.13 release manager who decided to revert the new GC which was intended to generally improve performance for non-free threaded builds, which it may still do in a future release with sufficient fine tuning.

Now, there are clearly communication issues in areas of the Python community, but there is also a lot of people getting on with great work and improvements and communicating fine.

Post reply on HN