Free-threaded CPython is ready to experiment with

Post by indigodaddy » Sat, Jul 13, 2024, 1:55 AM UTC

eigenvalue wrote: post #123

phkahler wrote: post #25

Earlier quoted context omitted.

I feel like most things that will benefit from moving to multiple cores for performance should probably not be written in Python. OTH "most" is not "all" so it's gonna be awesome for some.

I personally optimize more for development time and overall productivity in creating and refactoring, adding new features, etc. I'm just so much faster using Python than anything else, it's not even close. There is such an incredible world of great libraries easily available on pip for one thing. Also, I've found that ChatGPT/Claude3.5 are much, much smarter and better at Python than they are at C++ or Rust. I can us…

Post by dagenix » Sat, Jul 13, 2024, 1:57 AM UTC

stavros wrote: post #147

dagenix wrote: post #146

Earlier quoted context omitted.

The GIL prevents the corruption of Pythons internal structures. It's hard to remove because: 1. Lots of extensions, which can control when they release the GIL unlike regular Python code, depend on it 2. Removing the GIL requires some sort of other mechanism to protect internal Python stuff 3. But for a long time, such a mechanism was resisted by th Python team because all attempts to remove the GIL either made singl…

Hmm, that's interesting, thank you. I didn't realize extensions can control the GIL.

Post by jmward01 » Sat, Jul 13, 2024, 1:59 AM UTC

ipsum2 wrote: post #128

jmward01 wrote: post #105

I know, I know, 'not every story needs to be about ML' but.... I can only imagine how unlocking the GIL will change the nature of ML training and inference. There is so much waste and complexity in passing memory around and coordinating processes. I know that libraries have made it (somewhat) easier and more efficient but I can't wait to see what can be done with things like pytorch when optimized for this.

It'll mostly help for debugging and lowering RAM (not VRAM) usage. Otherwise it won't impact ML much.

Post by pests » Sat, Jul 13, 2024, 2:01 AM UTC

nilamo wrote: post #113

hot_gril wrote: post #92

Earlier quoted context omitted.

Basically true in JS too. You're not supposed to do blocking calls in async code. You also can't "await" an async call inside a non-async func, though you could fire-and-forget it. Right, but how often does a Python program have complex shared state across threads, rather than some simple fan-out-fan-in, and also need to take advantage of multiple cores?

The primary thing that tripped me up about async/await, specifically only in Python, is that the called function does not begin running until you await it. Before that moment, it's just an unstarted generator. To make background jobs, I've used the class-based version to start a thread, then the magic method that's called on await simply joins the thread. Which is a lot of boilerplate to get a little closer to how as…

Post by mixmastamyk » Sat, Jul 13, 2024, 2:10 AM UTC

Galanwe wrote: post #36

Arcanum-XIII wrote: post #30

Earlier quoted context omitted.

All is well, then, one day, you have to update one library. Some days later, in some woods or cave, people will hear your screams of rage and despair.

Been using python for 15 years now, and these screams were never heard. Dev/test with relaxed pip installs, freeze deployment dependencies with pip freeze/pip-tools/poetry/whateveryoulike, and what's the problem?