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

401–410 of 513 posts

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

#401

Post by School-Cotton »

TylerE wrote: post #168
qbasic_forever wrote: post #137

Earlier quoted context omitted.

Yep, and you'll have pip3-gil and pip3-nogil binaries because each permutation of python has separate and incompatible site-packages folders and libraries. It could get really ugly.

Is the situation in rust, where the answer is apparently to vendor the world, much better? Don't many of the big rust libraries still depend on nightly, too?

> Don't many of the big rust libraries still depend on nightly, too?

No, none of them do, or at least none that I’ve ever seen in 4 years of doing rust full-time.

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

#402

Post by zrball10 »

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 have a hard time seeing the equivalence here. In C the interaction with non thread safe functions is much more direct. Most people are also more cautious when writing in C.

In Python you have whole C modules with global state. Load 10 of them, add the interpreter complexity and soon enough no one knows what is going on any more.

As it is, most developers (including core devs!) don't even bother to check for memory leaks. I don't think they'll run tsan, and if they do, it will be on a small test suite that only covers 10% of the code.

Given the software development practices in Python and especially in the AI space, I'm very pessimistic about this feature.

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

#403

Post by Too »

nologic01 wrote: post #192
kalb_almas wrote: post #145

Even with improved support for parallelism, what role will Python have in the future if Mojo makes good on even half of its promises?

Mojo is not Python. The underlying pressure on the Python ecosystem is to transition to a post-Moore's law era and effectively become a HPC platform where the "same" code runs on a CPU, a GPU, multicore, clusters etc. Python may feel the pressure more than others because of the GIL and the fact it is used in compute intensive tasks more than others. But this major need to transition to easy and seamless HPC/heterogen…

Mojo is a superset of python, with goal to be able to run any python code and to import any python module under its own execution model, that runs magnitudes faster. Now, if that actually works as advertised, it would render python obsolete and become mojo instead, even if the authors don’t put it that way.

Lex Fridmans podcast had an interview with one of the creators recently. Chris Lattner, who is also the creator of LLVM and Swift. Recommended listen for those who haven’t heard of mojo yet, if you have 3h to spare.

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

#404

Post by School-Cotton »

usrbinbash wrote: post #317
miraculixx wrote: post #307

Earlier quoted context omitted.

> They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python Where is this demand exactly? We hear a lot of complaining but very often this is due to a lack of awareness of available (& often better) alternatives to threading. There is a very small number of use cases that will benefit from free threading.

> Where is this demand exactly? The motivation summary of PEP-703 contains some material on this: https://peps.python.org/pep-0703/#motivation Further discussions going back years can be found with a brief search. This discussion is almost as old as Python3. > due to a lack of awareness of available (& often better) alternatives to threading. Such as? There are exactly 2: asyncio, which is useless for CPU/GPU bound w…

> Use another language

Right, because the whole point of Python is as a glue language for native libraries. Adding multi threading to Python is like adding to to Bash.

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

#405

Post by School-Cotton »

oars wrote: post #399
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…

From PEP 703: > Manuel Kroiss, software engineer at DeepMind on the reinforcement learning team, describes how the bottlenecks posed by the GIL lead to rewriting Python codebases in C++, making the code less accessible: > "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…

So Python is being fundamentally changed for everyone because of the needs of a niche subset of Python programmers (AI researchers), because that niche subset refuses to learn a language more suited to their task?

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

#406

Post by School-Cotton »

raminf wrote: post #152

Remember the transition of text to Unicode? 32 to 64-bit? Intel to ARM? Y2K? No-GIL is a much smaller shift. It can follow the same transition path without radically breaking things. And if some things do break, there would be a well-defined way to handle those cases. We all somehow survived those. Glad to see forward motion on this. It will open up a lot more terrain that has been marked off as untenable. One of the…

I’m not worried about the difficulty of migration; I’m worried that the end state might actually be worse than what we have now.

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

#407

Post by t-vi »

andybak wrote: post #378
yellowapple wrote: post #216

Earlier quoted context omitted.

Or it could motivate total abandonment of system-level Python installations in favor of per-app virtualenvs or whatever the new hotness is, and we'll finally achieve world peace.

When I learned Python decades or so ago virtualenvs were standard practice. Who is using system level Python for anything non-trivial?

I use Debian's system Python 3.10 install for most of my stuff and it works really well for me. Some things I install via pip but the key libraries (e.g. PyTorch) from source.

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

#408

Post by chx »

samus wrote: post #386
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…

PEP-703 contains a whore Motivation section. Long enough to require a summary: > Python’s global interpreter lock makes it difficult to use modern multi-core CPUs efficiently for many scientific and numeric computing applications. Heinrich Kuttler, Manuel Kroiss, and Paweł Jurgielewicz found that multi-threaded implementations in Python did not scale well for their tasks and that using multiple processes was not a su…

Your comment has been nominated for the best typo in 2023.

Let's hope the change is not this badly mercenary.

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

#409

Post by pritambaral »

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…

> Pypi has what, 500k projects on it? Many abandoned.

> Whom exactly is going to update those?

> once all the hard work is done by the community.

If I want to use Python with parallel threads in the app I'm building, I don't need to wait for every last one of those 500k packages. I can wait for only the packages I'm using, or risk it and force Python to run in nogil mode anyway. It's my choice.

> Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it?

As other comments say in this thread: yes.

> Does that remind you of anything?

> Mmm.

2-to-3 burned you. We get it. You might be getting flashbacks to that nightmare. That is understandable. But you need to look beyond a surface level similarity — "That was a transition. This is a transition. They're identical!" — and at the actual transition itself. The problems of 2-to-3 aren't present here. The user is not forced to choose between two incompatible options. Library authors aren't forced to migrate their code forward. Users and library authors do not need to collectively choose one version over another. The newer version remains compatible with older code. The sky is not falling.

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

#410

Post by csmpltn »

usrbinbash wrote: post #367
csmpltn wrote: post #324

Earlier quoted context omitted.

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

> The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. I also don't need to use goroutines. I could simply spin up my golang application as a couple of processes, and use pipes and other IPC to coordinate them. "There is another way to do X" doesn't imply that other way is better.

> "doesn't imply that other way is better"

I never said that multiprocessing is "better" than multithreading.

Both are mechanisms to achieve parallelism with different pros/cons, and there are legit cases where threads are a necessity that can't be satisfied with processes (ref my previous comment with examples). This conversation would've been much easier to have given specific constraints and examples (which nobody seems to give).

Within the context of a general purpose VM which was never built to support multithreading (CPython), and which carries the baggage of 30+ years' worth of 3rd-party packages and libraries which were never built with multithreading in-mind - I think we can both agree that the costs and risks of changing literally everything may outweigh the benefits. It's not a difficult stance to accept.

My main argument, if you distill it down to the abstract, is "use the right tool for the job" - and stop pretending that a hammer and a knife are the same thing, when they're not.

If you need hardcore, ultra efficient and parallelized workflows - Python is just the wrong tool for the job period. This isn't up for debate - it's a given fact. This isn't just about the GIL - it's about the type system, the frameworks, the bloat, etc. There's nothing wrong with Python being this way - Python fills a niche of its own incredibly well, something which others tools suck at, and Python is loved by millions for it.

Python is used today by certain demographics to perform certain jobs - and it excels really well at those jobs for those demographics. This whole discussion now (GIL vs. no GIL) is about bending and twisting Python to fit the use cases of few companies like DeepMind or Facebook - who I'm certain represent a miniscule usage compared to the millions of students, schools and universities, research institutes, web shops, hobbyists, tinkerers, etc. Those people want to get shit done quickly - and mutexes, sempahores, events, threads, synchronization primitives, atomics, etc - will do nothing but make their lives a misery, and drive them away.

Also, I keep asking you for concrete examples where the Python community absolutely needs multithreading (where multiprocessing fails) and you're not really responding which makes me feel like we're not conversing here...

Post reply on HN