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

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

#241

Post by JonChesterfield » Sat, Jul 29, 2023, 7:04 AM UTC

yellowapple wrote: post #216

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.

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.

I can see system level python installs being abandoned. They seem to be getting progressively harder to use over time. I don't see the replacement being virtual env, it'll be a different language ecosystem. Whichever one looks like it has remembered "easy to do simple things in" is a feature.

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

#242

Post by JonChesterfield » Sat, Jul 29, 2023, 7:05 AM UTC

miraculixx wrote: post #115

qbasic_forever wrote: post #107

Earlier quoted context omitted.

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…

Indeed. The burden is 2x at least. They already estimate it's going to take 5+ years, so that's 10x the cost of a current library. At least. If the burden becomes too big, at some point people may find it is the easier option to switch to a different ecosystem. I hope not.

I hope it'll be lua. I fear it'll be javascript.

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

#243

Post by lraxny » Sat, Jul 29, 2023, 7:07 AM UTC

The ruling class in python-dev are populists who are not threading experts. Python is run by the wrong people.

They will approve something if it serves a corporation. The submission here is likely CYA, so they can say that "they asked the community".

There is no appreciation for people doing grassroots open source software. If Instagram can add another hack instead of switching to Java, it will be approved.

It is important to remember that paid corporate developers will have job security every time new pain is introduced in the Python ecosystem.

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

#244

Post by d0mine » Sat, Jul 29, 2023, 7:08 AM UTC

spamizbad wrote: post #98

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.

how likely, the corresponding code doesn't release GIL already? Pure Python is 100x slower than native code therefore the number crunching itself happens in C extensions where GIL can be released.

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

#245

Post by csmpltn » Sat, Jul 29, 2023, 7:08 AM UTC

r0l1 wrote: post #230

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.

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.

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

#246

Post by LegionMammal978 » Sat, Jul 29, 2023, 7:11 AM UTC

miraculixx wrote: post #218

smashed wrote: post #205

Earlier quoted context omitted.

As I understand it, as a library author you either do absolutely nothing and your library will be marked as requiring GIL by default. Nothing to do, you keep on working with that good old GIL and nothing changes. Or you make the extra effort of being thread safe and you can declare your library as not requiring the GIL. Now if a user script mixes your GIL free lib with an older lib that has not been updated, well, to…

Where can I read up on this planned way of working? This is not what the PEP says

It's in the "Py_mod_gil Slot" section [0] in the PEP:

> In --disable-gil builds, when loading an extension, CPython will check for a new PEP 489-style Py_mod_gil slot. If the slot is set to Py_mod_gil_not_used, then extension loading proceeds as normal. If the slot is not set, the interpreter pauses all threads and enables the GIL before continuing. Additionally, the interpreter will issue a visible warning naming the extension, that the GIL was enabled (and why) and the steps the user can take to override it.

[0] https://peps.python.org/pep-0703/#py-mod-gil-slot

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

#247

Post by hanselot » Sat, Jul 29, 2023, 7:12 AM UTC

KeplerBoy wrote: post #227

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…

Even with multithreading Python will still be slow. It's not like singlethreaded Python can keep up with singlethreaded C or even JS. This will just allow people to waste even more compute resources to get somewhat quick results from Python instead of doing the right thing. From an ecological viewpoint this PEP will be disastrous and keep entire power plants online.

Sometimes the right thing is writing code in a language that reaches market before runway runs out.

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

#248

Post by hanselot » Sat, Jul 29, 2023, 7:13 AM UTC

for self in selfs:

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

#249

Post by JonChesterfield » Sat, Jul 29, 2023, 7:14 AM UTC

Exciting. Python is mostly written as C shared libraries that knew they had a global lock to rely on.

Some of those do sufficiently simple things that they can run without any locking and all will be fine.

Others will still need locking, but are now under pressure to run without the gil. Some of those are going to do DIY locking within their own bounds.

Maybe what python has really been missing all these years is loads of ad hoc mutex calls scattered across the ecosystem. Data races and deadlocks introduced in the name of performance is not how I expected python to go out.

edit: expanding on this pessimism a bit.

Making C libraries written assuming a global lock thread safe is the sort of thing I'd expect concurrency experts to advise against and then make mistakes while implementing it. My working theory is that most people who wrote C extensions for python are not concurrency experts and are great programmers who won't back down from a challenge.

The data-race/hang/segfault consequences of this combination look totally inevitable to me. Python application developers are not going to love the new experience and I'm thankful my products are not built on top of the python ecosystem.

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

#250

Post by miraculixx » Sat, Jul 29, 2023, 7:15 AM UTC

uneekname wrote: post #183

miraculixx wrote: post #108

Earlier quoted context omitted.

In theory it's easy. In practice you need to design programs very carefully to leverage multiple threads. The same is true for multiple processes, yet that is much easier to reason about and a lot more likely to get it right.

> and a lot more likely to get it right I get that it's a hard problem, but it isn't a guessing game. Concurrency has always required one to carefully design their program. We will see how Python implements these new APIs, but I trust it will be approachable to those who want to do it.

It's not about the API. The multithreading API (in any language) is easy:

1. Start a thread 2. Give it work to do (data + code)

The problems start when multiple threads work on the same data and compete for the same system resources.

Agree, it's not a guessing game. But it is a huge state machine with unobvious hidden states. The cure are locks everywhere, and the magic is to find the least number and places of locks to still make it fast and correct, in any and all situations aka race conditions.

It's a much harder problem to reason about than most people realize.