Just In Time (Just-in-Time-Kompilierung) ist eine Softwareoptimierungstechnologie, die sich auf das Kompilieren von Bytecode für die Maschine bezieht im Laufzeitcode. Aus intuitiver Sicht ist es für uns leicht zu glauben, dass Maschinencode direkt von Computern erkannt und ausgeführt werden kann und dass es effizienter ist als Zend, Opcode zu lesen und einzeln auszuführen. Unter ihnen verwendet HHVM (HipHop Virtual Machine, HHVM ist eine virtuelle Open-Source-PHP-Maschine von Facebook) JIT, was ihren PHP-Leistungstest um eine Größenordnung verbessert und schockierende Testergebnisse veröffentlicht, was uns auch intuitiv denken lässt, dass JIT ein leistungsstarkes Tool ist Technologie, die Stein in Gold verwandelt.

Tatsächlich haben Bruder Niao und Dmitry (einer der Kernentwickler der PHP-Sprache) im Jahr 2013 einmal einen JIT-Versuch mit der PHP5.5-Version unternommen (sie wurde nicht veröffentlicht). Der ursprüngliche Ausführungsprozess von PHP5.5 besteht darin, den PHP-Code durch lexikalische und syntaktische Analyse in Opcode-Bytecode zu kompilieren (das Format ähnelt in gewisser Weise der Assemblierung). Anschließend liest die Zend-Engine diese Opcode-Anweisungen, analysiert sie und führt sie einzeln aus.

Und sie führten nach dem Opcode-Link eine Typinferenz (TypeInf) ein und generierten dann vor der Ausführung ByteCodes über JIT.

So wurden im Benchmark (Testprogramm) spannende Ergebnisse erzielt. Nach der Implementierung von JIT wurde die Leistung im Vergleich zu PHP5.5 um das Achtfache verbessert. Als sie diese Optimierung jedoch in das eigentliche Projekt WordPress (ein Open-Source-Blogging-Projekt) einbauten, stellten sie fast keine Leistungsverbesserung fest und erhielten ein rätselhaftes Testergebnis.

Also nutzten sie das Profiltyp-Tool unter Linux, um den CPU-Zeitverbrauch der Programmausführung zu analysieren.

Verteilung des CPU-Verbrauchs bei 100-maliger Ausführung von WordPress:

21 % der CPU-Zeit werden für die Speicherverwaltung aufgewendet.

12 % der CPU-Zeit werden für Hash-Tabellenoperationen aufgewendet, hauptsächlich für das Hinzufügen, Löschen, Ändern und Überprüfen von PHP-Arrays.

30 % CPU-Zeit werden für integrierte Funktionen wie strlen aufgewendet.

25 % CPU-Zeit werden in VM (Zend Engine) verbracht.

Nach der Analyse wurden zwei Schlussfolgerungen gezogen:

(1) Wenn die von JIT generierten ByteCodes zu groß sind, führt dies zu einer Verringerung der CPU-Cache-Trefferrate (CPU-Cache-Miss)

in PHP5 Da es im .5-Code keine offensichtliche Typdefinition gibt, können wir uns nur auf die Typinferenz verlassen. Definieren Sie die Variablentypen, auf die so weit wie möglich geschlossen werden kann, und entfernen Sie dann in Kombination mit der Typinferenz Zweigcodes, die nicht von diesem Typ sind, um direkt ausführbaren Maschinencode zu generieren. Allerdings kann die Typinferenz nicht alle Typen ableiten. In WordPress sind weniger als 30 % der Typinformationen, die abgeleitet werden können, begrenzt, und der Verzweigungscode, der reduziert werden kann, ist begrenzt. Infolgedessen wird nach JIT direkt Maschinencode generiert und die generierten ByteCodes sind zu groß, was schließlich zu einem erheblichen Rückgang der CPU-Cache-Treffer (CPU-Cache-Miss) führt.

CPU-Cache-Treffer bedeutet, dass während des Prozesses des Lesens und Ausführens von Anweisungen durch die CPU die Suche nach unten bis zum Cache der zweiten Ebene fortgesetzt werden muss, wenn die erforderlichen Daten nicht im Cache der ersten Ebene (L1) gelesen werden können Der First-Level-Cache (L2) und der Third-Level-Cache (L3) versuchen schließlich, die erforderlichen Befehlsdaten im Speicherbereich zu finden, und der Lesezeitunterschied zwischen dem Speicher und dem CPU-Cache kann das 100-fache erreichen. Wenn daher die ByteCodes zu groß sind und die Anzahl der ausgeführten Anweisungen zu groß ist, kann der mehrstufige Cache nicht so viele Daten aufnehmen und einige Anweisungen müssen im Speicherbereich gespeichert werden.

Die Größe der Caches auf allen Ebenen der CPU ist ebenfalls begrenzt. Das folgende Bild zeigt die Konfigurationsinformationen des Intel i7 920:

Daher ist die CPU-Cache-Trefferquote geringer wird einen erheblichen Zeitaufwand verursachen. Andererseits wird die durch JIT erzielte Leistungsverbesserung auch dadurch ausgeglichen.

Durch JIT kann der Overhead von VM reduziert werden. Gleichzeitig kann durch die Befehlsoptimierung die Entwicklung der Speicherverwaltung indirekt reduziert werden, da die Anzahl der Speicherzuweisungen reduziert werden kann. Allerdings werden bei echten WordPress-Projekten nur 25 % der CPU-Zeit für die VM aufgewendet, und das Hauptproblem und der Hauptengpass liegt nicht wirklich auf der VM. Daher war der JIT-Optimierungsplan nicht in den PHP7-Funktionen dieser Version enthalten. Es ist jedoch wahrscheinlich, dass es in einer späteren Version implementiert wird, worauf es sich zu freuen lohnt.

(2) Der Verbesserungseffekt der JIT-Leistung hängt vom tatsächlichen Engpass des Projekts ab.

JIT wurde im Benchmark erheblich verbessert, da die Codemenge relativ gering ist und die endgültig generierten ByteCodes ebenfalls relativ gering sind Gleichzeitig ist der Hauptaufwand in der VM. Im eigentlichen WordPress-Projekt gibt es jedoch keine offensichtliche Leistungsverbesserung, da das Codevolumen von WordPress viel größer ist als das des Benchmarks. Obwohl JIT den Overhead der VM reduziert, führt es zu einer Verringerung der CPU-Cache-Treffer und zu zusätzlichem Speicher ByteCodes sind zu groß, letztendlich gibt es keine Verbesserung.

Verschiedene Arten von Projekten haben unterschiedliche CPU-Overhead-Verhältnisse und erzielen auch unterschiedliche Ergebnisse. Leistungstests ohne tatsächliche Projekte sind nicht sehr repräsentativ.

3). Zvals Veränderungen

Tatsächlich ist Zval der eigentliche Speicherträger verschiedener Arten von Variablen in PHP, der sich durch seine Toleranz und Toleranz auszeichnet. Im Wesentlichen handelt es sich um eine in der C-Sprache implementierte Struktur (Struktur). Für Studenten, die PHP schreiben, können Sie es grob als etwas verstehen, das einem Array-Array ähnelt.

PHP5s Zval, der Speicher belegt 24 Bytes:

PHP7s Zval, der Speicher belegt 16 Bytes:

Zval sank von 24 Bytes auf. 16 Wörter Abschnitt, warum ist er rückläufig? Hier müssen wir ein wenig C-Sprachgrundlage hinzufügen, um Schülern, die mit C nicht vertraut sind, das Verständnis zu erleichtern. Es gibt einen kleinen Unterschied zwischen Struktur und Union (Union). Jede Mitgliedsvariable von Struct belegt einen unabhängigen Speicherplatz, während sich die Mitgliedsvariablen in Union einen Speicherplatz teilen (d. h. wenn eine der Mitgliedsvariablen geändert wird). Der öffentliche Raum wird sein. Nach der Änderung werden keine Datensätze anderer Mitgliedsvariablen vorhanden sein. Obwohl es scheinbar viel mehr Mitgliedsvariablen gibt, hat sich der tatsächlich belegte Speicherplatz verringert.

Darüber hinaus gibt es offensichtlich auch geänderte Funktionen, einige einfache Typen verwenden keine Referenzen mehr.

Zval-Strukturdiagramm:

Zval im Bild besteht aus 2 64 Bit (1 Byte = 8 Bit, Bit ist „Bit“), wenn der Variablentyp lang oder bealoon ist und die Länge 64 Bit nicht überschreitet direkt Beim Speichern im Wert gibt es keine folgenden Referenzen. Wenn es sich bei dem Variablentyp um ein Array, ein Objekt, eine Zeichenfolge usw. mit mehr als 64 Bit handelt, ist der gespeicherte Wert ein Zeiger, der auf die tatsächliche Speicherstrukturadresse zeigt.

Für einfache Variablentypen wird die Zval-Speicherung sehr einfach und effizient.

Typen, die keine Referenzen erfordern: NULL, Boolean, Long, Double

Typen, die Referenzen erfordern: String, Array, Object, Resource, Reference

4) Interner Typ zend_string

Zend_string Es handelt sich um eine Struktur, die tatsächlich Zeichenfolgen speichert. Der eigentliche Inhalt wird in val (char, Zeichentyp) gespeichert, und val ist ein char-Array mit einer Länge von 1 (praktisch für die Belegung mit Mitgliedsvariablen).

Die letzte Mitgliedsvariable der Struktur verwendet ein char-Array anstelle von char*. Hier ist ein kleiner Optimierungstrick, der den Cache-Fehler der CPU reduzieren kann.

Wenn Sie ein char-Array verwenden und malloc den Speicher der obigen Struktur anwendet, wird es im selben Bereich angewendet. Normalerweise beträgt die Länge sizeof(_zend_string) + tatsächlicher char-Speicherplatz. Wenn Sie jedoch char* verwenden, ist das, was an dieser Stelle gespeichert wird, nur ein Zeiger, und die eigentliche Speicherung erfolgt in einem anderen unabhängigen Speicherbereich.

Vergleich der Speicherzuordnung mit char[1] und char*:

Aus Sicht der Logikimplementierung gibt es eigentlich keinen großen Unterschied zwischen den beiden und die Auswirkungen sind sehr ähnlich. Wenn diese Speicherblöcke in die CPU geladen werden, sehen sie tatsächlich ganz anders aus. Da es sich bei Ersterem um denselben Speicher handelt, der kontinuierlich gemeinsam zugewiesen wird, kann er normalerweise zusammen abgerufen werden, wenn die CPU ihn liest (da er sich im Cache derselben Ebene befindet). Letzteres enthält Daten aus zwei Speichern. Wenn die CPU den ersten Speicher liest, ist es sehr wahrscheinlich, dass sich die Daten des zweiten Speichers nicht im Cache derselben Ebene befinden, sodass die CPU unterhalb von L2 (sekundärer Cache) suchen muss even to Das gewünschte zweite Stück Speicherdaten wird im Speicherbereich gefunden. Dies führt zu einem CPU-Cache-Fehler und der zeitaufwändige Unterschied zwischen beiden kann bis zu 100 Mal betragen.

Darüber hinaus kann zend_string beim Kopieren von Zeichenfolgen mithilfe der Referenzzuweisung Speicherkopien vermeiden. 5). Um es grob zusammenzufassen: Es handelt sich um eine HashTable, die doppelt verknüpfte Listen unterstützt. Sie unterstützt nicht nur die Hash-Zuordnung für den Zugriff auf Elemente über Array-Schlüssel, sondern kann auch Array-Elemente durchlaufen, indem sie über foreach auf doppelt verknüpfte Listen zugreift.

HashTable für PHP5:

// PHP 7之前的写法：比较两个数的大小
function order_func($a, $b) {
    return ($a < $b) ? -1 : (($a > $b) ? 1 : 0);
}
// PHP新增的操作符 <=>,perfect
function order_func($a, $b) {
    return $a <=> $b;
}