Verwendet cPython mehrere Kerne für integrierte Funktionen wie sort, any, all?

8

Ich verstehe, dass cPython über eine GIL verfügt, damit Ihr Skript nicht auf mehreren Kernen ausgeführt werden kann, ohne das Multiprocessing-Modul zu verwenden. Aber gibt es etwas, um die eingebauten Funktionen wie das Sortieren mit mehreren Kernen zu stoppen? Ich verstehe die cPython-Struktur nicht, aber ich denke, die Frage, die ich stelle, ist 'eingebaute Funktionen wie Sortieren, irgendwelche und Listen-Comprehensions tatsächlich unterhalb der GIL?

    
eggbert 15.10.2015, 10:17
quelle

2 Antworten

5

Die cPython-GIL hat damit zu tun, dass nur ein einzelner Thread Bytecode innerhalb eines Prozesses ausführen darf - er steht nicht mit der nicht-abstrahierten CPU in Beziehung.

Das heißt, solange Sie nicht etwas anrufen, um mehrere Prozesse abzufertigen / zu verwenden oder Ihr Betriebssystem / Ihre Hardware Anrufe entgegennimmt und dies für Sie tut (höchst unwahrscheinlich), werden Sie alle Ihre Vorgänge auf einem einzigen Server sehen CPU-Kern.

Integrierte Funktionen, die in C implementiert sind, passieren "unterhalb der GIL", da sie direktere Aufrufe der zugrunde liegenden APIs sind, aber das Eingeben von Argumenten und Daten in diese Funktionen geschieht innerhalb der GIL, da Sie Bytecode zum Lesen verwenden und schreibe.

Wenn Sie die cPython-Beziehung zu ihrem Host besser verstehen wollen, würde ich Ihnen den folgenden High-Level-Beamten vorschlagen Überblick und / oder die PDF-Folien und den Spielplatz, den ich für eine Konferenz geschrieben habe .

    
user559633 15.10.2015, 10:54
quelle
2

Keine der Funktionen, die Sie erwähnen, wird automatisch parallelisiert. Im Allgemeinen wird stillschweigend hervorstechende Threads in den meisten Sprachen als schlechte Form angesehen (dies ändert sich, aber es wird immer noch nur in reinen funktionalen Sprachen gesehen, in denen die Thread-Sicherheit durch Design eingebrannt ist); Wenn Sie viele Threads ohne Warnung erzeugen, erhalten Sie mysteriöse Fehler, wenn der Benutzer versucht, eigene Threads zu starten und transiente Fehler aufgrund zu vieler laufender Threads zu erhalten. Selbst wenn die GIL kein Problem wäre, wäre es nicht sinnvoll, dies zu tun.

Das heißt, die GIL ist da, um Interpreter Interna zu schützen, und das deckt jedes Szenario ab, in dem Referenzzählungen manipuliert werden, was konstant ist; mit einer seltenen Ausnahme ist es nicht möglich, eine sinnvolle Arbeit an PyObject* s zu erledigen (was ist, was alle Python-Level-Typen wie in C darstellen), wenn die GIL gehalten wird. In der Regel geben Python-Einbauten die GIL nur für blockierende Vorgänge frei (E / A, Warten auf Sperren usw.); es ist nur in C-Erweiterungen von Drittanbietern (und ctypes ), wo GIL-Release normal ist, da sie in diesen Fällen die PyObject s vollständig in C-Level-Typen umwandeln, geben Sie die GIL jetzt frei, da keine Referenzzählung oder andere Interna sind berührte, machte die teure Arbeit, erlangte die GIL erneut und konvertierte die Ergebnisse von C-Level-Typen in Python-Level-Objekte.

    
ShadowRanger 15.10.2015 11:09
quelle