Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gh-116167: Allow disabling the GIL

github.com

Post reply on HN
Print view View original

131–140 of 259 posts

Re: gh-116167: Allow disabling the GIL

#131

Post by logicchains »

actionfromafar wrote: post #71
kjqgqkejbfefn wrote: post #58

Earlier quoted context omitted.

>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 than 10 threads the GIL becomes the bottleneck. To work around this problem, we sometimes use subprocesses, but in many cases the inter-process communication becomes too big of an overhead. To deal with the GIL, we usuall…

Maybe they should look in to translating parts of their code base to Shedskin Python. It compiles (a subset of) Python to C++.

How's it different from Cython, which compiles a subset of Python to C or C++?

Re: gh-116167: Allow disabling the GIL

#132

Post by amethyst »

bmitc wrote: post #128
bb88 wrote: post #99

Earlier quoted context omitted.

Working with threads is a pain regardless of which language you use. Some might say: "Use Go!" Alas: https://songlh.github.io/paper/go-study.pdf After a couple decades of coding, I can say that threading is better if it's tightly controlled, limited to usages of tight parallelism of an algorithm. Where it doesn't work is in a generic worker pool where you need to put mutex locks around everything -- and then prod ran…

> Working with threads is a pain regardless of which language you use. That's not true at all. F#, Elixir, Erlang, LabVIEW, and several other languages make it very easy . Python makes it incredibly tough.

> Python makes it incredibly tough.

I disagree, Python makes it incredibly easy to work with threads in many different ways. It just doesn't make threads faster.

Re: gh-116167: Allow disabling the GIL

#133

Post by nerpderp82 »

KerrAvon wrote: post #122
nerpderp82 wrote: post #97

Earlier quoted context omitted.

Mojo should be viewed as an attack on the Python ecosystem due to it being a superset. It can consume Python, but it itself is not Python. Taichi is really underrated, it works across all platforms (including Metal), has tons of examples and the code is easy to write. And lastly, it integrates with the ecosystem and doesn't displace it. https://github.com/taichi-dev great demo reel of what Taichi can do, https://www.…

I think "attack" is a bit much; C++ isn't an attack on C.

I didn't mention C++ at all. Was that my argument? This thread is about Python, the GIL. Mojo was brought up as a way to speed up Python code.

C++ predates on C in a similar way to how Mojo predates on Python. At least C++ has extern C.

https://docs.modular.com/mojo/manual/python/#call-mojo-from-...

> As shown above, you can call out to Python modules from Mojo. However, there's currently no way to do the reverse—import Mojo modules from Python or call Mojo functions from Python.

One way street. Classic commons harvesting.

Re: gh-116167: Allow disabling the GIL

#134

Post by rmbyrro »

amethyst wrote: post #132
bmitc wrote: post #128

Earlier quoted context omitted.

> Working with threads is a pain regardless of which language you use. That's not true at all. F#, Elixir, Erlang, LabVIEW, and several other languages make it very easy . Python makes it incredibly tough.

> Python makes it incredibly tough. I disagree, Python makes it incredibly easy to work with threads in many different ways. It just doesn't make threads faster .

The whole purpose of threads is to improve overall speed of execution. Unless you're working with a very small number of threads (single digits), that's a very hard to achieve goal in Python. I wouldn't count this as easy to use. It's easy to program, yes, but not easy to get working with reasonably acceptable performance.

Re: gh-116167: Allow disabling the GIL

#135

Post by spprashant »

behnamoh wrote: post #25

I've been programming in Python for over 6 years now and every week I learn something new. But recently I've been thinking about moving to a more capable language with proper concurrency for backend API requests (FastAPI sucked). I also want types, so Elixir is not in the picture. I dabbled in Rust a bit. Although I was able to get the hang of things and build a CLI tool pretty quickly, I'm worried I'll have to deal…

As someone in a similar boat, just pick Golang. People often dislike the basic syntax, explicit error checking and the lack of algebraic data types. I did. Rust just seems like it offers so much more and you fear missing out on something really cool.

But once you get over it, you realize Golang has a good type system, concurrency model, package manager that's not pip, fast compile times, and static binaries. For most cases it will also offer great performance.

It has everything you need to build APIs, CLI tools, web servers, microservices - pieces which will form the building blocks of your software infrastructure. I have heard numerous stories of people being productive in Go in a few days, sometimes even hours.

If Python is 0 quality of life and Rust is a 100, Golang gets you all they way up to 80-90. That last bit is something you might never need.

Rust is a great language and something I hope to be in proficient someday, but I ll save it for where I actually need that last microsecond of performance.

Re: gh-116167: Allow disabling the GIL

#136

Post by rmbyrro »

bb88 wrote: post #99
rmbyrro wrote: post #72

Earlier quoted context omitted.

Although true, it doesn't mean they can't improve its performance. Working with threads is a pain in Python. If you want to spawn +10-20 threads in a process, it can quickly become way slower than running a single thread. Removing the GIL and refactoring some of the core will unlock levels of concurrency that are currently not feasible with Python. And that's a great deal, in my opinion. Well worth the trouble they'r…

Working with threads is a pain regardless of which language you use. Some might say: "Use Go!" Alas: https://songlh.github.io/paper/go-study.pdf After a couple decades of coding, I can say that threading is better if it's tightly controlled, limited to usages of tight parallelism of an algorithm. Where it doesn't work is in a generic worker pool where you need to put mutex locks around everything -- and then prod ran…

It's not such a big pain in every language. And certainly not as hard to get working with acceptable performance in many languages.

Even if you have zero shared resources, zero mutexes, no communication whatsoever between threads, it's a huge pain in Python if you need +10-ish threads going. And many times the GIL is the bottleneck.

Re: gh-116167: Allow disabling the GIL

#137

Post by bmitc »

amethyst wrote: post #132
bmitc wrote: post #128

Earlier quoted context omitted.

> Working with threads is a pain regardless of which language you use. That's not true at all. F#, Elixir, Erlang, LabVIEW, and several other languages make it very easy . Python makes it incredibly tough.

> Python makes it incredibly tough. I disagree, Python makes it incredibly easy to work with threads in many different ways. It just doesn't make threads faster .

In what way? Threading, asyncio, tasks, event loops, multiprocessing, etc. are all complicated and interact poorly if at all. In other languages, these are effectively the same thing, lighter weight, and actually use multicore.

If I launch 50 threads with run away while loops in Python, it takes minutes to laumch and barely works after. I can run hundreds of thousands and even millions of runaway processes in Elixir/Erlang that launch very fast and processes keep chugging along just fine.

Re: gh-116167: Allow disabling the GIL

#138

Post by android42 »

KerrAvon wrote: post #122
nerpderp82 wrote: post #97

Earlier quoted context omitted.

Mojo should be viewed as an attack on the Python ecosystem due to it being a superset. It can consume Python, but it itself is not Python. Taichi is really underrated, it works across all platforms (including Metal), has tons of examples and the code is easy to write. And lastly, it integrates with the ecosystem and doesn't displace it. https://github.com/taichi-dev great demo reel of what Taichi can do, https://www.…

I think "attack" is a bit much; C++ isn't an attack on C.

I wasn't sure whether to agree with this or not, so I finally took a slightly closer look at Mojo just now.

This depends on how they license it going forward, and whether they make it open, or use being a superset as a way to capture then trap python users in their ecosystem, and I don't think we have a certain answer which path they'll take yet.

The way they let you mix python compatible code with their similar but more performant code [1] looks interesting and provides a nice path for gradual migration and performance improvements. It looks like one of the ways they do this is by letting you define functions that only use typed variables which is something I would like to see make its way back to CPython someday (that is optionally enforcing typing in modules and getting some performance gains out of it).

[1] https://en.wikipedia.org/wiki/Mojo_(programming_language)#Pr...

Re: gh-116167: Allow disabling the GIL

#139

Post by orf »

vlovich123 wrote: post #110
colesbury wrote: post #107

Earlier quoted context omitted.

We could implement ownership transfer in CPython in the future, but it's a bit trickier. In Rust, "move" to transfer ownership is part of the language, but there isn't an equivalent in C or Python, so it's difficult to determine when to transfer ownership and which thread should be the new owner. We could use heuristics: we might give up or transfer ownership when putting an object in a queue.SimpleQueue, but even th…

I think you would do it on first access - “if new thread, increment atomic & exchange for a new object reference that has the local thread id affinity”. That way you don’t care about whether an object actually has thread affinity or not and you solve the “accessed by many threads” piece. But thanks for answering - I figured complexity was the reason a simpler choice was made to start with.

But this would now make the reference count increment require a conditional? It’s a very hot path, and this would cause a slowdown for single-threaded Python code.
Post reply on HN