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

91–100 of 513 posts

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

#91

Post by miraculixx »

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

I kept making this point as well as the other arguments above (and others did too) in the Core Dev discussion group. Unfortuately to no avail. To be sure I am not a core dev.

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

#92

Post by [deleted] »

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…

[deleted]

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

#93

Post by qbasic_forever »

Alifatisk wrote: post #21

No-GIL means better performance at the cost of being less beginner-friendly, right?

It's only more performance if you're using the threading primitives and spawning new threads, moving work to them to do in parallel, etc.--this isn't something any beginner will consciously be doing. It might actually be slower in regular single process use that 99% of python users use (since the GIL is there for a very good reason and synchronizing access to python's internal state doesn't just happen for free or without some cost somewhere).

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

#94

Post by n2d4 »

slt2021 wrote: post #73
n2d4 wrote: post #66

Earlier quoted context omitted.

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 implemen…

I would argue that if you have large concurrency and shared complex state - you better off use kafka and redis/memcached as a shared state - and design proper fan-out. This design scales much better for systems that will eventually overgrow one big machine. the No-GIL pytohn will be of no use, when you need to deploy your app across 100s machines. I understand people want to take advantage of all cores etc, but at la…

Stores like that, while scaling well, are orders of magnitudes slower than CPU memory. The kind of application I was thinking of is more compute-intensive, eg. image processing or fancy algorithms.

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

#95

Post by AlphaSite »

slt2021 wrote: post #60
KMnO4 wrote: post #32

Earlier quoted context omitted.

GIL is a promise from the internal implementation (eg CPython) of Python that things will happen atomically within the Python interpreter. This means that when multiple threads try to access and modify Python objects at the same time, the GIL ensures that only one thread can execute Python bytecode at any given moment, preventing potential conflicts and ensuring data integrity. However, this comes at the cost of limi…

But people are not doing cpu bound tasks in native python (performance is a joke), it all comes down to calling a C library that is optimized for compute - what will be the change that GIL brings here?

There is a JIT being built for Python, so performance is being attacked from 2 avenues, single threaded and multithreaded.

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

#96

Post by bjourne »

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). However, that is extremely unlikely and much C extension code is not written with such situations in mind.

People using C extensions may also rely on them executing atomically. For example, you could have a thread pool that posts and receives from a numpy array. Would work fine today but break without the GIL.

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

#97

Post by miraculixx »

pama wrote: post #87
miraculixx wrote: post #65

Earlier quoted context omitted.

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

Agreed. Feeding the GPUs with multiple forked memory-hogging processes is no fun and leads to annoying hacks. And, yes, as per your other post, there could have been other solutions to this problem, some of which might have been better.

Yes but that's a very particular use case that could have been well served with a per gil thread and arena based memory for explicitely shared objects.

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

#98

Post by spamizbad »

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…

This probably isn't going to be that groundbreaking for your average web application. But for several of the niches where Python has a large footprint (AI, Data Science), being able to spin up a pile of cpu/gpu-bound threads and let them rip is a huge boon.

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

#99

Post by Phil_Latio »

miraculixx wrote: post #59
Phil_Latio wrote: post #48

Earlier quoted context omitted.

> sane multithreading It's simply not "sane multithreading" not being able to run Python (byte)code concurrently. It's just a huge annoyance. > because it might lose its beginner friendlyness Python is not beginner friendly. It has one of the worst documentations out there. Also it does things very different compared to other languages (C#, PHP, Java, JS, ...) - I would advise anyone against learning Python as their…

> 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 library dev is free not support one or the other? If a library then does not provide the preferred mode of the user, then that's bad, but that's life. Ideally most libraries will support a gil version (that's still the default anyway!), but provide a no-gil version as a bonus. For example, Pytorch could provide thread-based data loaders if the no-gil version is in use.

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

#100

Post by miraculixx »

qbasic_forever wrote: post #88
jmount wrote: post #46

Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.

Yep I think over the next year a lot of python devs are going to learn threading isn't magic pixie dust that makes your code fast, and in reality is starts by making your code very unstable.

I'm afraid that's exactly what will happen. Unfortunately the overarching sentiment will not be "multithreading is hard" but "Python has become really hard to work with"
Post reply on HN