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

71–80 of 259 posts

Re: gh-116167: Allow disabling the GIL

#71

Post by actionfromafar »

kjqgqkejbfefn wrote: post #58
kjqgqkejbfefn wrote: post #20

Earlier quoted context omitted.

Disabling the GIL can unlock true multi-core parallelism for multi-threaded programs, but this requires code to be restructured for safe concurrency, which isn't that difficult it seems: > When we found out about the “nogil” fork of Python it took a single person less than half a working day to adjust the codebase to use this fork and the results were astonishing. Now we can focus on data acquisition system developme…

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

Re: gh-116167: Allow disabling the GIL

#72

Post by rmbyrro »

samatman wrote: post #44
scubbo wrote: post #37

Earlier quoted context omitted.

I wish I had your optimism. Thoughtless bandwagon-y "criticism" is extraordinarily persistent.

There's no need to pretend Python has virtues which it lacks. It's not a fast language. It's fast enough for many purposes, sure, but it isn't fast, and this work is unlikely to change that. Fast er , sure, and that's great.

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're going through.

Re: gh-116167: Allow disabling the GIL

#73

Post by ptx »

skrause wrote: post #67
liuliu wrote: post #16

Earlier quoted context omitted.

`multiprocessing` works fine for serving HTTP requests or do some other subset of embarrassingly-parallel problems.

> `multiprocessing` works fine for serving HTTP requests Not if you use Windows, then it's a mess. I have a suspicion that people who say that the multiprocessing works just fine never had to seriously use Python on Windows.

Why is it a mess? What's wrong with it on Windows?

Re: gh-116167: Allow disabling the GIL

#74

Post by 0cf8612b2e1e »

TylerE wrote: post #54
ollien wrote: post #8

Earlier quoted context omitted.

How do single-threaded programs benefit from a lack of GIL?

Speed. Admittedly not quite as much so the way this patch is implemented, since it just short circuits the extra function calls, doesn’t omit them entirely.

Removing the GIL results in slower execution. Without the guarantees of single thread action, the interpreter needs to utilize more locks under the hood.

Re: gh-116167: Allow disabling the GIL

#76

Post by behnamoh »

willcipriano wrote: post #69
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…

What sucked about FastAPI?

Not fast enough! I used it to call llama.cpp server but it would crash if requests were "too fast". Calling the llama.cpp server directly solved the issue.

Re: gh-116167: Allow disabling the GIL

#77

Post by rmbyrro »

samatman wrote: post #55
oivey wrote: post #38

Earlier quoted context omitted.

Notably, all of those are static languages and none of them have array types as nice as PyTorch or NumPy, among many other packages in the Python ecosystem. Those two facts are likely closely related.

If only there were a dynamic language which performs comparably to C and Fortran, and was specifically designed to have excellent array processing facilities. Unfortunately, the closest thing we have to that is Julia, which fails to meet none of the requirements. Alas.

If only there was a car that could fly, but was still as easy and cheap to buy and maintain :D

Re: gh-116167: Allow disabling the GIL

#80

Post by [deleted] »

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…

[deleted]
Post reply on HN