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

Deze studie toont aan dat de experimentele GIL-vrije build van Python 3.14.2 de uitvoeringstijd en energie-efficiëntie voor parallelle werklasten aanzienlijk verbetert, maar voor sequentiële taken of gedeelde data-structuren juist leidt tot hoger energieverbruik en meer geheugengebruik.

De kern

De GIL-vergrendeling: Een simpele uitleg van Python's nieuwe "meerdere handen" aanpak

Stel je voor dat Python een enorm drukke fabriek is waar computerspellen, data-analyses en kunstmatige intelligentie worden gebouwd. In deze fabriek werkt er altijd maar één werknemer tegelijk aan de taak, zelfs als er twaalf andere werknemers (kernen van de processor) klaarstaan om te helpen.

Die ene werknemer is de GIL (Global Interpreter Lock). Het is een soort "alleen-recht" dat zorgt dat er nooit twee Python-instructies tegelijk worden uitgevoerd. Dit is veilig, maar het is alsof je een auto met twaalf motoren hebt, maar er maar één sleutel is die maar één motor kan starten. De andere elf motoren staan stil, terwijl de auto toch energie verbruikt.

Sinds kort (Python 3.13 en 3.14) is er een experimentele nieuwe versie van deze fabriek: de "No-GIL" versie. Hier mag iedereen tegelijk werken. Maar de vraag is: bespaart dit energie en werkt het sneller?

Dit onderzoek kijkt precies hiernaar. Hier is wat ze ontdekten, vertaald naar alledaagse situaties:

1. De drie soorten fabrieken (Werklasten)

De onderzoekers testten drie verschillende soorten taken om te zien hoe de nieuwe versie presteert:

A. De "Buitenlandse Experts" (NumPy-taken)

• De situatie: Stel je voor dat Python de manager is, maar de zware, saaie werk (zoals het berekenen van enorme lijsten met getallen) wordt uitbesteed aan speciale, super-snelle robots (C-code libraries zoals NumPy).
• Het resultaat: Het maakt geen verschil of je de GIL hebt of niet. De robots werken al zo snel dat de Python-manager nauwelijks tijd verliest.
• Energie: Geen winst, geen verlies. De robots doen het werk anyway.
• Conclusie: Als je vooral NumPy gebruikt, hoef je je geen zorgen te maken.

B. De "Eenzame Werknemer" (Sequentiële taken)

• De situatie: Dit is werk dat niet verdeeld kan worden. Denk aan het sorteren van een lange lijst van A tot Z, of het berekenen van een wiskundig probleem dat stap voor stap moet.
• Het resultaat: De nieuwe versie werkt hier langzamer (tot 43% trager). Waarom? Omdat de nieuwe versie extra veiligheidsmaatregelen moet nemen (zoals extra vergrendelingen per object) die tijd kosten, terwijl er toch maar één persoon aan het werk is.
• Energie: Omdat het langer duurt, verbruikt het meer stroom. Het is alsof je een auto langzamer laat rijden, maar de motor toch blijft draaien.
• Conclusie: Voor simpele, één-op-één taken is de nieuwe versie slechter. Je betaalt een "snelheidstaks" voor iets dat je niet nodig hebt.

C. De "Meerdere Werknemers" (Parallelle taken)

• De situatie: Dit is het ideale scenario. Stel je hebt 1000 losse poststukken die je moet sorteren. Je kunt deze verdelen over 12 werknemers.
• Het resultaat:
  • Als de werknemers niet met elkaar hoeven te praten: (Elk werkt aan zijn eigen stapel) -> Gigantische winst! De taak is tot 4 keer sneller klaar. Omdat het zo snel klaar is, verbruikt het minder stroom, ondanks dat er meer motoren draaien.
  • Als de werknemers constant met elkaar moeten praten: (Ze moeten allemaal aan hetzelfde document werken en het steeds aanpassen) -> Ramp! Ze gaan elkaar blokkeren, ruzie maken over wie er mag schrijven, en vertragen elkaar. De nieuwe versie is hier zelfs 12 keer langzamer en verbruikt veel meer stroom dan de oude versie.
• Conclusie: Alleen werken als je taken goed te verdelen zijn en de werknemers elkaar niet in de weg zitten.

2. De "Stroomrekening" (Energie)

Een van de belangrijkste ontdekkingen is dit: Snelheid is energie.

In de oude wereld dachten we misschien: "Als ik meer kernen gebruik, verbruikt mijn computer meer stroom per seconde." Dat klopt, maar de onderzoekers ontdekken dat de totale energiebesparing vooral komt door het kortere tijdsbestek.

• Analogie: Stel je voor dat je een badkamer moet douchen.
  • Met de GIL (oude versie): Je wast langzaam, maar gebruikt weinig water per minuut. Het duurt 20 minuten.
  • Zonder GIL (nieuwe versie, bij goede taken): Je wast razendsnel, gebruikt veel water per minuut, maar het duurt maar 5 minuten.
  • Resultaat: De snelle versie verbruikt in totaal veel minder water (energie) omdat je de kraan zo snel mogelijk dichtdraait.

De regel: Als je Python-programma sneller draait, verbruikt het automatisch minder energie. Er is geen magische knop om energie te besparen; je moet gewoon sneller werken.

3. De "Pakketruimte" (Geheugen)

Er is een nadeel aan de nieuwe versie: meer ruimtegebruik.
De nieuwe versie heeft extra "veiligheidsgordels" en "vergrendelingen" nodig voor elke werknemer.

• Virtueel geheugen: De nieuwe versie vraagt om veel meer ruimte op je harde schijf (virtueel geheugen), alsof je een gigantisch magazijn huurt dat grotendeels leeg staat.
• Fysiek geheugen (RAM): Dit neemt ook iets toe, maar niet zo gek veel, tenzij de werknemers constant ruzie maken (lock contention). Dan wordt het geheugenverbruik wel erg hoog.

Samenvatting: Moet je overstappen?

De conclusie van het onderzoek is: Nee, niet voor iedereen. De nieuwe "No-GIL" versie is geen wondermiddel voor elke Python-gebruiker.

• Jij moet overstappen als: Je werkt met zware, rekenkrachtige taken die je kunt verdelen over meerdere kernen (bijvoorbeeld simuleren van natuurverschijnselen, grote data-analyses zonder NumPy, of AI-trainingen die puur Python zijn). Dan bespaar je enorm veel tijd en energie.
• Jij moet blijven bij de oude versie als: Je programma's vooral uit één lange, opeenvolgende reeks instructies bestaan, of als veel delen van je code constant aan dezelfde bestanden of lijsten werken. Dan wordt je computer juist trager en verbruikt hij meer stroom.

Het grote inzicht:
Python's nieuwe "meerdere handen" aanpak is een krachtig gereedschap, maar het is een specialist. Het is niet voor iedereen. Als je programmeur bent, moet je eerst kijken of je werk zich leent voor parallel werken voordat je de GIL uitschakelt. Anders betaal je de prijs voor een snelheid die je nooit gaat gebruiken.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het onderzoekspaper "Unlocking Python's Cores: Hardware Usage and Energy Implications of Removing the GIL" in het Nederlands.

Titel: Ontgrendelen van Python's Kernen: Hardware-gebruik en Energie-implicaties van het Verwijderen van de GIL

Auteur: José Daniel Montoya Salazar (Onafhankelijk Onderzoeker)
Onderwerp: Prestaties, energie-efficiëntie en hardware-gebruik van de experimentele "free-threaded" build van Python 3.14.2 (zonder GIL) vergeleken met de standaard GIL-enabled build.

---

1. Probleemstelling

Python is een van de meest gebruikte programmeertalen, maar staat bekend om zijn lage energie-efficiëntie ten opzichte van talen zoals C++ of Rust. Een van de belangrijkste architecturale beperkingen is de Global Interpreter Lock (GIL). Deze lock voorkomt dat meerdere threads tegelijkertijd Python-bytecode uitvoeren binnen één proces, waardoor multi-core CPU's vaak niet volledig worden benut, zelfs niet bij multi-threaded programma's.

Sinds Python 3.13 en 3.14 biedt CPython een optionele free-threaded build (zonder GIL) aan. Hoewel eerdere studies de snelheidswinst hebben onderzocht, is er weinig bekend over de impact op:

• Energieverbruik: Leidt snellere uitvoering op meerdere kernen tot daadwerkelijke energiebesparingen, of weegt het hogere stroomverbruik van actieve kernen op tegen de tijdwinst?
• Hardware-gebruik: Hoe verandert het CPU- en geheugengebruik (RAM en virtueel geheugen)?
• Trade-offs: Zijn er scenario's waarin het verwijderen van de GIL juist nadelig is voor prestaties of energie?

2. Methodologie

De auteur heeft een uitgebreid benchmark-experiment uitgevoerd om deze vragen te beantwoorden.

• Hardware: Een laptop met een Intel Core i7-8750H (6 fysieke kernen, 12 hyperthreading), 16 GB RAM, en Ubuntu 24.04.3 LTS.
• Software-configuraties:
  • Standaard Python 3.14.2 (met GIL).
  • Free-threaded Python 3.14.2 (gecompileerd met --disable-gil).
• Meetinstrumenten: Een aangepaste Python-profiler die elke 50 ms steekproeven nam met behulp van psutil voor CPU/Geheugen en Intel RAPL (via Linux sysfs) voor energieverbruik.
• Workload-categorieën:
  1. NumPy-berekeningen: Representatief voor data-analyse waar Python native code (C/C++) aanstuurt.
  2. Sequentiële kernels: Enkel-threaded pure Python-code (bijv. Bubble Sort, Mandelbrot, Primetabellen).
  3. Threaded numerieke workloads: Parallelle berekeningen met onafhankelijke data (bijv. Matrixvermenigvuldiging, N-body simulatie).
  4. Threaded object workloads: Workloads met veel allocatie en gedeelde mutable state (bijv. JSON-parsing, lijsten bewerken).
• Statistiek: Elke test werd 10 keer herhaald. Resultaten werden geaggregeerd met een geometrisch gemiddelde van log-ratio's (no-GIL / GIL) met 95% betrouwbaarheidsintervallen.

3. Belangrijkste Bijdragen en Resultaten

De studie onthult een duidelijk trade-off afhankelijk van het type workload:

A. NumPy en Native Extensions

• Resultaat: Geen significante verandering in uitvoeringstijd, CPU-gebruik of energie.
• Reden: NumPy geeft de GIL vrij tijdens zware berekeningen. De overhead van de free-threaded build is hier verwaarloosbaar.
• Geheugen: Er is een toename in Virtueel Geheugen (VMS) (tot 71% hoger) door de mimalloc-allocator en per-object locks, maar het fysieke RAM-gebruik (RSS) blijft gelijk.

B. Sequentiële Workloads (Single-threaded)

• Resultaat: Negatief effect. De free-threaded build is 13% tot 43% trager dan de standaard build.
• Energie: Omdat de uitvoeringstijd langer is en het stroomverbruik per seconde gelijk blijft, neemt het totale energieverbruik met 13–43% toe.
• Geheugen: Er is een aanzienlijke toename in zowel VMS als fysiek RAM (RSS), veroorzaakt door de runtime-overhead van thread-safety mechanismen.

C. Threaded Numerieke Workloads (Onafhankelijke data)

• Resultaat: Positief effect. Bij 6 workers (fysieke kernen) is de uitvoering 4x sneller.
• Energie: Ondanks dat meer kernen tegelijk actief zijn (hoger vermogen), leidt de drastische verkorting van de uitvoeringstijd tot een 74–77% reductie in totale energie.
• Conclusie: Dit is het ideale gebruiksscenario. Parallelisatie compenseert het hogere vermogen.

D. Threaded Object Workloads (Gedeelde mutable state)

• Resultaat: Afhankelijk van concurrentie.
  • Lage concurrentie (onafhankelijke data): Soortgelijke snelheidswinst als numerieke workloads (3x sneller, 3x minder energie).
  • Hoge concurrentie (gedeelde lijsten/objects): Zware degradatie. Bij werklasten waar threads dezelfde objecten wijzigen, treedt er lock-contention op. De free-threaded build kan hier 12x trager zijn en 380% meer energie verbruiken dan de GIL-versie.
• Reden: De overhead van per-object locks en synchronisatie weegt zwaarder dan de parallelle voordelen.

E. Hardware-gebruik en Geheugen

• CPU: De free-threaded build schaalbaar tot 11x meer CPU-gebruik bij hoge thread-aantallen, terwijl de GIL-versie vaak op één kern blijft hangen.
• Geheugen: De free-threaded build gebruikt consistent meer Virtueel Geheugen (VMS) (door arena-reservering van mimalloc en thread-lokale opslag). Het fysieke geheugen (RSS) neemt toe, vooral bij workloads met veel object-allocatie of lock-contention.

4. Kernvragen Beantwoord

1. Verlaagt no-GIL het energieverbruik?
   • Conditioneel ja. Alleen voor werklasten die goed paralleliseerbaar zijn met onafhankelijke data. Voor sequentiële code of code met veel gedeelde state verhoogt het het energieverbruik aanzienlijk.
2. Is er een evenredig verband tussen tijd en energie?
   • Ja. Over alle scenario's heen is energieverbruik direct evenredig met uitvoeringstijd. Als de tijd daalt, daalt de energie evenredig, zelfs als het piekvermogen (door meer kernen) stijgt. Optimaliseren voor snelheid is dus equivalent aan optimaliseren voor energie.
3. Hoe verschillen ze in hardware-gebruik?
   • No-GIL gebruikt meer CPU (schalend naar kernaantal) en meer geheugen (vooral VMS, maar ook RSS bij zware workloads).

5. Betekenis en Conclusie

De studie concludeert dat de free-threaded build van Python geen universele verbetering is, maar een gespecialiseerde tool.

• Aanbeveling voor ontwikkelaars:
  • Gebruik no-GIL voor CPU-bound applicaties die veel parallelle berekeningen doen op onafhankelijke data (bijv. data science pipelines, numerieke simulaties).
  • Blijf bij de standaard GIL-build voor sequentiële applicaties, applicaties met veel gedeelde mutable state, of omgevingen met strikte geheugenlimieten (zoals embedded systems), omdat de overhead hier de voordelen tenietdoet.
  • Voor NumPy-dominante workloads maakt het weinig uit; de prestaties worden bepaald door de native C-extensies.

Eindoordeel: Het verwijderen van de GIL opent de deur naar echte multi-core parallelisatie in Python, wat leidt tot aanzienlijke energiebesparingen voor de juiste werklasten. Echter, de prijs is een onvermijdelijke overhead voor sequentiële code en een risico op prestatiedegradatie bij slecht ontworpen multi-threaded code met gedeelde resources. Ontwikkelaars moeten hun workload zorgvuldig evalueren voordat ze overstappen.