Reale JIT-Traces beim CPython Core Dev Sprint

Dies ist eine ausführliche Zusammenfassung der technischen Herausforderungen, mit denen CPythons neuer Tracing-JIT-Compiler (Just-In-Time) konfrontiert ist.

Trace-Blocker

Ein Tracing-JIT identifiziert während der Programmausführung häufig ausgeführte Codepfade ("Hot Paths") und zeichnet die Micro-Operations dieser Pfade auf, um optimierten Maschinencode zu erzeugen. Dieser Prozess wird jedoch unterbrochen, wenn der JIT auf Code trifft, in den er nicht hineinschauen kann, also auf einen "Trace-Blocker". Im Fall von CPython ist ein typisches Beispiel der Aufruf von in C geschriebenen Erweiterungsfunktionen.

• Technische Erklärung: Im Blog wird als Beispiel eine reine Python-Funktion genannt, die die Kreiszahl π berechnet. Der JIT von PyPy optimiert diese numerische Berechnungsschleife sehr effizient und erreicht dadurch eine 42-mal höhere Leistung als CPython. Fügt man jedoch innerhalb der Schleife auch nur einen einzigen Aufruf einer C-Funktion hinzu, die der JIT nicht verfolgen kann (hic_sunt_leones()), fällt die Leistung von PyPy abrupt auf nur noch das 1,8-Fache von CPython zurück. Dieser einzelne "Trace-Blocker" setzt den Großteil der Optimierungsfähigkeit des JIT außer Kraft. Der Grund ist, dass der JIT das Innenleben der C-Funktion nicht kennen kann und deshalb nicht die gesamte Schleife als Einheit optimieren kann, sondern den Code vor und nach dem Aufruf der C-Funktion getrennt behandeln muss.

---

Datengesteuerter Kontrollfluss

Dieses Problem tritt auf, wenn der Kontrollfluss eines Programms je nach Eingabedaten stark variiert. Ein Tracing-JIT arbeitet am effektivsten unter der Annahme, dass es konsistente "Hot Paths" gibt. Wenn sich die Ausführungspfade jedoch abhängig von den Daten ständig ändern, bricht diese Annahme zusammen.

• Technische Erklärung: Im Blog wird als Beispiel eine Funktion mit 9 Argumenten genannt. Jedes Argument kann None oder eine Zahl sein, und innerhalb der Funktion folgen Bedingungen der Form if <var> is None: ... aufeinander. In diesem Fall ist der jeweils ausgeführte Codepfad jedes Mal anders, abhängig von der Kombination der None-Werte in den Argumenten. Dadurch steht der JIT vor dem Problem einer "exponentiellen Anzahl von Traces". Das heißt, der JIT versucht, für alle möglichen Kombinationen von None-Argumenten separaten optimierten Code zu erzeugen. Das verursacht enormen Overhead und führt letztlich dazu, dass die Ausführung sogar deutlich langsamer wird als in CPython ohne JIT.

Zusammenfassend betont dieser Blogbeitrag, dass CPythons neuer Tracing-JIT diese Probleme mit "Trace-Blockern" und "datengesteuertem Kontrollfluss" lösen muss, um sich erfolgreich zu etablieren. Das deutet darauf hin, dass es sich nicht nur um ein Umsetzungsproblem handelt, sondern möglicherweise um grundlegende Grenzen der Tracing-JIT-Technologie selbst.