Discussion

Computer Science > Distributed, Parallel, and Cluster Computing

philipallstar: Might be worth noting that this seems to be just running some tests using the current implementation, and these are not necessarily general implications of removing the GIL.

flowerthoughts: Sections 5.4 and 5.5 are the interesting ones.5.4: Energy consumption going down because of parallelism over multiple cores seems odd. What were those cores doing before? Better utilization causing some spinlocks to be used less or something?5.5: Fine-grained lock contention significantly hurts energy consumption.

alright2565: I'm not sure of the exact relationship, but power consumption increases greater than linear with clock speed. If you have 4 cores running at the same time, there's more likely to be thermal throttling → lower clock speeds → lower energy consumption.Greater power draw though; remember that energy is the integral of power over time.

spockz: By running more tasks in parallel across different cores they can each run at lower clock speed and potentially still finish before a single core at higher clock speeds can execute them sequentially.

pothamk: Removing the GIL solves one bottleneck but also removes a safety blanket. A lot of Python code implicitly relied on the GIL preventing true parallel execution. Once threads actually run concurrently, libraries that never needed locking could start hitting race conditions in surprising places.

OskarS: Thanks ChatGPT, good of you to let us know.

stingraycharles: There are so many ChatGPT responses in this thread, it’s giving me a headache.

OskarS: Yep. Real "dead internet theory" vibes, really sad to see.

chillitom: Our 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.

stingraycharles: It’s been very noticeable for about a year now, but the last few months is absolutely terrible. I wonder if clawdbot has anything to do with it.

exe34: my hypothesis is that chatgpt was trained on the internet, and useful technical answers on the internet were posted by autistic people. who else would spend their time learning and then rushing to answer such things the moment they get their chance to shine? so chatgpt is basically pure distilled autism, which is why it sounds so familiar.

Incipient: I'm curious what makes that obviously llm? As far as I can tell it was a short and fairly benign statement with little scope to give away llm-ness?

hrmtst93837: Swapping ProcessPoolExecutor for ThreadPoolExecutor gives real memory and IPC wins, but it trades process isolation for new failure modes because many C extensions and native libraries still assume the GIL and are not thread safe.Measure aggressively and test under real concurrency: use tracemalloc to find memory hotspots, py-spy or perf to profile contention, and fuzz C extension paths with stress tests so bugs surface in the lab not in production. Watch per thread stack overhead and GC behavior, design shared state as immutable or sharded, keep critical sections tiny, and if process level isolation is still required stick with ProcessPoolExecutor or expose large datasets via read only mmap.

devrimozcay: 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 were previously "protected" by the GIL.It will be interesting to see whether observability and incident tooling evolves alongside this shift.

matsemann: For big things the current way works fine. Having a separate container/deployment for celery, the web server, etc is nice so you can deploy and scale separately. Mostly it works fine, but there are of course some drawbacks. Like prometheus scraping of things then not able to run a web server in parallel etc is clunky to work around.And for smaller projects it's such an annoyance. Having a simple project running, and having to muck around to get cron jobs, background/async tasks etc. to work in a nice way is one of the reasons I never reach for python in these instances. I hope removing the GIL makes it better, but also afraid it will expose a whole can of worms where lots of apps, tools and frameworks aren't written with this possibility in mind.

carlsborg: 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.

apothegm: 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.

bob1029: > Across all workloads, energy consumption is proportional to execution timeRace-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.

nijave: I thought libraries had to explicitly opt in to no GIL via a macro or constant or something in C

pradeeproark: I am taking all the migration of electron apps.

GuB-42: 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.

Tiberium: I have a suspicion that this paper is basically a summary with some benchmarks, done with LLMs.

dr_zoidberg: Your suspicion could have easily been cleared by reading the paper.If you're short on time: the paper reads a bit dry, but falls in the norm for academic writing. The github repo shows work over months on 2024 (leading up to the release of 3.13) and some rush on Dec 2025 to Jan 2026, probably to wrap things up on the release of this paper. All commits on the repo are from the author, but I didn't look through the code to inspect if there was some Copilot intervention.[0] https://github.com/Joseda8/profiler

zozbot234: GP is a clanker spouting off a lot of random nonsense.