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

• Der Python Steering Council hat seine Bereitschaft signalisiert, PEP 703 anzunehmen, womit die Entfernung des GIL aus CPython in einen langen schrittweisen Prozess eintritt – von experimentellen Builds bis zur Umschaltung auf den Standardmodus
• Die Entfernung des GIL kann die Multithreading-Leistung freisetzen, könnte aber Kosten bei der Single-Thread-Performance, die den Großteil des bestehenden Ökosystems betrifft, sowie bei der Kompatibilität mit C-Erweiterungen verursachen
• Das Faster-CPython-Team sieht, dass der auf PEP 659 basierende spezialisierte adaptive Interpreter auf den GIL angewiesen ist und daher in einer no-GIL-Umgebung Optimierungsstrategien und Wartungsaufwand neu bewerten muss
• Meta erklärte, im Fall der Annahme von PEP 703 bis Ende 2025 3 engineer-years zu investieren, und Anaconda sagte Unterstützung bei Packaging-Arbeiten rund um pip, cibuildwheel und conda-forge zu
• Der Übergang soll einen Bruch wie bei Python 2→3 vermeiden und kann bis zur Festlegung als Standardmodus zurückgenommen werden, falls sich herausstellt, dass das Chaos von no-GIL größer ist als der Nutzen

---

Die Debatte über die Entfernung des GIL in Python nimmt wieder Fahrt auf

• Der Global Interpreter Lock (GIL) von Python serialisiert den Zugriff auf die virtuelle Maschine des Interpreters so, dass immer nur ein Thread gleichzeitig Python-Code ausführen kann
• Der GIL, der Leistungssteigerungen durch die Nutzung mehrerer Threads blockiert, gilt seit Langem als eine bekannte Schwäche von Python
• Sam Gross veröffentlichte im Oktober 2021 eine Proof-of-Concept-Version von no-GIL Python; nach dem anfänglichen Interesse gab es mehr als ein Jahr lang nur begrenzte Fortschritte
• Danach verkündete der Python Steering Council seine Bereitschaft, die no-GIL-Funktionalität zu akzeptieren
  • Bis sie in einer tatsächlichen Release-Version landet, wird es Zeit brauchen
  • Es bleibt möglich, dass die Arbeit zu einem späteren Zeitpunkt wieder zurückgenommen wird
  • Durch die Unterstützung mehrerer Unternehmen steigen die Erfolgschancen

Das Spannungsverhältnis zwischen Faster CPython und Single-Thread-Performance

• Beim Python Language Summit 2022 stellte Gross den no-GIL-Fork vor und versuchte, eine implizite Zustimmung für die Fortführung der Arbeit zu erhalten, doch da die konkreten Auswirkungen nicht ausreichend bekannt waren, kam kein Konsens zustande
• Zur gleichen Zeit konzentrierte sich das Projekt Faster CPython auf die Verbesserung der Single-Thread-Performance des Interpreters
• Mark Shannon verfasste PEP 659, den „Specialized Adaptive Interpreter“, und ein Teil dieser Änderungen floss in Python 3.10 und 3.11 ein
• Auf der PyCon stellte Brandt Bucher aus dem Faster-CPython-Team adaptive Instruktionen vor, während Shannon Verbesserungen am Speicherlayout und andere Optimierungstechniken präsentierte
• Bestehende Python-Programme sind wegen des GIL fast immer Single-Thread-Programme, daher wirkt sich eine Verbesserung der Single-Thread-Performance direkt auf die wahrgenommene Leistung des gesamten Python-Ökosystems aus

Der PEP-703-Vorschlag und erste Bedenken

• Łukasz Langa veröffentlichte im Januar 2023 die erste Version von PEP 703, „Making the Global Interpreter Lock Optional in CPython“, verfasst von Gross
• Neben der Erwartungshaltung gegenüber no-GIL rückten auch in C geschriebene Python-Erweiterungsmodule als zentrales Problem in den Fokus
  • Der GIL hat in C-Erweiterungscode bislang viele Nebenläufigkeitsprobleme verhindert
  • Seine Entfernung kann in diesem Code neue Bugs erzeugen
• Es bestand Einigkeit darüber, einen Flag-Day-Übergang wie bei Python 2 auf 3 zu vermeiden
  • Der Übergang zur GIL-Entfernung muss auch mit noch nicht vorbereitetem Code reibungslos funktionieren
• Shannon fragte, welche Leistungseinbußen bei Single-Thread-Code akzeptabel seien; seine eigene Schätzung lag bei 15–20 % und könnte je nach Auswirkung auf PEP 659 noch höher ausfallen
• Eric Snow veröffentlichte aus Sicht des Autors von PEP 684 „Per-Interpreter GIL“ und PEP 683 „Immortal Objects“ eine ausführliche Analyse und war der Ansicht, dass sich no-GIL und der Subinterpreter-Ansatz nicht zwingend ausschließen

Kosten und Nutzen für C-Erweiterungen

• Gross antwortete, dass die Auswirkungen auf C-Erweiterungen nicht nur negativ seien
• Das PEP enthält Zitate von Maintainer:innen weit verbreiteter C-API-Erweiterungen über die Komplexität, die ihnen die Umgehung des GIL bereits heute verursacht
• PyTorch-Core-Developer Zachary DeVito erklärte, er habe in den letzten Monaten dreimal mehr Zeit damit verbracht, GIL-Beschränkungen zu umgehen, als tatsächliche Probleme zu lösen
• no-GIL kann Maintainer:innen von Erweiterungsmodulen neue Nebenläufigkeitsprobleme bringen, gleichzeitig aber die Komplexität zur Umgehung des GIL verringern

Aktualisiertes PEP und Leistungsdebatte

• Anfang Mai 2023 veröffentlichte Gross eine PEP-703-Implementierung auf Basis einer Python-3.12-Entwicklerversion sowie ein aktualisiertes PEP
• Am 12. Mai bat er den Steering Council um eine Entscheidung zum PEP, doch bis zur Entscheidung gingen die Diskussionen weiter
• Am 2. Juni bewertete Shannon die Performance-Auswirkungen des PEP und nannte einen Bereich von 11–30 %, was eine Kontroverse auslöste
• Shannon war der Ansicht, dass der adaptive spezialisierte Interpreter auf dem GIL beruht und daher bei einer Annahme von no-GIL die Optimierungsstrategie neu entworfen werden müsse
  • Der Aufwand für Neudesign und Implementierung könnte dann nicht in die eigentliche Optimierungsarbeit fließen
• Langa veröffentlichte Benchmark-Zahlen, die deutlich geringere Auswirkungen als in Shannons Schätzung zeigten; weitere Ergebnisse lagen nahe bei dem, was Gross im PEP berichtet hatte

Lehren aus dem Übergang von Python 2 zu 3

• Guido van Rossum meinte, der Übergang wäre leichter gewesen, wenn Python-2- und Python-3-Code im selben Interpreter hätten koexistieren können
• Wenn no-GIL verfolgt wird, sollten auch Erweiterungsmodule, die den GIL benötigen, in einem no-GIL-Interpreter ohne zusätzliche Arbeit importierbar sein, betonte er
  • Auch der Anwendungscode sollte nicht angepasst werden müssen
  • Auch Erweiterungsmodule sollten nicht angepasst werden müssen
• Gregory P. Smith vom Steering Council erklärte, der Einflussbereich von PEP 703 sei so groß, dass man noch nicht bereit sei, sofort zu entscheiden
• Smith erkannte zwar die Nachfrage an, meinte aber, man müsse das gesamte Ökosystem berücksichtigen und einen Übergangsweg finden, der nicht die Welt kaputtmacht
• Gross reagierte, dass ein Aufschub ohne klare Annahmekriterien und Zeitplan in der Praxis wie ein „No“ wirke

Die drei Optionen aus Sicht des Faster-CPython-Teams

• In der Diskussion „A fast, free threading Python“ fasste Shannon drei Optionen für die Zukunft zusammen
  • Wie geplant einen schnellen Single-Thread-Interpreter verfolgen
  • Einen no-GIL-Free-Threading-Interpreter verfolgen, der unbekannte, aber nicht null Auswirkungen auf die Single-Thread-Performance hat
  • Beides gleichzeitig verfolgen
• Shannon meinte, man müsse entscheiden, was eingeschränkt werden solle: Performance, Parallelität oder Mutabilität
  • Er formulierte es eher als „Performance, Parallelität, Mutabilität: eine davon muss eingeschränkt werden“ statt als „pick two“
• Um Python in einer Free-Threading-Umgebung schnell zu machen, sei originäre Forschung nötig; Kosten und Risiken seien höher
• Seine bevorzugte Option war die dritte, doch man dürfe nicht nur no-GIL wählen und dann hoffen, „dass schon jemand die Performance-Probleme lösen wird“
• Auch van Rossum hielt es für am besten, Free Threading und schnelle per-thread Performance gemeinsam zu erreichen, betonte jedoch den Bedarf an zusätzlichen Ressourcen

Unterstützung aus Unternehmen und Stimmung unter den Core-Developern

• van Rossum erklärte, Microsoft werde das Faster-CPython-Team weiterhin unterstützen und dessen Rolle sei nicht auf Arbeiten zur Single-Thread-Performance beschränkt
• Ziel sei es, Spezialisierungs- und Optimierungsarbeit auf eine no-GIL-Welt auszurichten, um letztlich no-GIL ohne Einbußen bei der Single-Thread-Performance zum einzigen Build-Modus zu machen
• Carl Meyer von Meta erklärte, dass Meta bei Annahme von PEP 703 bis Ende 2025 3 engineer-years investieren werde
  • Ingenieur:innen mit Erfahrung im CPython-Inneren würden mit dem Core-Dev-Team zusammenarbeiten
  • Die PEP-703-Implementierung nahtlos in CPython integrieren
  • Kompatibilität und Performance von no-GIL-CPython fortlaufend verbessern
• Stan Seibert von Anaconda erklärte, man werde Packaging-Probleme im Zuge der Übernahme von PEP 703 unterstützen
  • Einschließlich Arbeiten rund um pip, cibuildwheel und conda-forge
  • Einschließlich der Arbeiten, die nötig sind, um no-GIL-kompatible Pakete in die Python-Community zu bringen
• In einer Umfrage unter Core Developern antworteten 87 % von 46 Personen, dass man ein free-threaded Python aktiv vorantreiben solle, und 63 % von 38 Personen erklärten, sie seien bereit, zur Unterstützung und Wartung eines auf PEP 703 basierenden no-GIL-Python beizutragen

Entscheidung des Steering Council und schrittweiser Übergang

• Am 28. Juli verkündete Thomas Wouters, dass der Steering Council PEP 703 annehmen werde, die Details der Annahme aber noch ausgearbeitet würden
• Zuerst soll ein no-GIL-Interpreter eingeführt werden, um Lücken zu identifizieren und die nötige Arbeit zu leisten, bevor no-GIL zum Standard und schließlich zur einzigen Version wird
• Der Übergangszeitraum wird auf etwa 5 Jahre geschätzt
• Der Council will keine Situation wie bei Python 3; Änderungen an Third-Party-Code, die für no-GIL-Builds nötig sind, sollen auch in with-GIL-Builds unverändert funktionieren
• Kurzfristig ist ein experimenteller no-GIL-Build vorgesehen, möglicherweise schon mit Python 3.13
  • Python 3.13 ist für Oktober 2024 geplant
  • Ein Build, mit dem Core Developer und andere experimentieren können
• Mittelfristig wird no-GIL zu einer unterstützten Option, aber nicht zum Standard
  • Der Zeitpunkt hängt stark davon ab, wie schnell die Community no-GIL-Builds übernimmt und unterstützt
• Langfristig wird no-GIL der Standard-Build und der GIL vollständig entfernt
  • Dies muss geschehen, ohne unnötig die Abwärtskompatibilität zu brechen

Die Arbeit ist noch lange nicht abgeschlossen

• Wouters betonte, dass die Entfernung des GIL viel mehr Arbeit ist als nur die Annahme eines einzelnen PEP
• Die Core Developer müssen Erfahrungen mit no-GIL-Python sammeln und auf dieser Basis die übrige Community anleiten
• Beim Aufräumen der Thread-Sicherheit bestehenden Codes könnten neue C-APIs und Python-APIs nötig werden
• Während des gesamten Prozesses müssen Fortschritt und Zeitplan regelmäßig neu bewertet werden
  • Es darf nicht in einen weiteren zehnjährigen Kampf um Abwärtskompatibilität ausarten
  • Wenn sich PEP 703 als problematisch erweist, muss man anhalten und nach einer anderen Lösung suchen können
• Bis zu einem Python nur noch mit no-GIL bleiben noch viel Forschung, Coding, Tests, Experimente und Dokumentation zu erledigen; als mögliches Beispiel wurde Python 3.17 im Oktober 2028 genannt

[GN⁺]

Meinungen auf Hacker News

• Der Artikel ist gut geschrieben und fasst den gesamten Prozess gut zusammen, legt den Schwerpunkt aber eher auf die Seite der Gegner der GIL-Entfernung und auf die Möglichkeit eines Scheiterns.
  Auch die Gegenseite sollte ausreichend betont werden. Die Qualität von Sam Gross’ Arbeit ist sehr hoch, und er hat auch Performance-Verbesserungen eingebaut, die nicht direkt mit no-GIL zusammenhängen, um Performance-Verluste zu verringern. Auch im Open-Source-Modus hat er sehr gut gearbeitet und Geduld gezeigt, obwohl die Reaktion so langsam war, dass das Steering Council das Thema ohne Druck aus der Community weiter hätte liegen lassen. Subinterpreter haben in Python bisher kaum ihre Nützlichkeit gezeigt, insbesondere nicht anhand ernsthafter Metriken, und dies kommt dem ersten gut definierten und gemessenen Versuch nahe. Auch die Reaktion der Community zeigte großes Interesse an diesem Projekt, und das Steering Council kam zu dem Schluss, man sei „bereit, PEP 703 anzunehmen, und stimme derzeit die genauen Annahmebedingungen ab“. Ich bin kein glühender no-GIL-Befürworter, fände es auch in Ordnung, wenn die GIL am Ende nicht entfernt wird, und denke, man sollte zuerst Subinterpreter ausprobieren, aber man sollte fair darauf schauen.

  • Auch auf der Subinterpreter-Seite läuft viel Arbeit, und eine GIL pro Interpreter kommt in Python 3.12.
    Die Ergebnisse sind ebenfalls ziemlich beeindruckend: https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. Es scheint so gut ausgefallen zu sein, wie man es erwarten konnte. Die Arbeit an Subinterpretern wird wohl parallel zur Free-Threading-Arbeit laufen, und beide haben unterschiedliche Anwendungsfälle.
  • Was mich persönlich an Python am meisten stört, ist PEP 582, „Python local packages directory“: https://peps.python.org/pep-0582/
    Soweit ich weiß, unterstützt PDM das noch. Ich mag es nicht, für Build und Deployment virtualenv zu verwenden, und fände es gut, wenn Python sich ähnlich wie JavaScript verhalten könnte. Dass das möglich ist, wurde bereits bewiesen. Der Diskussions-Thread ist unter https://discuss.python.org/t/pep-582-python-local-packages-d.... Frustrierend ist auch, dass „genau ein richtiger Weg“ wie ein Ablehnungsgrund verwendet wird; bei Python hatte ich nie das Gefühl, dass diese Aussage stimmt.
  • Ich würde gern nur die Performance-Patches sehen, ohne den no-GIL-Teil.
  • Ich frage mich, warum Leute gegen die Entfernung der GIL sind.

• Ein hervorragender Artikel von LWN, der sich sehr gelohnt hat zu lesen. Als Sam Gross’ NoGIL erstmals auftauchte, war ich erwartungsvoll, aber nach der Lektüre des Artikels und mit Blick auf meine eigenen Erfahrungen begann sich meine Meinung zu ändern.
  Ich habe Backend-Systeme in mehreren Sprachen gebaut, und im Großen und Ganzen gab es nur zwei Arten. Die eine öffnet einen Netzwerk-Endpunkt, nimmt Requests entgegen, führt Berechnungen und andere Netzwerk-Requests aus und antwortet dann; die andere liest Nachrichten aus einer Queue oder Datenbank, durch Polling anderer APIs usw., führt Berechnungen und Netzwerkaufrufe aus und schickt sie dann in eine andere Queue. Beim ersten Typ ist Latenz wichtig, beim zweiten Durchsatz. Beim ersten Typ ist NoGIL nützlich, weil man pro Request Threads starten kann, rechenintensive Endpunkte andere Requests nicht blockieren und man einen Datenbank-Connection-Pool teilen möchte. Beim zweiten Typ kann ich mich selbst in Sprachen ohne GIL kaum daran erinnern, Parallelität oder Concurrency innerhalb eines Prozesses mit gemeinsamen Ressourcen genutzt zu haben; es wird einfach zu schwer zu verstehen. Optimierung bestand meist in intelligenter Batch-Verarbeitung, und Parallelität bedeutete, mehrere unabhängige Prozesse auf mehreren Maschinen laufen zu lassen. Wenn NoGIL die Qualität des zweiten Typs von Systemen kompromittieren würde, wäre das ziemlich enttäuschend, und tatsächlich fließt der Großteil meiner mentalen Energie derzeit in die Verbesserung dieses zweiten Typs.

  • Bei einer GUI-Anwendung wie meiner Captain’s-Log-Anwendung ist no-GIL ebenfalls interessant.
    Derzeit implementiere ich den JournalParser mit QThread; dieser Parser liest fortlaufend die Player-Journal-Dateien, die Elite: Dangerous und Odyssey erzeugen, und löst für jedes Event ein eigenes QSignal aus, das dann von Slots verarbeitet wird, die auf dieses Signal hören. Auch in anderen Teilen der Anwendung könnte es recht nützlich sein, keine GIL zu haben. https://captainslog.scarygliders.net/captains-log-2/
  • Aus Sicht eines Hobby-Python-Nutzers werde ich wahrscheinlich nicht direkt Concurrency verwenden, aber mit der Zeit werden Standardbibliothek und beliebte externe Libraries sie wahrscheinlich nutzen.
    Dann kann der Code aller davon profitieren.
  • Man muss Parallelität nicht unbedingt selbst nutzen, um von NoGIL zu profitieren. Zum Beispiel könnten Webserver oder asynchrone Task-Runner Kontext effizienter zwischen Threads teilen.
  • Die GIL wird in CPU-gebundenen Anwendungen wie Machine Learning zum Bottleneck, daher ist es natürlich, dass NoGIL für Leute, die Serveranwendungen schreiben, nicht besonders spannend ist.
    Natürlich könnte man sagen, dass man CPU-zentrierte Programme von vornherein nicht in Python schreiben sollte, aber das ist wieder eine andere Geschichte.
  • Ich baue gerade genau so ein System, und wegen einer großen gemeinsamen Ressource mussten wir die Mehrprozess-Strategie aufgeben.
    Wenn die gemeinsame Ressource nur lesend ist, ist mir nicht ganz klar, warum das verwirrend sein sollte.

• Ich bin skeptisch, ob der Satz im verlinkten Thread „Es ist sehr unwahrscheinlich, dass die Entfernung des GIL eine rein in Python geschriebene Codebase kaputtmacht“ wirklich stimmt.
  Manche nebenläufige Python-Codes könnten dank des GIL erwarten, dass bestimmte Operationen implizit thread-sicher sind. Wenn zum Beispiel zwei Threads Elemente an dieselbe Liste anhängen, wird die Liste nicht beschädigt, weil der GIL verhindert, dass beide Threads diese Operation parallel ausführen. Entfernt man den GIL, könnte solcher Code plötzlich bestraft werden – ähnlich wie in C++, wenn man std::vector gleichzeitig verändert. Ich bin mir nicht sicher, aber dieser Satz wirkt etwas verdächtig. https://discuss.python.org/t/pep-703-making-the-global-inter...

  • Stimmt. Das ist ein Bereich, den der GIL trivialerweise mitgeschützt hat. In Go gibt es einen ähnlichen Fall, bei dem ein gleichzeitiges Ändern derselben map zu einer Panic führt.
    Der Abschnitt Container Thread Safety in PEP 703 behandelt dieses Problem. Vorgeschlagen wird, jeder list, jedem dictionary und jedem set eine leichtgewichtige objektspezifische Sperre zu geben; alle Operationen, die ein Objekt verändern, müssen diese Sperre halten, und auch die meisten Leseoperationen sollen sie halten. Details stehen unter https://peps.python.org/pep-0703/#container-thread-safety.
  • Tatsächlich ist das so, und außer alle Operationen auf eingebauten Datenstrukturen wie bei den frühen Java-Datenstrukturen Hashtable und Vector mit einem Mutex zu schützen, scheint es nicht viele gute Möglichkeiten zu geben.
    Dann bleibt allerdings die Frage, was man macht, wenn man ein nicht synchronisiertes [] braucht.
  • list.append wird vermutlich durch eine Sperre pro Instanz geschützt. Zumindest in manchen nogil-Konzeptcodes ist es so umgesetzt.
  • Als naive Lösung könnte man standardmäßig ein Flag setzen, das den GIL aktiviert, und beim Deaktivieren eine Warnung ausgeben.

• Schwer vorstellbar, dass es in Open Source eine schwierigere Bewährungsprobe gibt.
  Die Entscheidung selbst ist vernünftig: im Testmodus vorangehen, Multi-Interpreter als Zwischenexperiment behandeln, aber als Ziel ein gleichzeitig ausführbares Python setzen. Die Einschränkung, bestehenden und neuen Code in derselben virtuellen Maschine laufen zu lassen, ist allerdings enorm. Es ist überraschend, dass die LWN-Zusammenfassung Tests kaum behandelt; Tests sind noch lange nicht geklärt und könnten zu Releases mit unbekannten, aber schwerwiegenden Bugs führen. Microsoft, Facebook/Meta und Conda stellen Ressourcen bereit, und die überwältigende Mehrheit der Kernbeitragenden will vorankommen; unklar ist aber, was passiert, wenn die Arbeit schwieriger wird und mehr Leute gebraucht werden. Gleichzeitig hängen riesige Projekte in Wissenschaft und Industrie – von Websites über Big Data bis AI – von Python ab, und die auf Python-Entwickler abgewälzten Kosten könnten sich als Anteil am BIP messen lassen. Es scheint noch nicht einmal so, als seien die Probleme bekannt. Daher sollte man sich auf den Faster-CPython-Ansatz konzentrieren, der über die nächsten drei oder mehr Jahre absehbare Verbesserungen bringt, und die Befürworter eines gleichzeitig ausführbaren Python sollten über einfache Prototypen hinaus analysieren, welche Probleme auftreten können, wie man sie erkennt und was man dagegen tun kann. Fairer wäre es, wenn Leute mit Hintergrund im Nachweis von Nebenläufigkeitsgarantien das prüfen und die Fragen erst dann an das Steering Council gehen, wenn zumindest die Unbekannten identifiziert sind. In Open Source gab es nicht viele Entscheidungen im Maßstab von Programmmanagement; oft waren es vergleichsweise einfache Entscheidungen, die wie bei Apache, Eclipse oder Linux die Marktrichtung vorgaben. Diesmal gibt es jedoch echte technische Unbekannte. Gleichzeitig habe ich das Gefühl, dass auch das sprachenübergreifende ABI angegangen werden muss. Das große Problem ist, es mit dem Ausführungsmodell in Einklang zu bringen, das C erwartet. Javas Foreign Function & Memory API befindet sich seit Jahren in der Inkubation, und auch Swift wird beim Wrapping von C und C++ besser, aber FFI ist notorisch schwierig und wahrscheinlich unnötig kompliziert.

  • Wenn die auf Python-Entwickler abgewälzten Kosten als Anteil am BIP messbar sind, gilt dasselbe auch für den Nutzen.

• Persönlich halte ich die Entfernung des GIL für einen Fehler. Es gibt nicht viele Anwendungen, die stark davon profitieren werden, und die meisten werden eine Performance-Strafe zahlen.
  Diese Arbeit wird über Jahre Aufmerksamkeit und Aufwand verschlingen, die man vermutlich klüger hätte einsetzen können. Python wirkt, als hätte es wegen des GIL eine Art Unsicherheit oder Minderwertigkeitskomplex. Ich fände es besser, das Single-Thread-Modell wie JavaScript vollständig zu akzeptieren. Manche Anwendungen bleiben dadurch schwierig oder unmöglich, aber für Anwendungen, die hohe Performance oder hohe Skalierbarkeit brauchen, ist Python meiner Meinung nach ohnehin keine gute Wahl. Ein gewisser Spezialisierungsgrad und nicht alle Use Cases zu unterstützen, ist nicht unbedingt schlecht.

  • Es ist zu spät, den Geltungsbereich von Python so künstlich einzuschränken. Es wird bereits viel in Data Science und Machine Learning eingesetzt.
    Leute brauchen Performance für Dinge, die sie heute schon mit Python tun. Man kann nicht in eine Zeit zurück, in der das nicht der Fall war. Inzwischen ist das einer der häufigsten Use Cases für Python, und Menschen bauen ihre Karriere darauf auf.
  • Das PEP behandelt die Motivation und die Grenzen des Single-Thread-Modells ausführlich: https://peps.python.org/pep-0703/#motivation
    Leute versuchen bereits, parallele Arbeit mit Python zu erledigen. Sie dazu zu zwingen, eine andere Sprache zu verwenden, hilft nicht besonders.
  • In einer Zeit, in der Multiprozessoren seit über zehn Jahren allgegenwärtig sind, sollte man es inzwischen akzeptieren. Umso mehr, wenn die Kosten dank hervorragender Interpreter-Ingenieure fast null oder niedrig sind; persönlich begrüße ich es.
  • Es wäre schön gewesen, von Anfang an Unicode-Unterstützung zu haben, aber daran lässt sich nun nichts mehr ändern. Ich freue mich, dass man diese Aufgabe jetzt angeht.
  • Ich habe immer gedacht, dass ein starker JIT, der mit Cython kompatibel ist und auch zu wichtigen C-Extension-Projekten wie numpy und scipy passt, die wertvollere Anstrengung wäre.
    Viele datenintensive Aufgaben lassen sich in Python relativ einfach als parallele Prozesse ausführen, daher bin ich nicht sicher, ob die Entfernung des GIL wirklich so einen großen Gewinn bringt.

• Die Single-Thread-Performance sollte Vorrang haben, weil sie sich durch mehr Geld viel schwerer verbessern lässt
  Multi-Thread-Performance kann man dadurch verbessern, dass man einen weiteren Core hinzufügt und so den Overhead prozessbasierter Parallelisierung ausgleicht. Ich halte schon die Dichotomie GIL vs. no-GIL für falsch. Das größte Problem bei multiprocessing ist, dass sich Speicher nicht teilen lässt. Man müsste also virtuelle Prozesse mit einem expliziten Mechanismus für Shared Memory hinzufügen. Dann bleiben Objekte in einem Thread, sodass sich Single-Thread-Optimierungen wie Reference Counting ohne Barrieren beibehalten lassen.

  • Der Fehler liegt hier darin, dies als notwendigen Trade-off anzunehmen
    Auch ohne GIL lässt sich gute Single-Thread-Performance erreichen. Rust kennt das Konzept von Zero-Cost-Abstractions und kommt auch gut mit Threads zurecht. Java erledigt Single-Thread-Aufgaben ebenfalls gut. Es gibt viele andere Sprachen; das ist keine Science-Fiction. Locks können durch Optimierung verschwinden, man kann sich auch für lockfreien Code entscheiden, und feingranulare oder strukturierte Nebenläufigkeit ist ebenfalls möglich. Was thread-sicher ist, ist im Grunde ein API-Vertrag. Optimistisches Locking gibt es ebenfalls. Es gibt keinen guten Grund, warum Python nicht Ähnliches tun könnte, aber zuerst muss der GIL entfernt werden. Die Performanceeinbußen von Python ohne GIL sind zu einem erheblichen Teil eher ungelöste technische Schulden und können mit der Zeit behoben werden. Viele Locks einzubauen wirkt wie ein Workaround und macht langsam, aber die richtige Lösung dürfte eher darin bestehen, interne Abläufe neu zu durchdenken oder API-Verträge zu haben, die dokumentieren, ob etwas thread-sicher ist. Schnellere Python-Runtimes und Compiler könnten außerdem ermöglichen, vieles, was heute von nativen Bibliotheken abhängt, wieder in Python zu implementieren. Gerade die Interaktion mit nativem Code ist an vielen Stellen der Punkt, an dem Locks nötig werden, und wenn man diese Art nicht ändert, bleibt es ein Problem. Der Kern der GIL-Entfernung liegt darin, solche Dinge systematisch zu finden und zu beheben, und mit der Zeit wird es besser werden.
  • Stimme zu. Wenn man heute Nebenläufigkeit braucht, ist man vermutlich ohnehin schon zu multiprocessing gewechselt, daher ist no-GIL-Multithreading wenig nützlich
    Das einzige Problem bei Python/multiprocessing ist, dass man manchmal gemeinsam genutzten veränderlichen Zustand statt Queues braucht. Die heutige Art, Python-Objekte in Shared Memory zu legen, ist kompliziert, eingeschränkt und ineffizient. Genau das sollte behoben werden; Python braucht bessere Unterstützung dafür, native Instanzen in Shared Memory abzulegen.

• Auf die Frage, „wie viel Performanceverlust bei Single-Thread-Code akzeptabel wäre“, schätzte Shannon 15–20 %, aber die Frage blieb weitgehend unbeantwortet
  Heißt das also, dass einige Leute in einem Projekt, das „CPython schneller“ machen soll, es akzeptabel finden, den Großteil bestehenden Python-Codes über Nacht um 15–20 % langsamer zu machen? Ich sehe die Grenze eher bei höchstens 5 %. Und selbst das nur, wenn die Entfernung des GIL künftigen anderen Optimierungen hilft. Allerdings heißt es im Gegenteil, dass diese Änderung andere Optimierungen komplizierter macht und verzögert. Gleichzeitig hatte Shannon 2020 persönlich einen Fundraising-Vorschlag gemacht, CPython um den Faktor 5 schneller zu machen, und inzwischen arbeitet ein ganzes Team mit deutlich größerer Unternehmensunterstützung daran, CPython schneller zu machen, aber das Ziel wirkt viel kleiner.

  • Für ungefähr 99 % des heutigen Python-Codes ist hohe Performance von reinem Python-Code womöglich nicht das Hauptanliegen
    Wenn Performance wirklich wichtig ist, ist es viel wert, ohne Rewrite in einer anderen Sprache etwa den Faktor 20 an Geschwindigkeit zu gewinnen.
  • Einige der jüngsten Performanceverbesserungen kamen aus dem no-GIL-Lager, das zeigen wollte, dass auch nach Entfernen des GIL noch viel Optimierungsspielraum bleibt
    Wenn andere Optimierungen nicht gestoppt werden, sondern nur etwas länger dauern, könnte das akzeptabel sein.
  • Ich halte das Projekt Faster CPython für übertrieben vermarktet
    Wenn man realen Code mit numerischen und String-Operationen ohne Netzwerk- oder Plattenzugriffe vergleicht, braucht die 3.12-Beta nur etwa 20–25 % weniger Zeit als 3.8. Das entspricht dem Niveau von 2.7. Es wirkt so, als suchten alteingesessene Schlüsselpersonen verzweifelt nach Bullet-Point-Features, die sie den Unternehmenssponsoren in der nächsten Version vorzeigen können. Deshalb nutzen sie die Arbeit von Sam Gross, aber mit der Zeit werden sie sich die Anerkennung wohl langsam selbst zuschreiben.

• Eine hervorragende Zusammenfassung, ganz LWN-typisch
  Ich mag die Python-Community. Sie ist ein führendes Beispiel für Open-Source-Software und zeigt, was Transparenz und gute Governance erreichen können. Die von Meta, Microsoft usw. investierte Engineering-Zeit ist dankenswert, wirkt aber im Verhältnis zu dem Wert, den die gesamte Tech-Industrie und breitere Bereiche einschließlich Data Science aus Python und Open-Source-Software ziehen, immer noch viel zu gering.

  • Man kann das innerhalb der eigenen Organisation ändern
    Vor 8 Jahren habe ich bei JPMorgan das Tech-Leadership-Team überzeugt, PyCon UK zu sponsern, einen Recruiting-Stand einzurichten und die Teilnahme von Junior-Entwicklern von JPMorgan aus ganz Großbritannien zu unterstützen. Ich habe JPM vor 5 Jahren verlassen, aber sie sind immer noch Headline-Sponsor der PyCon UK. Verglichen mit den enormen Vorteilen, die sie aus Python und dem Open-Source-Ökosystem gezogen haben, waren die Kosten völlig vernachlässigbar.
  • Ich finde, es wird nur so getan, als sei alles transparent, während die tatsächlichen Entscheidungen alle in Hinterzimmern fallen
    Die Mailinglisten werden zensiert, und der innere Zirkel darf nicht kritisiert werden. Echte Beitragende werden von Leuten ausgebeutet, die in den richtigen Unternehmen sitzen, kaum etwas tun und bürokratische Machtpositionen besetzen. LWN-Artikel sind sehr wohlwollend und nennen immer brav die Namen der Entscheidungsträger, man sollte sich davon also nicht täuschen lassen. Für mich ist das eher selektive Berichterstattung.

• Die Art, wie Sam Gross Druck gemacht hat, ist ziemlich beeindruckend. Nach einer positiven, aber unverbindlichen Reaktion des Steering Council hätte er sich auch einfach zurücklehnen und auf Fortschritte warten können; dass er widersprochen und Druck ausgeübt hat, ist sehr hoch anzurechnen.

• Sehr interessant. Dass Sam Gross sagte: „Wir brauchen nicht sofort ein Yes/No, aber wir müssen wissen, wie eine Annahme aussehen würde, und dieses Issue wurde viel zu lange liegen gelassen“, war ein ziemlich mutiger Schritt: https://github.com/python/steering-council/issues/188#issuec...
  Diese Interaktion hätte in viele Richtungen laufen können, aber ich glaube, sie war genau der Anstoß, den das Steering Council brauchte. Bis zu no-GIL Python ist es immer noch ein langer, verschlungener Weg, vermutlich im Umfang von zweistelligen Engineer-Jahren, aber zumindest scheint es nun einen sauberen Pfad zu geben. Der schwierigste Teil wird sein, die Korrektheit bestehender Codebasen zu gewährleisten. Zu sagen, man wolle den Übergang von Python 2 zu 3 nicht wiederholen, ist eine Sache; dass Leute aus Angst vor Bugs Upgrades in der Praxis meiden, selbst wenn man behauptet, es gebe keine Breaking Changes, ist eine ganz andere. Selbst wenn man GIL/no-GIL nur als Compile-Time-Switch anbietet, steigen die Wartungskosten definitiv. Trotzdem denke ich, dass sich dieser Aufwand langfristig lohnen wird. Der GIL ist so etwas wie ein Blitzableiter für Python-Kritik, das sieht man schon an HN-Threads über Python und Parallelität. Wahrscheinlich, weil er etwas ist, auf das Leute direkt zeigen können – „das ist der Grund, warum Python nicht schneller werden kann“ –, ohne den jahrzehntelangen Kontext zu verstehen. In diesem Sinne ist er fast der Endgegner von Chestertons Zaun

  • So optimistisch wirkt das nicht. Die Entscheidung des Steering Council scheint unentschlossen
    Auch unter den neuen Leitlinien besteht weiterhin die Möglichkeit, dass die mehrjährige Arbeit zur Entfernung des GIL am Ende abgelehnt wird