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

Unlocking Python's Cores:Energy Implications of Removing the GIL

arxiv.org

Post reply on HN
Print view View original

71–80 of 111 posts

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#71

Post by fiedzia »

devrimozcay wrote: post #4

One 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…

> If true parallelism becomes common, it might actually reduce the number of containers/services needed for some workloads

Not by much. The cases where you can replace processes with threads and save memory are rather limited.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#72

Post by kccqzy »

philsnow wrote: post #66
kccqzy wrote: post #53

Earlier quoted context omitted.

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.

Fork-then-thread works, does it not?

If you have enough discipline to make sure you only create threads after all the forking is done, then sure. But having such discipline is harder than just forbidding fork or forbidding threads in your program. It turns a careful analysis of timing and causality into just banning a few functions.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#73

Post by akdev1l »

heavyset_go wrote: post #63
LtWorf wrote: post #48

Earlier quoted context omitted.

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.

Threads are cheap, you can do N work simultaneously with N threads in one process, without serialization, IPC or process creation overhead. With multiprocessing, processes are expensive and work hogs each process. You must serialize data twice for IPC, that's expensive and time consuming. You shouldn't have to break out multiple processes, for example, to do some simple pure-Python math in parallel. It doesn't make s…

I think you have a good point on IPC but process creation in Linux is almost as fast as thread creation

Unless the app would constantly be creating and killing processes then the process creation overhead would not be that much but IPC is killer

And also your types aren’t pickable or whatever and now you gotta change a lot of stuff to get it to work lol.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#74

Post by akdev1l »

kccqzy wrote: post #53
LtWorf wrote: post #48

Earlier quoted context omitted.

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.

Why is it unsafe?

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#75

Post by aoeusnth1 »

fiedzia wrote: post #71
devrimozcay wrote: post #4

One 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…

> If true parallelism becomes common, it might actually reduce the number of containers/services needed for some workloads Not by much. The cases where you can replace processes with threads and save memory are rather limited.

Citation needed? Tall tasks are standard practice to improve utilization and reduce hotspots by reducing load variance across tasks.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#76

Post by tuhgdetzhh »

airza wrote: post #56
zozbot234 wrote: post #31

Earlier quoted context omitted.

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

The llm accusations go out of hand nowadays. Cant see any typical AI slop here.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#77

Post by PaulHoule »

bigstrat2003 wrote: post #61
PaulHoule wrote: post #37

Earlier quoted context omitted.

There are 30,000 different x-platform GUI frameworks and they all share one attribute: (1) they look embarrassingly bad compared to Electron or Native apps and they mostly (2) are terrible to program for. I feel like I never wasting my time when I learn how to do things with the web platform because it turns out the app I made for desktop and tablet works on my VR headset. Sure if you are going to pay me 2x the marke…

> Every time I do a shoot-out of Electron alternatives Electron wins and it is not even close Only if you're ok with giving your users a badly performing application. If you actually care about the user experience, then Electron loses and it's not even close.

Name something specific. Note for two x-platform UI toolkits I have some familiarity with:

Python + tkinter == about the same size as electron

Java + JavaFX == about the same size as electron

Sure there are people who write little applets for software developers that are 20k Win32 applications still but that is really out of the mainstream.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#78

Post by ellis0n »

heavyset_go wrote: post #60
ellis0n wrote: post #57

That 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?

A security scanner, for example, we had to check tens of thousands of IPs of global exchanges for backdoors overnight while the exchanges were offline

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#79

Post by qzzi »

ellis0n wrote: post #57

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

Simply removing the GIL and running 10,000 threads seems very unlikely.

Re: Unlocking Python's Cores:Energy Implications of Removing the GIL

#80

Post by scottcha »

GuB-42 wrote: post #26
pradeeproark wrote: post #22

Earlier quoted context omitted.

I am taking all the migration of electron apps.

I wonder about the total energy cost of apps like Teams, Slack, Discord, etc... Hundreds of millions of users, an app running constantly in the background. I wouldn't be surprised if the global power consumption on the clients side reached the gigawatt. Add the increased wear on the components, the cost of hardware upgrades, etc... All that to avoid hiring a few developers to make optimized native clients on the most…

I actually built this analysis while I worked at Microsoft so I 100% agree. Doing the work at the platform level is the way to go and you can actually make a significant impact with this kind of approach. The other value of this that's not obvious is that doing it client side ends up touching all the grids/generators in the world outside of the market based accounting that tends to drive the datacenter carbon impact analysis.
Post reply on HN