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

461–470 of 513 posts

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

#461

Post by geekraver »

n2d4 wrote: post #66
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…

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…

A free-threaded Python will be harder to make faster for single-threaded cases. So this could be a win for those who want to write multi-threaded code at the expense of everyone else.

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

#462

Post by erinaceousjones »

cutler wrote: post #455
oars wrote: post #399

Earlier quoted context omitted.

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…

I never really understood Meta/Facebook's practice of relying on scripting languages. Ok, replacing PHP might not have been an option given the accelerated growth of Facebook but Python was only used for tooling originally, as I understand. If they needed threading and performance so badly why didn't they go for a compilted, statically-typed language?

Sunk cost / laziness - I remember when Facebook wrote their own JIT VM to run PHP on top of (HHVM?) to speed up all that PHP code.

Probably was easier to have one crack team of software developers write something new which could interpret all of the existing codebase, than it was to lead a widespread conversion of all of that code into faster languages.

ie. not everyone's a senior dev. There's reams more junior devs coming from bootcamps and such, computer science grads, etc, who can grok "scripting" languages like python and JS and Java much easier than they can pick up C++SIGSEGV or Rust algebraic data type smart pointer closure trait object macros.

Think how much of the world is boring "business logic" and it makes more sense - focus efforts making the [on the surface] simple, widespread, generalist, scripting languages, faster - we've seen it with Python, we've seen it with JS (node), we've seen it with Java.

Given how big the slow languages are, it makes lots of sense to save their CPU cycles compared to trying to hire from a much smaller pool of "competent at lower level programming" devs.

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

#463

Post by erinaceousjones »

School-Cotton wrote: post #405
oars wrote: post #399

Earlier quoted context omitted.

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?

Ugh, don't - we're convincing the legions of data scientists to move _away_ from the specialist languages (Matlab, R), because at least in Python, the code they publish with their papers is more repeatable/reproducible/reusable, and is a free language [that doesn't require a license server and/or paid plugins], and then we can plug their Torch model / numpy based computer vision algorithm into a Celery worker or a Flask endpoint :-)

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

#464

Post by aflag »

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…

When you create a new process you can't share things like network connections. Also, IPC tends to be very slow. It is abstracted away nicely in python, but it's still very slow, making some parallelism opportunities impossible to exploit.

For creating stateless, mostly IO bound, servers, it's great. Try to squeeze in performance and it all starts to fall apart.

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

#465

Post by imtringued »

qbasic_forever wrote: post #157
wokwokwok wrote: post #153

Earlier quoted context omitted.

You can down vote this til the cows come home but it’s historically what happened. This “that’s not how it went” stuff going down is quite just blatant historical revisionism. Maybe it’s a good idea? Maybe it’s not? …but anyone down voting “this reminds me of the Python 2/3” fiasco has no idea what they’re talking about.

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…

> every call into a library is now doing its own little bespoke GIL instead of relying on python's global one like now.

Is this some kind of joke? Do we live in clown world now? You do realize that a lock is a trivial primitive in multi threading?

The concept of a "little bespoke GIL" is ridiculous. A lock is a lock. Sure, an extension could just put a global lock on every extension call and then you do end up with an extension wide lock but every other extension remains unaffected. There is no intelligence or genius behind putting a global lock in the interpreter that somehow gets ruined by putting the lock in the extension. In fact, GIL is the dumbest decision you could make and everything from that point on can only get better, not worse.

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

#466

Post by imtringued »

qbasic_forever wrote: post #154
xmonkee wrote: post #148

Earlier quoted context omitted.

no-GIL libs will work with the GIL on surely? So you won’t have to support both?

Where will you get no-GIL libraries, especially in the early days? Just yell at the maintainers of core libs like flask and requests until they use their volunteer and spare time to implement incredibly complex and tricky locking semantics all over their codebases, AND test it all with both GIL and non-GIL interpretors at scale to suss out race conditions? That just happens for free and overnight because a lot of peo…

What exactly am I reading here? Requests and flask are both 100% python libraries. Do you take pleasure in trolling people?

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

#467

Post by imtringued »

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.

Come on, think about it harder. Do you really think this would even have a chance of becoming a PEP if python code was affected? If you thought even a little bit about it, then you would have come to the very simple conclusion "no" but here we are.

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

#468

Post by cutler »

erinaceousjones wrote: post #462
cutler wrote: post #455

Earlier quoted context omitted.

I never really understood Meta/Facebook's practice of relying on scripting languages. Ok, replacing PHP might not have been an option given the accelerated growth of Facebook but Python was only used for tooling originally, as I understand. If they needed threading and performance so badly why didn't they go for a compilted, statically-typed language?

Sunk cost / laziness - I remember when Facebook wrote their own JIT VM to run PHP on top of (HHVM?) to speed up all that PHP code. Probably was easier to have one crack team of software developers write something new which could interpret all of the existing codebase, than it was to lead a widespread conversion of all of that code into faster languages. ie. not everyone's a senior dev. There's reams more junior devs…

Java isn't a scripting language. I don't get your point about junior devs either as FAANG companies such as Facebook can pick and choose from the highest caliber developers.

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

#469

Post by imtringued »

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 am not using luajit for various reasons but the problem with the regular Lua interpreter is that the lua ffi backport from luajit is not included by default and the third party ones are broken on ARM.

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

#470

Post by imtringued »

winter_blue wrote: post #102
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 wonder why so many library developers even chose to build native libraries on the shaky and poorly-architected foundation that Python is. Even writing a JVM native JNI library would have allowed to avoid a lot of that pain (and the library would have been useable from Clojure, Kotlin , Scala, JRuby[1], Jython[2], Java, etc) without any painful threading issues. [1] which I’m aware of having been used in production…

Actually, Java virtual threads have a similar problem with JNI. Your virtual thread gets pinned to a core if you call native code. This isn't as bad as the python GIL but it still limits the usefulness of virtual threads if they can't migrate to other cores.
Post reply on HN