Intent to approve PEP 703: making the GIL optional • Hacker News Board

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

#121

Post by lmz » Sat, Jul 29, 2023, 1:47 AM UTC

Phil_Latio wrote: post #99

miraculixx wrote: post #59

Earlier quoted context omitted.

> It's simply not "sane multithreading" not being able to run Python (byte)code concurrentltly Please read my post again. I am advocating a GIL per-thread model with an explicit feature for sharing selected objects. This allows for all cores concurrency, essentially like free threading yet with safeguards. I like to call that a sane way because it builds on decades of research and industry experience of the software…

> I am advocating a GIL per-thread model with an explicit feature for sharing selected objects Is there a PEP or something written about it? I don't like this idea at first glance. Feels like another hack. Though I have to admit it sounds better than the annoying multiprocessing approach. > It's not optional if you build tools and libraries that need be able to run with both gil and no-gil. Why do they need to? A lib…

>> I am advocating a GIL per-thread model with an explicit feature for sharing selected objects

> Is there a PEP or something written about it? I don't like this idea at first glance. Feels like another hack. Though I have to admit it sounds better than the annoying multiprocessing approach.

This seems very similar to Perl's ithreads model: https://perldoc.perl.org/perlthrtut#Shared-And-Unshared-Data

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

#122

Post by n2d4 » Sat, Jul 29, 2023, 1:47 AM UTC

Jabrov wrote: post #113

catnibbler wrote: post #112

Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stu…

As opposed to?

In Python, asyncio and multiprocessing packages can get nearly the same or better performance for IO- and CPU-intensive tasks respectively as no-GIL multithreading (and are more performant than GIL multithreading), with only a tiny fraction of the pitfalls. For any use case where the last few percent matter, consider not using Python (which will be much much more significant).

Regardless, we did somehow end up here, and there's plenty of multi-threaded Python code that would benefit from no-GIL, so I support the proposal just from a practical perspective. But when designing a new codebase, you'll almost almost almost always want to avoid Python threads, even with no-GIL.

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

#123

Post by qbasic_forever » Sat, Jul 29, 2023, 1:50 AM UTC

n2d4 wrote: post #81

Steltek wrote: post #69

Earlier quoted context omitted.

Well someone has to say it so I might as well: Is this going to be another Python 2 -> 3 cat herding exercise again? I suppose the need to run your app in "no-GIL" mode is less than needing to jump from 2.7 to 3.

I didn't dive deep on this, but I assume that GIL mode can still run anything, including no-GIL code (it is one of their promises, at least). So, unlike 2->3, there is forwards-compatibility. It also seems like the latter isn't meant as a replacement (for the moment), but rather as an option.

Presumably C extensions will have a different API name/ABI to prevent accidentally calling into GIL code when in non-GIL mode and vice/versa so that's going to complicate the compatibility story.

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

#124

Post by paulddraper » Sat, Jul 29, 2023, 1:51 AM UTC

Steltek wrote: post #69

paulddraper wrote: post #63

Earlier quoted context omitted.

No-GIL mode is optional, and libraries will be marked "no-GIL compatible" and the ecosystem will gradually support more and more of these. No one's flipping a switch and breaking mountains of sketchy C.

Well someone has to say it so I might as well: Is this going to be another Python 2 -> 3 cat herding exercise again? I suppose the need to run your app in "no-GIL" mode is less than needing to jump from 2.7 to 3.

As sibling comments says, GIL mode can run no-GIL code.

Entirely different from 2->3.

That analogy is so poorly applicable it's laughable.

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

#125

Post by TX81Z » Sat, Jul 29, 2023, 1:51 AM UTC

But how will I waste thousands of person hours battling subprocesses now????

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

#126

Post by miraculixx » Sat, Jul 29, 2023, 1:52 AM UTC

catnibbler wrote: post #112

Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stu…

I was called inconsiderate for essentially asking this very question. I still think it's the right question to ask:

Why should Python even have a free threading model?

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

#127

Post by paulddraper » Sat, Jul 29, 2023, 1:52 AM UTC

qbasic_forever wrote: post #107

paulddraper wrote: post #63

Earlier quoted context omitted.

No-GIL mode is optional, and libraries will be marked "no-GIL compatible" and the ecosystem will gradually support more and more of these. No one's flipping a switch and breaking mountains of sketchy C.

That's the exact attitude that lead to decades of pain with the 2 to 3 transition and libraries though. There was zero plan for how to help libraries migrate from python 2 to 3, or more importantly how does one library support _both_ python 2 and 3 from one codebase as their users take time to switch their python interpretor. The attitude of "just turn off GIL if you don't need it, just use libraries that support tur…

> how does one library support _both_ python 2 and 3 from one codebase

How does one library support both GIL and no-GIL?

Easy, it supports no-GIL, so it supports both. Done.

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

#128

Post by MarkMarine » Sat, Jul 29, 2023, 1:53 AM UTC

qbasic_forever wrote: post #107

paulddraper wrote: post #63

Earlier quoted context omitted.

No-GIL mode is optional, and libraries will be marked "no-GIL compatible" and the ecosystem will gradually support more and more of these. No one's flipping a switch and breaking mountains of sketchy C.

That's the exact attitude that lead to decades of pain with the 2 to 3 transition and libraries though. There was zero plan for how to help libraries migrate from python 2 to 3, or more importantly how does one library support _both_ python 2 and 3 from one codebase as their users take time to switch their python interpretor. The attitude of "just turn off GIL if you don't need it, just use libraries that support tur…

I’m no fan of Java, but in comparison with python, Java’s focus on extreme backwards compatibility and their ability to actually execute on this promise year after year stands in stark relief with how python has handled the same challenges. I have low confidence, despite their claims this won’t be python 4, that this will actually be executed well. Looking forward to having homebrew deliver python@3.25_GIL and python@3.25_no_GIL with each flipping package I install.

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

#129

Post by catnibbler » Sat, Jul 29, 2023, 1:53 AM UTC

Jabrov wrote: post #113

catnibbler wrote: post #112

Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stu…

As opposed to?

Keep the GIL and avoid the problems its removal will cause. Allow parts of your program to run in a separate namespace with explicit passing of objects. No sharing means no contention, so no overhead.

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

#130

Post by TX81Z » Sat, Jul 29, 2023, 1:53 AM UTC

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.