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

Posted by runningmike 3 days ago

Unlocking Python's Cores:Energy Implications of Removing the GIL(arxiv.org)

103 points | 74 commentspage 2

newzino 5 hours ago|

[dead]

3tdimhcsb 4 hours ago||

[flagged]

rirze 4 hours ago|

Ok.

5tdimhcsb 3 hours ago||

[flagged]

pothamk 9 hours ago||

[flagged]

OskarS 9 hours ago||

Thanks ChatGPT, good of you to let us know.

stingraycharles 9 hours ago|||

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

OskarS 9 hours ago||

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

stingraycharles 9 hours ago|||

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 9 hours ago|||

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 9 hours ago|||

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?

elar_verole 6 hours ago|||

It's just the equivalent of that one student restating what the teacher just said with no added value

mrkeen 8 hours ago||||

Just as bad if it's human. No information has been shared. The writer has turned idle wondering into prose:

> Once threads actually run concurrently, libraries (which?) that never needed locking (contradiction?) could (will they or won't they?) start hitting race conditions in surprising (go on, surprise me) places.

OskarS 4 hours ago|||

It was an essentially pointless platitude about the GIL from a very new account not really related to the article, and all comments from this account are the same: top level comments with lots of em-dashes that are just a vague piece of pablum somewhat related to the subject. If it was just this comment, sure, it could be possible it's a rather uninteresting human. But given the history, this account is pure AI slop.

RobotToaster 9 hours ago||

The obvious solution is to require libraries that are no-GIL safe to declare that, and for all other libraries implicitly wrap them with GIL locks.

Tiberium 6 hours ago||

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

dr_zoidberg 6 hours ago||

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

bob1029 7 hours ago|

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

adrian_b 6 hours ago||

Programs whose performance is dominated by array operations, as it is the case for most scientific/technical/engineering applications, achieve a much better energy efficiency on the AMD or Intel CPUs with good AVX-512 support, e.g. Zen 5 Ryzen or Epyc CPUs and Granite Rapids Xeons, than on almost all ARM-based CPUs, including on all Apple CPUs (the only ARM-based CPUs with good energy efficiency for such applications are made by Fujitsu, but they are unobtainium).

So if you want maximum energy efficiency, you should choose well your CPU, but a prejudice like believing that ARM-based CPUs are always better is guaranteed to lead to incorrect decisions.

The Apple CPUs have exceptional and unmatched energy efficiency in single-thread applications, but their energy efficiency in multi-threaded applications is not better than that of Intel/AMD CPUs made with the same TSMC CMOS fabrication process, so Apple can have only a temporary advantage, when they use first some process to which competitors do not have access.

Except for personal computers, the energy efficiency that matters is that of multi-threaded applications, so there Apple does not have anything to offer.

adgjlsfhk1 6 hours ago||

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

adrian_b 6 hours ago||

CPU ISA is at most a 2x difference for programs that use only the general-purpose registers and operations.

For applications that use vector or matrix operations and which may need some specific features, it is frequent to have a 4x to 10x better performance, or even more than this, when passing from a badly-designed ISA to a well-designed ISA, e.g. from Intel AVX to Intel AVX-512.

Moreover, there are ISAs that are guilty of various blunders, which lower the performance many times. For instance, if an ISA does not have rotation instructions, an application whose performance depends a lot on such operations may run up to 3x slower than on an ISA with rotation instructions

Even greater slow-downs happen on ISAs that lack good means for detecting various errors, e.g. when running on RISC-V a program that must be reliable, so it has to check for integer overflows.