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

Intent to approve PEP 703: making the GIL optional

discuss.python.org

Post reply on HN
Print view View original

321–330 of 513 posts

Re: Intent to approve PEP 703: making the GIL optional

#321

Post by Dylan16807 »

wokwokwok wrote: post #161
qbasic_forever wrote: post #157

Earlier quoted context omitted.

It's good if there's a benefit for everyone, like python 3 fixing the terrible Unicode story. It's not clear non-GIL will even be a net performance improvement for most people--you are effectively moving syncronization from the core runtime to each and every library and program at the edge. Writing safe code at that level doesn't come for free, your basic program will be slower (and likely buggier) if every call into…

I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”. That’s not whining; it’s just an observation that the committee making these decisions gives zero ducks about the impact this will have for anyone other than the handful of vested parties involved in making the decisions. Pypi h…

> I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”.

1. But they don't "have to".

2. Even if they did, why would downvoting be "disingenuous"?

Re: Intent to approve PEP 703: making the GIL optional

#322

Post by smcl »

bjourne wrote: post #96

This can (and I think will) cause issues for C extensions because many are written without multi-threading in mind. Here is a small example which is unsafe if lst can be accessed from another thread: https://news.ycombinator.com/item?id=36649769 Note that the code may cause a context switch even today if the C code callbacks into Python bytecode (via a __del__ method) and the bytecode is long enough (100 instructions…

I think the CPython core devs are very keenly aware of these issues. Otherwise they'd have announced a plan to suddenly rip out the GIL altogether, rather than a phased approach that allows people to opt-in to the no-GIL mode.

Re: Intent to approve PEP 703: making the GIL optional

#323

Post by qbasic_forever »

kzrdude wrote: post #252
qbasic_forever wrote: post #154

Earlier quoted context omitted.

Where will you get no-GIL libraries, especially in the early days? Just yell at the maintainers of core libs like flask and requests until they use their volunteer and spare time to implement incredibly complex and tricky locking semantics all over their codebases, AND test it all with both GIL and non-GIL interpretors at scale to suss out race conditions? That just happens for free and overnight because a lot of peo…

Flask is pure python, isn't it?

Even pure python code could have race conditions with the GIL disabled. Stuff like accessing and modifying a dictionary item in python code is assumed and currently guaranteed to be atomic because of the GIL. Remove the GIL and decades of assumptions break.

Re: Intent to approve PEP 703: making the GIL optional

#324

Post by csmpltn »

usrbinbash wrote: post #304
csmpltn wrote: post #297

Earlier quoted context omitted.

> In what sense is the overhead of starting actual OS processes, and relying on IPC "free" With Python's current multiprocessing utilities - you get a big discount by not having to write thread-safe code, or worry about synchronization, despite the GIL still being there. Very broadly speaking, it's "free" in the sense that the OS handles parallelism automatically at the process-level, and provides a simple communicat…

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5 > and teach the entire Python community how to safely write multi-threaded code People who don't…

> "And as outlined above, these means are no suitable replacement for true thread based parallelism."

Your only argument is that "thread-based parallelism can't be achieved without threads", but that's not relevant to the conversation whatsoever.

The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads.

For CPU-bound workloads, the number of threads you can run in parallel is bound by the number of cores you have. For IO-bound workloads, your threads are just waiting on interrupts.

What are concrete use-cases where thread-based parallelism in Python is so desperately needed right now, that can't be achieved through process-based parallelism?

I'll give you one: real-time latency/throughput-sensitive DSP. Think real-time audio processing, or real-time algorithmic trading. Python isn't used there to begin with (for an entire flurry of reasons) - GIL or no GIL.

Re: Intent to approve PEP 703: making the GIL optional

#325

Post by r0l1 »

csmpltn wrote: post #245
r0l1 wrote: post #230

Earlier quoted context omitted.

We are working with a huge Go and Python codebase and Python is just a pain in terms of using all system resources. We moved many parts to C++ which are called and handled by goroutines. The outcome was a big success. This proposal/change is a big step forward, especially for the deep learning community.

> "Python is just a pain in terms of using all system resources" Whatever this comment means (I honestly can't properly tell) - removing the GIL will have absolutely no impact on Python's resource utilization.

https://peps.python.org/pep-0703/

Quote: "In PyTorch, Python is commonly used to orchestrate ~8 GPUs and ~64 CPU threads, growing to 4k GPUs and 32k CPU threads for big models. While the heavy lifting is done outside of Python, the speed of GPUs makes even just the orchestration in Python not scalable. We often end up with 72 processes in place of one because of the GIL. Logging, debugging, and performance tuning are orders-of-magnitude more difficult in this regime, continuously causing lower developer productivity."

Quote: "We frequently battle issues with the Python GIL at DeepMind. In many of our applications, we would like to run on the order of 50-100 threads per process. However, we often see that even with fewer than 10 threads the GIL becomes the bottleneck. To work around this problem, we sometimes use subprocesses, but in many cases the inter-process communication becomes too big of an overhead. To deal with the GIL, we usually end up translating large parts of our Python codebase into C++. This is undesirable because it makes the code less accessible to researchers."

Re: Intent to approve PEP 703: making the GIL optional

#326

Post by miraculixx »

TX81Z wrote: post #130
slt2021 wrote: post #54

Naiive question: Who needs No-GIL when we have asyncio and multiprocessing packages ? never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed. is there any use case of No-GIL which is not solved by multiprocessing ? I thought Single threaded execution without overhead for concurrency primitives is the best way to high p…

Multiprocessing has a lot of issues, one of which is handling processes that never complete, subprocesses that crash and don’t return, a subprocesses that needs to spawn another subprocesses, etc.

Threads can end in limbo too. At least with multiprocessing you get to kill those that hang. Threads, not so much.

Re: Intent to approve PEP 703: making the GIL optional

#327

Post by miraculixx »

usrbinbash wrote: post #304
csmpltn wrote: post #297

Earlier quoted context omitted.

> In what sense is the overhead of starting actual OS processes, and relying on IPC "free" With Python's current multiprocessing utilities - you get a big discount by not having to write thread-safe code, or worry about synchronization, despite the GIL still being there. Very broadly speaking, it's "free" in the sense that the OS handles parallelism automatically at the process-level, and provides a simple communicat…

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5 > and teach the entire Python community how to safely write multi-threaded code People who don't…

Progress in the name if progress is rarely a good choice.

The key question that remains unanswered is

Why should Python even need a free threading model?

There are no good answers afaik.

Re: Intent to approve PEP 703: making the GIL optional

#328

Post by majewsky »

Dylan16807 wrote: post #305
insanitybit wrote: post #188

Earlier quoted context omitted.

It wasn't a suggestion, they were asking a question.

Oh please. Even if we ignore that any question can have implications, they directly said "someone has to say it". They were explicitly suggesting something by asking that question.

They were suggesting that this is a question that is going to be on people's minds, which is very different from suggesting that the answer is yes.

Re: Intent to approve PEP 703: making the GIL optional

#329

Post by miraculixx »

usrbinbash wrote: post #304
csmpltn wrote: post #297

Earlier quoted context omitted.

> In what sense is the overhead of starting actual OS processes, and relying on IPC "free" With Python's current multiprocessing utilities - you get a big discount by not having to write thread-safe code, or worry about synchronization, despite the GIL still being there. Very broadly speaking, it's "free" in the sense that the OS handles parallelism automatically at the process-level, and provides a simple communicat…

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5 > and teach the entire Python community how to safely write multi-threaded code People who don't…

> The GIL doesn't prevent race conditions between individual python instructions

Yes it does. Unless we mean something different?

Re: Intent to approve PEP 703: making the GIL optional

#330

Post by Dylan16807 »

slt2021 wrote: post #78
miraculixx wrote: post #74

Earlier quoted context omitted.

Fully agree. People put far too much emphasis & expectations on the "free" part in "free multithreading".

even if they get "free multithreading" with no-GIL, their system eventually will overgrow one beefy machine and will need to be deployed across a fleet of 10/100/1000 machines. at which point you lose benefit of no-GIL, because you now have to introduce redis and kafka into the system

Most systems don't grow forever, and can stay on one machine.

And "one beefy machine" has a very high limit, so by the time you actually outgrow it you usually have tons of resources available to help rewrite things.

Post reply on HN