Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Free-threaded CPython is ready to experiment with

labs.quansight.org

Post reply on HN
Print view View original

351–360 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#351

Post by bdd8f1df777b »

veber-alex wrote: post #207
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.

huh? Any python library that cares about performance is written in C/C++/Rust/Fortran and only provides a python interface. ML will have 0 benefit from this.

If you have done ML with PyTorch or Tensorflow you will know how much multithreading can improve data loading performance. Currently multiprocessing provides the necessary parallelization of data loading but it is painful and riddle with bugs.

Re: Free-threaded CPython is ready to experiment with

#352

Post by lyu07282 »

skissane wrote: post #344
lyu07282 wrote: post #324

Earlier quoted context omitted.

There is a reason why it's "complicated" in threads, because doing it correctly just IS complicated, and the same reason applies to child processes, you just ignored that reason. That's one example of a footgun in using multiprocessing, people write broken code but they don't know that because it appears to work... until it doesn't (in production on friday night).

I don't agree. A big reason why abruptly terminating threads at an arbitrary point is risky is it can corrupt shared memory. If you aren't using shared memory in a multiprocess solution, that's not an issue. Another big reason is it can lead to resource leaks (e.g. thread gets terminated in a finally clause to close resources and hence the resource doesn't get closed). Again, that's less of an issue for processes, si…

This is not a matter of opinion. Always clean up after yourself, the kernel doesn't know shit about your application or what state it's in, you can not rely on it to cleanly terminate your process. Just because it's a child process (by default it's a forked process!) not a thread, doesn't mean it can not have shared resources. It can lead to deadlocks, stuck processes, all kinds of resource leaks, data and stream corruption, orphaned processes, etc. etc.

Re: Free-threaded CPython is ready to experiment with

#353

Post by skissane »

lyu07282 wrote: post #352
skissane wrote: post #344

Earlier quoted context omitted.

I don't agree. A big reason why abruptly terminating threads at an arbitrary point is risky is it can corrupt shared memory. If you aren't using shared memory in a multiprocess solution, that's not an issue. Another big reason is it can lead to resource leaks (e.g. thread gets terminated in a finally clause to close resources and hence the resource doesn't get closed). Again, that's less of an issue for processes, si…

This is not a matter of opinion. Always clean up after yourself, the kernel doesn't know shit about your application or what state it's in, you can not rely on it to cleanly terminate your process. Just because it's a child process (by default it's a forked process!) not a thread, doesn't mean it can not have shared resources. It can lead to deadlocks, stuck processes, all kinds of resource leaks, data and stream cor…

> This is not a matter of opinion. Always clean up after yourself, the kernel doesn't know shit about your application or what state it's in, you can not rely on it to cleanly terminate your process.

If you have an open file or network connection, the kernel is guaranteed to close it for you when the process is killed (assuming it hasn't passed the fd/socket to a subprocess, etc). That's not a matter of opinion.

Yes, if you are writing to a file, it is possible abruptly killing the writer may leave the file in an inconsistent state. But maybe you know your process doesn't write to any files (that's true in my case). Or maybe it does write to files, but you already have other mechanisms to recover their integrity in this scenario (since file writing processes can potentially die at any time–kernel panic, power loss, intermittent crash bug, etc)

Re: Free-threaded CPython is ready to experiment with

#354

Post by lyu07282 »

skissane wrote: post #353
lyu07282 wrote: post #352

Earlier quoted context omitted.

This is not a matter of opinion. Always clean up after yourself, the kernel doesn't know shit about your application or what state it's in, you can not rely on it to cleanly terminate your process. Just because it's a child process (by default it's a forked process!) not a thread, doesn't mean it can not have shared resources. It can lead to deadlocks, stuck processes, all kinds of resource leaks, data and stream cor…

> This is not a matter of opinion. Always clean up after yourself, the kernel doesn't know shit about your application or what state it's in, you can not rely on it to cleanly terminate your process. If you have an open file or network connection, the kernel is guaranteed to close it for you when the process is killed (assuming it hasn't passed the fd/socket to a subprocess, etc). That's not a matter of opinion. Yes,…

Oh well I see, you will learn the hard way then (:

Re: Free-threaded CPython is ready to experiment with

#355

Post by gomizari »

pansa2 wrote: post #271
anwlamp wrote: post #270

Earlier quoted context omitted.

Yes, good summary. My prediction is that free-threading will be the default at some point because one of the corporations that usurped Python-dev wants it. The rest of us can live with arcane threading bugs and yet another split ecosystem. As I understand it, if a single C-extension opts for the GIL, the GIL will be enabled. Of course the invitation to experiment is meaningless. CPython is run by corporations, many e…

> one of the corporations that usurped Python-dev Man, that phrase perfectly encapsulates so much of Python’s evolution over the last ~10 years.

Just Python evolution?

Re: Free-threaded CPython is ready to experiment with

#356

Post by ansgri »

dgfitz wrote: post #142
stavros wrote: post #89

Earlier quoted context omitted.

That was the entire point, that C++ is the absolute worst.

I pip3 installed something today. It didn’t work, at all. I then yum installed a lib and headers, it worked well. C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.

C++ on linux is indeed pleasant if you use only distro-provided library versions. Some specialized library with specific version, also no big deal. Need some upgraded version of a widely-used library -- get containerized or prepare for real pain.

Re: Free-threaded CPython is ready to experiment with

#357

Post by [deleted] »

whoiscroberts wrote: post #173
nine_k wrote: post #6

Python 3 progress so far: [x] Async. [x] Optional static typing. [x] Threading. [ ] JIT. [ ] Efficient dependency management.

Optional static typing, not really. Those type hints are not used at runtime for performance. Type hint a var as a string then set it to an init, that code still gonna try to execute.

[deleted]

Re: Free-threaded CPython is ready to experiment with

#358

Post by Certhas »

pdhborges wrote: post #338
Certhas wrote: post #281

Earlier quoted context omitted.

But multiprocessing can't? I used to write a ton of MPI based parallel python. It's pretty straightforward. But one could easily imagine trying to improve the multiprocessing ergonomics rather than introducing threading. Obviously the people who made the choice to push forward with this are aware of these options, too. Still mildly puzzling to me why threads for Python are needed/reasonable.

It doesn't to be puzzling just read the motivation section of https://peps.python.org/pep-0703/

I know that document. It doesn't really answer this point though. It motivates the need for parallelism in slow python by noting that this is important once other performance critical code is in extensions.

But the mai point against multiprocessing seems to be that spawning new processes is slow ...

That single "alternatives" paragraph doesn't answer at all why mp isn't viable for python level parallelism.

I am no longer invested in python heavily, I am sure there are discussions or documents somewhere that go into this more. Might be that it's simply that everyone is used to threads so you should support it for sheer familiarity. All I am saying is it's not obvious to a casual observer.

Re: Free-threaded CPython is ready to experiment with

#359

Post by bjourne »

adament wrote: post #243
wesselbindt wrote: post #240

Earlier quoted context omitted.

I've always found the criticism leveled by the colored functions blog post a bit contrived. Yes, when you replace the words async/await with meaningless concepts I do not care about, it's very annoying to have to arbitrarily mark a function as blue or red. But when you replace the word "aync" with something like "expensive", or "does network calls", it becomes clear that "async/await" makes intrinsic properties about…

But a synchronous function can and many do make network calls or write to files. It is a rather vague signal about the functions behavior as opposed to the lack of the IO monad in Haskell. To me the difficulty is more with writing generic code and maintaining abstraction boundaries. Unless the language provides a way to generalise over asyncness of functions, we need a combinatorial explosion of async variants of gen…

What you write is eerily similar to one of the pain points of Haskell. You can write a compiler that is purely functional. But then you want logging so you must put wrap it with the IO monad. And then also every function that calls the compiler and so on.

Re: Free-threaded CPython is ready to experiment with

#360

Post by npalli »

dgfitz wrote: post #142
stavros wrote: post #89

Earlier quoted context omitted.

That was the entire point, that C++ is the absolute worst.

I pip3 installed something today. It didn’t work, at all. I then yum installed a lib and headers, it worked well. C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.

Have you tried vcpkg on msft (work on linux and mac too btw)? I found it to be much better than pip3 and venv nonsense.
Post reply on HN