Dieser Artikel führt Sie durch die JIT in PHP 8 und spricht darüber, wie JIT am Interpretationsprozess beteiligt ist. Ich hoffe, dass er für alle hilfreich ist!
Der JIT-Compiler (Just In Time) von PHP 8 wird als Erweiterung in PHP integriert. Die Opcache-Erweiterung wird verwendet, um bestimmte Opcodes zur Laufzeit direkt in CPU-Anweisungen umzuwandeln.
Das bedeutet, dass Zend VM nach der Verwendung von JIT bestimmte Opcodes nicht interpretieren muss und diese Anweisungen direkt als Anweisungen auf CPU-Ebene ausgeführt werden.
Die Auswirkungen des PHP 8 Just In Time (JIT)-Compilers sind unbestreitbar. Bisher habe ich jedoch festgestellt, dass sehr wenig darüber bekannt ist, was JIT tun soll.
Nach langem Recherchieren und Aufgeben habe ich beschlossen, den PHP-Quellcode selbst zu überprüfen. Durch die Kombination einiger meiner Kenntnisse der C-Sprache und all der verstreuten Informationen, die ich bisher gesammelt habe, habe ich diesen Artikel verfasst, der Ihnen hoffentlich dabei helfen wird, PHPs JIT besser zu verstehen.
Um es einfach auszudrücken: Wenn das JIT wie erwartet funktioniert, wird Ihr Code nicht über die Zend-VM ausgeführt, sondern direkt als Satz von Anweisungen auf CPU-Ebene.
Das ist die ganze Idee.
Aber um es besser zu verstehen, müssen wir uns überlegen, wie PHP intern funktioniert. Nicht sehr kompliziert, bedarf aber einer Einführung.
Ich habe einen Blogbeitrag geschrieben, der einen groben Überblick über die Funktionsweise von PHP gibt. Wenn Sie der Meinung sind, dass dieser Beitrag zu viel ist, schauen Sie sich einfach einen anderen an und kommen Sie später noch einmal vorbei. Die Dinge werden verständlicher.
Wie wir alle wissen, ist PHP eine interpretierte Sprache, aber was bedeutet dieser Satz selbst?
Jedes Mal, wenn Sie PHP-Code (Befehlszeilenskript oder WEB-Anwendung) ausführen, muss dieser den PHP-Interpreter durchlaufen. Am häufigsten werden die PHP-FPM- und CLI-Interpreter verwendet.
Die Aufgabe des Interpreters ist einfach: PHP-Code empfangen, interpretieren und das Ergebnis zurückgeben.
Allgemein interpretierte Sprachen folgen diesem Prozess. Bei einigen Sprachen entfallen möglicherweise einige Schritte, die Grundidee ist jedoch dieselbe. In PHP ist der Prozess wie folgt:
liest den PHP-Code und interpretiert ihn als eine Reihe von Schlüsselwörtern, sogenannte Tokens. Durch diesen Vorgang weiß der Interpreter, welcher Code in jedem Programm geschrieben wurde. Dieser Schritt wird Lexing oder Tokenisieren genannt.
Nachdem der PHP-Interpreter die Token-Sammlung erhalten hat, versucht er, sie zu analysieren. Ein abstrakter Syntaxbaum (AST) wird durch einen Prozess namens „Parsing“ generiert. Hier ist AST eine Reihe von Knoten, die darstellen, welche Operationen ausgeführt werden sollen. Beispielsweise bedeutet „echo 1 + 1“ tatsächlich „das Ergebnis von 1 + 1 drucken“ oder genauer gesagt „eine Operation drucken, diese Operation ist 1 + 1“.
Mit Opcodes kommt jetzt der spaßige Teil:
AusführenDieses Bild kann es für Sie klarer machen:
Wie Sie sehen können. Hier ist eine Frage: Auch wenn sich der PHP-Code nicht geändert hat, wird dieser Prozess bei jeder Ausführung befolgt?
Lassen Sie uns einen Blick zurück auf Opcodes werfen. Das ist richtig! Aus diesem Grund gibt es die
Opcache-Erweiterung.
Opcache-ErweiterungDie Opcache-Erweiterung wird mit PHP geliefert und es besteht normalerweise keine Notwendigkeit, sie zu deaktivieren. Wenn Sie PHP verwenden, ist es am besten, Opcache zu aktivieren.
Dies ist ein Prozessdiagramm, das die Opcache-Erweiterung enthält:
Erklärungsprozess für PHP mit Opcache. Wenn die Datei bereits analysiert wurde, ruft PHP zwischengespeicherte Opcodes dafür ab, anstatt sie erneut zu analysieren.Die Schritte Lexing/Tokenisieren, Parsen und Kompilieren perfekt überspringen?
Randbemerkung:Dies sind die fantastischen PHP 7.4-Vorladefunktionen. RFC ermöglicht es Ihnen, PHP FPM anzuweisen, die Codebasis zu analysieren, in Opcodes umzuwandeln und vor der Ausführung zwischenzuspeichern.
Möchten Sie wissen, wie JIT an diesem Interpretationsprozess teilnimmt? Dieser Artikel wird es erklären. Was bewirkt die Just-In-Time-Kompilierung?
Nachdem ich mir Zeevs PHP- und JIT-Sendung auf PHP Internals News angehört habe, habe ich herausgefunden, was JIT eigentlich macht.
Zend VM ist ein in C geschriebenes Programm, das als Schicht zwischen Opcodes und der CPU fungiert. JIT generiert kompilierten Code direkt zur Laufzeit, sodass PHP die Zend-VM überspringen und direkt von der CPU ausgeführt werden kann. Theoretisch wird die Leistung besser sein.
Das klingt seltsam, da für jeden Strukturtyp eine konkrete Implementierung geschrieben werden muss, bevor er in Maschinencode kompiliert werden kann. Aber tatsächlich ist das vernünftig.
PHPs JIT verwendet eine Bibliothek namens DynaASM (Dynamic Assembler), die einen Satz von CPU-Anweisungen in einem bestimmten Format in Assembler-Code für viele verschiedene CPU-Typen abbildet. Daher muss der Compiler nur DynASM verwenden, um Opcodes in Maschinencode für eine bestimmte Struktur umzuwandeln.
Allerdings gibt es ein Problem, das mich schon seit langem beschäftigt.
Wenn das Vorladen PHP-Code vor der Ausführung in Opcodes analysieren kann und DynASM Opcodes in Maschinencode kompilieren kann (Just-In-Time-Kompilierung), warum verwenden wir dann nicht die Ahead-of-Time-Kompilierung, um PHP sofort zu kompilieren?
Einer der Gründe, warum ich durch das Anhören von Zeevs Sendung herausgefunden habe, ist, dass PHP eine schwach typisierte Sprache ist, was bedeutet, dass PHP den Typ einer Variablen normalerweise nicht kennt, bis die Zend-VM versucht, einen Opcode auszuführen.
Sie können den Union-Typ Zend_value überprüfen, um zu erfahren, dass viele Zeiger auf Variablen unterschiedlichen Typs verweisen. Immer wenn Zend VM versucht, einen Wert von einem Zend_value abzurufen, verwendet es Makros wie ZSTR_VAL, um einen Zeiger auf einen String im Union-Typ abzurufen.
Zum Beispiel verarbeitet dieser Zend VM-Handler „kleiner als oder gleich“ (
Die Verwendung von Maschinencode zur Ausführung der Typinferenzlogik ist nicht möglich und kann langsamer werden.
Erst auswerten und dann kompilieren ist ebenfalls keine gute Option, da das Kompilieren in Maschinencode eine CPU-intensive Aufgabe ist. Es ist also auch nicht gut, alles zur Laufzeit zu kompilieren.
Jetzt wissen wir, dass Typen nicht gut abgeleitet werden können, um sie im Voraus zu kompilieren. Wir wissen auch, dass die Kompilierung zur Laufzeit rechenintensiv ist. Was sind also die Vorteile von JIT für PHP?
Um ein Gleichgewicht zu erreichen, versucht PHPs JIT, nur wertvolle Opcodes zu kompilieren. Dazu analysiert das JIT die Opcodes, die die Zend-VM ausführen wird, und prüft auf mögliche Kompilierungen. (Laut Konfigurationsdatei)
Wenn ein Opcode kompiliert wird, übergibt er die Ausführung an den kompilierten Code und nicht an Zend VM. Es sieht so aus:
JIT-Interpretationsprozess für PHP. Wenn sie kompiliert werden, werden Opcodes nicht von der Zend-VM ausgeführt.
Daher gibt es in der Opcache-Erweiterung zwei Erkennungsanweisungen, um zu bestimmen, ob Opcode kompiliert werden soll. Wenn ja, verwendet der Compiler DynASM, um diesen Opcode in Maschinencode umzuwandeln und diesen Maschinencode auszuführen.
Interessanterweise muss die Codeausführung nahtlos zwischen JIT und interpretiertem Code wechseln können, da der in der aktuellen Schnittstelle kompilierte Code ein MB-Limit hat (ebenfalls konfigurierbar).
Übrigens hat mir dieser Vortrag von Benoit Jacquemont über JIT in PHP geholfen, die ganze Sache zu verstehen.
Ich bin mir immer noch nicht sicher, wann der Kompilierungsteil tatsächlich fertig war, aber ich denke, im Moment möchte ich es nicht wirklich wissen.
Ich hoffe, jetzt ist jedem klar, warum die meisten PHP-Anwendungen durch die Verwendung von Just-in-Time-Compilern keine enormen Leistungssteigerungen erzielen. Aus diesem Grund empfiehlt Zeev, dass die Erstellung von Profilen und das Experimentieren mit verschiedenen JIT-Konfigurationen für Ihre Anwendung der beste Ansatz ist.
Wenn Sie PHP FPM verwenden, ist es üblich, kompilierte Opcodes über mehrere Anfragen hinweg zu teilen, aber das ändert nichts.
Das liegt daran, dass JIT rechenintensive Vorgänge optimiert und die meisten PHP-Anwendungen heutzutage mehr E/A-gebunden sind als alles andere. Wenn Sie ohnehin auf Festplatte oder Netzwerk zugreifen, ist die Verarbeitung des Vorgangs kompiliert. Das spielt keine Rolle. Der Zeitpunkt wird sehr ähnlich sein.
Es sei denn...
Sie machen etwas, das nicht an E/A gebunden ist, wie Bildverarbeitung oder maschinelles Lernen. Alles, was E/A nicht berührt, profitiert von einem JIT-Compiler.
Aus diesem Grund sagen die Leute jetzt, dass wir lieber native Funktionen in PHP schreiben als in C. Wenn diese Funktion trotzdem kompiliert werden würde, wäre der Overhead nicht ausdrucksstark.
Es macht Spaß, PHP-Programmierer zu werden ...
Ich hoffe, dieser Artikel wird Ihnen hilfreich sein und es Ihnen ermöglichen, die JIT von PHP8 besser zu verstehen.
Ursprüngliche Adresse: https://thephp.website/en/issue/php-8-jit/
Empfohlen: „PHP Video Tutorial“
Das obige ist der detaillierte Inhalt vonEin detaillierter Blick auf JIT in PHP 8. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!