△Klicken Sie oben auf „ Python-Katze “, um zu folgen, und antworten Sie mit „ 1 “, um das E-Book zu erhalten
Blühende Katzensprache: In der neuesten Ausgabe von Python Weekly ( zum Lesen klicken ) habe ich die neuesten Nachrichten über den GIL-freien Vorschlag (PEP-703) geteilt, der die technische Community bereits in Aufregung versetzt hat! Hier ist ein Artikel zum Teilen. Der Hauptinhalt ist die Übersetzung der offiziellen Ankündigung. Sie können den weiteren Entwicklungsplan erkunden:
Quelle: Herz der Maschine
Die GIL in Python wird nicht mehr existieren, was einen großen Gewinn im Bereich des KI-Ökosystems darstellt. sagte PyTorch-Kernbetreuer Dmytro Dzhulgakov mit Emotionen.
Was ist die GIL? Der vollständige Name von GIL lautet Global Interpreter Lock (globale Interpretersperre), was nicht nur für Python gilt, sondern ein Konzept ist, das bei der Implementierung von CPython (Python-Interpreter) eingeführt wurde.
Wir können GIL als Mutex verstehen, der zum Schutz von Objekten in Python verwendet wird und verhindert, dass mehrere Threads gleichzeitig Python-Bytecode ausführen, wodurch die Thread-Sicherheit gewährleistet wird.
Quelle: https://realpython.com/python-gil/
GIL hat jedoch einen Nachteil: Es kann jeweils nur ein Thread auf einer CPU ausgeführt werden und mehrere Threads können nicht mehreren CPUs zugeordnet werden, sodass Python keine echte Multithread-Parallelität erreichen kann, wodurch die Ausführungseffizienz verringert wird.
Jetzt hat das Python-Team den Vorschlag, die GIL zu entfernen, offiziell angenommen und sie zu einem optionalen Modus gemacht , was für Entwickler von Vorteil ist.
Dieser Beitrag wurde von einem Software-Ingenieur bei Meta namens Sam Gross geleistet und er brauchte über vier Jahre, um das Projekt abzuschließen.
Nachdem sie die Nachricht gehört hatten, applaudierten alle. Yann LeCun, einer der drei Giganten des Deep Learning, schickte eine Glückwunschbotschaft: Ohne die GIL kann Python-Code jetzt Multithreading frei ausführen.
„Endlich kein GIL mehr in Python!“
„Dies ist eine bahnbrechende Entscheidung, auf die die Programmiergemeinschaft mit Spannung gewartet hat.“
Die Einzelheiten finden Sie weiter unten.
CPython-Kernentwickler Thomas Wouters hat einen Artikel geschrieben, in dem er die Details von GIL-free in Python beschreibt und einen Ausblick auf zukünftige Entwicklungen gibt.
Vielen Dank für das Feedback aller zum No-GIL-Vorschlag und die insgesamt positive Unterstützung. Der Lenkungsausschuss beabsichtigt, den No-GIL-Vorschlag anzunehmen und wird Ihnen die nachstehenden spezifischen Details mitteilen.
Unsere Grundannahmen sind:
Langfristig (ca. 5+ Jahre) sollten No-GIL-Builds die einzigen Builds sein;
Wir möchten sehr sorgfältig auf die Abwärtskompatibilität achten. Wir möchten keine weitere Python 3-Situation, in der alle Codeänderungen von Drittanbietern, die zur Anpassung an No-GIL-Builds erforderlich sind, nur für Builds mit GIL gelten sollten (obwohl die Abwärtskompatibilität mit älteren Python-Versionen noch berücksichtigt werden muss). Dies funktioniert nicht mit Python 4. Wir prüfen noch die Anforderungen für die ABI-Kompatibilität und andere Details dieser beiden Builds sowie die Auswirkungen auf die Abwärtskompatibilität.
Wir würden uns über die Unterstützung der Community freuen, bevor wir uns zu einer vollständigen Umstellung auf No-GIL verpflichten. Wir können nicht einfach die Standardeinstellungen ändern, wir möchten, dass die Community herausfindet, was sie tut, um uns zu unterstützen. Unser Kernentwicklungsteam muss Erfahrungen mit dem neuen Build-Modus und allem, was damit zusammenhängt, sammeln. Wir müssen die Thread-Sicherheit im vorhandenen Code klären und neue C-APIs und Python-APIs entwickeln. Wir müssen diese Erkenntnisse auch anderen in der Python-Community vermitteln und sicherstellen, dass die Änderungen, die wir vornehmen möchten, und die Änderungen, die wir von anderen erwarten, wünschenswert sind;
Zu jedem Zeitpunkt vor unserer standardmäßigen No-GIL-Einstellung möchten wir in der Lage sein, unsere Meinung zu ändern, wenn sich herausstellt, dass sie zu störend für zu wenig Nutzen ist. Das bedeutet auch, dass wir unsere gesamte Arbeit zurücksetzen, sodass No-GIL-spezifischer Code einigermaßen identifizierbar sein sollte, bis wir uns entscheiden, No-GIL zum Standard zu machen.
Derzeit sehen wir den weiteren Weg in drei Phasen:
Kurzfristig werden wir No-GIL-Builds als experimentellen Build-Modus verfügbar machen, wahrscheinlich in 3.13 (und möglicherweise 3.14). Es ist experimentell, da unser Kernentwicklungsteam diesen Build-Modus zwar unterstützt, aber nicht erwartet, dass die gesamte Community ihn unterstützt. Wir brauchen Zeit, um herauszufinden, was wir tun wollen, zumindest was das API-Design sowie die Verpackung und Verteilung betrifft, damit wir Unterstützung von der Community erhalten können. Wir raten Händlern auch davon ab, experimentelle No-GIL-Builds als Standardinterpreter zu veröffentlichen.
Mittelfristig werden wir No-GIL-Builds unterstützen, wenn wir sicher sind, dass wir über genügend Community-Unterstützung verfügen, um den Einsatz von No-GIL in der Produktion zu ermöglichen, allerdings nicht standardmäßig, sondern zu einem bestimmten Zieldatum oder in einer bestimmten Python-Version Die Verwendung wird zur Standardmethode. Der genaue Zeitpunkt hängt von vielen Faktoren ab, z. B. davon, wie kompatibel die API-Änderungen letztendlich sind, wie viel Arbeit die Community für nötig hält usw. Wir gehen davon aus, dass dies mindestens ein bis zwei Jahre dauern wird. Sobald wir den Support ankündigen, werden einige Distributoren voraussichtlich standardmäßig ohne GIL ausliefern.
Langfristig möchten wir, dass No-GIL die Standardeinstellung ist und alle Spuren der GIL entfernen (aber ohne die Abwärtskompatibilität unnötig zu beeinträchtigen). Wir wollen nicht zu lange warten, denn die gleichzeitige Existenz von zwei häufig verwendeten Build-Modi stellt eine große Belastung für die Community dar (z. B. die Notwendigkeit, Testressourcen zu verdoppeln und Szenarios zu debuggen). Aber wir dürfen nicht zu voreilig sein. Wir gehen davon aus, dass dieser Prozess fünf Jahre dauern wird.
Natürlich muss unser gesamtes Entwicklungsteam während des gesamten Prozesses den Fortschritt in Echtzeit bewerten und Anpassungen am Zeitplan vornehmen.
Referenzlink:
https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474
https://twitter.com/dzhulgakov/status/1685667015800066048
Die technische Austauschgruppe für Python-Katzen ist geöffnet! Zur Gruppe gehören aktuelle Mitarbeiter inländischer Fabriken der ersten und zweiten Stufe sowie Studenten, die an in- und ausländischen Hochschulen und Universitäten studieren. Es gibt Programmierveteranen mit mehr als zehn Jahren Programmiererfahrung und Neueinsteiger, die gerade erst dabei sind Grund- und weiterführende Schulen gegründet. Die Lernatmosphäre ist gut! Studenten, die der Gruppe beitreten möchten, antworten bitte auf die „ Kommunikationsgruppe “ im offiziellen Konto , um den WeChat von Bruder Mao zu erhalten (lehnen Sie die Werbeparty ab, wenn Sie derjenige sind!)~
Nicht genug? Versuch sie
▲ Python Trend Weekly #2: Rust macht Python wieder großartig
▲ Best-Practice-Leitfaden für die Python-Projektentwicklung
▲ Python-Programm-Debugging-Analyse, große Killer-Sammlung
▲ 8 Tipps zur Beschleunigung der Python-Optimierung
▲ Python Trend Weekly #7: Ich hasse die Verwendung von Asyncio
Wenn Sie diesen Artikel hilfreich fanden
Bitte großzügig teilen und liken , vielen Dank !