Ankündigung des Steering Council zum JIT-Projekt

• Der experimentelle JIT-Compiler von CPython wurde über mehrere Jahre im main-Branch entwickelt und hat zuletzt echte Leistungsverbesserungen gezeigt, benötigt aber eine formale PEP-Prüfung, um als unterstützte Funktion bestehen zu bleiben
• PEP 744 behandelte das ursprüngliche Design und die Kriterien für den Übergang zu einer dauerhaften Funktion, doch über langfristige Maintainer, Sicherheitsprüfung, Unterstützung für Debugging und externe Prozesstools, Laufzeitgarantien sowie Pflichten von Redistributoren und nachgelagerten Paketierern besteht noch kein Konsens
• Der Python Steering Council hat offiziell die Ausarbeitung eines Standards Track PEP angefordert, um JIT zu einer unterstützten, nicht experimentellen Funktion von CPython zu machen, und gebeten, bis zur Annahme des PEP keine neuen Features, Optimierungen oder Performance-Arbeiten in main zu übernehmen
• Das neue PEP muss langfristige Wartung, Kompatibilität mit bestehenden CPython-Funktionen und -Tools, messbare Erfolgsmetriken und einen Zeitplan, die Beziehung zu Third-Party-JITs wie CinderX, Numba und PyTorch sowie die Stabilität der aktuellen Architektur behandeln
• Wenn das PEP nicht innerhalb von 6 Monaten eingereicht, abgeschlossen oder angenommen wird, soll der JIT-Code aus dem main-Branch entfernt werden und die Entwicklung außerhalb des main-Python-Repositories fortgesetzt werden

---

Hintergrund und offizielle Anfrage

• Der experimentelle Just-in-Time-Compiler von CPython ist Arbeit, die in den vergangenen Jahren von mehreren Core Developern und Beitragenden im main-Branch entwickelt wurde; die jüngsten Leistungsverbesserungen sind real und ermutigend
• Diese Maßnahme ist keine Kritik an der JIT-Arbeit oder den Beteiligten; vielmehr ist man der Ansicht, dass es an der Zeit ist, den inoffiziellen Status von JIT innerhalb des CPython-Projekts neu zu bewerten, da das Projekt schon lange läuft und mehrere Neugestaltungen durchlaufen hat
• JIT wurde bei der ersten Zusammenführung in main als Experiment aufgenommen, und das zugehörige PEP, PEP 744, ist ein Informational PEP
• PEP 744 behandelt das ursprüngliche Design und skizziert grob die Kriterien, unter denen JIT zu einer dauerhaften Funktion werden könnte, lässt aber Fragen offen wie langfristige Maintainer, Sicherheitsprüfung, Unterstützung für Debugging und externe Prozesstools, Laufzeitgarantien sowie Pflichten von Redistributoren und nachgelagerten Paketierern
• Der Python Steering Council ist der Auffassung, dass Änderungen dieser Komplexität und dieses Umfangs ein strengeres Verfahren erfordert hätten und dass diese offenen Fragen Verpflichtungen darstellen, die die Community über den PEP-Prozess prüfen und vereinbaren muss
• Um JIT zu einer unterstützten, nicht experimentellen Funktion von CPython zu machen, ist ein Standards Track PEP erforderlich, das Garantien, Wartungszusagen und Auswirkungen auf Redistributoren behandelt, sowie ein Verfahren zur formalen Annahme oder Ablehnung durch den Steering Council nach der Community-Diskussion
• Bis dieses PEP angenommen wird, sollen keine neuen JIT-Entwicklungen in den main-Branch übernommen werden; neue Features, Optimierungen und Performance-Arbeiten sind von diesem Stopp betroffen
• Bugfixes und Sicherheitskorrekturen können weiter vorgenommen werden; der Stopp bezieht sich ausschließlich auf die Aufnahme zusätzlicher JIT-Funktionen vor der Annahme des PEP

Streitpunkte, die das PEP behandeln muss, und der 6-Monats-Zeitplan

• Es besteht nicht die Absicht, konkurrierende Vorschläge zu verlangen, aber jetzt ist ein guter Zeitpunkt, auch alternative Vorschläge zu diskutieren; das steht auch im Einklang mit der bisherigen Sicht, dass im CPython-main-Branch nicht ohne PEP experimentiert werden sollte
• Statt eine einzelne JIT-Implementierung vorzuschlagen, könnte ein PEP, das eine JIT-Infrastruktur beschreibt, die mehrere Implementierungsstrategien unterstützen kann, angemessener sein
• Da weiterhin mehrere vielversprechende Tracing-Ansätze für JIT vorgeschlagen werden, sollte die Infrastruktur nicht stark an eine einzelne Strategie gekoppelt sein, sondern es ermöglichen, solche Ansätze innerhalb von CPython leicht zu erproben und zu bewerten
• Das PEP muss einen klaren Plan dafür aufstellen, wie ein Subsystem dieser Größe und Komplexität langfristig fortgeführt und gewartet werden soll und welche Auswirkungen es auf Maintainer und Beitragende hat, die nicht direkt an JIT arbeiten
• Das PEP muss die Kompatibilität mit bestehenden CPython-Funktionen und -Tools behandeln und die Wechselwirkungen und Garantien von JIT mit Funktionen wie Free-Threading, Profilern und Debuggern umfassend und detailliert darlegen
• Das PEP muss klare und messbare Erfolgsmetriken sowie einen Zeitplan enthalten und Ziele sowie Zeitpunkte für Performance-Ziele, den Umfang der Plattformunterstützung und Memory-Overhead behandeln
• Das PEP muss die Beziehung zu anderen JIT-Compilern behandeln und klarstellen, ob es sich um ein Design handelt, das allgemeine Infrastruktur bereitstellt, auf der andere Bemühungen aufbauen können, und ob Kompatibilität oder Inkompatibilität mit Third-Party-JITs wie CinderX, Numba und PyTorch erwartet wird
• Das PEP muss behandeln, ob die aktuelle JIT-Architektur als stabil angesehen wird oder ob mit weiteren Änderungen zu rechnen ist
• Diese Liste ist nicht vollständig; während der Community-Diskussion können weitere Streitpunkte hinzukommen
• Für die Einreichung und Klärung des PEP ist ein Zeitraum von 6 Monaten vorgesehen; wenn das betreffende PEP innerhalb dieser Frist nicht angenommen wird, wird der JIT-Code aus dem main-Branch entfernt und die Entwicklung außerhalb des main-Python-Repositories fortgesetzt
• Diese Anforderung ist keine Einstellung des Projekts, sondern ein Verfahren, um die notwendige Klarheit und die ausdrückliche Verpflichtung der Community für große Änderungen an der CPython-Runtime zu schaffen

[GN⁺]

Lobste.rs-Kommentare

• Es wirkt nicht besonders feindselig, aber etwas unbeholfen. Wenn JIT noch eine experimentelle Funktion ist, scheint es an sich kein Problem zu sein, dass die Zusammenführung weiterläuft
  Wenn Leute wie Shannon sagen würden: „Ich bringe ein PEP ein, aber sorgt bitte dafür, dass es keine unangenehmen Konflikte gibt“, dann hätte ich das Gefühl, dass man ihnen genug vertrauen kann, um keine harte Sperre zu verhängen, die weiteres Vorankommen verhindert. Es mag sein, dass diese öffentliche Ankündigung auf private Gespräche folgte, aber ich hoffe, dass das ohne unnötige Verletzungen gut über die Bühne geht

• Der Vorschlag einer Schnittstelle, die verschiedene JIT-Implementierungen zulässt, wirkt, als würde er stark missverstehen, was für einen Hochleistungs-JIT nötig ist. Die JIT-Leute hatten wohl mehrere Probleme, aber eines der großen scheint gewesen zu sein, dass sie die zentralen Runtime-Datenstrukturen nicht stark verändern konnten oder wollten
  Natürlich hat Python auch das Problem, praktisch die gesamte Implementierung wie eine API offenzulegen. Trotzdem kann man Leute, die Unfug treiben, dazu zwingen, ihre Typen neu zu schreiben — dafür braucht man aber eine Community, der Performance wirklich wichtig ist. Python hat sich historisch damit beholfen, performancekritische Bibliotheken nicht in Python selbst zu schreiben, und das hat die Prioritäten beeinflusst. Ich erinnere mich noch an alte Sprach-Benchmarks, in denen grundlegende Algorithmus-Implementierungen verglichen wurden mit Python-Implementierungen, die in Wirklichkeit nur ausgereifte Hochleistungsimplementierungen in C-Bibliotheken umhüllten

  • Der Vorschlag für eine JIT-Schnittstelle scheint von Ruby inspiriert zu sein, und dort wirkt das für meinen Eindruck ziemlich gut. Vielleicht gibt es deshalb in Ruby keinen extrem leistungsfähigen JIT, aber das könnte auch völlig in Ordnung sein. Wenn ein Python-JIT nur so gut wie ein Ruby-JIT funktionieren würde, wären viele Leute wahrscheinlich schon zufrieden

  • Ich verstehe nicht ganz, warum „der Vorschlag einer Schnittstelle, die verschiedene JIT-Implementierungen zulässt, stark missversteht, was für einen Hochleistungs-JIT nötig ist“
    Wie gesagt gibt es bei Python die Situation, dass die Implementierung wie eine API offengelegt ist, aber aus demselben Grund ruft auch ein JIT diese APIs auf. Tatsächlich wurden einige Funktionen sogar als öffentliche Symbole für den Linker offengelegt, weil der JIT sie brauchte. Ich selbst arbeite eher an einem Methoden-JIT als an einem Tracing-JIT und habe die Idee eines steckbaren JITs öffentlich unterstützt

• Ich frage mich, warum das nicht als private Anfrage an die zentralen JIT-Entwickler geschickt wurde, sondern als öffentliche Ankündigung gepostet wurde

  • Weil Python ein communitygetriebenes Open-Source-Projekt ist. Selbst in proprietären Projekten sind ähnliche Ankündigungen schon durchgesickert

• Irgendein Anthropologe sollte wohl ein Buch über die Bürokratie in Open-Source-Softwareprojekten schreiben, und Python sowie Debian sollten zentrale Untersuchungsobjekte sein
  Das ist nicht als Vorwurf gemeint. Solche Bürokratien sind letztlich Prozesse verteilter Entscheidungsfindung und Konsensbildung, und es ist schwer, das in dieser Größenordnung gut funktionieren zu lassen

  • Gabriella Coleman ist eine Anthropologin, die Debian per Feldforschung untersucht hat. Das daraus entstandene Buch heißt „Coding Freedom“ und ist sehr zu empfehlen

• Ehrlich gesagt wirkt es wie dasselbe Syndrom, das zu Python 3 geführt hat, nur mit umgekehrtem Effekt. CPython existiert hauptsächlich zum Vergnügen der Implementierer, und diese Änderung dürfte für Leute, die ans Hacken auf die bisherige Weise gewöhnt sind, ziemlich lästig sein
  Wahrscheinlich wäre der richtige Weg, eine JIT-Version als separate Implementierung zu fördern, ihr Änderungen zu erlauben und die Kompatibilität zum ursprünglichen CPython nur nach bestem Bemühen anzustreben

  • Ich verstehe nicht genau, was mit „dasselbe Syndrom, das zu Python 3 geführt hat, nur mit umgekehrtem Effekt“ gemeint ist
    Auch bei „CPython existiert hauptsächlich zum Vergnügen der Implementierer“ war mein Eindruck aus dem begrenzten Austausch mit dem SC und den Kernentwicklern eher das Gegenteil. Insgesamt schienen sie sich ziemlich ernsthaft dafür einzusetzen, ein vernünftiges Gleichgewicht zwischen der weiteren Unterstützung der bestehenden Community und dem Vorankommen zu finden