Zusammenfassung

Die Akzeptanz von PEP 703 (Making the Global Interpreter Lock Optional in CPython), wie vom Steering Council angekündigt, beschreibt drei Entwicklungsphasen für die Arbeit zur Entfernung des Global Interpreter Lock. Phase I begann früh in der Entwicklung von Python 3.13 und beinhaltet die Bereitstellung des freigeschalteten (GIL-losen) Python-Builds, der jedoch ausdrücklich als *experimentell* gilt. Phase II würde den freigeschalteten Build offiziell unterstützen, aber weiterhin optional machen, und Phase III würde den freigeschalteten Build zum Standard machen. Aufgrund der vielen Unbekannte zu dieser Zeit wurden die Kriterien für den Übergang zur nächsten Phase absichtlich vage gehalten. Dieses PEP legt klare Erwartungen und Anforderungen für den Übergang zu Phase II fest, die den freigeschalteten Python-Build offiziell unterstützen.

Motivation

Ob man mit PEP 703 fortfährt (und es schließlich zum Standard macht), ist eine Frage, ob die Kosten die Vorteile überwiegen. Die offizielle Unterstützung des freigeschalteten Pythons ist wichtig, um zu signalisieren, dass wir nun an einem Punkt sind, an dem das Design finalisiert ist, die APIs nutzbar und stabil sind und wir zufrieden sind, dass die Kosten für Leistung und Komplexität nicht prohibitiv sind.

Der Übergang zur Stufe "offiziell unterstützt" ist ein wichtiger Schritt zur Standardisierung des freigeschalteten Pythons und schließlich zu dessen einzigem Build. Bevor wir entscheiden können, dass wir bereit sind, ihn zum Standard zu machen, benötigen wir ein viel besseres Bild der Kosten und Vorteile, und das können wir nur erreichen, wenn mehr Ökosysteme von Python den freigeschalteten Python unterstützen. Wir haben derzeit genügend Pakete und Tools, die PEP 703 unterstützen, sodass klar ist, dass wir auf dem richtigen Weg sind, aber nicht genug, um die endgültige Entscheidung zu treffen. Zusätzlich zur Zeit, die der Python-Community eingeräumt wird, um die notwendigen Änderungen zur Unterstützung des freigeschalteten Pythons vorzunehmen, erwarten wir, Phase II zu nutzen, um klare Vorteile in realen Anwendungen aufzuzeigen und die Kosten in Bezug auf Leistung, Support-Aufwand und Ökosystem-Komplexität klar zu definieren.

Begründung

Damit PEP 703 akzeptabel ist, sollte es wünschenswert, stabil, wartbar, performant (in Bezug auf CPU und Speicher) sein und idealerweise eine stabile ABI haben, sodass dieselben Wheels sowohl für freigeschaltete als auch für GIL-unterstützte Builds verwendet werden können.

• Wünschbarkeit: Aus verschiedenen Experimenten geht klar hervor, dass freigeschaltetes Python ein enormes potenzielles Nutzen hat. Es ist keine einfache Plug-and-Play-Lösung – einige Codes müssen neu gestaltet werden, um das Potenzial der neuen Funktion voll auszuschöpfen und Leistungseinbrüche zu vermeiden – aber es kann höhere Leistung, deutlich geringere Latenzzeiten und neue thread-basierte Funktionalität erzielen, wenn es angenommen wird.
• Stabilität: Die Mehrheit des neuen API-Designs befindet sich in 3.13 und wird erfolgreich zur Unterstützung des freigeschalteten Pythons in einer Reihe von Drittanbieterpaketen verwendet (siehe zum Beispiel https://py-free-threading.github.io/tracking/). Es gab weitere Entwicklungen in 3.14, um mehr Komfortfunktionen hinzuzufügen und APIs zu ersetzen, die zuvor für Thread-Sicherheit auf den GIL angewiesen waren, aber wir mussten die 3.13-APIs für freigeschaltetes Python nicht ändern.
• Wartbarkeit: Die Mehrheit des Designs von PEP 703 ist relativ einfach, wobei die meiste Komplexität hinter den bestehenden C-APIs von CPython verborgen ist. Die Implementierungsdetails von beispielsweise Lockless Listen- und Dictionary-APIs, die auf QSBR basieren, und Deadlock-vermeidende kritische Abschnitte können komplex und schwierig zu realisieren sein, bieten uns aber einfach zu bedienende APIs ohne allzu viele Fallstricke. Mehr Teile von CPython freigeschaltet-sicher zu machen, ist ein relativ einfacher Prozess, obwohl wir wahrscheinlich mehr Dokumentation über die grundlegenden Garantien benötigen, die die neuen APIs bieten (https://github.com/python/cpython/issues/128642).
• Leistung: Die Leistungsstrafe für die lineare Leistung im Vergleich zwischen einem freigeschalteten Build und einem mit-GIL-Build, gemessen an den pyperformance-Benchmarks (zum Beispiel ausgeführt vom Microsoft Faster CPython-Team oder dem Python Runtime-Team von Meta), beträgt derzeit etwa 10 % (außer unter macOS, wo sie eher bei 3 % liegt). Wir haben noch einige weitere PRs in Arbeit, die uns unter Linux und Windows komfortabel unter 10 % bringen sollten.
• Speichernutzung. Genaue Zahlen variieren aufgrund der unterschiedlichen Implementierung des gc-Moduls, aber freigeschaltetes Python weist derzeit eine um etwa 15–20 % höhere Speichernutzung auf (geometrisches Mittel, gemessen an pyperformance). Wir haben noch nicht viel Zeit damit verbracht, dies zu senken, daher können wir dies möglicherweise noch weiter reduzieren. Realistisch gesehen ist die höhere Speichernutzung jedoch der Preis für effizientes, sicheres freigeschaltetes Threading, und es ist unwahrscheinlich, dass wir dies ohne erhebliche Leistungseinbußen sehr nahe an die Speichernutzung des mit-GIL-Builds heranbringen.
• Stabile ABI. Die Unterstützung einer stabilen ABI wird vom Steering Council als potenzielle Anforderung für Phase II erwähnt. Obwohl die Unterstützung einer stabilen ABI die Verteilung von Drittanbieterpaketen erheblich erleichtern würde, gibt es ein gewisses Henne-Ei-Problem: Wir wissen nicht, ob die stabile ABI gut genug ist, wenn wir keine Pakete haben, die freigeschaltetes Python damit unterstützen, und wir können keine Dinge aus der stabilen ABI entfernen, wenn wir Probleme damit feststellen. Angesichts dessen, dass Phase II dazu dient, der Community Zeit zu geben, freigeschaltetes Python zu adoptieren und Feedback zu APIs und ABIs zu geben, sind wir uns nicht sicher, wie stark die stabile ABI für Phase II sein sollte.

Spezifikation

Spezifische Kriterien für die offizielle Unterstützung von freigeschaltetem Python (Phase II), wie wir sie vorschlagen

• Akzeptable Leistung. Der Steering Council erwähnte, dass freigeschaltetes Python etwa 10–15 % langsamer sein würde, obwohl dies kein hartes Ziel war. Wir liegen derzeit bei etwa 10 % und erwarten nicht, dass es langsamer wird, aber für Phase II (nicht der Standard-Flip) schlagen wir 15 % als hartes Leistungsziel vor.
• Akzeptable Speichernutzung. Dies wurde vom Steering Council nicht erwähnt und hat wenig Diskussion erfahren. Wir schlagen für Phase II ein Ziel von 20 % (geometrisches Mittel, gemessen an pyperformance) vor. Für Phase III benötigen wir Input von der Community, wo der Kompromiss zwischen Speicher- und CPU-Leistung enden soll.
• Nachgewiesene, stabile APIs. Dies ist schwer zu messen, aber wir haben eine signifikante Akzeptanz von freigeschaltetem Python mit den bestehenden APIs gesehen und mussten keine bestehenden APIs radikal ändern, um sie anzupassen. Wir werden wahrscheinlich in Zukunft noch einige weitere Komfort-APIs für spezifische Anwendungsfälle hinzufügen, aber wir glauben, dass wir die Machbarkeit und Stabilität der von uns vorhandenen APIs bewiesen haben. Wir haben keine Breaking Changes bei neuen APIs benötigt und erwarten, dass alle zukünftigen Änderungen der Änderungsrichtlinie von PEP 387 folgen.
• Interne Dokumentation. Wir haben mehrere Core Developer, die an freigeschaltetem Python arbeiten, darunter auch einige, die kürzlich mit der Behebung von Thread-Sicherheitslücken in bestimmten Modulen begonnen haben, aber wir müssen wahrscheinlich die einleitende Dokumentation für die Interna des freigeschalteten Pythons aufstocken. Dies sollte für 3.14 kein Problem darstellen.

Mit diesen Kriterien glauben wir, dass Python 3.14 der richtige Zeitpunkt für Phase II von PEP 703 ist.

(Beachten Sie, dass dies nur Anforderungen für den Eintritt in Phase II sind. Die Entscheidung, freigeschaltetes Python zum Standard zu machen (Phase III), ist ganz anders und wir erwarten, dass sie sich um Community-Unterstützung, Bereitschaft und klare Vorteile drehen wird. Das ist für ein zukünftiges PEP reserviert.)

Offene Fragen

• Sollte die stabile ABI eine starke Anforderung für den "unterstützten" Status des freigeschalteten Builds sein?

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.