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

291–300 of 513 posts

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

#291

Post by weinzierl »

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 remember these warnings as well from when I started programming C seriously in the 90s. When I first encountered them I was convinced these issues will be resolved in a matter of weeks, maybe a couple of month at worst. Ohh, so little did I know.

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

#292

Post by anyoneamous »

JonChesterfield wrote: post #242
miraculixx wrote: post #115

Earlier quoted context omitted.

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.

I hope it'll be Nim, I fear it'll be Julia.

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

#293

Post by weinzierl »

neilv wrote: post #61
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 remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice fea…

That Java had concurrency built in from the start is a blessing mostly, but also a bit of a curse. Most of the Java ecosystem is still in the mindset that threads are cheap and firing up a couple more cannot hurt. So we end up with apps that run thousands of threads and this disease is hard to contain.

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

#294

Post by usrbinbash »

n2d4 wrote: post #122
Jabrov wrote: post #113

Earlier quoted context omitted.

As opposed to?

In Python, asyncio and multiprocessing packages can get nearly the same or better performance for IO- and CPU-intensive tasks respectively as no-GIL multithreading (and are more performant than GIL multithreading), with only a tiny fraction of the pitfalls. For any use case where the last few percent matter, consider not using Python (which will be much much more significant). Regardless, we did somehow end up here,…

> asyncio

...is useless for CPU bound tasks. The event loop uses only one core.

> multiprocessing

...relies on IPC and running actual system processes, both of which have alot more overhead than switching thread context and using shared memory.

> For any use case where the last few percent matter, consider not using Python (which will be much much more significant).

Here is an interesting question: If asyncio and multiprocessing already give us "nearly the same or better performance", then why is "use another language" such a common advice to escape parallelism-problems in Python?

Because, curiously enough, the languages that are usually recommended for this (C, Go, Rust, C++, Java) all implement thread-based parallelism.

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

#295

Post by samsquire »

slt2021 wrote: post #67
dragonwriter wrote: post #62

Earlier quoted context omitted.

> is there any use case of No-GIL which is not solved by multiprocessing ? Anything that benefits from both parallelism and replacing IPC overhead with shared data between parallel tasks.

but it would incur overhead of concurrency control: mutex, locks, semaphores. I dont believe python will ever have atomic operations, even if it had - they still incur significant overhead for concurrency control. sharing state between threads is such a narow niche use case, this pattern is practically solved by memcached/redis for larger scale python based systems

Relying on Redis for data sharing between concurrent processes seems like a massive overhead to me. You've got network overhead as well as a single threaded data store.

I am thinking about multithreading every day to try make it easier to use. I journal about it in my ideas journals.

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

#296

Post by concordDance »

JonChesterfield wrote: post #242
miraculixx wrote: post #115

Earlier quoted context omitted.

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.

Lua? Really?

That's by far the most unpleasant language I've coded in.

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

#297

Post by csmpltn »

usrbinbash wrote: post #279
commonlisp94 wrote: post #53

Earlier quoted context omitted.

Exactly. I think a lot of the negativity about GIL comes from a misunderstanding about forking processes. If python is being used as a scripting language, and spawning other tools, you're already getting free multi-core. A similar misunderstanding exists about SQLite and concurrency.. but that's a topic for another time.

> you're already getting free multi-core. Please explain: In what sense is the overhead of starting actual OS processes, and relying on IPC "free", compared to running threads or even greenlets, and using shared process memory?

> In what sense is the overhead of starting actual OS processes, and relying on IPC "free"

With Python's current multiprocessing utilities - you get a big discount by not having to write thread-safe code, or worry about synchronization, despite the GIL still being there. Very broadly speaking, it's "free" in the sense that the OS handles parallelism automatically at the process-level, and provides a simple communication mechanism between those processes through standard APIs. It also reduces potential attack surfaces (although this is a lesser argument).

It's also "free" in the sense that you don't need to re-write large parts of the VM, as-well as all supported libraries, and teach the entire Python community how to safely write and test multi-threaded code (something I bet upwards of 75% of the people using Python today won't manage) to support this specific form of parallelism.

If your goal is to run code (whether IO bound or CPU bound) in parallel - Python has the means to do that already today, without removing the GIL.

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

#298

Post by rightbyte »

jborean93 wrote: post #254
a_nop wrote: post #104

Earlier quoted context omitted.

They kind of burned a breaking major version transition for no good reason with 2-to-3, now they are prefacing a major change with "it won't be like 2-to-3". It sounds like they may be maintaining two operating modes in CPython 3 instead of going forward with another major transition, just because of that history.

> They kind of burned a breaking major version transition for no good reason with 2-to-3 The unicode/text changes alone were a pretty good reason. Division producing floats are also a nice change IMO. I don’t want to discount the challenges with the transition but saying there was no good reason isn’t right to me.

Not good enough reason then?

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

#299

Post by asah »

geewee wrote: post #228
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 mean going from text to unicode did pose a huge problem for python specifically.

I have PTSD from that transition.

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

#300

Post by lozenge »

miraculixx wrote: post #263
LegionMammal978 wrote: post #246

Earlier quoted context omitted.

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

Here's what's puzzling me about this: Why then is there even a need for a seperate nogil build? If it is like this says, wouldn't it be easier to just make the standard build switch to gil or nogil automatically (or honor the users choice). The fact that the SC thinks having two versions suggests there is more complexity involved than this section of the PEP leads readers to believe.

You have to recompile your C extensions for the nogil build. Consider an application where one thread is calling xs.append from a C extension and another is calling xs.pop and xs[-1] on the same list object xs. In the nogil build these operations need to use a fine-grained lock on xs, and in the gil build these are thread-safe due to each thread holding the GIL when it does these operations.

On top of that, some of the list and dictionary operations are available to extensions as C macros to avoid the overhead of a C function call.

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, but I'm expecting this to be slower than running the gil build in GIL mode.

Post reply on HN