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

341–350 of 513 posts

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

#341

Post by 12_throw_away »

worik wrote: post #203

I am not a python programmer. What is the use case for this? Who needs it?

> I am not a python programmer

I _am_ a python programmer.

> What is the use case for this?

> Who needs it?

This can be answered with a simple user story:

As "THE PYTHON STEERING COUNCIL",

I want to "GET RID OF THE GIL",

so that "PEOPLE WILL STOP WHINGING ABOUT THE GIL."

To be fair, there's another group of people who stand to benefit. Namely, any python programmers who currently believe that "threads are an easy way to make my program go faster" will soon be the recipients of a valuable learning experience.

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

#342

Post by lozenge »

Dylan16807 wrote: post #334
lozenge wrote: post #331

Earlier quoted context omitted.

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…

> 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. It looks for a flag, if it doesn't see it then it turns the GIL on. Where is…

"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://docs.python.org/3/c-api/type.html#c.PyType_FromModul...

The stable ABI lets extensions create new Python types. 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.

> But you're just guessing that it's slower in GIL mode, aren't you?

There are new implementations with per-object locks of list.append, dict.__setitem__ etc. These are incredibly common operations in Python code. These inherently will be more complicated than the previous implementation, meaning more instructions and slower. So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower.

Now with a lot of work these can be optimised and the speed penalty reduced, but CPython goes on an annual release cycle. If the nogil code is held as a fork of the CPython repository without being merged in, until it reaches a performance goal, that brings other issues.

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

#343

Post by miraculixx »

fred123 wrote: post #236
miraculixx wrote: post #91

Earlier quoted context omitted.

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.

Do you think Meta (Instagram) are pushing GIL removal and Cinder for no reason? They clearly have that scale and still benefit from faster single machine performance

Yes they will benefit from this. Unfortunately most everyone else will suffer.

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

#344

Post by kzrdude »

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…

GIL blocks parallelism for ThreadPool.

But I have the same question as you have if we add another coming concurrency model: SubinterpreterThreadPool, which will be possible with the per-interpreter GIL in python 3.12 and later.

That's another new model that is already confirmed to be coming: interpreters (isolated from each other) in the same process, that can run with each their own GIL.

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

#345

Post by n2d4 »

asvitkine wrote: post #165
n2d4 wrote: post #25

Earlier quoted context omitted.

The GIL does very little to protect unexperienced users. It's still really easy to run into race conditions, for example, if your thread gets scheduled out in any multi-instruction operation (this is more common than you think [1]). In general, Python code still has to be thread-safe; you get the risks without the benefits. If you don't care about CPU performance, instead of threads you should go for an event-loop ap…

I don't think the blog you cite backs up your claim of "it's still really easy to run into race conditions". The author literally says: "This was actually pretty hard to discover. The first few experiments failed, because Python is pretty smart about when it runs each thread." But I think the main way the GIL protects inexperienced users is that its presence has the effect that Python code using the threading APIs is…

More precise wording would've been: "It's still really easy to write code that runs into race conditions". The race conditions are rare, but code that (rarely) causes them isn't.

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

#346

Post by miraculixx »

r0l1 wrote: post #325
csmpltn wrote: post #245

Earlier quoted context omitted.

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

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.

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

#347

Post by miraculixx »

12_throw_away wrote: post #341
worik wrote: post #203

I am not a python programmer. What is the use case for this? Who needs it?

> I am not a python programmer I _am_ a python programmer. > What is the use case for this? > Who needs it? This can be answered with a simple user story: As "THE PYTHON STEERING COUNCIL", I want to "GET RID OF THE GIL", so that "PEOPLE WILL STOP WHINGING ABOUT THE GIL." To be fair, there's another group of people who stand to benefit. Namely, any python programmers who currently believe that "threads are an easy way…

Nice!

;)

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

#349

Post by baq »

MarkMarine wrote: post #151
kelipso wrote: post #146

Earlier quoted context omitted.

Lol the correct statement is it will get really ugly. Pretty much no question it will be a bigger mess than 2 to 3 transition. Here's hoping my subfield will move to a different language in the meanwhile because I don't want to deal with this shit again.

All your hopes of GIL free code ruined by a GIL requiring left pad dep buried deep in the dependency tree.

Fortunately Python’s package management is so horrible left pad is not a problem.

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

#350

Post by Dylan16807 »

lozenge wrote: post #342
Dylan16807 wrote: post #334

Earlier quoted context omitted.

> 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. It looks for a flag, if it doesn't see it then it turns the GIL on. Where is…

"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.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower.

I don't know about that. CPUs handle always-taken and never-taken branches very well.

Post reply on HN