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

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

#61

Post by neilv » Sat, Jul 29, 2023, 12:49 AM UTC

ggm wrote: post #33

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers…

I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed.

Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice features that were easier to use than C++, and I "knew" it was going to be huge. (But who knew that the MIS people would take over Java, when it seemed clearly targeted at non-MIS programmers, and now MIS people are stuck with the C++ syntax and verbosity, after coming from 4GLs, etc.)

Then mainstream programmers picked up Python, which, IIRC, originally was an embeddable extension language, which was why it was simple. And for which the GIL made more sense.

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

#62

Post by dragonwriter » Sat, Jul 29, 2023, 12:51 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…

> is there any use case of No-GIL which is not solved by multiprocessing ?

Anything that benefits from both parallelism and replacing IPC overhead with shared data between parallel tasks.

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

#63

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

ggm wrote: post #33

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers…

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.

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

#64

Post by Galanwe » Sat, Jul 29, 2023, 12:51 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…

Not sure why this is downvoted, I never had much issues with the GIL as well.

Multiprocessing does the parallel computation pretty well as long as the granularity is not too small. When smaller chunks are needed most of the time that's something better done from an extension.

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

#65

Post by miraculixx » Sat, Jul 29, 2023, 12:54 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…

Some of the use cases advocating for nogil come from the AI/ML group of library builders, stating a need for free threading concurrency.

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

#66

Post by n2d4 » Sat, Jul 29, 2023, 12:54 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…

It's only about performance. asyncio is still inherently single-threaded, and hence also single core. multiprocessing is multi-core and hence better for performance, but each process is relatively heavy and there's additional overhead to shared memory. GIL multi-threading is both single-core and difficult to use correctly.

No-GIL multi-threading is multi-core, though difficult to use. I don't know the Python implementation but shared memory should be faster than using multiprocessing.

That said, when designing a system from scratch, I completely agree with you that for almost almost almost all Python use cases, threads should never be touched and asyncio/multiprocessing is the way to go instead. Most Python programs that need fast multi-threading instead should not have been written in Python. Still, we're here now and people did write CPU-intensive code in Python for one reason or another, so no-GIL is practical.

In these threads, I also always see a lot of people who simply aren't aware of asyncio/multiprocessing. I assume these are also a significant share of people asking for no-GIL, though probably not the ones pushing the change in the committee.

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

#67

Post by slt2021 » Sat, Jul 29, 2023, 12:55 AM UTC

dragonwriter wrote: post #62

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…

> is there any use case of No-GIL which is not solved by multiprocessing ? Anything that benefits from both parallelism and replacing IPC overhead with shared data between parallel tasks.

but it would incur overhead of concurrency control: mutex, locks, semaphores.

I dont believe python will ever have atomic operations, even if it had - they still incur significant overhead for concurrency control.

sharing state between threads is such a narow niche use case, this pattern is practically solved by memcached/redis for larger scale python based systems

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

#68

Post by lmm » Sat, Jul 29, 2023, 12:57 AM UTC

wtetzner wrote: post #38

dpedu wrote: post #36

Earlier quoted context omitted.

That's not quite true. For example, most operations on lists and dicts are thread-safe in the current version of python. You can't say that about languages with true multithreading.

Of course Java has thread safe collections in the standard library. ConcurrentHashMap etc. are popular in multithreaded contexts.

It does, but you have to opt into them.

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

#69

Post by Steltek » Sat, Jul 29, 2023, 12:57 AM UTC

paulddraper wrote: post #63

ggm wrote: post #33

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers…

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.

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

#70

Post by miraculixx » Sat, Jul 29, 2023, 12:57 AM UTC

paulddraper wrote: post #63

ggm wrote: post #33

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers…

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.

I hope you are right. I fear it will turn out rather painful (I have lived through 10 years of Java multithreading, I don't miss it)

* update: I have also lived through 10 years of Python 2-3. It was not pretty.