Projekt zur Entfernung des GIL und für ein schnelleres CPython

• Der Python Global Interpreter Lock (GIL) war ein zentrales Hindernis für Leistungssteigerungen bei Programmen mit mehreren Threads.
• Im Oktober 2021 stellte Sam Gross eine Proof-of-Concept-Version von Python ohne GIL vor, die zunächst begeistert aufgenommen wurde, danach aber mehr als ein Jahr lang kaum Fortschritte machte.
• Der Python Steering Council hat nun seine Bereitschaft angekündigt, die no-GIL-Funktionalität zu integrieren.
• Das Mitte 2021 gestartete Faster-CPython-Projekt konzentriert sich darauf, die Single-Thread-Leistung des Python-Interpreters zu verbessern.
• Auf der diesjährigen PyCon stellten zwei Mitglieder des Faster-CPython-Teams die Strategien vor, die sie zur Verbesserung der Interpreter-Leistung eingesetzt haben.
• Im Januar 2023 veröffentlichte der Core-Entwickler Łukasz Langa die erste Version von PEP 703 ("Making the Global Interpreter Lock Optional in CPython" / „Den Global Interpreter Lock in CPython optional machen“), verfasst von Gross.
• Die Python-Community will einen chaotischen Übergang wie von Python 2 zu Python 3 vermeiden. Alle Änderungen zur Entfernung des GIL müssen mit Code kompatibel sein, der darauf nicht vorbereitet ist.
• Am 14. Juni erhöhte das Faster-CPython-Team den Druck und forderte eine Entscheidung zur no-GIL-Funktionalität.
• Am 28. Juli gab Vorstandsmitglied Thomas Wouters bekannt, dass der Rat PEP 703 angenommen hat, auch wenn die Details der Annahme noch abgestimmt werden.
• Der Plan ist, eine no-GIL-Version des Interpreters einzuführen, alle fehlenden Komponenten zu identifizieren, diese zu beheben und no-GIL anschließend zur Standard- und endgültigen Version von Python zu machen.
• Der Übergang zu einer no-GIL-Version wird voraussichtlich etwa fünf Jahre dauern; zugleich gibt es das Versprechen, Fehler der Vergangenheit nicht zu wiederholen.
• In diesem Artikel wird diskutiert, wie sich mit paralleler Programmierung in .NET for-/foreach-Schleifen beschleunigen lassen, wenn „embarrassingly parallel“ Daten vorliegen.
• Der Artikel behandelt die langfristige Tragfähigkeit, die Single-Thread-Leistung von Python aufrechtzuerhalten; einige argumentieren, dass unvermeidlicher Overhead und steigende Komplexität die Leistung am Ende verschlechtern werden.
• Der Text blickt auf den Übergang von Python 2 zu Python 3 zurück, zwischen denen keine Kompatibilität bestand.
• Der Autor argumentiert, dass die Folgen der Inkompatibilität von Python 3 zu Python 2 für manche vorhersehbar waren, entgegen der verbreiteten Ansicht, und teilt dazu einen Link auf einen Blogbeitrag aus dem Jahr 2007.
• Der Autor betont, wie wichtig die Lehren aus dem Übergang von Python 2 zu Python 3 sind, um ähnliche Probleme in Zukunft zu vermeiden.
• Abschließend würdigt der Artikel die Weitsicht derjenigen, die die Herausforderungen des Übergangs von Python 2 zu Python 3 vorausgesehen haben.

[GN⁺]

Hacker-News-Kommentare

• Diskussion des Artikels über die Entfernung des Global Interpreter Lock (GIL) und das Projekt für ein schnelleres CPython.
• Einige Kommentatoren sind der Ansicht, dass der Artikel die Vorteile der GIL-Entfernung nicht ausreichend hervorhebt und stärker auf die „Anti-GIL“-Seite ausgerichtet ist.
• Sam Gross’ Arbeit am no-GIL-Projekt wird für ihre hohe Qualität und die damit verbundenen Performance-Verbesserungen gelobt.
• Die Community zeigte großes Interesse an dem Projekt, und der Steering Council plant, PEP 703, den zugehörigen Vorschlag, anzunehmen.
• Einige Kommentatoren äußern Bedenken, dass die Entfernung des GIL negative Auswirkungen auf multithreaded Python-Code haben könnte.
• Die Entscheidung, das Projekt zunächst im Testmodus voranzutreiben, wirkt vernünftig, doch es gibt Bedenken, dass bei potenziellen Bugs und Schwierigkeiten mehr Ressourcen nötig sein werden.
• Einige Kommentatoren halten die Entfernung des GIL für einen Fehler, da sie zu Performance-Einbußen führen und andere potenzielle Verbesserungen verdrängen könnte.
• Andere schlagen vor, Single-Thread-Performance zu priorisieren und virtuelle Prozesse mit einem klaren Mechanismus für das Teilen von Speicher hinzuzufügen.
• Sam Gross’ Vorantreiben des Projekts wird gelobt; obwohl der Weg zu einem no-GIL-Python lang und steinig ist, wirkt er wie eine positive Entwicklung.
• Es gibt Bedenken hinsichtlich der Sicherstellung der Korrektheit bestehender Codebasen und der steigenden Wartungskosten, wenn GIL/no-GIL zu einem Compile-Time-Switch wird.
• Die Python-Community wird für ihre Transparenz und gute Governance gelobt, zugleich gibt es angesichts des Werts, den die Tech-Industrie aus Python zieht, Forderungen nach mehr Unterstützung aus der Branche.
• Einige Kommentatoren stellen infrage, ob es akzeptabel wäre, wenn Single-Thread-Code infolge des Projekts 15–20 % langsamer würde.