Der JIT-Compiler (Just In Time) von PHP 8 wird als Erweiterung in PHP integriert. Die Opcache-Erweiterung wird verwendet, um bestimmte Opcodes direkt in From-CPU-Anweisungen umzuwandeln .
Das bedeutet, dass Zend VM bei Verwendung von JIT bestimmte Opcodes nicht interpretieren muss und diese Anweisungen direkt als Anweisungen auf CPU-Ebene ausgeführt werden.
JIT von PHP 8
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 auszuprobieren. Durch die Kombination einiger meiner Kenntnisse der C-Sprache und aller 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 die 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.
Wie wird PHP-Code ausgeführt?
Wie wir alle wissen, ist PHP eine interpretierte Sprache, aber was bedeutet dieser Satz selbst?
Jedes Mal, wenn PHP-Code (Befehlszeilenskript oder WEB-Anwendung) ausgeführt wird, muss er 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 Tokenizing genannt. Nachdem er die Tokens-Sammlung erhalten hat, versucht der PHP-Interpreter, 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 einem AST sind Abläufe und Prioritäten leichter zu verstehen. Um einen abstrakten Syntaxbaum in eine von der CPU ausführbare Operation umzuwandeln, ist ein Übergangsausdruck (IR) erforderlich, den wir in PHP Opcodes nennen. Der Prozess der Konvertierung von ASTs in Opcodes wird als Kompilierung bezeichnet. Bei Opcodes kommt jetzt der spaßige Teil: das Ausführen des Codes! PHP verfügt über eine Engine namens Zend VM, die eine Folge von Opcodes empfangen und ausführen kann. Nachdem alle Opcodes ausgeführt wurden, beendet Zend VM das Programm.
Dieses Diagramm kann es für Sie klarer machen:
Eine vereinfachte Version der Übersicht über den PHP-Interpretationsprozess.
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 Opcache-Erweiterungen.
Opcache-Erweiterung
Die Opcache-Erweiterung wird mit PHP geliefert und muss normalerweise nicht deaktiviert werden. Wenn Sie PHP verwenden, ist es am besten, Opcache zu aktivieren.
Es fügt Opcodes eine Speicher-Shared-Cache-Ebene hinzu. Seine Aufgabe besteht darin, neu generierte Opcodes aus dem AST zu extrahieren und zwischenzuspeichern, sodass die Schritte Lexing/Tokenizing und Parsing während der Ausführung übersprungen werden können.
Dies ist ein Prozessdiagramm einschließlich der Opcache-Erweiterung:
PHPs Interpretationsprozess unter Verwendung von 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 werden perfekt übersprungen.
Randbemerkung: Dies ist die fantastische Vorladefunktion von PHP 7.4. 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 beteiligt ist? Dieser Artikel wird es erklären.
Welche Auswirkungen hat die Just-In-Time-Kompilierung?
Nachdem ich mir Zeevs PHP- und JIT-Sendung auf PHP Internals News angehört hatte, fand ich heraus, was JIT eigentlich macht.
Wenn die Opcache-Erweiterung es schneller macht, Opcodes direkt an die Zend-VM zu übertragen, lässt das JIT sie laufen, ohne die Zend-VM zu verwenden.
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 DynASM (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 sofort die Ahead-of-Time-Kompilierung?
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 oft erst kennt, wenn die Zend-VM es versucht einen Opcode ausführen.
Sie können den Union-Typ Zend_value anzeigen, 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 ein Makro wie ZSTR_VAL, um einen Zeiger auf einen String im Union-Typ abzurufen.
Zum Beispiel verarbeitet dieser Zend VM-Handler „kleiner als oder gleich“ (<=)-Ausdrücke. Sehen Sie, wie es so viele if else-Verzweigungen nur zur Typinferenz codiert.
Die Verwendung von Maschinencode zur Ausführung der Typinferenzlogik ist nicht möglich und kann langsamer werden.
Erst auszuwerten und dann zu 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.
Wie wird Just In Time zusammengestellt?
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:
PHPs JIT-Interpretationsprozess. 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 es in der aktuellen Schnittstelle ein MB-Limit (auch konfigurierbar) für kompilierten Code gibt.
Übrigens hat mir dieser Vortrag von Benoit Jacquemont über JIT in PHP geholfen, die ganze Sache zu verstehen.
Ich bin immer noch nicht sicher, wann der Kompilierungsteil tatsächlich abgeschlossen wurde, aber ich denke, im Moment möchte ich es nicht wirklich wissen.
Ihre Leistungssteigerung wird also wahrscheinlich nicht riesig sein
Ich hoffe, es ist jetzt klar, warum die meisten PHP-Anwendungen nicht viel von der Verwendung von Just-in-Time-Compilern profitieren Große Leistungssteigerungen. 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 immer noch 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 trotzdem auf die Festplatte oder das Netzwerk zugreifen, spielt es keine Rolle, ob der Verarbeitungsvorgang kompiliert wird oder nicht. Der Zeitpunkt wird sehr ähnlich sein.
Es sei denn...
Sie machen etwas, das nicht 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.
Empfohlenes Tutorial: „PHP7“
Das obige ist der detaillierte Inhalt vonNeue Funktionen von PHP 8: JIT-Verständnis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
