Zusammenfassung

Anfang dieses Jahres wurde ein experimenteller „Just-in-Time“-Compiler in den Hauptentwicklungszweig von CPython (main) integriert. Während neuere CPython-Versionen andere wesentliche interne Änderungen enthalten haben, stellt diese Ergänzung eine besonders signifikante Abweichung von der Art und Weise dar, wie CPython traditionell Python-Code ausführt. Daher verdient sie eine breitere Diskussion.

Dieses PEP zielt darauf ab, die Designentscheidungen hinter dieser Ergänzung, den aktuellen Stand der Implementierung und zukünftige Pläne zur dauerhaften, nicht-experimentellen Integration des JIT in CPython zusammenzufassen. Es versucht *nicht*, einen umfassenden Überblick darüber zu geben, *wie* der JIT funktioniert, sondern konzentriert sich stattdessen auf die spezifischen Vor- und Nachteile des gewählten Ansatzes sowie auf die Beantwortung vieler Fragen, die seit seiner Einführung zum JIT gestellt wurden.

Leser, die mehr über den neuen JIT erfahren möchten, werden ermutigt, die folgenden Ressourcen zu konsultieren:

• Die Präsentation, die den JIT erstmals auf dem CPython Core Developer Sprint 2023 vorstellte. Sie enthält relevante Hintergrundinformationen, eine leichte technische Einführung in die verwendete „Copy-and-Patch“-Technik und eine offene Diskussion seines Designs unter den anwesenden Kernentwicklern. Folien zu diesem Vortrag finden Sie auf GitHub.
• Das Open-Access-Paper, das ursprünglich Copy-and-Patch beschrieb.
• Der Blogbeitrag des Autors des Papers, der die Implementierung eines Copy-and-Patch JIT-Compilers für Lua detailliert beschreibt. Obwohl dies eine großartige Low-Level-Erklärung des Ansatzes ist, beachten Sie, dass er auch andere Techniken integriert und Implementierungsentscheidungen trifft, die für den CPython JIT nicht besonders relevant sind.
• Die Referenzimplementierung selbst.

Motivation

Bis zu diesem Punkt hat CPython Python-Code immer durch Kompilierung in Bytecode ausgeführt, der zur Laufzeit interpretiert wird. Dieser Bytecode ist eine mehr oder weniger direkte Übersetzung des Quellcodes: er ist untypisiert und weitgehend unoptimiert.

Seit der Veröffentlichung von Python 3.11 verwendet CPython einen „spezialisierenden adaptiven Interpreter“ (PEP 659), der diese Bytecode-Instruktionen während der Ausführung inplace mit typspezialisierten Versionen überschreibt. Dieser neue Interpreter liefert signifikante Leistungsverbesserungen, obwohl sein Optimierungspotenzial durch die Grenzen einzelner Bytecode-Instruktionen begrenzt ist. Er sammelt auch eine Fülle neuer Profiling-Informationen: die durch ein Programm fließenden Typen, das Speicherlayout bestimmter Objekte und welche Pfade durch das Programm am häufigsten ausgeführt werden. Mit anderen Worten: *was* optimiert werden soll und *wie* es optimiert werden soll.

Seit der Veröffentlichung von Python 3.12 generiert CPython diesen Interpreter aus einer C-ähnlichen domänenspezifischen Sprache (DSL). Neben der Bändigung einiger der Komplexität des neuen adaptiven Interpreters ermöglicht die DSL auch CPython-Maintainern, das manuelle Schreiben mühsamer Boilerplate-Codes in vielen Teilen des Interpreters, Compilers und der Standardbibliothek zu vermeiden, die mit den Instruktionsdefinitionen synchron gehalten werden müssen. Diese Fähigkeit, große Mengen an Laufzeuginfrastruktur aus einer einzigen Quelle der Wahrheit zu generieren, ist nicht nur für die Wartung praktisch, sondern eröffnet auch viele Möglichkeiten zur Erweiterung der Ausführung von CPython auf neue Weise. Zum Beispiel macht sie es machbar, automatisch Tabellen für die Übersetzung einer Sequenz von Instruktionen in eine äquivalente Sequenz kleinerer „Mikro-Ops“ zu generieren, einen Optimierer für Sequenzen dieser Mikro-Ops zu generieren und sogar einen vollständigen zweiten Interpreter für deren Ausführung zu generieren.

Tatsächlich enthalten seit Anfang des Python 3.13 Release-Zyklus alle CPython-Builds exakt diese Maschinen für die Mikro-Op-Übersetzung, Optimierung und Ausführung. Sie sind jedoch standardmäßig deaktiviert; der Overhead der Interpretation selbst optimierter Mikro-Op-Traces ist für die meisten Codes einfach zu groß. Eine stärkere Optimierung wird die Situation wahrscheinlich auch nicht wesentlich verbessern, da alle durch neue Optimierungen erzielten Effizienzgewinne wahrscheinlich durch den interpretativen Overhead noch kleinerer, komplexerer Mikro-Ops aufgewogen werden.

Die offensichtlichste Strategie, diesen neuen Engpass zu überwinden, ist die statische Kompilierung dieser optimierten Traces. Dies bietet die Möglichkeit, mehrere Quellen für Indirektion und Overhead zu vermeiden, die durch die Interpretation eingeführt werden. Insbesondere ermöglicht es die Beseitigung von Dispatch-Overhead zwischen Mikro-Ops (durch Ersetzung eines generischen Interpreters durch eine lineare Sequenz von Hot Code), Instruktionsdekodierungs-Overhead für einzelne Mikro-Ops (durch „Einbrennen“ der Werte oder Adressen von Argumenten, Konstanten und gecachten Werten direkt in Maschinencode-Instruktionen) und Speicherverkehr (durch Verschieben von Daten von Heap-allozierten Python-Frames in physische Hardware-Register).

Da ein Großteil dieser Daten selbst zwischen identischen Ausführungen eines Programms variiert und die bestehende Optimierungspipeline stark auf Laufzeit-Profiling-Informationen setzt, macht es wenig Sinn, diese Traces im Voraus zu kompilieren, und es wäre eine substanzielle Neugestaltung der bestehenden Spezifikation und der Mikro-Op-Tracing-Infrastruktur, die bereits implementiert wurde. Wie für viele andere dynamische Sprachen (und sogar für Python selbst) gezeigt wurde, ist der vielversprechendste Ansatz, die optimierten Mikro-Ops „just in time“ für die Ausführung zu kompilieren.

Begründung

Trotz ihres Rufs sind JIT-Compiler keine magischen „Schneller machen“-Maschinen. Die Entwicklung und Wartung jeglicher Art von optimierendem Compiler, selbst für eine einzige Plattform, geschweige denn für alle gängigsten unterstützten Plattformen von CPython, ist eine unglaublich komplizierte und kostspielige Aufgabe. Die Verwendung eines bestehenden Compiler-Frameworks wie LLVM kann diese Aufgabe vereinfachen, aber nur auf Kosten von schweren Laufzeitabhängigkeiten und deutlich höherem JIT-Kompilierungs-Overhead.

Es ist klar, dass die erfolgreiche Kompilierung von Python-Code zur Laufzeit nicht nur hochwertige Python-spezifische Optimierungen für den ausgeführten Code erfordert, *sondern auch* eine schnelle Generierung von effizientem Maschinencode für das optimierte Programm. Das Python-Kernentwicklungsteam verfügt über die notwendigen Fähigkeiten und Erfahrungen für ersteres (eine Middle-End-Schicht, die eng mit dem Interpreter gekoppelt ist), und die Copy-and-Patch-Kompilierung bietet eine attraktive Lösung für letzteres.

Kurz gesagt, Copy-and-Patch ermöglicht die Generierung eines hochwertigen JIT-Compiler-Templates aus derselben DSL, die zur Generierung des restlichen Interpreters verwendet wird. Für ein weit verbreitetes, ehrenamtlich geführtes Projekt wie CPython kann dieser Vorteil nicht hoch genug eingeschätzt werden: CPython-Maintainer erhalten durch bloßes Bearbeiten der Bytecode-Definitionen auch den JIT-Backend-Update „kostenlos“ für *alle* JIT-unterstützten Plattformen gleichzeitig. Dies gilt gleichermaßen, wenn Instruktionen hinzugefügt, geändert oder entfernt werden.

Wie der Rest des Interpreters wird auch der JIT-Compiler zur Build-Zeit generiert und hat keine Laufzeitabhängigkeiten. Er unterstützt eine breite Palette von Plattformen (siehe Abschnitt Support unten) und hat einen vergleichsweise geringen Wartungsaufwand. Insgesamt besteht die aktuelle Implementierung aus etwa 900 Zeilen Python-Code für die Build-Zeit und 500 Zeilen C-Code für die Laufzeit.

Spezifikation

Der JIT ist derzeit nicht Teil der Standard-Build-Konfiguration und wird dies wahrscheinlich auch in absehbarer Zeit bleiben (offizielle Binärdateien könnten ihn jedoch enthalten). Dennoch wird der JIT nicht-experimentell, sobald alle folgenden Bedingungen erfüllt sind:

1. Er liefert eine sinnvolle Leistungssteigerung für mindestens eine populäre Plattform (realistisch gesehen im Bereich von 5%).
2. Er kann mit minimaler Störung gebaut, verteilt und bereitgestellt werden.
3. Der Steering Council hat auf Anfrage festgestellt, dass die Aktivierung der JIT der Community mehr Wert bietet als ihre Deaktivierung (unter Berücksichtigung von Kompromissen wie Wartungsaufwand, Speicherverbrauch oder der Machbarkeit alternativer Designs).

Diese Kriterien sollten als Ausgangspunkt betrachtet werden und können im Laufe der Zeit erweitert werden. Beispielsweise könnten bei der Diskussion dieses PEP zusätzliche Anforderungen (wie mehrere engagierte Maintainer, eine Sicherheitsprüfung, Dokumentation im Devguide, Unterstützung für Out-of-Process-Debugging oder eine Laufzeitoption zur Deaktivierung des JIT) zu dieser Liste hinzugefügt werden.

Bis der JIT nicht-experimentell ist, sollte er *nicht* in der Produktion verwendet werden und kann jederzeit ohne Vorwarnung gebrochen oder entfernt werden.

Sobald der JIT nicht mehr experimentell ist, sollte er weitgehend so behandelt werden wie andere Build-Optionen wie --enable-optimizations oder --with-lto. Er kann eine empfohlene (oder sogar Standard-)Option für einige Plattformen sein, und Release-Manager *können* sich entscheiden, ihn in offizielle Releases aufzunehmen.

Abwärtskompatibilität

Aufgrund der Tatsache, dass der aktuelle Interpreter und der JIT-Backend beide aus derselben Spezifikation generiert werden, sollte das Verhalten von Python-Code vollständig unverändert bleiben. In der Praxis waren beobachtbare Unterschiede, die während des Tests gefunden und behoben wurden, eher Fehler in den bestehenden Mikro-Op-Übersetzungs- und Optimierungsstufen als Fehler im Copy-and-Patch-Schritt.

Sicherheitsimplikationen

Dieser JIT erzeugt, wie jeder JIT, zur Laufzeit große Mengen ausführbaren Daten. Dies führt zu einer potenziellen neuen Angriffsfläche für CPython, da ein böswilliger Akteur, der in der Lage ist, den Inhalt dieser Daten zu beeinflussen, dadurch in der Lage ist, beliebigen Code auszuführen. Dies ist eine bekannte Schwachstelle von JIT-Compilern.

Um dieses Risiko zu mindern, wurde der JIT nach Best Practices geschrieben. Insbesondere werden die fraglichen Daten vom JIT-Compiler nicht an andere Teile des Programms weitergegeben, solange sie schreibbar sind, und zu *keinem* Zeitpunkt sind die Daten sowohl schreibbar *als auch* ausführbar.

Die Natur von Template-basierten JITs begrenzt zudem stark die Art des generierbaren Codes, was die Wahrscheinlichkeit eines erfolgreichen Exploits weiter reduziert. Als zusätzliche Vorsichtsmaßnahme werden die Templates selbst im statischen, schreibgeschützten Speicher gespeichert.

Es wäre jedoch naiv anzunehmen, dass keine möglichen Schwachstellen im JIT existieren, insbesondere in diesem frühen Stadium. Der Autor ist kein Sicherheitsexperte, steht aber zur Verfügung, um dem Python Security Response Team beizutreten oder eng mit ihm zusammenzuarbeiten, um Sicherheitsprobleme bei deren Auftreten zu triagieren und zu beheben.

Wie man das lehrt

Wählen Sie die Abschnitte, die Sie am besten beschreiben

• Wenn Sie ein Python-Programmierer oder Endbenutzer sind...
  • ...ändert sich für Sie nichts. Niemand sollte Ihnen JIT-aktivierte CPython-Interpreter verteilen, solange es sich noch um eine experimentelle Funktion handelt. Sobald sie nicht-experimentell ist, werden Sie wahrscheinlich eine etwas bessere Leistung und einen etwas höheren Speicherverbrauch feststellen. Sie sollten keine anderen Änderungen beobachten können.
• Wenn Sie Drittanbieterpakete pflegen...
  • ...ändert sich für Sie nichts. Es gibt keine API- oder ABI-Änderungen, und der JIT ist für Drittanbietercode nicht zugänglich. Sie sollten Ihre CI-Matrix nicht ändern müssen und keine Unterschiede in der Funktionsweise Ihrer Pakete beobachten können, wenn der JIT aktiviert ist.
• Wenn Sie Python-Code profilieren oder debuggen...
  • ...ändert sich für Sie nichts. Alle Python-Profiling- und Tracing-Funktionen bleiben erhalten.
• Wenn Sie C-Code profilieren oder debuggen...
  • ...derzeit ist die Möglichkeit, *durch* JIT-Frames zu tracen, eingeschränkt. Dies kann zu Problemen führen, wenn Sie den gesamten C-Call-Stack beobachten müssen und nicht nur „Leaf“-Frames. Weitere Informationen finden Sie im Abschnitt Debugging oben.
• Wenn Sie Ihren eigenen Python-Interpreter kompilieren...
  • ...wenn Sie den JIT nicht bauen möchten, können Sie ihn einfach ignorieren. Andernfalls müssen Sie eine kompatible Version von LLVM installieren und das entsprechende Flag an die Build-Skripte übergeben. Ihr Build kann bis zu einer Minute länger dauern. Beachten Sie, dass der JIT *nicht* an Endbenutzer verteilt oder in der Produktion verwendet werden sollte, solange er sich noch in der experimentellen Phase befindet.
• Wenn Sie ein CPython-Maintainer sind (oder eines Forks von CPython)...
  • ...und Sie die Bytecode-Definitionen oder die Haupt-Interpreter-Schleife ändern...
    • ...im Allgemeinen sollte der JIT keine große Unannehmlichkeit für Sie darstellen (abhängig davon, was Sie tun möchten). Der Mikro-Op-Interpreter wird nirgendwohin gehen und bietet immer noch eine Debugging-Erfahrung, die der heutigen Haupt-Bytecode-Interpreter-Erfahrung ähnelt. Es besteht eine moderate Wahrscheinlichkeit, dass größere Änderungen am Interpreter (wie das Hinzufügen neuer lokaler Variablen, Änderungen an der Fehlerbehandlung und Deoptimierungslogik oder Änderungen am Mikro-Op-Format) Änderungen am C-Template erfordern, das zur Generierung des JIT verwendet wird und die Haupt-Interpreter-Schleife nachahmen soll. Sie können auch gelegentlich Pech haben und die JIT-Code-Generierung brechen, was Sie entweder dazu zwingt, die Python-Build-Skripte selbst zu ändern, oder Hilfe von jemandem zu suchen, der damit vertrauter ist (siehe oben).
  • ...und Sie am JIT selbst arbeiten...
    • ...Sie haben hoffentlich bereits eine gute Vorstellung davon, worauf Sie sich einlassen. Sie werden regelmäßig die Python-Build-Skripte, das C-Template zur Generierung des JIT und den C-Code, der den Laufzeitanteil des JIT tatsächlich ausmacht, bearbeiten. Sie werden sich auch mit allen möglichen Abstürzen befassen, Maschinencode in einem Debugger überspringen, COFF/ELF/Mach-O-Dumps betrachten, auf einer breiten Palette von Plattformen entwickeln und im Allgemeinen der Ansprechpartner für die Leute sein, die den Bytecode ändern, wenn die CI bei ihren PRs fehlschlägt (siehe oben). Idealerweise sind Sie zumindest mit Assembler *vertraut*, haben ein paar Kurse mit „Compiler“ im Namen besucht und einen Blogbeitrag oder zwei über Linker gelesen.
  • ...und Sie pflegen andere Teile von CPython...
    • ...für Sie ändert sich nichts. Sie müssen nicht lokal mit JIT-Builds entwickeln. Wenn Sie sich dafür entscheiden (z. B. um JIT-Probleme zu reproduzieren und zu triagieren), können Ihre Builds jedes Mal, wenn die relevanten Dateien geändert werden, bis zu einer Minute länger dauern.

Referenzimplementierung

Schlüsselkomponenten der Implementierung umfassen:

• Tools/jit/README.md: Anweisungen zum Bauen des JIT.
• Python/jit.c: Der gesamte Laufzeitanteil des JIT-Compilers.
• jit_stencils.h: Ein Beispiel für die generierten Templates des JIT.
• Tools/jit/template.c: Der Code, der kompiliert wird, um die Templates des JIT zu erzeugen.
• Tools/jit/_targets.py: Der Code zum Kompilieren und Parsen der Templates zur Build-Zeit.

Abgelehnte Ideen

Offene Fragen

Fußnoten

Urheberrecht

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