Cet article vous fera découvrir le JIT en PHP 8 et expliquera comment JIT participe au processus d'interprétation. J'espère qu'il sera utile à tout le monde !
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 CPU au moment de l'exécution.
Cela signifie qu'après avoir utilisé 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.
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 PHP. En combinant certaines de mes connaissances du langage C et toutes les informations dispersées 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 Zend VM, 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.
J'ai écrit un article de blog donnant un aperçu général du fonctionnement de PHP. Si vous pensez que cet article en est trop, consultez-en un autre et revenez plus tard. Les choses deviendront plus faciles à comprendre.
Comme nous le savons tous, PHP est un langage interprété, mais que signifie cette phrase elle-même ?
Chaque fois que vous exécutez du code PHP (script en ligne de commande ou application WEB), celui-ci 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éteur 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 s'appelle 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 AST, il est plus facile de comprendre les opérations et les priorités. 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érie d'opcodes et de les exécuter. Une fois tous les Opcodes exécutés, Zend VM termine le programme.
Cette image peut vous rendre les choses plus claires :
Une version simplifiée de l'aperçu 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 ?
Regardons en arrière les Opcodes. C'est exact! C'est pourquoi l'extension Opcache existe.
L'extension Opcache est fournie 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 qui inclut l'extension Opcache :
Processus d'explication pour PHP utilisant Opcache. Si le fichier a déjà été analysé, PHP obtiendra les Opcodes mis en cache au lieu de l'analyser à nouveau.
Vous ignorez parfaitement les étapes de Lexing/Tokenisation, d'Analyse et de Compilation ?
Remarque : Il s'agit de l'impressionnant RFC des fonctionnalités de préchargement de PHP 7.4. 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 participe à ce processus d'interprétation ? Cet article vous l'expliquera.
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 peut obtenir des Opcodes plus rapidement et les transférer directement vers 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 DynaASM (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 la compilation Ahead of Time pour compiler PHP immédiatement Tissu de laine ?
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 généralement pas le type d'une variable jusqu'à ce que la VM Zend essaie d'exécuter un opcode.
Vous pouvez vérifier le type d'union Zend_value pour savoir 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 des macros 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 à" (
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.
Maintenant, nous savons 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 l'équilibre, le JIT de PHP essaie 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 :
Processus d'interprétation JIT pour 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, puisque le code compilé dans l'interface actuelle a une limite de Mo (également configurable), 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 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 ne veux vraiment pas le savoir.
J'espère que tout le monde comprend désormais pourquoi la plupart des applications PHP n'obtiennent pas d'énormes gains de performances en utilisant des compilateurs juste à temps. 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 qui nécessitent beaucoup de calculs et la plupart des applications PHP de nos jours sont plus liées aux E/S qu'autre chose. Si vous accédez de toute façon au disque ou au réseau, la gestion de l'opération est compilée. Cela n'a pas d'importance. 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 que nous préférons é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.
Des moments amusants pour devenir programmeur PHP...
J'espère que cet article vous sera utile et vous permettra de mieux comprendre le JIT de PHP8.
Adresse originale : https://thephp.website/en/issue/php-8-jit/
Recommandé : "Tutoriel vidéo PHP"
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!