Verfügt der Python 3-Interpreter über eine JIT-Funktion?


71

Ich habe festgestellt, dass Python, wenn ich Python etwas mehr frage, meine Maschinenressource nicht zu 100% nutzt und es nicht wirklich schnell ist, es ist schnell im Vergleich zu vielen anderen interpretierten Sprachen, aber im Vergleich zu kompilierten Sprachen denke ich, dass der Unterschied ist wirklich bemerkenswert.

Ist es möglich, Dinge mit einem Just In Time (JIT) -Compiler in Python 3 zu beschleunigen?

Normalerweise ist ein JIT-Compiler das einzige, was die Leistung in interpretierten Sprachen verbessern kann. Ich beziehe mich also auf diese. Wenn andere Lösungen verfügbar sind, würde ich gerne neue Antworten akzeptieren.



@rubik danke, aber ich suchte nach einer Lösung für Python 3, nicht für Python 2, und für den offiziellen Interpreter, keinen anderen Interpreter.
guz

1
Obwohl PyPy noch nicht Python unterstützt 3. Je nachdem , was Sie taten, gibt es alle Arten von Möglichkeiten zur Verbesserung der Leistung - zum Beispiel besseren Algorithmen, Parallelisierung der Verwendung multiprocssingoder threadingModule oder in C eine Verlängerung zu schreiben (was sein kann einfacher gemacht mit Cython oder ähnlicher Software).
James

Die meisten Implementierungen von Python werden nicht interpretiert, sondern zu Bytecode kompiliert.
Russell Borogove

3
@ Rubik, toller Vorschlag. Ich würde Ihrer Liste hinzufügen: "Vorhandene Erweiterungen verwenden (wie NumPy)".
Jimhark

Antworten:


70

Zunächst einmal ist Python 3 (.x) eine Sprache, für die es eine beliebige Anzahl von Implementierungen geben kann. Okay, bis heute implementiert keine Implementierung außer CPython diese Versionen der Sprache. Aber das wird sich ändern (PyPy holt auf).

Um die Frage zu beantworten, die Sie stellen wollten: CPython, 3.x oder andere, enthält, hat und wird wahrscheinlich nie einen JIT-Compiler enthalten. Einige andere Python-Implementierungen (PyPy nativ, Jython und IronPython durch Wiederverwendung von JIT-Compilern für die virtuellen Maschinen, auf denen sie aufbauen) verfügen über einen JIT-Compiler. Und es gibt keinen Grund, warum ihre JIT-Compiler nicht mehr funktionieren würden, wenn sie Python 3-Unterstützung hinzufügen.

Aber während ich hier bin, möchte ich auch ein Missverständnis ansprechen:

Normalerweise ist ein JIT-Compiler das einzige, was die Leistung in interpretierten Sprachen verbessern kann

Das ist nicht richtig. Ein JIT-Compiler entfernt in seiner grundlegendsten Form lediglich den Interpreter-Overhead, der einen Teil der beobachteten Verlangsamung ausmacht, nicht jedoch die Mehrheit. Ein guter JIT-Compiler führt auch eine Reihe von Optimierungen durch, die den für die Implementierung zahlreicher Python-Funktionen im Allgemeinen erforderlichen Overhead beseitigen (indem Sonderfälle erkannt werden, die eine effizientere Implementierung ermöglichen). Beispiele hierfür sind dynamische Typisierung, Polymorphismus und verschiedene introspektive Funktionen.

Einfach implementieren a Compilers hilft dabei nicht. Sie benötigen sehr clevere Optimierungen, von denen die meisten nur unter ganz bestimmten Umständen und für ein begrenztes Zeitfenster gültig sind. JIT-Compiler haben es hier leicht, weil sie zur Laufzeit speziellen Code generieren können (das ist ihr springender Punkt), das Programm einfacher (und genauer) analysieren können, indem sie es während der Ausführung beobachten, und Optimierungen rückgängig machen können, wenn sie ungültig werden. Sie können im Gegensatz zu früheren Compilern auch mit Dolmetschern interagieren und tun dies häufig, weil dies eine vernünftige Entwurfsentscheidung ist. Ich denke, dies ist der Grund, warum sie in den Köpfen der Menschen mit Dolmetschern verbunden sind, obwohl sie unabhängig existieren können und existieren.

Es gibt auch andere Ansätze, um die Python-Implementierung zu beschleunigen, abgesehen von der Optimierung des Interpreter-Codes selbst - zum Beispiel das HotPy (2) -Projekt. Diese befinden sich jedoch derzeit in der Forschungs- oder Experimentierphase und müssen ihre Wirksamkeit (und Reife) für echten Code erst noch zeigen.

Und natürlich hängt die Leistung eines bestimmten Programms viel mehr vom Programm selbst ab als von der Sprachimplementierung. Die Sprachimplementierung legt nur eine Obergrenze fest, wie schnell Sie eine Abfolge von Vorgängen ausführen können. Im Allgemeinen können Sie die Programmleistung viel besser verbessern, indem Sie unnötige Arbeit vermeiden, dh das Programm optimieren. Dies gilt unabhängig davon, ob Sie das Programm über einen Interpreter, einen JIT-Compiler oder einen vorzeitigen Compiler ausführen. Wenn Sie möchten, dass etwas schnell ist, geben Sie sich keine Mühe, um eine schnellere Sprachimplementierung zu erreichen. Es gibt Anwendungen, die mit dem Aufwand an Interpretation und Dynamik nicht realisierbar sind, aber nicht so häufig sind, wie Sie denken (und häufig durch selektives Aufrufen von maschinencodekompiliertem Code gelöst werden).


Ich habe gehört, dass Google daran interessiert ist, Python mit einem JIT für die 3.x-Version schneller zu machen, also habe ich nach Antworten gesucht. Das Problem mit einem anderen Interpreter ist nur die Tatsache, dass Sie am Ende mehr als eine Implementierung haben. Viele Anwendungen, die eine integrierte Python-Konsole anbieten, beziehen sich nur auf den offiziellen Python-Interpreter. Also gibt es am Ende nichts Gutes und bereit für Python 3?
guz

7
@guz Googles Unladden Swallow-Projekt wurde vor langer Zeit aufgegeben, und während ein Teil ihrer Arbeit in CPython und anderswo weiterlebt , ist ihr JIT-Compiler tot (und hat anfangs nie gut funktioniert). Ich sehe es im Allgemeinen als Vorteil an , mehrere Implementierungen zu haben , obwohl der Punkt beim Einbetten gut ist.

3
@NoctisSkytower Die meisten JVMs enthalten einen JIT-Compiler, der Java- Bytecode in Maschinencode kompiliert (und AFAIK Jython generiert JVM-Bytecode). CPython und PyPy kompilieren Python-Code tatsächlich zu ihrem eigenen internen Bytecode, bevor sie ausgeführt werden. Dies macht sie jedoch nicht zu JIT-Compilern im üblichen Sinne (einschließlich Kompilierung auf native Code-Ausgabe und enge Integration mit anderen Teilen der Laufzeit, falls vorhanden).

2
@delnan Danke für die Klarstellung! Es ist interessant herauszufinden, dass es dann tatsächlich mehrere Kompilierungsebenen gibt. source code -> byte code -> native codeUnd dann interpretiert der Mikroprozessor das in Mikrocode ...
Noctis Skytower

1
Ich hatte eine relativ einfache Modifikation der Levenshtein-Distanz in Python implementiert. Diese Routine wurde oft aufgerufen, daher habe ich sie in C erneut implementiert, aber die Python-Speichertypen verwendet und keinerlei Optimierung durchgeführt. Es ist also im Grunde der gleiche Code. Die Ausführungszeit wurde von 5 s auf 200 ms gesenkt. CPython macht einen schrecklichen Job beim Ausführen von CPU-schweren Operationen. Wenn CPU und RAM die Ursache für eine langsame Ausführungszeit sind, führt das Kompilieren anstelle des Interpretierens immer zu einer erheblichen Beschleunigung. Eine JIT ist eine Möglichkeit, die Leistung in vielen Szenarien zu steigern, ohne den Komfort für die Programmierer zu verlieren.
Gellweiler

15

Die einzige Python-Implementierung mit JIT ist PyPy . Byt - PyPy ist sowohl eine Python 2-Implementierung als auch eine Python 3-Implementierung.


5
Python 3 Unterstützung ist jetzt mehr oder weniger vollständig, zu Python 3.2
naught101

10

Das Numba-Projekt sollte unter Python 3 funktionieren. Obwohl es nicht genau das ist, was Sie gefragt haben, können Sie es ausprobieren: https://github.com/numba/numba/blob/master/docs/source/doc/userguide .rst .

Derzeit werden nicht alle Python-Syntax unterstützt.


1
Numba ist, soweit ich das beurteilen kann, keine Implementierung von Python und soll es auch nie sein. Stattdessen handelt es sich anscheinend um eine Implementierung für eine Sprache, die täuschend wie Python aussieht, aber eigentlich nichts Vergleichbares ist - viele Sprachfunktionen für die Leistung zu opfern. Korrigiere mich, wenn ich falsch liege. Vielleicht haben mich die PyPy-Entwickler einer Gehirnwäsche unterzogen, aber ich denke, dass dies nicht mit Python verglichen werden sollte (oder sogar so genannt werden sollte), außer um festzustellen, dass es völlig anders ist als Python.

@delnan: Das ist interessant. Warum nennst du es nicht Python mit weniger Funktionen? Ich kenne das Projekt nicht gut, aber IIUC Sie haben eine Python-Datei, dann wenden Sie den JIT-Dekorator an und Sie sind fertig :) Wahrscheinlich ist dies zu optimistisch und / oder naiv. Eigentlich habe ich es noch nicht einmal ausprobiert, obwohl ich wollte ...
Rubik

Da "Python mit weniger Funktionen" nicht Python ist, ist es eine ganz andere Sprache, die zufällig auch in Python akzeptiert wird. Ja, wenn es einfach funktioniert, ist es zu optimistisch. Sofern die Numba-Entwickler nicht im Alleingang das getan haben, was PyPy mit vielen zusätzlichen Einschränkungen in viel kürzerer Zeit und mit weniger Personal getan hat, unterstützt Numba notwendigerweise nur eine winzige Teilmenge von Python. Ich würde sagen, die Mindestbeschränkung ist (implizite, leicht ableitbare) statische Typisierung. Ich wäre angenehm überrascht, wenn sie auch beliebige benutzerdefinierte Objekte unterstützen würden, aber ich bezweifle es.

@delnan: Ok du hast mich überzeugt! Ich werde es in zukünftigen Antworten nicht Python nennen! ;)
Rubik

6

Sie können den pypy py3-Zweig ausprobieren , der mehr oder weniger python-kompatibel ist, aber die offizielle CPython-Implementierung hat keine JIT.


danke, ich bin nur auf der offiziellen Python - Interpreter für die Version 3.x der Sprache interessiert, so dass ich dies als nehmen nicht
guz

3

Dies wird am besten von einigen der bemerkenswerten Python-Entwickler auf dieser Site beantwortet.

Dennoch möchte ich kommentieren: Wenn ich über die Geschwindigkeit interpretierter Sprachen spreche, zeige ich gerne auf ein Projekt, das an diesem Ort gehostet wird : Computer Language Benchmarks Game

Es ist eine Seite, die sich dem Ausführen von Benchmarks widmet. Es sind bestimmte Aufgaben zu erledigen. Jeder kann eine Lösung in seiner bevorzugten Sprache einreichen, und dann vergleichen die Tests die Laufzeit jeder Lösung. Lösungen können von Experten begutachtet werden, werden häufig von anderen weiter verbessert und die Ergebnisse werden anhand der Spezifikation überprüft. Auf lange Sicht ist dies das fairste Benchmarking-System zum Vergleich verschiedener Sprachen.

Wie Sie aus indikativen Zusammenfassungen wie dieser sehen können , sind kompilierte Sprachen im Vergleich zu interpretierten Sprachen recht schnell. Der Unterschied liegt jedoch wahrscheinlich nicht so sehr in der genauen Art der Kompilierung, sondern in der Tatsache, dass Python (und die anderen im Diagramm langsamer als Python) vollständig dynamisch sind. Objekte können im laufenden Betrieb geändert werden. Typen können im laufenden Betrieb geändert werden. Daher muss einige Typprüfung auf die Laufzeit verschoben werden, anstatt auf die Kompilierungszeit.

Während Sie über die Vorteile des Compilers streiten können, müssen Sie berücksichtigen, dass es verschiedene Funktionen in verschiedenen Sprachen gibt. Und diese Funktionen können zu einem intrinsischen Preis kommen.

Wenn es um Geschwindigkeit geht: Meistens ist es nicht die Sprache und die wahrgenommene Langsamkeit einer Sprache, die das Problem verursacht, sondern ein schlechter Algorithmus. Ich musste nie die Sprache wechseln, weil eine zu langsam war: Wenn mein Code ein Geschwindigkeitsproblem aufweist, behebe ich den Algorithmus. Wenn Ihr Code jedoch zeitaufwändige, rechenintensive Schleifen enthält, lohnt es sich normalerweise, diese neu zu kompilieren. Ein prominentes Beispiel sind in C codierte Bibliotheken, die von Skriptsprachen verwendet werden (Perl XS-Bibliotheken oder zB numpy / scipy für Python, lapack / blas sind Beispiele für Bibliotheken, die mit Bindungen für viele Skriptsprachen verfügbar sind).


Ja, aber wenn ich nur Code aus einer source.py-Datei ausführe, kann ich von dieser Dynamik wahrscheinlich nicht profitieren. Auch in dem Moment, in dem ich meinen Code aus Dateien ausführen werde, können Sie mein Betriebssystem, meine Plattform und mein Programm bestimmen Dies ist wahrscheinlich eine nützliche Information, die zu einer Optimierung wie im JIT-Beispiel führen kann.
guz

@igouy: Danke, dass du darauf hingewiesen hast. Ich habe meine Antwort klargestellt.
cfi

Der Projektname wird im Banner auf jeder Seite und in der Titelleiste des Webbrowsers angezeigt. Die auf der Website angezeigten Absätze erklären, warum das Projekt seit mindestens 5 Jahren nicht mehr als "Shootout" bezeichnet wurde.
igouy

Du bist wählerisch. Aber vielleicht zu Recht. Der Name wurde geändert. Seien Sie vorsichtig mit Ihren Kritikern: Der Server heißt immer noch Shootout, und ich bin viel älter, als ich hier zugeben möchte, und bin seit Jahren an diesen Namen gewöhnt. Ich glaube, die Namensänderung ist nur ein Wortspiel, denn am Ende zählt der Kontext. Wenn die Leute die Vorzüge und Probleme mit sprachübergreifenden Benchmarks vorher nicht verstanden haben, werden sie es jetzt nicht verstehen. Ich habe das immer noch korrigiert, weil ich an die Magie der Worte glaube und selbst ein Trottel bin :-) Im Ernst, danke für deine Bemühungen, dies zu korrigieren.
cfi

Das Durchsuchen der Google-Suchergebnisse, die aus Pornoseiten und Massenmorden am College bestehen, war für mich kein guter Start in den Tag - also habe ich nach Virginia Tech den Namen geändert.
igouy

1

Wenn Sie JIT wie im Just-in-Time-Compiler für eine Bytecode-Darstellung meinen, dann hat es eine solche Funktion (seit 2.2). Wenn Sie JIT für Maschinencode meinen, dann nein. Die Kompilierung zu Bytecode bietet jedoch eine erhebliche Leistungsverbesserung. Wenn Sie möchten, dass es zu Maschinencode kompiliert wird, ist Pypy die Implementierung, nach der Sie suchen.

Hinweis: pypy funktioniert nicht mit Python 3.x.


0

Wenn Sie nach Geschwindigkeitsverbesserungen in einem Codeblock suchen, sollten Sie sich rpythonic ansehen , das mit pypy auf C kompiliert wird. Es wird ein Dekorator verwendet, der es in eine JIT für Python konvertiert.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.