Die GIL erschwert den Ausdruck vieler Arten von Parallelität

Neuronale Netz-basierte KI-Modelle bieten mehrere Möglichkeiten zur Parallelisierung. Beispielsweise können einzelne Operationen intern parallelisiert werden („intra-operator“), mehrere Operationen können gleichzeitig ausgeführt werden („inter-operator“) und Anfragen (die mehrere Operationen umfassen) können ebenfalls parallelisiert werden. Eine effiziente Ausführung erfordert die Ausnutzung mehrerer Arten von Parallelität [1].

Die GIL erschwert die effiziente Formulierung von Inter-Operator-Parallelität sowie einiger Formen von Anfrage-Parallelität in Python. In anderen Programmiersprachen könnte ein System Threads verwenden, um verschiedene Teile eines neuronalen Netzes auf separaten CPU-Kernen auszuführen, aber dies ist in Python aufgrund der GIL ineffizient. Ebenso nutzen latenzempfindliche Inferenz-Workloads häufig Threads, um Anfragen zu parallelisieren, stoßen aber in Python auf dieselben Skalierungsschranken.

Die Herausforderungen, die die GIL für die Ausnutzung von Parallelität in Python darstellt, treten häufig im Bereich des Reinforcement Learning auf. Heinrich Kuttler, Autor der NetHack Learning Environment und Mitglied des Technical Staff bei Inflection AI, schreibt

Jüngste Durchbrüche im Reinforcement Learning, wie bei Dota 2, StarCraft und NetHack beruhen auf dem parallelen Ausführen mehrerer Umgebungen (simulierte Spiele) mittels asynchroner Actor-Critic-Methoden. Einfache multithreaded Implementierungen in Python skalieren aufgrund von GIL-Konflikten nicht über wenige parallele Umgebungen hinaus. Multiprocessing mit Kommunikation über Shared Memory oder UNIX-Sockets fügt viel Komplexität hinzu und schließt im Wesentlichen die Interaktion mit CUDA von verschiedenen Workern aus, was den Designraum stark einschränkt.

Manuel Kroiss, Softwareentwickler bei DeepMind im Reinforcement Learning Team, beschreibt, wie die von der GIL ausgehenden Engpässe dazu führen, Python-Codebasen in C++ neu zu schreiben, wodurch der Code weniger zugänglich wird.

Wir kämpfen bei DeepMind häufig mit Problemen der Python-GIL. In vielen unserer Anwendungen möchten wir etwa 50-100 Threads pro Prozess ausführen. Wir stellen jedoch oft fest, dass die GIL bereits bei weniger als 10 Threads zum Flaschenhals wird. Um dieses Problem zu umgehen, verwenden wir manchmal Subprozesse, aber in vielen Fällen wird die Interprozesskommunikation zu einem zu großen Overhead. Um mit der GIL umzugehen, übersetzen wir meist große Teile unserer Python-Codebasis in C++. Das ist unerwünscht, da es den Code für Forscher weniger zugänglich macht.

Projekte, die mit mehreren Hardwaregeräten interagieren, stehen vor ähnlichen Herausforderungen: Eine effiziente Kommunikation erfordert die Nutzung mehrerer CPU-Kerne. Das Dose-3D-Projekt zielt darauf ab, die Krebsstrahlentherapie mit präziser Dosisplanung zu verbessern. Es verwendet medizinische Phantome (Stellvertreter für menschliches Gewebe) zusammen mit kundenspezifischer Hardware und einer in Python geschriebenen Serveranwendung. Paweł Jurgielewicz, leitender Softwarearchitekt für das Datenerfassungssystem des Dose-3D-Projekts, beschreibt die Skalierungsprobleme, die durch die GIL verursacht werden, und wie die Verwendung eines Forks von Python ohne GIL das Projekt vereinfacht hat.

Im Dose-3D-Projekt war die Hauptaufgabe, eine stabile, nicht-triviale parallele Kommunikationsverbindung mit Hardwareeinheiten aufrechtzuerhalten und gleichzeitig eine 1 Gbit/s UDP/IP-Verbindung maximal zu nutzen. Natürlich haben wir mit dem multiprocessing-Paket begonnen, aber irgendwann wurde klar, dass die meiste CPU-Zeit für die Datenübertragungen zwischen den Datenverarbeitungsstufen verbraucht wurde, nicht für die Datenverarbeitung selbst. Auch die CPython-Multithreading-Implementierung basierend auf der GIL war eine Sackgasse. Als wir von dem "nogil"-Fork von Python erfuhren, brauchte eine einzelne Person weniger als einen halben Arbeitstag, um die Codebasis an die Verwendung dieses Forks anzupassen, und die Ergebnisse waren erstaunlich. Jetzt können wir uns auf die Entwicklung des Datenerfassungssystems konzentrieren, anstatt die Datenaustauschalgorithmen zu optimieren.

Allen Goodman, Autor von CellProfiler und Staff Engineer bei Prescient Design und Genentech, beschreibt, wie die GIL die Forschung an biologischen Methoden in Python erschwert.

Probleme mit der globalen Interpreter-Sperre von Python sind eine häufige Quelle der Frustration in der gesamten Forschung an biologischen Methoden.

Ich wollte die aktuelle Multithreading-Situation besser verstehen und habe Teile von HMMER, einer Standardmethode für die multiple Sequenzalignierung, neu implementiert. Ich habe diese Methode gewählt, weil sie sowohl die Ein-Thread-Leistung (Scoring) als auch die Multi-Thread-Leistung (Suche in einer Sequenzdatenbank) beansprucht. Die GIL wurde zum Flaschenhals, als ich nur acht Threads verwendete. Dies ist eine Methode, bei der die derzeit gängigen Implementierungen auf 64 oder sogar 128 Threads pro Prozess setzen. Ich habe versucht, auf Subprozesse umzusteigen, wurde aber durch die prohibitiven IPC-Kosten blockiert. HMMER ist eine relativ elementare Bioinformatik-Methode und neuere Methoden haben weitaus größere Multithreading-Anforderungen.

Methodenforscher flehen darum, Python zu nutzen (einschließlich meiner selbst), wegen seiner Benutzerfreundlichkeit, des Python-Ökosystems und weil „es das ist, was die Leute kennen“. Viele Biologen kennen nur wenig Programmierung (und das ist fast immer Python). Solange die Multithreading-Situation von Python nicht geklärt ist, werden C und C++ die Lingua Franca der biologischen Methoden-Forschungsgemeinschaft bleiben.

Die GIL beeinträchtigt die Benutzerfreundlichkeit von Python-Bibliotheken

Die GIL ist ein Implementierungsdetail von CPython, das die parallele Ausführung von Threads einschränkt, sodass es unintuitiv erscheinen mag, sie als Usability-Problem zu betrachten. Allerdings kümmern sich Bibliotheksautoren häufig sehr um die Leistung und entwerfen APIs, die die Umgehung der GIL unterstützen. Diese Workarounds führen oft zu APIs, die schwieriger zu verwenden sind. Folglich können Benutzer dieser APIs die GIL als Usability-Problem und nicht nur als Performance-Problem erfahren.

Zum Beispiel bietet PyTorch eine multiprocessing-basierte API namens DataLoader zum Erstellen von Dateneingabepipelines an. Sie verwendet fork() unter Linux, da dies im Allgemeinen schneller ist und weniger Speicher verbraucht als spawn(), was jedoch zu zusätzlichen Herausforderungen für Benutzer führt: Das Erstellen eines DataLoader nach dem Zugriff auf eine GPU kann zu verwirrenden CUDA-Fehlern führen. Der Zugriff auf GPUs innerhalb eines DataLoader-Workers führt schnell zu Out-of-Memory-Fehlern, da Prozesse keine CUDA-Kontexte teilen (im Gegensatz zu Threads innerhalb eines Prozesses).

Olivier Grisel, scikit-learn-Entwickler und Softwareingenieur bei Inria, beschreibt, wie die Notwendigkeit, die GIL in scikit-learn-bezogenen Bibliotheken zu umgehen, zu einer komplexeren und verwirrenderen Benutzererfahrung führt.

Im Laufe der Jahre haben scikit-learn-Entwickler Hilfsbibliotheken wie joblib und loky gepflegt, um einige der Einschränkungen von multiprocessing zu umgehen: zusätzlicher Speicherverbrauch, der teilweise durch halbautomatische Speicherabbildung großer Datenpuffer gemildert wird, langsame Worker-Starts durch transparente Wiederverwendung eines Pools von langlebigen Workern, Fork-Sicherheitsprobleme von Drittanbieter-Native-Runtime-Bibliotheken wie GNU OpenMP durch die ausschließliche Verwendung der nur-Fork-Startmethode, die Fähigkeit, parallele Aufrufe von interaktiv definierten Funktionen in Notebooks und REPLs plattformübergreifend über cloudpickle durchzuführen. Trotz unserer Bemühungen ist diese multiprocessing-basierte Lösung immer noch fragil, wartungsintensiv und für Data Scientists mit begrenztem Verständnis von Systembeschränkungen verwirrend. Darüber hinaus gibt es immer noch irreduzible Einschränkungen wie den Overhead, der durch die Pickle-basierten Serialisierungs-/Deserialisierungsschritte für die Interprozesskommunikation verursacht wird. Viel von dieser zusätzlichen Arbeit und Komplexität wäre nicht mehr nötig, wenn wir Threads ohne Konflikte auf Multi-Core-Hosts (manchmal mit 64 physischen Kernen oder mehr) verwenden könnten, um Data-Science-Pipelines auszuführen, die zwischen Python-Level-Operationen und Aufrufen nativer Bibliotheken wechseln.

Ralf Gommers, Co-Direktor von Quansight Labs und Maintainer von NumPy und SciPy, beschreibt, wie die GIL die Benutzererfahrung von NumPy und numerischen Python-Bibliotheken beeinflusst.

Ein Hauptproblem in NumPy und dem darauf aufbauenden Paketstapel ist, dass NumPy immer noch (größtenteils) Single-Threaded ist – und das hat signifikante Teile der Benutzererfahrung und der darum aufgebauten Projekte geprägt. NumPy gibt die GIL in seinen inneren Schleifen (die die Schwerstarbeit leisten) zwar frei, aber das reicht bei weitem nicht aus. NumPy bietet keine Lösung, um alle CPU-Kerne einer einzelnen Maschine gut zu nutzen, und überlässt dies stattdessen Dask und anderen multiprocessing-Lösungen. Diese sind nicht sehr effizient und auch umständlicher zu verwenden. Diese Umständlichkeit äußert sich hauptsächlich in den zusätzlichen Abstraktionen und Ebenen, mit denen sich die Benutzer auseinandersetzen müssen, wenn sie z.B. dask.array verwenden, das numpy.ndarray umschließt. Sie zeigt sich auch in Überschneidungsproblemen, die dem Benutzer bewusst sein und über Umgebungsvariablen oder ein drittes Paket, threadpoolctl, verwalten muss. Der Hauptgrund dafür ist, dass NumPy BLAS für lineare Algebra aufruft – und diese Aufrufe hat es nicht unter Kontrolle, sie nutzen standardmäßig alle Kerne über pthreads oder OpenMP.

Die Koordination von APIs und Designentscheidungen zur Steuerung der Parallelität ist immer noch eine erhebliche Menge Arbeit und eine der größten Herausforderungen im gesamten PyData-Ökosystem. Ohne eine GIL hätte das alles ganz anders (besser, einfacher) ausgesehen.

GPU-intensive Workloads erfordern Multi-Core-Verarbeitung

Viele High-Performance-Computing- (HPC) und KI-Workloads nutzen GPUs intensiv. Diese Anwendungen erfordern häufig eine effiziente Multi-Core-CPU-Ausführung, auch wenn der Großteil der Berechnung auf einer GPU ausgeführt wird.

Zachary DeVito, PyTorch Core Developer und Forscher bei FAIR (Meta AI), beschreibt, wie die GIL selbst dann, wenn der Großteil der Berechnung außerhalb von Python erfolgt, multithreaded Skalierung ineffizient macht.

In PyTorch wird Python häufig verwendet, um ca. 8 GPUs und ca. 64 CPU-Threads zu orchestrieren, was für große Modelle auf bis zu 4k GPUs und 32k CPU-Threads anwächst. Obwohl die Schwerstarbeit außerhalb von Python geleistet wird, macht die Geschwindigkeit von GPUs selbst die Orchestrierung in Python unskalierbar. Wir landen oft bei 72 Prozessen anstelle von einem wegen der GIL. Logging, Debugging und Performance-Tuning sind in diesem Regime um Größenordnungen schwieriger und führen kontinuierlich zu geringerer Entwicklerproduktivität.

Die Verwendung vieler Prozesse (anstatt Threads) erschwert allgemeine Aufgaben. Zachary DeVito fährt fort:

Bei drei separaten Gelegenheiten in den letzten Monaten (Reduzierung redundanter Berechnungen in Datenladern, asynchrones Schreiben von Modell-Checkpoints und Parallelisierung von Compiler-Optimierungen) habe ich eine um eine Größenordnung höhere Zeit damit verbracht, herauszufinden, wie man GIL-Beschränkungen umgehen kann, als das eigentliche Problem zu lösen.

Selbst GPU-intensive Workloads haben häufig eine CPU-intensive Komponente. Beispielsweise erfordern Computer-Vision-Aufgaben typischerweise mehrere „Pre-Processing“-Schritte in der Dateneingabepipeline, wie z.B. Bilddekodierung, Zuschneiden und Größenänderung. Diese Aufgaben werden üblicherweise auf der CPU ausgeführt und können Python-Bibliotheken wie Pillow oder Pillow-SIMD verwenden. Es ist notwendig, die Dateneingabepipeline auf mehreren CPU-Kernen auszuführen, um die GPU mit Daten „gefüttert“ zu halten.

Die Zunahme der GPU-Leistung im Vergleich zu einzelnen CPU-Kernen macht die Multi-Core-Leistung wichtiger. Es wird zunehmend schwieriger, die GPUs vollständig auszulasten. Um dies zu erreichen, ist eine effiziente Nutzung mehrerer CPU-Kerne erforderlich, insbesondere auf Multi-GPU-Systemen. Zum Beispiel verfügt NVIDIAs DGX-A100 über 8 GPUs und zwei 64-Kern-CPUs, um die GPUs mit Daten „gefüttert“ zu halten.

Die GIL erschwert die Bereitstellung von Python-KI-Modellen

Python wird häufig zur Entwicklung von neuronalen Netz-basierten KI-Modellen eingesetzt. In PyTorch werden Modelle häufig als Teil von Multi-Threaded, meist C++-basierten Umgebungen bereitgestellt. Python wird oft skeptisch betrachtet, da die GIL ein globaler Flaschenhals sein kann, der eine effiziente Skalierung verhindert, obwohl die überwiegende Mehrheit der Berechnungen „außerhalb“ von Python mit freigegebener GIL stattfindet. Das torchdeploy-Paper [2] zeigt experimentelle Beweise für diese Skalierungsprobleme in mehreren Modellarchitekturen.

PyTorch bietet eine Reihe von Mechanismen zur Bereitstellung von Python-KI-Modellen, die die GIL umgehen oder umgehen, aber sie alle sind mit erheblichen Einschränkungen verbunden. Zum Beispiel erfasst TorchScript eine Darstellung des Modells, die von C++ ohne Python-Abhängigkeiten ausgeführt werden kann, unterstützt aber nur eine begrenzte Teilmenge von Python und erfordert oft das Umschreiben eines Teils des Modellcodes. Die torch::deploy API ermöglicht mehrere Python-Interpreter, jeder mit seiner eigenen GIL, im selben Prozess (ähnlich wie PEP 684). torch::deploy hat jedoch nur begrenzte Unterstützung für Python-Module, die C-API-Erweiterungen verwenden.

Zusammenfassung der Motivation

CPythons globale Interpreter-Sperre macht es schwierig, moderne Multi-Core-CPUs für viele wissenschaftliche und numerische Computing-Anwendungen effizient zu nutzen. Heinrich Kuttler, Manuel Kroiss und Paweł Jurgielewicz stellten fest, dass multithreaded Implementierungen in Python für ihre Aufgaben nicht gut skalierten und dass die Verwendung mehrerer Prozesse keine geeignete Alternative war.

Die Skalierungsprobleme beschränken sich nicht nur auf numerische Kernaufgaben. Sowohl Zachary DeVito als auch Paweł Jurgielewicz beschrieben Herausforderungen bei der Koordination und Kommunikation in Python.

Olivier Grisel, Ralf Gommers und Zachary DeVito beschrieben, wie aktuelle Workarounds für die GIL „wartungsintensiv“ sind und zu einer „geringeren Entwicklerproduktivität“ führen. Die GIL erschwert die Entwicklung und Wartung von wissenschaftlichen und numerischen Computing-Bibliotheken sowie die Entwicklung von Bibliotheken, die schwieriger zu verwenden sind.

Änderungen der Build-Konfiguration

Die globale Interpreter-Sperre bleibt der Standard für CPython-Builds und python.org-Downloads. Eine neue Build-Konfigurationsflagge, --disable-gil, wird dem Konfigurationsskript hinzugefügt, das CPython mit Unterstützung für die Ausführung ohne die globale Interpreter-Sperre baut.

Wenn mit --disable-gil kompiliert, definiert CPython das Makro Py_GIL_DISABLED in Python/patchlevel.h. Der ABI-Tag wird den Buchstaben „t“ (für „threading“) enthalten.

Die --disable-gil-Builds von CPython werden weiterhin optional mit aktivierter GIL zur Laufzeit unterstützt (siehe PYTHONGIL Umgebungsvariable und Py_mod_gil Slot).

Überblick über CPython-Änderungen

Das Entfernen der globalen Interpreter-Sperre erfordert erhebliche Änderungen an den CPython-Interna, aber relativ wenige Änderungen an den öffentlichen Python- und C-APIs. Dieser Abschnitt beschreibt die erforderlichen Änderungen an der CPython-Implementierung, gefolgt von den vorgeschlagenen API-Änderungen.

Die Implementierungsänderungen lassen sich in die folgenden vier Kategorien einteilen:

• Referenzzählung
• Speicherverwaltung
• Thread-Sicherheit von Containern
• Sperr- und atomare APIs

Referenzzählung

Das Entfernen der GIL erfordert Änderungen an CPythons Referenzzählungsimplementierung, um sie Thread-sicher zu machen. Außerdem muss sie einen geringen Ausführungs-Overhead haben und eine effiziente Skalierung mit mehreren Threads ermöglichen. Dieses PEP schlägt eine Kombination aus drei Techniken vor, um diese Einschränkungen zu bewältigen. Die erste ist ein Wechsel von der einfachen nicht-atomaren Referenzzählung zur voreingenommenen Referenzzählung, einer Thread-sicheren Referenzzählungstechnik mit geringerem Ausführungs-Overhead als die einfache atomare Referenzzählung. Die anderen beiden Techniken sind Unsterblichmachung und eine begrenzte Form der verzögerten Referenzzählung; sie adressieren einige der Multithreading-Skalierungsprobleme bei der Referenzzählung, indem sie einige Referenzzählungsmodifikationen vermeiden.

Voreingenommene Referenzzählung (BRC) ist eine Technik, die erstmals 2018 von Jiho Choi, Thomas Shull und Josep Torrellas beschrieben wurde [3]. Sie basiert auf der Beobachtung, dass die meisten Objekte selbst in Multi-Threaded-Programmen nur von einem einzigen Thread zugegriffen werden. Jedes Objekt ist einem besitzenden Thread zugeordnet (dem Thread, der es erstellt hat). Referenzzählungsoperationen des besitzenden Threads verwenden nicht-atomare Instruktionen, um eine „lokale“ Referenzanzahl zu ändern. Andere Threads verwenden atomare Instruktionen, um eine „geteilte“ Referenzanzahl zu ändern. Dieses Design vermeidet viele atomare Lese-Modifizier-Schreiboperationen, die auf modernen Prozessoren teuer sind.

Die in diesem PEP vorgeschlagene Implementierung von BRC stimmt weitgehend mit der ursprünglichen Beschreibung der voreingenommenen Referenzzählung überein, unterscheidet sich jedoch in Details wie der Größe der Referenzzählungsfelder und speziellen Bits in diesen Feldern. BRC erfordert die Speicherung von drei Informationen im Header jedes Objekts: der „lokalen“ Referenzanzahl, der „geteilten“ Referenzanzahl und der Kennung des besitzenden Threads. Das BRC-Paper packt diese drei Dinge in ein einziges 64-Bit-Feld. Dieses PEP schlägt die Verwendung von drei separaten Feldern im Header jedes Objekts vor, um potenzielle Probleme aufgrund von Überläufen der Referenzanzahl zu vermeiden. Zusätzlich unterstützt das PEP einen schnelleren Deallokationspfad, der im Normalfall eine atomare Operation vermeidet.

Die vorgeschlagene PyObject-Struktur (auch struct _object genannt) ist unten aufgeführt.

struct _object {
  _PyObject_HEAD_EXTRA
  uintptr_t ob_tid;         // owning thread id (4-8 bytes)
  uint16_t __padding;       // reserved for future use (2 bytes)
  PyMutex ob_mutex;         // per-object mutex (1 byte)
  uint8_t ob_gc_bits;       // GC fields (1 byte)
  uint32_t ob_ref_local;    // local reference count (4 bytes)
  Py_ssize_t ob_ref_shared; // shared reference count and state bits (4-8 bytes)
  PyTypeObject *ob_type;
};

Die Felder ob_tid, ob_ref_local und ob_ref_shared werden für die Implementierung der voreingenommenen Referenzzählung verwendet. Das Feld ob_gc_bits wird verwendet, um Flags für die Müllsammlung zu speichern, die zuvor in PyGC_Head gespeichert waren (siehe Garbage Collection (Cycle Collection)). Das Feld ob_mutex bietet ein Sperrfunktion pro Objekt in einem einzigen Byte.

// low two bits of "ob_ref_shared" are used for flags
#define _Py_SHARED_SHIFT 2

void Py_INCREF(PyObject *op)
{
  uint32_t new_local = op->ob_ref_local + 1;
  if (new_local == 0)
    return;  // object is immortal
  if (op->ob_tid == _Py_ThreadId())
    op->ob_ref_local = new_local;
  else
    atomic_add(&op->ob_ref_shared, 1 << _Py_SHARED_SHIFT);
}

void Py_DECREF(PyObject *op)
{
  if (op->ob_ref_local == _Py_IMMORTAL_REFCNT) {
    return;  // object is immortal
  }
  if (op->ob_tid == _Py_ThreadId()) {
    op->ob_ref_local -= 1;
    if (op->ob_ref_local == 0) {
      _Py_MergeZeroRefcount(); // merge refcount
    }
  }
  else {
    _Py_DecRefShared(); // slow path
  }
}

void _Py_MergeZeroRefcount(PyObject *op)
{
  if (op->ob_ref_shared == 0) {
    // quick deallocation code path (common case)
    op->ob_tid = 0;
    _Py_Dealloc(op);
  }
  else {
    // slower merging path not shown
  }
}

Speicherverwaltung

CPython verwendet derzeit einen internen Allokator, pymalloc, der für die Allokation kleiner Objekte optimiert ist. Die pymalloc-Implementierung ist ohne GIL nicht Thread-sicher. Dieses PEP schlägt vor, pymalloc durch mimalloc zu ersetzen, einen allgemeinen, Thread-sicheren Allokator mit guter Leistung, auch für kleine Allokationen.

Die Verwendung von mimalloc, mit einigen Modifikationen, löst auch zwei weitere Probleme im Zusammenhang mit der Entfernung des GIL. Erstens ermöglicht das Durchlaufen der internen mimalloc-Strukturen dem Garbage Collector, alle Python-Objekte zu finden, ohne eine verknüpfte Liste zu pflegen. Dies wird im Abschnitt Garbage Collection detaillierter beschrieben. Zweitens ermöglichen mimalloc-Heaps und Allokationen basierend auf Größenklassen Sammlungen wie dict im Allgemeinen, Sperren während Leseoperationen zu vermeiden. Dies wird im Abschnitt Thread-Sicherheit von Sammlungen detaillierter beschrieben.

CPython verlangt bereits, dass Objekte, die Garbage Collection unterstützen, die GC-Allokator-APIs verwenden (typischerweise indirekt durch Aufruf von PyType_GenericAlloc). Dieses PEP würde zusätzliche Anforderungen an die Verwendung der Python-Allokator-APIs stellen. Erstens müssen Python-Objekte über Objektallokations-APIs allokiert werden, wie z.B. PyType_GenericAlloc, PyObject_Malloc oder andere Python-APIs, die diese Aufrufe umschließen. Python-Objekte sollten nicht über andere APIs allokiert werden, wie z.B. rohe Aufrufe an C's malloc oder den C++ new-Operator. Darüber hinaus sollte PyObject_Malloc nur für die Allokation von Python-Objekten verwendet werden; es sollte nicht für die Allokation von Puffern, Speichern oder anderen Datenstrukturen verwendet werden, die keine PyObjects sind.

Dieses PEP setzt auch Einschränkungen für die pluggable allocator API (PyMem_SetAllocator). Beim Kompilieren ohne GIL müssen Allokatoren, die über diese API gesetzt wurden, die Allokation letztendlich an den entsprechenden zugrundeliegenden Allokator delegieren, wie z.B. PyObject_Malloc, für Python-Objektallokationen. Dies ermöglicht Allokatoren, die zugrundeliegende Allokatoren "umhüllen", wie z.B. Python's tracemalloc und den Debug-Allokator, aber nicht den Allokator vollständig zu ersetzen.

Garbage Collection (Cycle Collection)

Der CPython-Garbage-Collector erfordert die folgenden Änderungen, um mit diesem Vorschlag zu funktionieren

• Verwendung von "stop-the-world", um Thread-Sicherheitsgarantien zu bieten, die zuvor vom GIL bereitgestellt wurden.
• Abschaffung der generativen Garbage Collection zugunsten eines nicht-generativen Collectors.
• Integration mit verzögerter Referenzzählung und biased Referenzzählung.

Darüber hinaus ermöglichen die oben genannten Änderungen die Entfernung der Felder _gc_prev und _gc_next aus GC-Objekten. Die GC-Bits, die die Zustände "tracked", "finalized" und "unreachable" speicherten, werden in das Feld ob_gc_bits im PyObject-Header verschoben.

Thread-Sicherheit von Containern

In CPython schützt der globale Interpreter-Lock (GIL) vor der Beschädigung interner Interpreter-Zustände, wenn mehrere Threads gleichzeitig auf Python-Objekte zugreifen oder diese ändern. Wenn beispielsweise mehrere Threads dieselbe Liste gleichzeitig ändern, stellt der GIL sicher, dass die Länge der Liste (ob_size) genau der Anzahl der Elemente entspricht und dass die Referenzzählungen jedes Elements die Anzahl der Referenzen auf diese Elemente genau widerspiegeln. Ohne den GIL – und ohne andere Änderungen – würden gleichzeitige Modifikationen diese Felder beschädigen und wahrscheinlich zu Programmabstürzen führen.

Der GIL stellt nicht unbedingt sicher, dass Operationen atomar sind oder korrekt bleiben, wenn mehrere Operationen gleichzeitig ablaufen. Beispielsweise ist list.extend(iterable) möglicherweise nicht atomar, wenn das Iterable einen Iterator hat, der in Python implementiert ist (oder den GIL intern freigibt). Ebenso kann list.remove(x) das falsche Objekt entfernen, wenn es sich mit einer anderen Operation überschneidet, die die Liste modifiziert, abhängig von der Implementierung des Gleichheitsoperators. Dennoch stellt der GIL sicher, dass einige Operationen effektiv atomar sind. Beispielsweise kopiert der Konstruktor list(set) die Elemente des Sets atomar in eine neue Liste, und einige Codes verlassen sich darauf, dass diese Kopie atomar ist (d.h. ein Schnappschuss der Elemente im Set vorliegt). Dieses PEP bewahrt diese Eigenschaft.

Dieses PEP schlägt die Verwendung von Objektsperren vor, um viele der gleichen Schutzfunktionen zu bieten, die der GIL bietet. Zum Beispiel hat jede Liste, jedes Wörterbuch und jede Menge eine zugehörige leichtgewichtige Sperre. Alle Operationen, die das Objekt ändern, müssen die Sperre des Objekts halten. Die meisten Operationen, die vom Objekt lesen, sollten ebenfalls die Sperre des Objekts erwerben; die wenigen Leseoperationen, die ohne Sperre durchgeführt werden können, werden nachfolgend beschrieben.

Objektsperren mit kritischen Abschnitten bieten schwächere Schutzfunktionen als der GIL. Da der GIL nicht unbedingt sicherstellt, dass gleichzeitige Operationen atomar oder korrekt sind, kann das Objektsperrschema auch nicht sicherstellen, dass gleichzeitige Operationen atomar oder korrekt sind. Stattdessen zielt die Objektsperrung auf ähnliche Schutzfunktionen wie der GIL ab, jedoch mit gegenseitigem Ausschluss, der auf einzelne Objekte beschränkt ist.

Die meisten Operationen auf einer Instanz eines Container-Typs erfordern das Sperren dieses Objekts. Zum Beispiel

• list.append, list.insert, list.repeat, PyList_SetItem
• dict.__setitem__, PyDict_SetItem
• list.clear, dict.clear
• list.__repr__, dict.__repr__, usw.
• list.extend(iterable)
• setiter_iternext

Einige Operationen arbeiten direkt mit zwei Container-Objekten und kennen die interne Struktur beider Container. Zum Beispiel gibt es interne Spezialisierungen von list.extend(iterable) für bestimmte Iterable-Typen, wie z.B. set. Diese Operationen müssen beide Container sperren, da sie gleichzeitig auf die Interna beider Objekte zugreifen. Beachten Sie, dass die generische Implementierung von list.extend nur ein Objekt (die Liste) sperren muss, da das andere Objekt indirekt über die Thread-sichere Iterator-API angesprochen wird. Operationen, die zwei Container sperren, sind

• list.extend(list), list.extend(set), list.extend (dictitems) und andere Spezialisierungen, bei denen die Implementierung für den Argumenttyp spezialisiert ist.
• list.concat(list)
• list.__eq__(list), dict.__eq__(dict)

Einige einfache Operationen können direkt mit atomaren Zugriffen implementiert werden und benötigen keine Sperren, da sie nur auf ein einziges Feld zugreifen. Zu diesen Operationen gehören

• len(list), d.h. list_length(PyListObject *a)
• len(dict)
• len(set)

Einige wenige ausgewählte Operationen vermeiden optimistisch Sperren, um die Leistung zu verbessern. Diese erfordern spezielle Implementierungen und die Zusammenarbeit mit dem Speicherallokator

• list[idx] (list_subscript)
• dict[key] (dict_subscript)
• listiter_next, dictiter_iternextkey/value/item
• list.contains

PyObject *item = PyList_GetItem(list, idx);
Py_INCREF(item);

Py_INCREF(a->ob_item[i]);
return a->ob_item[i];

 PyObject **ob_item = atomic_load(&a->ob_item);
 PyObject *item = atomic_load(&ob_item[i]);
 if (!item || !_Py_TRY_INCREF(item)) goto retry;
 if (item != atomic_load(&ob_item[i])) {
   Py_DECREF(item);
   goto retry;
 }
 if (ob_item != atomic_load(&a->ob_item)) {
   Py_DECREF(item);
   goto retry;
}
return item;

retry:
  PyObject *item;
  Py_BEGIN_CRITICAL_SECTION(a->ob_mutex);
  item = a->ob_item[i];
  Py_INCREF(item);
  Py_END_CRITICAL_SECTION(a->ob_mutex);
  return item;

Spezialisierender Interpreter

Der spezialisierende Interpreter erfordert einige Änderungen, um Thread-sicher zu sein, wenn er ohne GIL ausgeführt wird.

• Gleichzeitige Spezialisierungen werden durch die Verwendung einer Mutex verhindert. Dies verhindert, dass mehrere Threads auf denselben Inline-Cache schreiben.
• In Multi-Thread-Programmen, die ohne GIL laufen, wird jeder Bytecode nur einmal spezialisiert. Dies verhindert, dass ein Thread einen teilweise geschriebenen Inline-Cache liest.
• Das Sperren stellt auch sicher, dass zwischengespeicherte Werte von tp_version_tag und keys_version mit den zwischengespeicherten Deskriptoren und anderen Werten konsistent sind.
• Modifikationen an Inline-Zählern verwenden „relaxed atomics“. Mit anderen Worten, einige Zählerdekremente können verpasst oder überschrieben werden, aber das beeinträchtigt die Korrektheit nicht.

Py_mod_gil Slot

In --disable-gil-Builds prüft CPython beim Laden einer Erweiterung auf einen neuen PEP 489-konformen Py_mod_gil-Slot. Wenn der Slot auf Py_mod_gil_not_used gesetzt ist, fährt die Modulerweiterung normal fort. Wenn der Slot nicht gesetzt ist, pausiert der Interpreter alle Threads und aktiviert den GIL, bevor er fortfährt. Zusätzlich gibt der Interpreter eine sichtbare Warnung aus, die die Erweiterung nennt, dass der GIL aktiviert wurde (und warum), und welche Schritte der Benutzer unternehmen kann, um ihn zu überschreiben.

Umgebungsvariable PYTHONGIL

In --disable-gil-Builds kann der Benutzer das Verhalten auch zur Laufzeit überschreiben, indem er die Umgebungsvariable PYTHONGIL setzt. Das Setzen von PYTHONGIL=0 erzwingt die Deaktivierung des GIL und überschreibt die Modul-Slot-Logik. Das Setzen von PYTHONGIL=1 erzwingt die Aktivierung des GIL.

Die PYTHONGIL=0-Überschreibung ist wichtig, da Erweiterungen, die nicht Thread-sicher sind, in Multi-Thread-Anwendungen weiterhin nützlich sein können. Zum Beispiel möchte man die Erweiterung möglicherweise nur von einem einzigen Thread aus verwenden oder den Zugriff durch Sperren schützen. Zum besseren Verständnis gibt es bereits einige Erweiterungen, die auch mit dem GIL nicht Thread-sicher sind, und Benutzer müssen bereits solche Schritte unternehmen.

Die PYTHONGIL=1-Überschreibung ist manchmal für das Debugging nützlich.

Nicht-generationale Garbage Collection

Dieses PEP schlägt vor, von einem generativen zyklischen Garbage Collector zu einem nicht-generativen Collector zu wechseln (wenn CPython ohne den GIL erstellt wird). Das entspricht dem Vorhandensein nur einer Generation (der „alten“ Generation). Es gibt zwei Gründe für diese vorgeschlagene Änderung.

Die zyklische Garbage Collection, selbst nur für die junge Generation, erfordert das Pausieren anderer Threads im Programm. Der Autor ist besorgt, dass häufige Sammlungen der jungen Generation die effiziente Skalierung in Multi-Thread-Programmen beeinträchtigen würden. Dies ist eine Sorge für junge Generationen (aber nicht für die alte Generation), da die jungen Generationen nach einer festen Anzahl von Allokationen gesammelt werden, während die Sammlungen für die ältere Generation im Verhältnis zur Anzahl der lebenden Objekte im Heap geplant werden. Außerdem ist es schwierig, Objekte in jeder Generation effizient zu verfolgen, ohne den GIL. Zum Beispiel verwendet CPython derzeit eine verkettete Liste von Objekten in jeder Generation. Wenn CPython dieses Design beibehalten würde, müssten diese Listen Thread-sicher gemacht werden, und es ist nicht klar, wie das effizient geschehen könnte.

Die generative Garbage Collection wird in vielen anderen Sprach-Laufzeitumgebungen gut eingesetzt. Zum Beispiel verwenden viele der Java HotSpot Garbage Collector-Implementierungen mehrere Generationen [11]. In diesen Laufzeitumgebungen ist eine junge Generation oft ein Gewinn für den Durchsatz: Da ein großer Prozentsatz der jungen Generation typischerweise „tot“ ist, kann der GC einen großen Speicherbereich im Verhältnis zur geleisteten Arbeit zurückgewinnen. Beispielsweise zeigen mehrere Java-Benchmarks, dass über 90 % der „jungen“ Objekte typischerweise gesammelt werden [12] [13]. Dies wird allgemein als „schwache generative Hypothese“ bezeichnet; die Beobachtung ist, dass die meisten Objekte jung sterben. Dieses Muster kehrt sich in CPython aufgrund der Verwendung von Referenzzählung um. Obwohl die meisten Objekte jung sterben, werden sie gesammelt, wenn ihre Referenzzähler Null erreichen. Objekte, die einen Garbage Collection-Zyklus überleben, bleiben wahrscheinlich lebendig [14]. Dieser Unterschied bedeutet, dass die generative Sammlung in CPython weitaus weniger effektiv ist als in vielen anderen Sprach-Laufzeitumgebungen [15].

Optimistisches Vermeiden von Sperren beim Zugriff auf dict und list

Dieser Vorschlag beruht auf einem Schema, das beim Zugriff auf einzelne Elemente in Listen und Dictionaries weitgehend das Erwerben von Sperren vermeidet. Beachten Sie, dass dies nicht „lock-frei“ im Sinne von „lock-free“ und „wait-free“ Algorithmen ist, die einen Fortschritt garantieren. Es vermeidet einfach das Erwerben von Sperren (Mutexes) im häufigen Fall, um Parallelität zu verbessern und den Aufwand zu reduzieren.

Eine viel einfachere Alternative wäre die Verwendung von Reader-Writer-Sperren zum Schutz von Dictionary- und Listen-Zugriffen. Reader-Writer-Sperren erlauben gleichzeitige Lesezugriffe, aber keine Aktualisierungen, was für Listen und Dictionaries ideal erscheinen mag. Das Problem ist, dass Reader-Writer-Sperren erheblichen Aufwand und schlechte Skalierbarkeit aufweisen, insbesondere wenn die kritischen Abschnitte klein sind, wie sie bei Einzel-Element-Dictionary- und Listen-Zugriffen der Fall sind [9]. Die schlechte Leser-Skalierbarkeit rührt daher, dass Leser alle dieselbe Datenstruktur aktualisieren müssen, wie z. B. die Anzahl der Leser in pthread_rwlocks.

Die in diesem PEP beschriebene Technik ist verwandt mit RCU („read-copy-update“) [6] und, in geringerem Maße, mit Hazard Pointers, zwei bekannte Schemata zur Optimierung von gleichzeitigen, hauptsächlich Lese-Datenstrukturen. RCU wird häufig im Linux-Kernel verwendet, um gemeinsame Datenstrukturen skalierbar zu schützen. Sowohl die Technik in diesem PEP als auch RCU arbeiten, indem sie die Rückgewinnung verzögern, während Leser auf die gleichzeitige Datenstruktur zugreifen können. RCU wird am häufigsten zum Schutz einzelner Objekte (wie Hash-Tabellen oder verketteten Listen) verwendet, während dieses PEP ein Schema zum Schutz größerer Speicherblöcke (mimalloc „Seiten“) vorschlägt [10].

Die Notwendigkeit dieses Schemas ist größtenteils auf die Verwendung von Referenzzählung in CPython zurückzuführen. Wenn CPython nur auf einen Tracing Garbage Collector angewiesen wäre, wäre dieses Schema wahrscheinlich nicht notwendig, da Tracing Garbage Collectors die Rückgewinnung bereits auf die erforderliche Weise verzögern. Dies würde Skalierungsprobleme nicht „lösen“, sondern viele der Herausforderungen auf die Implementierung des Garbage Collectors verlagern.

Multiprocessing

Die `multiprocessing`-Bibliothek erlaubt Python-Programmen, Python-Subprozesse zu starten und mit ihnen zu kommunizieren. Dies ermöglicht Parallelität, da jeder Subprozess seinen eigenen Python-Interpreter hat (d. h. einen GIL pro Prozess). Multiprocessing hat einige erhebliche Einschränkungen. Die Kommunikation zwischen Prozessen ist begrenzt: Objekte müssen im Allgemeinen serialisiert oder in den Shared Memory kopiert werden. Dies führt zu Overhead (aufgrund von Serialisierung) und erschwert den Aufbau von APIs auf Multiprocessing. Das Starten eines Subprozesses ist auch teurer als das Starten eines Threads, insbesondere mit der „spawn“-Implementierung. Das Starten eines Threads dauert ~100 µs, während das Erzeugen eines Subprozesses ~50 ms (50.000 µs) aufgrund der Python-Reinitialisierung dauert.

Schließlich unterstützen viele C- und C++-Bibliotheken den Zugriff von mehreren Threads, unterstützen aber keinen Zugriff oder Gebrauch über mehrere Prozesse hinweg.

Freigabe der GIL in C-API-Erweiterungen

C-API-Erweiterungen können den GIL um langlaufende Funktionen herum freigeben. Dies ermöglicht ein gewisses Maß an Parallelität, da mehrere Threads gleichzeitig laufen können, wenn der GIL freigegeben ist, aber der Overhead des Erwerbens und Freigebens des GIL verhindert normalerweise, dass dies über einige Threads hinaus effizient skaliert. Viele wissenschaftliche Computerbibliotheken geben den GIL in rechenintensiven Funktionen frei, und die CPython-Standardbibliothek gibt den GIL um blockierende E/A-Operationen herum frei.

Interne Parallelisierung

In C implementierte Funktionen können intern mehrere Threads verwenden. Zum Beispiel verwenden die NumPy-Distribution von Intel, PyTorch und TensorFlow diese Technik, um einzelne Operationen intern zu parallelisieren. Dies funktioniert gut, wenn die Grundoperationen groß genug sind, um effizient parallelisiert zu werden, aber nicht, wenn viele kleine Operationen vorhanden sind oder wenn die Operationen von Python-Code abhängen. Der Aufruf von Python aus C erfordert den Erwerb des GIL – selbst kurze Python-Code-Schnipsel können die Skalierung behindern.

GIL pro Interpreter

Das kürzlich angenommene PEP 684 schlägt einen pro-Interpreter-GIL zur Bewältigung der Multi-Core-Parallelität vor. Dies würde Parallelität zwischen Interpretern im selben Prozess ermöglichen, setzt aber erhebliche Einschränkungen für das Teilen von Python-Daten zwischen Interpretern. Sowohl dieses PEP als auch PEP 684 befassen sich mit der Multi-Core-Parallelität, jedoch mit unterschiedlichen Kompromissen und Techniken. Es ist möglich, beide PEPs gleichzeitig in CPython zu implementieren.

Gilectomy

Gilectomy [20] war ein Projekt von Larry Hastings zur Entfernung des GIL in CPython. Ähnlich wie das von diesem PEP vorgeschlagene Design unterstützte Gilectomy mehrere Threads, die innerhalb desselben Interpreters parallel liefen (d. h. „free-threading“), und nutzte feingranulare Sperren. Die Referenzimplementierung in diesem PEP verbessert die Single-Threaded-Leistung und Skalierbarkeit im Vergleich zu Gilectomy.

PyParallel

PyParallel [21] war ein Proof-of-Concept-Fork von Python 3.3 von Trent Nelson, der mehrere Threads unterstützte, die gleichzeitig in einem einzigen Python-Prozess liefen. Der Fork führte das Konzept der „parallelen Threads“ ein – Threads, die gleichzeitig laufen konnten, während der Haupt-Python-Thread angehalten war. Parallele Threads hatten Lesezugriff auf Objekte, die vom Hauptthread erstellt wurden. Objekte, die in parallelen Threads erstellt wurden, lebten für die Lebensdauer des erstellenden Threads. Für HTTP-Server könnte dies der Lebensdauer einer Anfrage entsprechen.

python-safethread

Das `python-safethread` [22] Projekt war ein Patch für Python 3.0 von Adam Olsen zur Entfernung des GIL. Einige Aspekte des Projekts ähneln dem von diesem PEP vorgeschlagenen Design. Beide verwenden feingranulare Sperren und optimieren die Referenzzählung für Fälle, in denen das Objekt vom selben Thread erstellt und darauf zugegriffen wird.

Greg Steins Free-Threading Patch

Im Jahr 1996 veröffentlichte Greg Stein einen Patch für Python 1.4, der den GIL entfernte [23]. Der Patch verwendete atomare Referenzzählung unter Windows und eine globale Referenzzähler-Sperre unter Linux. Listen- und Dictionary-Zugriffe wurden durch Mutexes geschützt. Teile des Patches wurden in CPython übernommen. Insbesondere führte der Patch eine `PyThreadState`-Struktur und eine korrekte Thread-spezifische Ausnahmebehandlung ein.

Dave Beazley überarbeitete den Patch in einem Blogbeitrag von 2011 [24].

Jython und IronPython

Einige alternative Python-Implementierungen wie Jython [25] und IronPython [26] haben keinen globalen Interpreter-Lock. Sie unterstützen jedoch keine CPython-Erweiterungen. (Die Implementierungen können mit in Java oder C# geschriebenem Code interagieren).

PyPy-STM

Der `pypy-stm` [27] Interpreter ist eine Variante von PyPy, die Software Transactional Memory verwendet. Die Autoren berichten über einen Single-Threaded-Leistungsaufwand im Bereich von 20 % bis 50 % im Vergleich zu PyPy. Er ist nicht kompatibel mit CPython-Erweiterungen.

Warum keinen nebenläufigen Garbage Collector verwenden?

Viele aktuelle Garbage Collectors sind größtenteils nebenläufig – sie vermeiden lange Stop-the-World-Pausen, indem sie zulassen, dass der Garbage Collector nebenläufig mit der Anwendung läuft. Warum also keinen nebenläufigen Collector verwenden?

Nebenläufige Sammlung erfordert Write Barriers (oder Read Barriers). Dem Autor ist kein Weg bekannt, Write Barriers zu CPython hinzuzufügen, ohne die C-API erheblich zu brechen.

Warum PyDict_GetItem nicht zugunsten von PyDict_FetchItem verwerfen?

Dieses PEP schlägt eine neue API PyDict_FetchItem vor, die sich wie PyDict_GetItem verhält, aber eine neue Referenz anstelle einer geliehenen Referenz zurückgibt. Wie in Geliehene Referenzen beschrieben, sind einige Verwendungen von geliehenen Referenzen, die beim Ausführen mit GIL sicher waren, beim Ausführen ohne GIL unsicher und müssen durch Funktionen wie PyDict_FetchItem ersetzt werden, die neue Referenzen zurückgeben.

Dieses PEP schlägt aus mehreren Gründen **nicht** die Deprecation von PyDict_GetItem und ähnlichen Funktionen vor, die geliehene Referenzen zurückgeben.

• Viele Verwendungen von geliehenen Referenzen sind auch beim Ausführen ohne GIL sicher. Zum Beispiel verwenden C API-Funktionen oft PyDict_GetItem, um Elemente aus dem Schlüsselwort-Argument-Dictionary abzurufen. Diese Aufrufe sind sicher, da das Schlüsselwort-Argument-Dictionary nur für einen einzigen Thread sichtbar ist.
• Ich habe diesen Ansatz frühzeitig ausprobiert und festgestellt, dass das vollständige Ersetzen von PyDict_GetItem durch PyDict_FetchItem häufig neue Referenzzählungsfehler eingeführt hat. Meiner Meinung nach überwiegt das Risiko, neue Referenzzählungsfehler einzuführen, im Allgemeinen die Risiken, einen PyDict_GetItem-Aufruf zu verpassen, der ohne GIL unsicher ist.

Warum nicht die Unsterblichmachung von PEP 683 verwenden?

Ähnlich wie PEP 683 schlägt dieses PEP ein Unsterblichkeits-Schema für Python-Objekte vor, aber die PEPs verwenden unterschiedliche Bitdarstellungen, um unsterbliche Objekte zu markieren. Die Schemata können nicht identisch sein, da dieses PEP auf verzerrte Referenzzählung angewiesen ist, die zwei Referenzzählerfelder anstelle von einem hat.

Verbesserte Spezialisierung

Die Python 3.11-Veröffentlichung führte Quickening und Spezialisierung als Teil des schnelleren CPython-Projekts ein und verbesserte die Leistung erheblich. Spezialisierung ersetzt langsame Bytecode-Anweisungen durch schnellere Varianten [19]. Um die Thread-Sicherheit zu gewährleisten, werden Anwendungen, die mehrere Threads verwenden (und ohne GIL laufen), jeden Bytecode nur einmal spezialisieren, was die Leistung einiger Programme verringern kann. Es ist möglich, die Spezialisierung mehrmals zu unterstützen, aber das erfordert weitere Untersuchungen und ist nicht Teil dieses PEP.

Python Build-Modi

Dieses PEP führt einen neuen Build-Modus (--disable-gil) ein, der nicht ABI-kompatibel mit dem Standard-Build-Modus ist. Der zusätzliche Build-Modus erhöht die Komplexität sowohl für Python-Core-Entwickler als auch für Erweiterungsentwickler. Der Autor glaubt, dass ein lohnendes Ziel darin besteht, diese Build-Modi zu kombinieren und die globale Interpreter-Sperre zur Laufzeit zu steuern, möglicherweise standardmäßig deaktiviert. Der Weg zu diesem Ziel bleibt eine offene Frage, aber ein möglicher Weg könnte wie folgt aussehen:

1. Im Jahr 2024 wird CPython 3.13 mit Unterstützung für ein --disable-gil-Build-Flag veröffentlicht. Es gibt zwei ABIs für CPython, eine mit und eine ohne GIL. Erweiterungsautoren zielen auf beide ABIs ab.
2. Nach 2–3 Veröffentlichungen (d. h. im Jahr 2026–2027) wird CPython mit dem GIL, der durch eine Laufzeitumgebungsvariable oder ein Flag gesteuert wird, veröffentlicht. Der GIL ist standardmäßig aktiviert. Es gibt nur eine einzige ABI.
3. Nach weiteren 2–3 Veröffentlichungen (d. h. 2028–2030) wechselt CPython zur Standardeinstellung, dass der GIL deaktiviert ist. Der GIL kann weiterhin zur Laufzeit über eine Umgebungsvariable oder ein Kommandozeilenargument aktiviert werden.

Dieses PEP deckt den ersten Schritt ab, wobei die verbleibenden Schritte offene Fragen bleiben. In diesem Szenario gäbe es eine Periode von zwei bis drei Jahren, in der Erweiterungsautoren zusätzlich zu jedem unterstützten CPU-Architektur und Betriebssystem einen CPython-Build erstellen müssten.

Integration

Die Referenzimplementierung ändert etwa 15.000 Zeilen Code in CPython und enthält mimalloc, das ebenfalls etwa 15.000 Zeilen Code umfasst. Die meisten Änderungen sind nicht leistungsabhängig und können sowohl in --disable-gil- als auch in Standard-Builds aufgenommen werden. Einige Makros wie Py_BEGIN_CRITICAL_SECTION sind im Standard-Build No-Ops. Der Autor erwartet keine große Anzahl von #ifdef-Anweisungen zur Unterstützung der --disable-gil-Builds.

Minderungsmaßnahmen für Ein-Thread-Leistung

Die in PEP vorgeschlagenen Änderungen erhöhen den Ausführungsaufwand für --disable-gil-Builds im Vergleich zu Python-Builds mit GIL. Mit anderen Worten, sie haben eine langsamere Single-Threaded-Leistung. Es gibt einige mögliche Optimierungen zur Reduzierung des Ausführungsaufwands, insbesondere für --disable-gil-Builds, die nur einen einzigen Thread verwenden. Diese könnten sich lohnen, wenn ein längerfristiges Ziel darin besteht, einen einzigen Build-Modus zu haben, aber die Wahl der Optimierungen und ihre Kompromisse bleiben eine offene Frage.