Alternativen

Es gibt eine Reihe alternativer Strategien zur Verbesserung der Python-Leistung, die wir in Betracht gezogen haben, aber für unbefriedigend befanden.

• Cython, Shedskin: Cython [101] und Shedskin [102] sind beides statische Compiler für Python. Wir betrachten diese als nützliche, aber begrenzte Workarounds für die historisch schlechte Leistung von CPython. Shedskin unterstützt nicht die vollständige Python-Standardbibliothek [103], während Cython für optimale Leistung manuelle Cython-spezifische Annotationen erfordert.

  Statische Compiler wie diese sind nützlich für das Schreiben von Erweiterungsmodulen, ohne sich um die Referenzzählung kümmern zu müssen, aber da sie statische Ahead-of-Time-Compiler sind, können sie nicht den vollen Bereich des Codes optimieren, der von einem Just-In-Time-Compiler, der durch Laufzeitdaten informiert wird, berücksichtigt wird.

• IronPython: IronPython [106] ist Python auf Microsofts .Net-Plattform. Es wird nicht aktiv auf Mono getestet [107], was bedeutet, dass es im Wesentlichen nur unter Windows funktioniert und daher als allgemeiner CPython-Ersatz ungeeignet ist.
• Jython: Jython [108] ist eine vollständige Implementierung von Python 2.5, aber deutlich langsamer als Unladen Swallow (3-5x bei gemessenen Benchmarks) und unterstützt keine CPython-Erweiterungsmodule [109], was die Migration großer Anwendungen unerschwinglich machen würde.
• Psyco: Psyco [64] ist ein spezialisierter JIT-Compiler für CPython, implementiert als Erweiterungsmodul. Es verbessert hauptsächlich die Leistung für numerischen Code. Vorteile: existiert; macht einige Codes schneller. Nachteile: nur 32-Bit, keine Pläne für 64-Bit-Unterstützung; unterstützt nur x86; sehr schwer zu warten; inkompatibel mit SSE2-optimiertem Code aufgrund von Ausrichtungsproblemen.
• PyPy: PyPy [65] erzielt gute Leistung bei numerischem Code, ist aber bei einigen Workloads langsamer als Unladen Swallow. Die Migration großer Anwendungen von CPython zu PyPy wäre unerschwinglich: PyPys JIT-Compiler unterstützt nur die Generierung von 32-Bit-x86-Code; wichtige Module wie MySQLdb und pycrypto lassen sich gegen PyPy nicht kompilieren; PyPy bietet keine Einbettungs-API, geschweige denn dieselbe API wie CPython.
• PyV8: PyV8 [110] ist ein experimenteller Python-zu-JavaScript-Compiler im Alpha-Stadium, der auf V8 läuft. PyV8 implementiert nicht die gesamte Python-Sprache und unterstützt keine CPython-Erweiterungsmodule.
• WPython: WPython [104] ist eine wortbasierte Neuimplementierung der Interpreter-Schleife von CPython. Während es eine moderate Verbesserung der Interpreter-Leistung bietet [105], ist es kein Entweder-Oder-Ersatz für einen Just-In-Time-Compiler. Ein Interpreter wird nie so schnell sein wie optimierter Maschinencode. Wir betrachten WPython und ähnliche Interpreter-Verbesserungen als ergänzend zu unserer Arbeit und nicht als Konkurrenten.

Benchmarks

Unladen Swallow hat eine ziemlich große Suite von Benchmarks entwickelt, die von synthetischen Mikrobenchmarks, die eine einzelne Funktion testen sollen, bis hin zu Ganzanwendungs-Makrobenchmarks reichen. Die Inspiration für diese Benchmarks kam teilweise von Drittanbietern (im Fall des html5lib-Benchmarks), von Googles eigenen internen Workloads (slowspitfire, pickle, unpickle) sowie von Werkzeugen und Bibliotheken, die in der breiteren Python-Community intensiv genutzt werden (django, 2to3, spambayes). Diese Benchmarks werden über eine einzige Schnittstelle namens perf.py ausgeführt, die sich um die Erfassung von Speicherverbrauchsinformationen, die grafische Darstellung der Leistung und die Durchführung von Statistiken zu den Benchmark-Ergebnissen zur Sicherstellung der Signifikanz kümmert.

Die vollständige Liste der verfügbaren Benchmarks finden Sie im Unladen Swallow Wiki [43], einschließlich Anweisungen zum Herunterladen und Ausführen der Benchmarks für sich selbst. Alle unsere Benchmarks sind Open-Source; keine sind proprietär für Google. Wir glauben, dass diese Benchmark-Sammlung als nützliches Werkzeug zur Benchmark-Erstellung für jede vollständige Python-Implementierung dient, und tatsächlich nutzt PyPy diese Benchmarks bereits für seine eigenen Leistungstests [80], [95]. Wir begrüßen dies und suchen zusätzliche Workloads für die Benchmark-Suite von der Python-Community.

Wir haben unsere Bemühungen auf die Erfassung von Makro-Benchmarks und Benchmarks konzentriert, die reale Anwendungen so gut wie möglich simulieren, wenn die Ausführung einer ganzen Anwendung nicht praktikabel ist. Auf einer anderen Achse konzentrierte sich unsere Benchmark-Sammlung ursprünglich auf die Art von Workloads, die Googles Python-Code sieht (Webanwendungen, Textverarbeitung), obwohl wir die Sammlung inzwischen erweitert haben, um Workloads einzuschließen, die Google überhaupt nicht betreffen. Wir haben bisher stark numerische Workloads gemieden, da NumPy [79] bereits hervorragende Arbeit bei solchem Code leistet und die Verbesserung der numerischen Leistung daher keine anfängliche Priorität für das Team war; wir haben begonnen, solche Benchmarks in die Sammlung aufzunehmen [96] und mit der Optimierung von numerischem Python-Code begonnen.

Über diese Benchmarks hinaus gibt es auch eine Reihe von Workloads, die wir explizit nicht benchmarken wollen. Unladen Swallow konzentriert sich auf die Verbesserung der Leistung von Pure-Python-Code, daher ist die Leistung von Erweiterungsmodulen wie NumPy uninteressant, da die Kernroutinen von NumPy in C implementiert sind. Ebenso würden Workloads, die viel I/O beinhalten, wie GUIs, Datenbanken oder socket-intensive Anwendungen, unserer Meinung nach keine genaue Messung von Interpreter- oder Codegenerierungsoptimierungen ermöglichen. Dennoch gibt es sicherlich Raum zur Verbesserung der Leistung von C-Sprach-Erweiterungsmodulen in der Standardbibliothek, und als solche haben wir Benchmarks für die Module cPickle und re hinzugefügt.

Leistung im Vergleich zu CPython 2.6.4

Die folgenden Diagramme vergleichen das arithmetische Mittel mehrerer Benchmark-Iterationen für CPython 2.6.4 und Unladen Swallow. perf.py sammelt mehr Daten als diese, und tatsächlich ist das arithmetische Mittel nicht alles; wir reproduzieren nur den Mittelwert aus Gründen der Kürze. Wir fügen den t-Wert aus dem zweiseitigen T-Test von Student [44] mit einem Konfidenzintervall von 95 % ein, um die Signifikanz des Ergebnisses anzuzeigen. Die meisten Benchmarks werden 100 Mal ausgeführt, obwohl einige länger laufende Ganzanwendungs-Benchmarks weniger oft ausgeführt werden.

Eine Beschreibung jedes dieser Benchmarks ist im Unladen Swallow Wiki verfügbar [43].

Befehl

./perf.py -r -b default,apps ../a/python ../b/python

32-Bit; gcc 4.0.3; Ubuntu Dapper; Intel Core2 Duo 6600 @ 2.4GHz; 2 Kerne; 4MB L2-Cache; 4 GB RAM

64-Bit; gcc 4.2.4; Ubuntu Hardy; AMD Opteron 8214 HE @ 2,2 GHz; 4 Kerne; 1 MB L2-Cache; 8 GB RAM

Viele dieser Benchmarks zeigen unter Unladen Swallow Leistungseinbußen, da die aktuelle Version die Ausführung blockiert, um Python-Funktionen in Maschinencode zu kompilieren. Dies führt zu dem Verhalten, das in den Zeitliniendiagrammen für die Benchmarks html5lib und rietveld zu sehen ist, und verlangsamt die Gesamtleistung von 2to3. Wir haben einen aktiven Entwicklungszweig, um dieses Problem zu beheben ([46], [47]), aber die Arbeit innerhalb der Beschränkungen des aktuellen Threading-Systems von CPython hat den Prozess kompliziert und weit mehr Sorgfalt und Zeit erfordert als ursprünglich erwartet. Wir betrachten dieses Problem als kritisch für die endgültige Zusammenführung in den Zweig py3k.

Wir haben unser ursprüngliches Ziel einer Leistungsverbesserung um das 5-fache offensichtlich nicht erreicht. Eine Leistungs-Retrospektive folgt, die erklärt, warum wir unser ursprüngliches Leistungsziel nicht erreicht haben. Wir pflegen eine Liste noch zu implementierender Leistungsarbeiten [50].

Speicherverbrauch

Die folgende Tabelle zeigt den maximalen Speicherverbrauch (in Kilobytes) für jeden der Standard-Benchmarks von Unladen Swallow für CPython 2.6.4 und Unladen Swallow r988, sowie eine Zeitlinie des Speicherverbrauchs über die Lebensdauer des Benchmarks. Wir fügen Tabellen für 32- und 64-Bit-Binärprogramme hinzu. Der Speicherverbrauch wurde auf Linux 2.6-Systemen gemessen, indem die Abschnitte Private_ aus den /proc/$pid/smaps Pseudo-Dateien des Kernels summiert wurden [45].

Befehl

./perf.py -r --track_memory -b default,apps ../a/python ../b/python

32-Bit

64-Bit

Der erhöhte Speicherverbrauch resultiert aus a) LLVM-Bibliotheken für Codegenerierung, Analyse und Optimierung; b) nativem Code; c) Speicherverbrauchsproblemen oder -lecks in LLVM; d) Datenstrukturen, die zur Optimierung und Generierung von Maschinencode benötigt werden; e) noch nicht kategorisierten anderen Quellen.

Obwohl wir erhebliche Fortschritte bei der Reduzierung des Speicherverbrauchs seit der ersten naiven JIT-Implementierung gemacht haben [42], gibt es offensichtlich noch mehr zu tun. Wir glauben, dass noch Speicher eingespart werden kann, ohne die Leistung zu beeinträchtigen. Wir haben uns eher auf die reine Leistung konzentriert und noch keinen konzertierten Vorstoß zur Reduzierung des Speicherverbrauchs unternommen. Wir betrachten die Reduzierung des Speicherverbrauchs als blockierendes Problem für die endgültige Zusammenführung in den Zweig py3k. Wir bitten die Community um Hinweise zu einem akzeptablen erhöhten Speicherverbrauch.

Startzeit

Die statische Verlinkung der LLVM-Bibliotheken für Codegenerierung, Analyse und Optimierung verlängert die Startzeit des Python-Binärprogramms. C++-statische Initialisierer, die von LLVM verwendet werden, erhöhen ebenfalls die Startzeit, ebenso wie der Import der Sammlung von vorcompilierten C-Laufzeitroutinen, die wir in Python-Code einfügen wollen.

Ergebnisse der startup-Benchmarks von Unladen Swallow

$ ./perf.py -r -b startup /tmp/cpy-26/bin/python /tmp/unladen/bin/python

### normal_startup ###
Min: 0.219186 -> 0.352075: 1.6063x slower
Avg: 0.227228 -> 0.364384: 1.6036x slower
Significant (t=-51.879098, a=0.95)
Stddev: 0.00762 -> 0.02532: 3.3227x larger
Timeline: http://tinyurl.com/yfe8z3r

### startup_nosite ###
Min: 0.105949 -> 0.264912: 2.5004x slower
Avg: 0.107574 -> 0.267505: 2.4867x slower
Significant (t=-703.557403, a=0.95)
Stddev: 0.00214 -> 0.00240: 1.1209x larger
Timeline: http://tinyurl.com/yajn8fa

### bzr_startup ###
Min: 0.067990 -> 0.097985: 1.4412x slower
Avg: 0.084322 -> 0.111348: 1.3205x slower
Significant (t=-37.432534, a=0.95)
Stddev: 0.00793 -> 0.00643: 1.2330x smaller
Timeline: http://tinyurl.com/ybdm537

### hg_startup ###
Min: 0.016997 -> 0.024997: 1.4707x slower
Avg: 0.026990 -> 0.036772: 1.3625x slower
Significant (t=-53.104502, a=0.95)
Stddev: 0.00406 -> 0.00417: 1.0273x larger
Timeline: http://tinyurl.com/ycout8m

bzr_startup und hg_startup messen, wie lange es dauert, bis Bazaar bzw. Mercurial ihre Hilfebildschirme anzeigen. startup_nosite führt python -S viele Male aus; die Verwendung der Option -S ist selten, aber wir glauben, dass dies einen guten Hinweis darauf gibt, woher die erhöhte Startzeit stammt.

Unladen Swallow hat Fortschritte bei der Optimierung der Startzeit gemacht, aber es gibt noch mehr zu tun und weitere Optimierungen zu implementieren. Die Verbesserung der Startzeit ist ein hochpriorisiertes Element [33] in der Zusammenführungs-Punchlist von Unladen Swallow.

Binäre Größe

Die statische Verlinkung der LLVM-Bibliotheken für Codegenerierung, Analyse und Optimierung erhöht signifikant die Größe des python-Binärprogramms. Die folgenden Tabellen zeigen stripped On-Disk-Binärgrößen; die Binärprogramme sind stripped, um besser mit den Konfigurationen übereinzustimmen, die von Systempaketmanagern verwendet werden. Wir glauben, dass dies die realistischste Messung einer Änderung der Binärgröße ist.

Die erhöhte Binärgröße wird durch die statische Verlinkung der LLVM-Bibliotheken für Codegenerierung, Analyse und Optimierung in das python-Binärprogramm verursacht. Dies kann einfach dadurch behoben werden, dass LLVM so modifiziert wird, dass es die dynamische Verlinkung besser unterstützt und diese dann verwendet wird, anstelle der aktuellen statischen Verlinkung. Vorerst bietet die statische Verlinkung jedoch einen genauen Einblick in die Kosten der Verlinkung gegen LLVM.

Selbst bei statischer Verlinkung glauben wir, dass es noch Spielraum zur Verbesserung der On-Disk-Binärgröße gibt, indem die Abhängigkeiten von Unladen Swallow von LLVM reduziert werden. Dieses Problem wird aktiv angegangen [32].

Leistungs-Retrospektive

Unser ursprüngliches Ziel für Unladen Swallow war eine Leistungsverbesserung um das 5-fache gegenüber CPython 2.6. Wir haben dieses Ziel nicht erreicht, geschweige denn, um es unverblümt zu sagen, auch nur annähernd. Warum hat das Projekt dieses Ziel nicht erreicht, und kann ein LLVM-basierter JIT jemals dieses Ziel erreichen?

Warum hat Unladen Swallow sein 5x-Ziel nicht erreicht? Der Hauptgrund war, dass LLVM mehr Arbeit erforderte, als wir ursprünglich erwartet hatten. Basierend auf der Tatsache, dass Apple Produkte auf LLVM-Basis vertrieb [81] und andere Hochsprachen erfolgreich LLVM-basierte JITs implementiert hatten ([61], [62], [82]), hatten wir angenommen, dass LLVMs JIT relativ frei von Showstopper-Bugs ist.

Das hat sich als falsch erwiesen. Wir mussten unsere Aufmerksamkeit von der Leistung abwenden, um eine Reihe kritischer Fehler in der JIT-Infrastruktur von LLVM zu beheben (z.B. [83], [84]) sowie eine Reihe von Nice-to-have-Verbesserungen, die weitere Optimierungen in verschiedenen Bereichen ermöglichen würden (z.B. [86], [85], [87]). LLVMs statische Codegenerierungseinrichtungen, Werkzeuge und Optimierungsdurchläufe sind stabil und intensiv getestet, aber die Just-In-Time-Infrastruktur war relativ unerprobt und fehlerhaft. Wir haben dies behoben.

(Unsere Hypothese ist, dass wir auf diese Probleme gestoßen sind – Probleme, die andere Projekte vermieden hatten –, weil die Testsuite der Standardbibliothek von CPython komplex und gründlich ist.)

Wir haben auch Ingenieursressourcen von der Leistung auf Support-Tools wie gdb und oProfile umgelenkt. gdb funktionierte überhaupt nicht gut mit JIT-Compilern, und LLVM hatte zuvor keine Integration mit oProfile. JIT-fähige Debugger und Profiler waren für das Projekt sehr wertvoll, und wir bereuen es nicht, unsere Zeit in diese Richtungen gelenkt zu haben. Weitere Informationen finden Sie in den Abschnitten Debugging und Profiling.

Kann ein LLVM-basierter CPython JIT jemals das 5-fache Leistungsziel erreichen? Die Benchmark-Ergebnisse für JIT-basierte JavaScript-Implementierungen deuten darauf hin, dass 5x tatsächlich möglich ist, ebenso wie die Ergebnisse, die PyPys JIT für numerische Workloads geliefert hat. Die Erfahrung von Self-92 [52] ist ebenfalls lehrreich.

Kann LLVM das liefern? Wir glauben, dass wir gerade erst an der Oberfläche dessen kratzen, was unser LLVM-basierter JIT liefern kann. Die Optimierungen, die wir bisher in dieses System integriert haben, haben erhebliche Früchte getragen (z. B. [88], [89], [90]). Unsere bisherigen Erfahrungen zeigen, dass der limitierende Faktor für die Leistung von Unladen Swallow die Ingenieurszyklen sind, die benötigt werden, um die Literatur zu implementieren. Wir haben festgestellt, dass LLVM einfach zu handhaben und zu modifizieren ist, und seine integrierten Optimierungen haben die Aufgabe der Implementierung von Optimierungen auf Python-Ebene erheblich vereinfacht.

Ein Überblick über weitere Leistungsmöglichkeiten wird im Abschnitt Future Work diskutiert.

Bekannte Inkompatibilitäten

Die einzige Anwendung oder Bibliothek, von der wir wissen, dass sie nicht mit Unladen Swallow funktioniert, aber mit CPython 2.6.4 funktioniert, ist Psyco [64]. Wir sind uns einiger Bibliotheken wie PyGame [78] bewusst, die gut mit CPython 2.6.4 funktionieren, aber aufgrund von Änderungen in Unladen Swallow einige Leistungseinbußen erleiden. Wir verfolgen dieses Problem [47] und arbeiten daran, diese Leistungseinbußen zu beheben.

Während Unladen Swallow quellcodekompatibel mit CPython 2.6.4 ist, ist es nicht binärkompatibel. C-Erweiterungsmodule, die gegen eines kompiliert wurden, müssen neu kompiliert werden, um mit dem anderen zu funktionieren.

Die Zusammenführung von Unladen Swallow sollte minimale Auswirkungen auf langlaufende CPython-Optimierungszweige wie WPython haben. WPython [104] und Unladen Swallow sind weitgehend orthogonal, und es gibt keinen technischen Grund, warum beide nicht in CPython zusammengeführt werden könnten. Die Änderungen, die erforderlich sind, um WPython mit einer JIT-erweiterten Version von CPython kompatibel zu machen, sollten minimal sein [113]. Dasselbe sollte für andere CPython-Optimierungsprojekte gelten (z. B. [114]).

Invasive Forks von CPython wie Stackless Python [115] sind schwieriger zu unterstützen. Da es sehr unwahrscheinlich ist, dass Stackless in CPython zusammengeführt wird [116] und ein erhöhter Wartungsaufwand Teil jedes Forks ist, betrachten wir die Kompatibilität mit Stackless als relativ niedrig priorisiert. JIT-kompilierte Stack-Frames verwenden den C-Stack, sodass Stackless sie genauso behandeln sollte wie Aufrufe über Erweiterungsmodule. Wenn sich dies als nicht akzeptabel erweist, könnte Stackless entweder den JIT-Compiler entfernen oder die JIT-Codegenerierung verbessern, um Heap-basierte Stack-Frames besser zu unterstützen [117], [118].

Experimente mit Änderungen an Python oder CPython-Bytecode

Der JIT-Compiler von Unladen Swallow arbeitet mit CPython-Bytecode und ist daher immun gegen Änderungen der Python-Sprache, die nur den Parser betreffen.

Wir empfehlen, dass Änderungen am CPython-Bytecode-Compiler oder an der Semantik einzelner Bytecodes zuerst in der Interpreter-Schleife prototypisiert und dann in den JIT-Compiler portiert werden, sobald die Semantik klar ist. Um dies zu erleichtern, enthält Unladen Swallow eine Konfigurationsoption --without-llvm, die den JIT-Compiler und die gesamte zugehörige Infrastruktur entfernt. Dies belässt die aktuelle Experimentierlast unverändert, sodass Entwickler in der aktuellen Interpreter-Schleife mit geringem Einstiegsaufwand prototypisieren können.

Unladen Swallow begann mit der Implementierung seines JIT-Compilers durch direkte, naive Übersetzungen von Bytecode-Implementierungen in LLVM API-Aufrufe. Wir fanden diesen Prozess leicht verständlich und empfehlen denselben Ansatz für CPython. Wir fügen hier mehrere Beispieländerungen aus dem Unladen Swallow Repository als Beispiele für diesen Entwicklungsstil hinzu: [26], [27], [28], [29].

Debugging

Das Unladen Swallow-Team hat Änderungen an gdb vorgenommen, um die Verwendung von gdb zum Debuggen von JIT-kompiliertem Python-Code zu erleichtern. Diese Änderungen wurden in gdb 7.0 veröffentlicht [17]. Sie ermöglichen es gdb, JIT-generierte Call-Stack-Frames zu identifizieren und zu entwirren. Dies ermöglicht es gdb, für die CPython-Entwicklung weiterhin wie zuvor zu funktionieren, wenn beispielsweise der list-Typ oder integrierte Funktionen geändert werden.

Beispiel-Backtrace nach unseren Änderungen, wobei baz, bar und foo JIT-kompiliert sind

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabe7d1a8 in baz ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in baz ()
#1 0x00002aaaabe7d12c in bar ()
#2 0x00002aaaabe7d0aa in foo ()
#3 0x00002aaaabe7d02c in main ()
#4 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70, F=0x14024e0, ArgValues=...)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#5 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#6 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8,
envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208

Zuvor hätten die JIT-kompilierten Frames dazu geführt, dass gdb falsch entwirrt wurde, was viele offensichtlich falsche Stack-Frames im Stil von #6 0x00002aaaabe7d0aa in ?? () erzeugt hätte.

Höhepunkte

• gdb 7.0 kann JIT-kompilierte Stack-Frames korrekt parsen und ermöglicht die vollständige Nutzung von gdb für nicht JIT-kompilierte Funktionen, d. h. den größten Teil der CPython-Codebasis.
• Das Disassemblieren innerhalb eines JIT-kompilierten Stack-Frames gibt automatisch die vollständige Liste der Befehle aus, aus denen diese Funktion besteht. Dies ist ein Fortschritt gegenüber dem Zustand von gdb vor unserer Arbeit: Entwickler mussten die Startadresse der Funktion erraten und den Assemblercode manuell disassemblieren.
• Der flexible zugrunde liegende Mechanismus ermöglicht es CPython, immer mehr Informationen hinzuzufügen und schließlich die Parität mit der C/C++-Unterstützung in gdb für JIT-kompilierten Maschinencode zu erreichen.

Niedrige Punkte

• gdb kann keine lokalen Variablen anzeigen oder sagen, in welcher Zeile Sie sich gerade innerhalb einer JIT-kompilierten Funktion befinden. Es kann auch nicht durch JIT-kompilierten Code schrittweise durchlaufen, außer ein Befehl nach dem anderen.
• Noch nicht in Apples gdb oder Microsofts Visual Studio Debuggern integriert.

Das Unladen Swallow-Team arbeitet mit Apple zusammen, um diese Änderungen in zukünftige gdb-Releases zu integrieren.

Profiling

Unladen Swallow integriert sich mit oProfile 0.9.4 und neuer [18] zur Unterstützung von Assembly-Level-Profiling auf Linux-Systemen. Das bedeutet, dass oProfile JIT-kompilierte Funktionen in seinen Berichten korrekt symbolisieren wird.

Beispielbericht, bei dem die mit #u# beginnenden Symbolnamen JIT-kompilierte Python-Funktionen sind

$ opreport -l ./python | less
CPU: Core 2, speed 1600 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples % image name symbol name
79589 4.2329 python PyString_FromFormatV
62971 3.3491 python PyEval_EvalCodeEx
62713 3.3354 python tupledealloc
57071 3.0353 python _PyEval_CallFunction
50009 2.6597 24532.jo #u#force_unicode
47468 2.5246 python PyUnicodeUCS2_Decode
45829 2.4374 python PyFrame_New
45173 2.4025 python lookdict_string
43082 2.2913 python PyType_IsSubtype
39763 2.1148 24532.jo #u#render5
38145 2.0287 python _PyType_Lookup
37643 2.0020 python PyObject_GC_UnTrack
37105 1.9734 python frame_dealloc
36849 1.9598 python PyEval_EvalFrame
35630 1.8950 24532.jo #u#resolve
33313 1.7717 python PyObject_IsInstance
33208 1.7662 python PyDict_GetItem
33168 1.7640 python PyTuple_New
30458 1.6199 python PyCFunction_NewEx

Diese Unterstützung ist funktionsfähig, aber noch nicht ausgereift. Unladen Swallow pflegt eine Liste von Punkten, die unserer Meinung nach wichtig sind, um unsere oProfile-Integration zu verbessern und sie für Kern-CPython-Entwickler nützlicher zu machen [19].

Höhepunkte

• Symbolisierung von JIT-Frames funktioniert in oProfile unter Linux.

Niedrige Punkte

• Bisher wurde keine Arbeit in die Verbesserung der Symbolisierung von JIT-kompilierten Frames für Apples Shark [20] oder Microsofts Visual Studio Profiling-Tools investiert.
• Für die oProfile-Ausgabe ist noch etwas Polishing gewünscht.

Wir empfehlen die Verwendung von oProfile 0.9.5 (und neuer), um einen inzwischen behobenen Bug auf x86-64-Plattformen in oProfile zu umgehen. oProfile 0.9.4 funktioniert jedoch auch auf 32-Bit-Plattformen.

Angesichts der einfachen Integration von oProfile mit LLVM [21] und Unladen Swallow [22] sollten auch andere Profiling-Tools einfach zu integrieren sein, sofern sie eine ähnliche JIT-Schnittstelle unterstützen [23].

Wir haben den Prozess zur Verwendung von oProfile zum Profilieren von Unladen Swallow dokumentiert [24]. Dieses Dokument wird in den Doc/-Baum von CPython in die Zusammenführung aufgenommen.

Hinzufügen von C++ zu CPython

Um LLVM zu verwenden, hat Unladen Swallow C++ in den Kern-CPython-Baum und den Build-Prozess eingeführt. Dies ist ein unvermeidlicher Teil der Abhängigkeit von LLVM; obwohl LLVM eine C-API anbietet [8], ist diese begrenzt und macht die von CPython benötigte Funktionalität nicht zugänglich. Aus diesem Grund haben wir die internen Details des Unladen Swallow JIT und seine unterstützende Infrastruktur in C++ implementiert. Wir schlagen nicht vor, den gesamten CPython-Code in C++ zu konvertieren.

Höhepunkte

• Einfache Nutzung von LLVMs vollständiger, leistungsfähiger Codegenerierung und zugehörigen APIs.
• Bequeme, abstrakte Datenstrukturen vereinfachen den Code.
• C++ ist auf relativ kleine Ecken der CPython-Codebasis beschränkt.
• C++ kann über ./configure --without-llvm deaktiviert werden, was sogar die Abhängigkeit von libstdc++ auslässt.

Niedrige Punkte

• Entwickler müssen zwei verwandte Sprachen, C und C++, kennen, um an der gesamten Breite von CPython-Interna arbeiten zu können.
• Ein C++-Styleguide muss entwickelt und durchgesetzt werden. PEP 7 wird erweitert [119], um C++ zu umfassen, indem die relevanten Teile der C++-Styleguides von Unladen Swallow [69], LLVM [70] und Google [71] übernommen werden.
• Unterschiedliche C++-Compiler erzeugen unterschiedliche ABIs; dies kann Probleme verursachen, wenn CPython mit einem C++-Compiler kompiliert wird und Erweiterungsmodule mit einem anderen C++-Compiler kompiliert werden.

Verwaltung von LLVM-Releases, C++-API-Änderungen

LLVM wird regelmäßig alle sechs Monate veröffentlicht. Das bedeutet, dass LLVM während der Entwicklung einer CPython 3.x-Version zwei- oder dreimal veröffentlicht werden kann. Jede LLVM-Veröffentlichung bringt neuere und leistungsfähigere Optimierungen, verbesserte Plattformunterstützung und anspruchsvollere Codegenerierung.

LLVM-Releases enthalten normalerweise inkompatible Änderungen an der LLVM C++ API; die Release Notes für LLVM 2.6 [9] enthalten eine Liste von absichtlich eingeführten Inkompatibilitäten. Unladen Swallow hat den LLVM-Trunk während der Entwicklung eng verfolgt. Unsere Erfahrung ist, dass LLVM API-Änderungen offensichtlich und leicht oder mechanisch zu beheben sind. Wir fügen zwei solche Änderungen aus dem Unladen Swallow-Baum als Referenzen hinzu: [10], [11].

Aufgrund von API-Inkompatibilitäten empfehlen wir, dass ein LLVM-basierter CPython die Kompatibilität mit einer einzigen LLVM-Version gleichzeitig anstrebt. Dies wird den Aufwand für das Kernentwicklungsteam reduzieren. Die Bindung an eine LLVM-Version sollte aus Sicht des Paketmanagements kein Problem darstellen, da vorab kompilierte LLVM-Pakete in der Regel recht schnell nach einer LLVM-Veröffentlichung über Standard-Systempaketmanager verfügbar werden und andernfalls stellt llvm.org selbst Binärpakete bereit.

Unladen Swallow enthielt historisch eine Kopie der LLVM- und Clang-Source-Trees im Unladen Swallow-Baum; dies geschah, um uns zu ermöglichen, den LLVM-Trunk eng zu verfolgen, während wir Patches daran vornahmen. Wir empfehlen dieses Entwicklungsmodell für CPython nicht. CPython-Releases sollten auf offiziellen LLVM-Releases basieren. Vorab kompilierte LLVM-Pakete sind für Darwin über MacPorts [12] und für die meisten großen Linux-Distributionen verfügbar ([13], [14], [16]). LLVM selbst bietet zusätzliche Binärdateien, z. B. für MinGW [25].

LLVM ist derzeit für statisches Linken vorgesehen; dies bedeutet, dass Binärpakete von CPython die relevanten Teile (nicht alle!) von LLVM enthalten werden. Dies wird die Binärgröße erhöhen, wie oben erwähnt. Um die nachgelagerte Paketverwaltung zu vereinfachen, werden wir LLVM modifizieren, um die dynamische Verlinkung besser zu unterstützen. Dieses Problem wird die endgültige Zusammenführung blockieren [97].

Unladen Swallow hat einen Vollzeit-Ingenieur beauftragt, alle verbleibenden kritischen Probleme in LLVM vor der LLVM 2.7-Veröffentlichung zu beheben. Wir halten es für unerlässlich, dass CPython 3.x auf einer veröffentlichten Version von LLVM basieren kann, anstatt wie Unladen Swallow eng den LLVM-Trunk zu verfolgen. Wir glauben, dass wir diese Arbeit [98] vor der Veröffentlichung von LLVM 2.7, erwartet im Mai 2010, abschließen werden.

CPython kompilieren

Zusätzlich zu einer Laufzeitabhängigkeit von LLVM enthält Unladen Swallow eine Build-Zeitabhängigkeit von Clang [5], einem LLVM-basierten C/C++-Compiler. Wir verwenden dies, um Teile der C-Sprachen-Python-Laufzeit in LLVMs Zwischenrepräsentation zu kompilieren; dies ermöglicht uns Cross-Language-Inlining, was zu erhöhter Leistung führt. Clang ist nicht erforderlich, um Unladen Swallow auszuführen. Clang Binärpakete sind von den meisten großen Linux-Distributionen verfügbar (z. B. [15]).

Wir haben die Auswirkungen von Unladen Swallow auf die Zeit zum Kompilieren von Python untersucht, einschließlich Konfigurieren, vollständiger Kompilierung und inkrementeller Kompilierung nach dem Berühren einer einzelnen C-Quelldatei.

Vollständige Builds erleiden Einbußen aufgrund von a) zusätzlichen .cc-Dateien, die für die LLVM-Interaktion benötigt werden, b) statischer Verlinkung von LLVM in libpython, c) Kompilierung von Teilen der Python-Laufzeit in LLVM IR, um Cross-Language-Inlining zu ermöglichen.

Inkrementelle Builds sind ebenfalls etwas langsamer als das Mainline CPython. Die folgende Tabelle zeigt die inkrementellen Neubauzeiten nach dem Berühren von Objects/listobject.c.

Wie bei vollständigen Builds stammt diese zusätzliche Zeit aus der statischen Verlinkung von LLVM in libpython. Wenn libpython dynamisch gegen LLVM gelinkt wäre, würde dieser Overhead reduziert.

Notfallpläne

Es besteht die Möglichkeit, dass wir den Speicherverbrauch oder die Startzeit nicht auf ein für die CPython-Community zufriedenstellendes Niveau reduzieren können. Unser primärer Notfallplan für diese Situation ist die Umstellung von einer Online-Just-in-Time-Kompilierungsstrategie auf eine Offline-Ahead-of-Time-Strategie unter Verwendung einer instrumentierten CPython-Interpreter-Schleife zur Gewinnung von Feedback. Dies ist dasselbe Modell, das von GCCs Feedback-Directed Optimizations (-fprofile-generate) [111] und Microsoft Visual Studios Profil-gesteuerten Optimierungen [112] verwendet wird; wir werden uns hier auf „Feedback-Directed Optimization“ oder FDO beziehen.

Wir glauben, dass ein FDO-Compiler für Python einem JIT-Compiler unterlegen wäre. FDO erfordert eine qualitativ hochwertige, repräsentative Benchmark-Suite, die sowohl in der Open-Source- als auch in der Closed-Source-Entwicklung relativ selten ist. Ein JIT-Compiler kann dynamisch die Hotspots in jeder Anwendung finden und optimieren – Benchmark-Suite oder nicht – und so Anpassungen an Änderungen in Anwendungsengpässen ohne menschliches Eingreifen ermöglichen.

Wenn ein Ahead-of-Time FDO-Compiler benötigt wird, sollte er einen großen Teil des Codes und der Infrastruktur nutzen können, die bereits für den JIT-Compiler von Unladen Swallow entwickelt wurden. Tatsächlich könnten diese beiden Kompilierungsstrategien nebeneinander existieren.