Should 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.
Unlocking Python's Cores:Energy Implications of Removing the GIL
21–30 of 111 posts
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#22Should 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.
I am taking all the migration of electron apps.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#23Our experience on memory usage, in comparison, has been generally positive. Previously we had to use ProcessPoolExecutor which meant maintaining multiple copies of the runtime and shared data in memory and paying high IPC costs, being able to switch to ThreadPoolExecutor was hugely beneficially in terms of speed and memory. It almost feels like programming in a modern (circa 1996) environment like Java.
[flagged]
I thought libraries had to explicitly opt in to no GIL via a macro or constant or something in C
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#24> Across all workloads, energy consumption is proportional to execution time
Race-to-idle used to be the best path before multicore. Now it's trickier to determine how to clock the device. Especially in battery powered cases. This is why all modern CPU manufacturers are looking into heterogeneous compute (efficiency vs performance cores).
Put differently, I don't think we should be killing ourselves over this at software time. If you are actually concerned about the impact on raw energy consumption, you should move your workloads from AMD/Intel to ARM/Apple. Everything else would be noise compared to this.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#25One 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…
A lot of that has already been solved for by scaling workers to cores along with techniques like greenlets/eventlets that support concurrency without true multithreading to take better advantage of CPU capacity.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#26Should 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.
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 popular platforms. Popular apps and websites should lose or get carbon credits on optimization. What is negligible for a small project becomes important when millions of users get involved, and especially background apps.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#27I have a suspicion that this paper is basically a summary with some benchmarks, done with LLMs.
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#28> Across all workloads, energy consumption is proportional to execution time Race-to-idle used to be the best path before multicore. Now it's trickier to determine how to clock the device. Especially in battery powered cases. This is why all modern CPU manufacturers are looking into heterogeneous compute (efficiency vs performance cores). Put differently, I don't think we should be killing ourselves over this at soft…
this is a very silly take. cpu isa is at most a 2x difference, and software has plenty of 100x differences. most of the difference between Windows and macos isn't the chips, OS and driver bloat is a much bigger factor
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#29Earlier 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…
If we go by Microsofts 2020 account of 1 billion devices running Windows 10 [0], and assume all those are running some kind of electron app (or multiple?) you easily get your gigawatt by just saving 1 watt across each device (on average). I suspect you'd probably go higher than 1 gigawatt, but I'm not sure as far as making another order of magnitude. I also think the noisy fan on my notebook begs to differ and maybe the 10 GW mark could be doable...
[0] https://news.microsoft.com/apac/2020/03/17/windows-10-poweri...
Re: Unlocking Python's Cores:Energy Implications of Removing the GIL
#30I have a suspicion that this paper is basically a summary with some benchmarks, done with LLMs.
[deleted]