![](https://secure.gravatar.com/avatar/1fee087d7a1ca17c8ad348271819a8d5.jpg?s=120&d=mm&r=g)
Le 02/02/2021 à 10:50, M.-A. Lemburg a écrit :
On 02.02.2021 10:27, Antoine Pitrou wrote:
Le 02/02/2021 à 10:14, M.-A. Lemburg a écrit :
On 02.02.2021 00:37, Senthil Kumaran wrote:
On Mon, Feb 01, 2021 at 06:34:04PM +0100, M.-A. Lemburg wrote:
As I said: we have those years to wait. The GIL is not causing people to run away from Python anymore, since compute has moved on and no longer relies on threads for scaling up.
Where has it moved to? I see people choosing Go and Rust for performance reasons.
Compute has moved on to distributed computing, quoting an earlier email:
""" Also note that the Python GIL scalability problem is not really that urgent anymore these days. People are moving to distributed computing, splitting workloads across processes, containers, VMs, GPUs and other specialized hardware. Together with async code, the GIL no longer prevents Python applications from scaling easily. """
Have a look at Python Dask for example.
Speaking as own of the Dask core developers, the Python GIL is very much a problem for some parts of Dask (ironically, for the part that distributes work over multiple computers, since distributed scheduling is a difficult task that takes a lot of CPU).
See for example https://github.com/dask/distributed/issues/4443
Reading through that ticket, it looks more like a socket problem than a GIL problem:
https://github.com/dask/distributed/issues/4443#issuecomment-765241186
The concerns in that issue a bit commingled. But the underlying issue is that the main scheduler thread competes for CPU resources with other threads where other tasks are offloaded. The scheduler by design works on shared state and cannot be rewritten to use several processes.
Regards
Antoine.