Python ist eine Programmiersprache auf hohem Niveau.
Kürzlich kam die Nachricht, dass die Der Lenkungsausschuss des Python-Projekts hat seinen Wunsch bekundet, das zu genehmigen Vorschlag zur Erweiterung der Python-Sprache «PEP-0703″, wodurch die globale Interpretersperre in CPython optional wird und im Grunde die Einbettung des CPython-Kompilierungsmodus ohne Global Interpreter Lock (GIL) definiert.
PEP-0703 legt fest, dass GIL standardmäßig nicht mehr verwendet werden soll. aber fügen Sie die Build-Option „–sin-gil“ hinzu, um sie zu deaktivieren. Wie geht es dirl Der neue Modus soll das Problem der Parallelisierung lösen von Operationen auf Multi-Core-Systemen, verursacht durch die Tatsache, dass die globale Sperre keinen parallelen Zugriff auf gemeinsam genutzte Objekte von verschiedenen Threads aus zulässt.
Es wird erwähnt, dass langfristig (nach 5 Jahren) Es ist geplant, den Interpreter standardmäßig auf den globalen, nicht sperrenden Modus umzustellen, während gleichzeitig die Unterstützung für das Kompilieren mit GIL eingestellt wird.
Vielen Dank an alle, die an der Umfrage zum No-GIL-Vorschlag teilgenommen haben. Es ist klar, dass die allgemeine Stimmung positiv ist, sowohl für die allgemeine Idee als auch für den PEP 703 im Besonderen. Auch der Vorstand steht beiden Punkten überwiegend positiv gegenüber. Wir beabsichtigen, PEP 703 zu akzeptieren, arbeiten jedoch noch an den Einzelheiten der Annahme.
Wie wir es schon einige Male in der Vergangenheit getan haben, möchten wir unsere Absicht, das PEP zu akzeptieren, zusammen mit unseren aktuellen Überlegungen zu den Details im Zusammenhang mit der Akzeptanz mitteilen.
Außerdem, Es wird erwähnt, dass die Änderungen, die in drei Phasen durchgeführt werden sollen, die kurz-, mittel- und langfristig sind. Angesichts dessen In der ersten Phase ist es unpraktisch, GIL standardmäßig zu deaktivieren aufgrund des Mehraufwands, der mit Änderungen am Garbage Collector, dem Speicherverwaltungssystem und den Grundelementen zum Organisieren von Sperren verbunden ist. Aufgrund der Verwendung der Referenzzählung zur Thread-Isolierung kommt es beispielsweise zu einem Leistungsabfall für Single-Threaded-Skripte (in der pyperformance-Testsuite um 10 %). Gleichzeitig kann es notwendig sein, die GIL im wissenschaftlichen Rechnen zu deaktivieren, wo die fehlende Parallelisierung ein schwerwiegenderes Problem darstellt als die lineare Geschwindigkeit der Codeausführung.
Im zweiten Schritt wird grundsätzlich auf die Bestätigung gewartet. und dass es dafür ausreichend Unterstützung aus der Community gibt die Verwendung von „Nicht-GIL ist machbar“ und stellen Sie sicher, dass GIL-lose Builds unterstützt werden, aber nicht standardmäßig.
Im letzten Schritt wird no-GIL bereits der Standardwert sein und alle Spuren von GIL werden entfernt (ohne die Abwärtskompatibilität unnötig zu beeinträchtigen).
Es wird beobachtet, dass Die Abkehr von GIL wird sehr sorgfältig durchgeführt, um den Fehler nicht zu wiederholen Was ist bei der Werbung passiert? Python 3: Ein Nicht-GIL-Build muss die Kompatibilität mit älteren Versionen von Python sicherstellen, und alle Codeänderungen von Drittanbietern, die für die Arbeit an Nicht-GIL-Builds erforderlich sind, sollten auch für GIL-Builds funktionieren.
Es gibt keine Pläne, die Versionen für Nicht-GIL-Builds auf Python 4 umzunummerieren, da dadurch die ABI-Kompatibilität gewahrt bleibt.
Während des gesamten Prozesses müssen wir (die Kernentwickler, nicht nur der SC) den Fortschritt und die vorgeschlagenen Zeitpläne neu bewerten. Wir möchten nicht, dass dies zu einem weiteren zehnjährigen Kampf um die Abwärtskompatibilität wird, und wir möchten die Möglichkeit haben, PEP 703 abzubrechen und eine andere Lösung zu finden, wenn es problematisch zu werden scheint. Daher müssen wir regelmäßig überprüfen, ob sich die weitere Arbeit lohnt.
Wir hoffen, dass dies etwas Klarheit über die Zukunft des PEP bringt, während wir die genauen Einzelheiten der Akzeptanz ausarbeiten. Der SC wird daran arbeiten, die Annahme in den kommenden Wochen abzuschließen.
Vor dem vollständigen Übergang zu Nicht-GIL-Builds planen wir, vollständige Community-Unterstützung für diese Builds zu erreichen und zusätzliche C-APIs und Python-APIs bereitzustellen, um sicheres Multithreading in vorhandenem Code zu ermöglichen.
Schließlich wird, wie bereits erwähnt, erwartet, dass der Übergang zur dritten Stufe in mindestens 5 Jahren erfolgen kann und der wahrscheinliche Termin für PEP-0703 die Veröffentlichung von Python 3.13 ist, die für nächsten Herbst geplant ist.
Wenn Sie daran interessiert, mehr darüber zu erfahrenkönnen Sie die Details überprüfen im folgenden Link.