[flagged]
Unlocking Python's Cores:Energy Implications of Removing the GIL
51–60 of 111 posts
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#52[flagged]
Ok.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#53One thing I'm curious about here is the operational impact. In production systems we often see Python services scaling horizontally because of the GIL limitations. If true parallelism becomes common, it might actually reduce the number of containers/services needed for some workloads. But that also changes failure patterns — concurrency bugs, race conditions, and deadlocks might become more common in systems that wer…
But python can fork itself and run multiple processes into one single container. Why would there be a need to run several containers to run several processes? There's even the multiprocessing module in the stdlib to achieve this.
Forking and multi threading do not coexist. Even if one of your transitive dependencies decides to launch a thread that’s 99% idle, it becomes unsafe to fork.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#54Should have funded the entire GIL-removal effort by selling carbon credits. Here's an industry waiting to happen: issue carbon credits for optimizing CPU and GPU resource usage in established libraries.
There's a spicy argument to be made that "Rewrite it in Rust" is actually an environmentalist approach.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#55Earlier quoted context omitted.
Many times this. Native path is the path of infinite churn, ALL the time. With web you might find some framework bro who takes pride in knowing all the intricacies of React hooks who'll grill you for not dreaming in React/Vue/framework of the day, but fundamental web skills (JS/HTML/CSS) are universal. And you can pretty much apply them on any platform: - iOS? React Native, Ionic, Web app via Safari - Android? Same t…
Qt does exist. It's not difficult.
Qt costs serious money if you go commercial. That might not be important for a hobby project, but lowers the enthusiasm for using the stack since the big players won't use it unless other considerations compel them.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#56Earlier quoted context omitted.
I thought libraries had to explicitly opt in to no GIL via a macro or constant or something in C
GP is a clanker spouting off a lot of random nonsense. Edit: Never mind. If it walks like a duck and talks like a duck...
It seems like ai generated stuff to me, the whole history is eerily identical
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#57That reminded me of how back in 2008 I removed the GIL from Python to run thousands Python modules in 10,000 threads. We were fighting for every clock cycle and byte and it worked. It took 20 years for the GIL to be removed and become available to the public.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#58Earlier quoted context omitted.
Many times this. Native path is the path of infinite churn, ALL the time. With web you might find some framework bro who takes pride in knowing all the intricacies of React hooks who'll grill you for not dreaming in React/Vue/framework of the day, but fundamental web skills (JS/HTML/CSS) are universal. And you can pretty much apply them on any platform: - iOS? React Native, Ionic, Web app via Safari - Android? Same t…
Qt does exist. It's not difficult.
...which is the same as Flutter. Both don't use native UI toolkits (though Qt doesn't use Skia, I'll give you that (Flutter has Impeller engine in the works)). And Qt has much worse developer experience and costs money.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#59> Similarly, workloads where threads frequently access and modify the same objects show reduced improvements or even degradation due to lock contention. Perhaps I'm stating the obvious, but you deal with this with lock-free data structures, immutable data, siloing data per thread, fine-grain locks, etc. Basically you avoid locks as much as possible.
It'd be nice if Python std lib had more thread safe primitives/structures (compared to something like Java where there's tons of thread safe data structures)
Imo the GIL was used as an excuse for a long time to avoid building those out.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#60That reminded me of how back in 2008 I removed the GIL from Python to run thousands Python modules in 10,000 threads. We were fighting for every clock cycle and byte and it worked. It took 20 years for the GIL to be removed and become available to the public.
What was the use case?