PHP 8 nouvelles fonctionnalités Compréhension JIT

Le compilateur JIT (Just In Time) de PHP 8 sera intégré à php en tant qu'extension. L'extension Opcache est utilisée pour convertir certains opcodes directement en instructions From cpu. .

Cela signifie qu'en utilisant JIT, Zend VM n'a pas besoin d'interpréter certains opcodes et ces instructions seront exécutées directement en tant qu'instructions au niveau du CPU.

JIT de PHP 8

L'impact du compilateur PHP 8 Just In Time (JIT) est incontestable. Mais jusqu’à présent, j’ai constaté que l’on sait très peu de choses sur ce que JIT est censé faire.

Après de nombreuses recherches et abandons, j'ai décidé de vérifier moi-même le code source de PHP. En combinant certaines de mes connaissances du langage C et toutes les informations que j'ai rassemblées jusqu'à présent, j'ai rédigé cet article qui, je l'espère, vous aidera à mieux comprendre le JIT de PHP.

Pour faire simple : lorsque le JIT fonctionne comme prévu, votre code n'est pas exécuté via la VM Zend, mais directement sous la forme d'un ensemble d'instructions au niveau du CPU.

C’est toute l’idée.

Mais pour mieux le comprendre, nous devons considérer le fonctionnement interne de PHP. Pas très compliqué, mais nécessite une introduction.

Comment le code PHP est-il exécuté ?

Comme nous le savons tous, PHP est un langage interprété, mais que signifie cette phrase elle-même ?

Chaque fois que du code PHP (script en ligne de commande ou application WEB) est exécuté, il doit passer par l'interpréteur PHP. Les plus couramment utilisés sont les interpréteurs PHP-FPM et CLI.

Le travail de l'interprète est simple : recevoir du code PHP, l'interpréter et renvoyer le résultat.

Les langues généralement interprétées suivent ce processus. Certains langages peuvent supprimer quelques étapes, mais l’idée générale est la même. En PHP, le processus est le suivant :

lit le code PHP et l'interprète comme un ensemble de mots-clés appelés Tokens. Ce processus permet à l'interprète de savoir quel code a été écrit dans chaque programme. Cette étape est appelée Lexing ou Tokenizing. Après avoir obtenu la collection Tokens, l'interpréteur PHP tentera de les analyser. Un arbre de syntaxe abstraite (AST) est généré via un processus appelé Parsing. Ici, AST est un ensemble de nœuds représentant les opérations à effectuer. Par exemple, « écho 1 + 1 » signifie en réalité « imprimer le résultat de 1 + 1 » ou plus précisément « imprimer une opération, cette opération est 1 + 1 ». Avec un AST, les opérations et les priorités sont plus faciles à comprendre. La conversion d'un arbre de syntaxe abstraite en une opération pouvant être exécutée par le CPU nécessite une expression de transition (IR), que nous appelons en PHP Opcodes. Le processus de conversion des AST en Opcodes est appelé compilation. Avec les Opcodes, voici la partie amusante : exécuter le code ! PHP dispose d'un moteur appelé Zend VM capable de recevoir une séquence d'opcodes et de les exécuter. Une fois tous les Opcodes exécutés, Zend VM termine le programme.

Ce diagramme peut vous rendre les choses plus claires :

Une version simplifiée de la présentation du processus d'interprétation PHP.

Comme vous pouvez le constater. Voici une question : même si le code PHP n’a pas changé, ce processus sera-t-il toujours suivi à chaque exécution ?

Retournons sur les Opcodes. C'est exact! C'est pourquoi les extensions Opcache existent.

Extension Opcache

L'extension Opcache est livrée avec PHP et il n'est généralement pas nécessaire de la désactiver. Lorsque vous utilisez PHP, il est préférable d'activer Opcache.

Ce qu'il fait, c'est ajouter une couche de cache de mémoire partagée aux Opcodes. Son travail consiste à extraire les Opcodes nouvellement générés à partir de l'AST et à les mettre en cache afin que les étapes de Lexing/Tokenizing et d'Analyse puissent être ignorées pendant l'exécution.

Ceci est un diagramme de processus incluant l'extension Opcache :

Le processus d'interprétation de PHP utilisant Opcache. Si le fichier a déjà été analysé, PHP obtiendra les Opcodes mis en cache au lieu de l'analyser à nouveau.

Saute parfaitement les étapes de Lexing/Tokenisation, d'analyse et de compilation.

Note latérale : il s'agit de l'impressionnante fonctionnalité de préchargement de PHP 7.4, RFC ! Vous permet de dire à PHP FPM d'analyser la base de code, de la convertir en Opcodes et de la mettre en cache avant de l'exécuter.

Voulez-vous savoir comment JIT est impliqué dans ce processus d'interprétation ? Cet article vous l'expliquera.

Quels sont les effets de la compilation Just In Time ?

Après avoir écouté la diffusion PHP et JIT de Zeev sur PHP Internals News, j'ai compris ce que fait réellement JIT.

Si l'extension Opcache accélère l'obtention des Opcodes directement sur la VM Zend, le JIT leur permet de s'exécuter sans utiliser du tout la VM Zend.

Zend VM est un programme écrit en C qui agit comme une couche entre les Opcodes et le CPU. JIT génère du code compilé directement au moment de l'exécution, afin que PHP puisse

ignorer la VM Zend et être exécuté directement par le CPU. En théorie, les performances seront meilleures.

Cela semble étrange car une implémentation concrète doit être écrite pour chaque type de structure avant de pouvoir être compilée en code machine. Mais en fait, c'est raisonnable.

Le JIT de PHP utilise une bibliothèque appelée DynASM (Dynamic Assembler), qui mappe un ensemble d'instructions CPU dans un format spécifique en code assembleur pour de nombreux types de CPU différents. Par conséquent, le compilateur n'a besoin d'utiliser DynASM que pour convertir les Opcodes en code machine pour une structure spécifique.

Cependant, il y a un problème qui me préoccupe depuis longtemps.

Si le préchargement peut analyser le code PHP en Opcodes avant l'exécution et que DynASM peut compiler les Opcodes en code machine (compilation Just In Time), pourquoi n'utilisons-nous pas immédiatement la compilation Ahead of Time ?

L'une des raisons pour lesquelles j'ai découvert en écoutant la diffusion de Zeev est que PHP est un langage faiblement typé, ce qui signifie que PHP ne connaît souvent pas le type d'une variable jusqu'à ce que la VM Zend essaie de exécuter un opcode.

Vous pouvez afficher le type d'union Zend_value pour apprendre que de nombreux pointeurs pointent vers des variables de types différents. Chaque fois que Zend VM essaie d'obtenir une valeur d'un Zend_value, elle utilise une macro comme ZSTR_VAL pour obtenir un pointeur vers une chaîne dans le type union.

Par exemple, ce gestionnaire de VM Zend gère les expressions "inférieur ou égal à" (<=). Voyez comment il code autant de branches if else juste pour l'inférence de type.

Utiliser du code machine pour effectuer une logique d'inférence de type n'est pas réalisable et peut devenir plus lent.

Évaluer d'abord puis compiler n'est pas non plus une bonne option car la compilation en code machine est une tâche gourmande en CPU. Donc, tout compiler au moment de l’exécution n’est pas non plus une bonne chose.

Alors, comment est compilé Just In Time ?

Nous savons désormais que les types ne peuvent pas être bien déduits pour être compilés à l'avance. Nous savons également que la compilation au moment de l’exécution est coûteuse en termes de calcul. Alors, quels sont les avantages du JIT pour PHP ?

Pour rechercher un équilibre, le JIT de PHP tente de compiler uniquement des Opcodes précieux. Pour ce faire, le JIT analyse les Opcodes que la Zend VM va exécuter et vérifie les éventuelles compilations. (Selon le fichier de configuration)

Lorsqu'un Opcode est compilé, il confiera l'exécution au code compilé plutôt qu'à la Zend VM. Cela ressemble à ceci :

Le processus d'interprétation JIT de PHP. S'ils sont compilés, les Opcodes ne sont pas exécutés par Zend VM.

Par conséquent, dans l'extension Opcache, il existe deux instructions de détection pour déterminer s'il faut compiler l'Opcode. Si tel est le cas, le compilateur utilisera DynASM pour convertir cet Opcode en code machine et exécuter ce code machine.

Fait intéressant, puisqu'il existe une limite de Mo (également configurable) sur le code compilé dans l'interface actuelle, l'exécution du code doit pouvoir basculer de manière transparente entre JIT et le code interprété.

D'ailleurs, cette conférence de Benoit Jacquemont sur le JIT en php m'a aidé à comprendre tout cela.

Je ne sais toujours pas quand la partie compilation a été effectivement terminée, mais je suppose que pour le moment, je n'ai pas vraiment envie de savoir.

Donc, vos gains de performances ne seront probablement pas énormes

J'espère que c'est clair maintenant pourquoi la plupart des applications PHP ne tirent pas grand-chose de l'utilisation de compilateurs juste à temps Gros gains de performances. C'est pourquoi Zeev recommande que le profilage et l'expérimentation de différentes configurations JIT pour votre application constituent la meilleure approche.

Si vous utilisez PHP FPM, il est courant de partager des opcodes compilés sur plusieurs requêtes, mais cela ne change toujours pas la donne.

En effet, JIT optimise les opérations gourmandes en calcul et la plupart des applications PHP actuelles sont plus liées aux E/S qu'autre chose. Si vous souhaitez quand même accéder au disque ou au réseau, peu importe que l'opération de traitement soit compilée ou non. Le timing sera très similaire.

À moins que...

Vous faites quelque chose qui n'est pas lié aux E/S, comme le traitement d'image ou l'apprentissage automatique. Tout ce qui ne touche pas aux E/S bénéficiera d'un compilateur JIT.

C'est pourquoi les gens disent maintenant qu'on préfère écrire des fonctions natives en PHP plutôt qu'en C. Si cette fonction devait quand même être compilée, la surcharge serait inexpressive.

Tutoriel recommandé : "PHP7"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!