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

71–80 of 193 posts

Re: State of Python 3.13 performance: Free-threading

#71

Post by nicce »

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…

It took me few days to get some old Jupyter Notebooks working. I had to find the correct older version of Jupyter, correct version of the every plugin/extension that notebook used and then I had to find the correct version of every dependency of these extensions. Only way to get it working was a bunch of pinned dependencies.

Re: State of Python 3.13 performance: Free-threading

#72

Post by rfoo »

eigenspace wrote: post #48
rfoo wrote: post #40

Earlier quoted context omitted.

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

Numpy is not fast enough for actual performance sensitive scientific computing. Yes threading can help, but at the end of the day the single threaded perf isn't where it needs to be, and is held back too much by the python glue between Numpy calls. This makes interproceedural optimizations impossible. Accellerated sub-languages like Numba, Jax, Pytorch, etc. or just whole new languages are really the only way forward…

These "accelerated sub-languages" are still driven by, well, Python glue. That's why we need free-threading and faster Python. We want the glue to be faster because it's currently the most accessible glue to the community.

In fact, Sam, the man behind free-threading, works on PyTorch. From my understanding he decided to explore nogil because GIL is holding DL trainings written in PyTorch back. Namely, the PyTorch DataLoader code itself and almost all data loading pipelines in real training codebases are hopeless bloody mess just because all of the IPC/SHM nonsense.

Re: State of Python 3.13 performance: Free-threading

#73

Post by eigenspace »

dagmx wrote: post #69
hawski wrote: post #41

Earlier quoted context omitted.

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.

No I wasn't?

Re: State of Python 3.13 performance: Free-threading

#74

Post by acdha »

refdl wrote: post #25

[flagged]

> As usual in Python, people are kept in line with CoC threats and the official marketing is amplified.

You’d need some serious evidence to back those claims up, and without it this seems like pure flamebait unrelated to the topic of this post.

Re: State of Python 3.13 performance: Free-threading

#75

Post by dagmx »

eigenspace wrote: post #73
dagmx wrote: post #69

Earlier quoted context omitted.

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.

No I wasn't?

Maybe i misunderstood your argument here where you scope it tightly to syntax changes being an issue but internal changes being fine.

https://news.ycombinator.com/item?id=42051745

Re: State of Python 3.13 performance: Free-threading

#76

Post by Archit3ch »

Jtsummers wrote: post #46
eigenspace wrote: post #38

Earlier quoted context omitted.

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

Common Lisp is probably not a good point of comparison. It offers comparable (if not more) dynamism to Python and still remains fast (for most implementations). You can redefine class definitions and function definitions on the fly in a Common Lisp program and other than the obvious overhead of invoking those things the whole system remains fast.

> You can redefine class definitions and function definitions on the fly in a Common Lisp program and other than the obvious overhead of invoking those things the whole system remains fast.

You can also treat Julia as C and recompile vtables on the fly.

Re: State of Python 3.13 performance: Free-threading

#77

Post by saurik »

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…

The Python 2 to 3 thing was worse when they started: people who made the mistake of falling for the rhetoric to port to python3 early on had a much more difficult time as basic things like u"" were broken under an argument that they weren't needed anymore; over time the porting process got better as they acquiesced and unified the two languages a bit.

I thereby kind of feel like this might have happened in the other direction: a ton of developers seem to have become demoralized by python3 and threw up their hands in defeat of "backwards compatibility isn't going to happen anyway", and now we live in a world with frozen dependencies running in virtual environments tied to specific copies of Python.

Re: State of Python 3.13 performance: Free-threading

#78

Post by eigenspace »

dagmx wrote: post #75
eigenspace wrote: post #73

Earlier quoted context omitted.

No I wasn't?

Maybe i misunderstood your argument here where you scope it tightly to syntax changes being an issue but internal changes being fine. https://news.ycombinator.com/item?id=42051745

What I meant by that is that because the changes mostly aren't syntax changes, they won't upset most users who are just using big packages that are actively maintained and keeping ahead of the breakage.

But I still find the high level of instability in Python land rather disturbing, and I would be unhappy if the languages I used constantly did these sorts of breaking changes

I'm even more extreme in that I also think the ABI instability is bad. Even though Python gives no guarantee of its stability, it's used by so many people it seems like a bad thing to constantly break and it probably should be stabilized.

Re: State of Python 3.13 performance: Free-threading

#79

Post by d0mine »

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…

At least bugfix versions could have kept Enum behavior the same. Postponing breaking changes until the next minor version. Some Enum features work differently (incompatible) in Python 3.11.x versions.

Re: State of Python 3.13 performance: Free-threading

#80

Post by wormlord »

d0mine wrote: post #79
wormlord wrote: post #12

Earlier quoted context omitted.

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

At least bugfix versions could have kept Enum behavior the same. Postponing breaking changes until the next minor version. Some Enum features work differently (incompatible) in Python 3.11.x versions.

> Some Enum features work differently (incompatible) in Python 3.11.x versions.

I wasn't aware of that, that's actually insane. It's odd to me that it took so long to get f-strings and Enums right in Python, I assumed those would be pretty easy language features to implement.

Post reply on HN