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

181–190 of 259 posts

Re: gh-116167: Allow disabling the GIL

#181

Post by neonsunset »

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…

Strong recommendation to look into ASP.NET Core with C#. It gives static typing, easy first-class concurrency, it runs on all platforms and now can be AOT compiled if that's your thing, if not - can still produce just a single executable if you choose to. Also its CLI is nice and similar to cargo. Naturally, you won't be having performance issues.

Re: gh-116167: Allow disabling the GIL

#182

Post by Shog9 »

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…

This is where Python's GIL bit me: I was more than familiar with how to shoot myself in the foot using threads in other languages, and careful to avoid those traps. Threads spun up only in situations where they had their own work to do and well-defined conditions for how both failure and success would be reported back to the thread that requested it, along with a pool that wouldn't exceed available resources.

Like every other language I've used this approach with, nothing bad happened - the program ran as expected and produced correct results. Unlike every other language, spreading calculations across multiple cores didn't appreciably improve performance. In some cases, it got slower.

Eventually scrapped it all, and went with an approach closer to what I'd have done with C and fork() decades ago... Which, to Python's credit, was fairly painless and worked well. But it caught me off-guard, because with asyncio for IO-bound stuff, it didn't seem like threads really have much of a purpose in Python, other than to be a tripwire for unwary and overconfident folks like myself!

Re: gh-116167: Allow disabling the GIL

#183

Post by mlyle »

hsbauauvhabzb wrote: post #178
nextaccountic wrote: post #140

Earlier quoted context omitted.

If any package depends on the GIL, it will be enabled. Packages won't break

What packages might depend on the GIL and why would they need it?

Packages with native components that have not been updated for the semantics changes.

Re: gh-116167: Allow disabling the GIL

#184

Post by mlyle »

scubbo wrote: post #168
bmitc wrote: post #127

Earlier quoted context omitted.

It isn't thoughtless. I'm working in Python after having come from more designed languages, and concurrency in Python is an absolute nightmare. It feels like using a language from the 60s. An effectively single threaded language in 2024! That's really astonishing.

If your criticism isn't thoughtless, then that's not what I'm complaining about. Specifically, I'm annoyed about people who _just_ say "Python isn't fast enough, therefore it's not suitable to our use-case", when their use-case doesn't require significant speed or concurrency. If you thoughtfully discount Python as being unsuitable for a use-case that it's _actually_ unsuitable for, then good luck to you!

Python has been too often just a -bit- too slow for my use cases; the ability to throw a few cores at problems more easily is not going to eliminate this criticism from me but it's sure going to diminish it by a large factor.

Re: gh-116167: Allow disabling the GIL

#185

Post by maple3142 »

sneed_chucker wrote: post #150
mixmastamyk wrote: post #117

Earlier quoted context omitted.

I've read that it can't even be as fast as JS, because everything is monkey-patchable at runtime. Maybe they can optimize for that when it doesn't happen, but remains to be seen.

I've heard similar claims but I don't think it's true. JavaScript is just as monkey-patchable. You can reassign class methods at runtime. You can even reassign an object's prototype. Existing Python JIT runtimes and compilers are already pretty fast.

Python is probably much more monkey patchable. Almost any monkey patching that JavaScript supports also works in Python (e.g. modifying class prototype = assigning class methods), but there are a few things that only Python can do: accessing local variables as dict, access other stack frames, modifying function bytecode, read/write closure variables, patching builtins can change how the language works (__import__, __build_class__). Many of them can make a language hard to optimize.

Re: gh-116167: Allow disabling the GIL

#186

Post by jononor »

ynik wrote: post #28
protomikron wrote: post #9

Although this is nice, the problems with the GIL are often blown out of proportion: people stating that you couldn't do efficient (compute-bounded) multi-processing, which was never the case as the `multiprocessing` module works just fine.

multiprocessing only works fine when you're working on problems that don't require 10+ GB of memory per process . Once you have significant memory usage, you really need to find a way to share that memory across multiple CPU cores. For non-trivial data structures partly implemented in C++ (as optimization, because pure python would be too slow), that means messing with allocators and shared memory. Such GIL-workaroun…

I think that 90 or maybe even 99% of cases has under 1GB of memory per process? At least it has been the case for me the last 15 years.

Of course, getting threads to be actually useful for concurrency (GIL removed) adds another very useful tool to the performance toolkit, so that is great.

Re: gh-116167: Allow disabling the GIL

#187

Post by Intralexical »

its-summertime wrote: post #169
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.…

Cython is also a superset, is Cython also guilty of such crimes?

Cython is dependent on CPython. Cython outputs Python extension modules, which can only be used when imported into a standard CPython environment, and which interoperate cleanly with the rest of the Python ecosystem.

Mojo explicitly does the opposite, allowing Mojo to use Python but requiring Mojo to be in control, while making it hard/impossible for code written in Mojo to benefit code written in Python:

> Our long-term goal is to make Mojo a superset of Python (that is, to make Mojo compatible with existing Python programs). […] Mojo lets you import Python modules, call Python functions and interact with Python objects from Mojo code. […]

> 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. […]

> This pattern doesn't work because you can't pass Mojo callbacks to a Python module.

> Since Python can't call back into Mojo, one alternative is to have the Mojo application drive the event loop and poll for updates.

No comment on whether this should be viewed as an attack.

https://docs.modular.com/mojo/manual/python/

Re: gh-116167: Allow disabling the GIL

#188

Post by richrichie »

Kranar wrote: post #126
KerrAvon wrote: post #122

Earlier quoted context omitted.

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

While Ken Thompson never used the word attack, he certainly didn't have a positive opinion of the language or of Bjarne Stroustrup either in terms of his technical contributions or his handling of C++ adoption: https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-p...

Thanks for sharing.

> perhaps Erik Naggum, scourge of Usenet, was right when he said: “life is too long to know C++ well.”

I feel similar about Rust. I have read “the book”. Did a couple of small projects. It is also sort of committee administered language that sucks up tiny features like a giant vacuum cleaner sweeping the streets and changes every hour.

Re: gh-116167: Allow disabling the GIL

#189

Post by jononor »

TylerE wrote: post #175
0cf8612b2e1e wrote: post #145

Earlier quoted context omitted.

Umm, yes it does? For the longest time, Guido’s defense for the GIL was that all previous efforts resulted in an unacceptable hit to single threaded performance. Read PEP-703 ( https://peps.python.org/pep-0703/#performance ) where the performance hit is currently 5-8%

That's to make it thread safe without the GIL. If you only care about single thread there's all kinds of stuff you can do.

How to ensure there are no other threads, confidently enough that one can turn thread safety off?

Re: gh-116167: Allow disabling the GIL

#190

Post by whiterknight »

hsbauauvhabzb wrote: post #178
nextaccountic wrote: post #140

Earlier quoted context omitted.

If any package depends on the GIL, it will be enabled. Packages won't break

What packages might depend on the GIL and why would they need it?

Any C code that uses global variables casually.
Post reply on HN