I think OP is making a joke about python's GIL, which makes it so even if you are explicitly multi threading, only one thread is ever running at a time, which can defeat the point in some circumstances.
no, they're just saying python is slow. even without the GIL python is not multithreaded. the thread library doesn't use OS threads so even a free-threaded runtime running "parallel" code is limited to one thread.
Oooooh this is really cool, thanks for sharing. How could I install it on Linux (Ubuntu)? I assume I would have to compile CPython. Also, would the source of the programs I run need any modifications?
From memory I can only answer one of those: The way I understand it (and I could be wrong), your programs theoretically should only need modifications if they have a concurrency related bug. The global interlock is designed to take a sledgehammer at "fixing" a concurrency data race. If you have a bug that the GIL fixed, you'll need to solve that data race using a different control structure once free threading is enabled.
I know it's kind of a vague answer, but every program that supports true concurrency will do it slightly differently. Your average script with just a few libraries may not benefit, unless a library itself uses threads. Some libraries that use native compiled components may already be able to utilize the full power of you computer even on standard Python builds because threads spawned directly in the native code are less beholden to the GIL (depending on how often they'd need to communicate with native python code)
In this case, it's a feature of the language that enables developers to implement greater amounts of parallelism. So, the developers of the Python-based application will need to refactor to take advantage of it.
Oh wow, a programming language that is not supposed to be used for every single software in the world. Unlike Javascript for example which should absolutely be used for making everything (horrible). Nodejs was a mistake.
The documentation is kinda lacking, but if you could figure out how to set up Synapse then you can probably figure out Conduit too. https://conduit.rs/
I prefer this default. Im sick of having to rein in Numba cores or OpenBlas threads or other out of control software that immediately tries to bottleneck my stack.
CGroups (Docker/LXC) is the obvious solution, but it shouldn't have to be
I'll be honest, this only matters when running single services that are very expensive. it's fine if your program can't be pararlelized if the OS does its job and spreads the love around the cpus