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

371–380 of 513 posts

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

#371

Post by lozenge »

Dylan16807 wrote: post #350
lozenge wrote: post #342

Earlier quoted context omitted.

"Where is the need for recompilation?" https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_r... The stable ABI lets extensions access the reference count of any object directly. I don't know why. Normally the functions Py_IncRef and Py_DecRef should be sufficient. Objects no longer have a single number as their reference count. Edit: In Python 3.2-3.9, the stable ABI included Py_INCREF, the C macro. https://do…

> Objects no longer have a single number as their reference count. Does that stay true once the GIL turns back on? > These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1. I'm not following why this affects ABI compatibility, sorry. > So there needs to be a branch at the start of list.appe…

> Does that stay true once the GIL turns back on?

In the current nogil implementation, AFAICS, it seems the GIL can't be turned back on so there is no answer yet.

Theoretically, you could have a one-off operation which fixes all objects when the GIL is turned on. However, there's no way to get all objects in Python. gc.get_objects() only returns tracked objects, and there is no way to list untracked objects.

It seems, three fields are exposed on every CPython object in the stable ABI, any change which affects their offsets will break the stable ABI. https://github.com/capi-workgroup/problems/issues/4#issuecom...

> I'm not following why this affects ABI compatibility, sorry.

True, PyType_FromSpec can set tp_alloc to a wrapper function which papers over the difference in what the "allocfunc" should initialise the memory to.

Re performance - merging the change is the only way people will actually start targeting nogil.

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

#372

Post by samus »

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.

Most of them don't contain C extensions.

> Whom exactly is going to update those?

Its developers of course. Many are presumably watching PEP-703, others will require lobbying by their users. But there is no rush to do so because...

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

> Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode?

... the interpreter will indeed fall back to enable the GIL if an extension is loaded that doesn't declare support of the no-GIL mode. Additionally, some extensions are actually safe to use without GIL as long as their Python APIs prevent concurrent access to them and thus act like the GIL themselves. In these cases, the interpreter can be forced to run without the GIL.

Isolating the C extension to another process is another possibility to reduce the impact on applications where all others can already run without the GIL. Actually, multiprocessing is already a common approach in the Python ecosystem for concurrent and parallel processing.

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

#374

Post by Arbortheus »

tgv wrote: post #284
JonChesterfield wrote: post #249

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

I think you're right. Making it an explicit opt-out, as is planned for the first stage, should be fine. Expecting to make it opt-in in 5 years seems too optimistic to me. It relies on all the library developers to fix their libraries (also the Python ones). That's tough work, and importantly, if done well, it will even go unappreciated: nobody will notice it. Many libraries have never had a multi-processing use case,…

Surely if it goes well people will see their existing python codebases become more performant with no development required aside from updating some dependencies? Not nobody will notice it.

It seems like it could be a great outcome for developers.

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

#375

Post by usrbinbash »

miraculixx wrote: post #79
Galanwe wrote: post #57

Earlier quoted context omitted.

I don't quite get your "unpopular opinion". First, I don't see how the GIL would have much to do with free multithreading. The GIL should not have much observable logical impact on multithreaded _Python_ code. It should not make it more or less susceptible to race conditions. It's only practical impact should be slowness. Second, your proposed "one GIL per thread" is pretty much the equivalent of the current state of…

Yes, used for decades - and for good reason and benefit. No, no the same thing. Sharing objects between processes is not easily achieved for various reasons (at least in Python). It would be easier to get it in multithreading with an arena based allocation model where objects live in a shared or non-shared area of memory. Also it's not my idea. I am just advocating it as the better model for Python to advance to. It…

> It would be easier to get it in multithreading with an arena based allocation model where objects live in a shared or non-shared area of memory.

That still relies on IPC, and the associated kernel overhead to set, ctl and access the shared memory, IN ADDITION to the kernel overhead of having to do a context switch between processes.

Threads only rely on the context switch.

> I am just advocating it as the better model for Python to advance to

https://discuss.python.org/t/poll-feedback-to-the-sc-on-maki...

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

#376

Post by r0l1 »

miraculixx wrote: post #346
r0l1 wrote: post #325

Earlier quoted context omitted.

https://peps.python.org/pep-0703/ Quote: "In PyTorch, Python is commonly used to orchestrate ~8 GPUs and ~64 CPU threads, growing to 4k GPUs and 32k CPU threads for big models. While the heavy lifting is done outside of Python, the speed of GPUs makes even just the orchestration in Python not scalable. We often end up with 72 processes in place of one because of the GIL. Logging, debugging, and performance tuning are…

This requirement could have been well served with a gil per thread and arena based (shared) object allocation model. Every other use case would have been unaffected. Now we change the world for everyone and put most of library developers through a valley of desperation for 5 years+, just so that a very few narrow use cases get the benefits they want. Not a smart move IMHO.

Good point. Did the Meta and Deepmind devs really miss this?

I try to avoid python as much as possible, because I mainly work with Go & C++ and multi-threading with those languages is just better (imho). Bringing python a step forward and making it future proof might be a good thing... Even if this means to break some things? Not sure if dismissing the GIL is the right step, but there is a big performance gap to fix. Or maybe the AI community must move to a better suited language? Having python code in production just feels so wrong. Especially if a rewrite in another language shows the performance gap.

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

#377

Post by samus »

qbasic_forever wrote: post #323
kzrdude wrote: post #252

Earlier quoted context omitted.

Flask is pure python, isn't it?

Even pure python code could have race conditions with the GIL disabled. Stuff like accessing and modifying a dictionary item in python code is assumed and currently guaranteed to be atomic because of the GIL. Remove the GIL and decades of assumptions break.

The GIL doesn't serialize the execution of threads, but ensures only one executes at a time. Therefore, the race condition issues you describe already exist even with the GIL. The GIL is only there to ensure that the interpreter doesn't corrupt Python objects and its internal data structures, which in the best case leads to a crash.

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

#378

Post by andybak »

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.

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

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

#379

Post by formerly_proven »

lozenge wrote: post #331
Dylan16807 wrote: post #311

Earlier quoted context omitted.

> However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution Yes, that's what they were asking about. Why have two versions for a mode switch. Everything you explained before that is irrelevant, I'm afraid. > but I'm expecting this to be slower than running the gil build in GIL mode. That could be the answer to their qu…

1. The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation. 2. There are a lot of users that want fast Python and a lot of effort was p…

I'm not sure if the stable ABI is really like... going to stick around. Python 3.11 deprecated numerous functions in it mostly around interpreter configuration (the new PyConfig and PyPreConfig APIs are by definition not ABI stable), and the last couple releases have shown that deprecations in Python do mean it'll be removed later. The question then is whether they'll drop these APIs with a 3.x release (which would break the entire preomise of the stable ABI) or during a bump to 4.x. It really ought to be the latter and I suspect Python 4.x is going to remove the entire notion of stable ABI.

In either case it seems obvious now that there is likely no point bothering with the stable ABI any more.

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

#380

Post by samus »

HoppyHaus wrote: post #198
mikepurvis wrote: post #195

Earlier quoted context omitted.

Coming from a place of total ignorance, it would be nice if you could do this more incrementally, like have it be in no-gil mode by default, but then have a context manager you can use for gil sections, and have the interpreter bomb out if you try to enter gil-required code while still in no-gil mode.

The issue is when someone's unattended-upgrades bumps up the version and causes something to come crashing down. The people who need to use nogil should know that they need to, and will now have the ability to enable it

Almost more importantly, it is also possible to force the GIL to remain on with `PYTHONGIL=1`
Post reply on HN