Interprétation complète de l'optimisation et des améliorations de la version php8.0

À moins d'avoir vécu sous un rocher, ou de vivre dans le passé, vous vous rendrez compte que JIT arrivePHP 8 : le vote s'est tranquillement clôturé aujourd'hui, avec une nette majorité en faveur Fusionné avec PHP8, c'est donc officiel. Cet article explique en détail l'optimisation et l'amélioration de la version php8.0.

Annonce officielle de PHP8 "PHP 8 est là ! L'équipe PHP a publié la première version bêta Alpha1》

Maintenant, asseyez-vous et lisez l'article suivant qui brise les mythes dans lequel nous clarifierons quelques éléments sur ce qu'est JIT et quels en seront les avantages. apportez de la confusion et approfondissez son fonctionnement (mais seulement un peu parce que je ne veux pas vous ennuyer).

Comme je ne sais pas à qui je parle, je vais commencer par des questions simples et passer ensuite aux questions complexes, que vous pouvez ignorer si vous êtes déjà sûr de savoir la réponse à la question dans le titre Cette partie. . .

Qu'est-ce que le JIT ?

PHP implémente une machine virtuelle, un processeur virtuel, que nous appelons Zend VM. PHP compile des scripts lisibles par l'homme en instructions (nous les appelons des opcodes) que la machine virtuelle peut comprendre. Cette étape d'exécution est ce que nous appelons le « temps de compilation ». Lors de la phase d'exécution "runtime", la machine virtuelle (Zend VM) exécute les instructions du code (opcodes).

Tout cela fonctionne très bien, des outils comme APC (dans le passé) et OPCache (maintenant) peuvent mettre en cache les instructions du code (opcodes) afin que le "temps de compilation" ne se produise que lorsque cela est nécessaire.

Tout d'abord, il y a une ligne de code qui explique ce qu'est JIT :

Just-in-time est une stratégie de compilateur qui accepte une représentation intermédiaire du code et la convertit en dépendances au moment de l'exécution. Spécifique à l'architecture code machine pour une exécution rapide.

En PHP, cela signifie que le JIT utilisera les instructions générées par Zend VM comme représentation intermédiaire et émettra du code machine dépendant de l'architecture, donc l'hôte du code n'est plus ZendVM, mais le CPU.

Pourquoi PHP a-t-il besoin de JIT ?

Avant PHP 7.0, la communauté interne PHP se concentrait sur la performance, provoquée par une saine concurrence provoquée par le projet HHVM de Facebook. La plupart des changements fondamentaux de PHP 7.0 ont été inclus dans le correctif PHPNG, qui a considérablement amélioré la façon dont PHP utilisait la mémoire et le processeur sur son cœur, et depuis lors, chacun d'entre nous a été obligé de se concentrer sur les performances.

Depuis PHP 7.0, il y a eu quelques améliorations de performances, des optimisations de HashTable (les structures de données de base de PHP), des spécialisations Zend VM pour certains opcodes, des spécialisations du compilateur pour certaines séquences et des améliorations continues du composant optimiseur d'OPCache. . . Il y a tellement d'autres choses à part ça, c'est tellement ennuyeux.

C'est une dure vérité que ces optimisations ne peuvent nous mener que jusqu'à présent et que nous approchons rapidement, ou que nous avons peut-être heurté un mur de briques dans notre capacité à l'améliorer davantage.

REMARQUE : Quand nous disons « nous ne pouvons plus l'améliorer », ce que nous voulons vraiment dire, c'est « nous devons faire des compromis pour ne plus l'améliorer ». ça a l'air attrayant". . . Chaque fois que nous discutons d’optimisation des performances, nous discutons de compromis. Il y a souvent un compromis entre simplicité et performance. Nous aimons tous penser que le code le plus simple est le code le plus rapide, mais dans le monde moderne de la programmation C, ce n’est pas le cas. Le code le plus rapide est généralement un code préparé pour tirer parti des intrinsèques dépendants de l’architecture ou des intrinsèques dépendants de la plate-forme (compilateur). La simplicité ne garantit pas les meilleures performances. . .

À l'heure actuelle, la fonctionnalité JIT de PHP semble être le meilleur moyen d'obtenir plus de performances de PHP.

JIT rendra-t-il mon site Web plus rapide ?

Possible, pas évident.

n'est peut-être pas la réponse que vous attendiez : en général, les applications écrites en PHP sont I/O绑定 et JIT fonctionnent mieux sur CPU绑定 code.

Que signifie exactement « Liaison E/S et CPU » ?

Nous utilisons les termes I/O绑定 et CPU绑定 lorsque nous souhaitons décrire les caractéristiques générales de performances d'un morceau de code ou d'une application.

La façon la plus simple de le dire est :

• Un morceau de code lié aux E/S, si nous pouvons améliorer (réduire, optimiser) les E/S qu'il effectue, le fera courir plus vite.

• Un morceau de code lié au CPU s'exécutera plus rapidement si nous pouvons améliorer (réduire, optimiser) les instructions que le CPU exécute, ou (comme par magie) augmenter la vitesse d'horloge du CPU : )

• Un morceau de code ou une application peut être lié aux E/S, au CPU, ou à la fois au CPU et aux E/S de manière égale.

• De manière générale, les applications PHP ont tendance à être liées aux E/S - ce qui les ralentit, ce sont les E/S qu'elles effectuent - connexion, lecture et écriture dans des bases de données, des caches, des fichiers, des sockets, etc. .

À quoi ressemble le PHP lié au CPU ?

En raison de la nature de la plupart des applications PHP, de nombreux programmeurs PHP ne sont pas familiers avec le code lié au processeur - leur travail consiste souvent à se connecter à une base de données, ou peut-être à un cache, à effectuer un travail et des sorties légers. une html/json/xml réponse.

Vous pourriez parcourir la base de code et trouver beaucoup de code qui n'a rien à voir avec les E/S, ou même du code qui appelle des fonctions complètement déconnectées des E/S, et être confus, et je semble impliquer que ce n'est pas le cas. Cela ne limite pas le processeur de votre application, même s'il peut y avoir plus de lignes de code gérant les non-E/S que les E/S.

PHP est en fait assez rapide, c'est l'un des langages interprétés les plus rapides au monde. Il n'y a pas de différence significative entre la Zend VM appelant une fonction qui n'a rien à voir avec les E/S et le fait d'effectuer le même appel en code machine.

Il y a évidemment une différence, mais le fait est que le code machine a une convention d'appel, Zend VM a une convention d'appel, le code machine a un prologue, Zend VM a un prologue : appeler quelque chose dans un opcode Zend c_level_function（） ou le code machine n'a pas d'impact significatif sur les performances de l'application appelante - bien qu'il semble avoir un impact important sur cet appel.

Remarque : La convention d'appel fait grossièrement référence à une série d'instructions exécutées avant d'entrer dans une autre fonction, et le prologue fait référence à une série d'instructions exécutées lors de la saisie d'une autre fonction : dans les deux cas , la convention d'appel place les paramètres sur la pile et le prologue les supprime de la pile.

Qu'en est-il des boucles, des appels de queue et des X ? Je vous entends demander : PHP est en fait très intelligent, et avec le composant d'optimisation d'OPCache activé, c'est comme si votre code était transformé comme par magie en la forme la plus efficace que vous puissiez écrire.

Maintenant, il est important de noter que le JIT ne change pas la convention d'appel des fonctions Zend, plutôt que celle établie par la VM - Zend doit pouvoir basculer entre les modes JIT et VM à tout moment, donc la décision de conserver celle établie par la convention VM Calling. Ainsi, lorsque le JIT est en cours d’exécution, ces appels ne sont pas significativement accélérés partout.

Si vous voulez voir à quoi ressemble le code PHP lié au CPU, consultez la documentation Zend/bench.php... Il s'agit évidemment d'un exemple extrême de code CPU, mais il devrait nous donner une idée d'où le JIT brille vraiment C'est dans le domaine des mathématiques.

PHP constitue-t-il le compromis ultime pour des mathématiques plus rapides ?

Non, nous avons fait cela pour élargir la portée de PHP, et pas mal.

De l'avis de ce développeur PHP très partial, si vous êtes un programmeur web en 2019 et que vous n'avez pas envisagé d'utiliser PHP dans votre prochain projet, alors vous faites mal le web.

Améliorer la capacité d'effectuer des calculs plus rapidement en PHP, à première vue, semble être une portée très étroite.

Cependant, cela ouvre en fait la porte à l'apprentissage automatique, au rendu 3D, au rendu 2D (GUI) et à l'analyse de données (pour n'en nommer que quelques-uns).

Pourquoi ne pouvons-nous pas l'utiliser dans PHP 7.4 ?

Je viens d'appeler JIT le "compromis ultime", et je pense que c'est le cas : c'est sans doute l'une des stratégies de compilateur les plus complexes jamais conçues, peut-être la plus complexe. L’introduction de JIT introduit une complexité considérable.

Si vous demandiez à Dmitry (l'auteur de JIT) s'il avait créé du PHP complexe, il répondrait "Non, je déteste la complexité" (c'est une citation directe).

En fin de compte, la complexité est quelque chose que nous ne comprenons pas, et actuellement, il y a très peu de développeurs internes (moins de quelques-uns) qui comprennent vraiment la mise en œuvre du JIT.

PHP 7.4 évolue rapidement et la fusion avec php7.4 nous laissera avec une version de PHP que seules quelques personnes peuvent déboguer, corriger ou améliorer (dans le vrai sens du terme). Pour ceux qui ont voté contre la fusion avec PHP 7.4, cette situation est inacceptable.

D'ici PHP 8, beaucoup d'entre nous travailleront dur pour comprendre le JIT pendant notre temps libre :

Nous avons encore certaines fonctionnalités à implémenter et devons être retravaillées pour php8 Pour écrire des outils, nous devons d’abord comprendre JIT. Nous avons besoin de ce temps et sommes extrêmement reconnaissants qu’une majorité d’électeurs aient jugé bon de nous l’accorder.

La complexité n'est pas synonyme de terrible :

La complexité peut être belle, et comme une nébuleuse, JIT est ce genre de complexité. En principe, vous pouvez comprendre pleinement quelque chose de complexe et ne réduire que légèrement sa complexité apparente. En d’autres termes, même s’il y avait 20 développeurs internes aussi familiers avec JIT que Dmitry, cela ne changerait pas vraiment la complexité du JIT.

Le développement PHP va-t-il ralentir ?

Il n’y a aucune raison de penser que ce soit le cas. Nous avons suffisamment de temps pour affirmer avec certitude qu'au moment où PHP 8 sera généralement disponible, suffisamment d'entre nous seront familiers avec JIT pour être au moins aussi utiles qu'aujourd'hui pour corriger les bugs et faire avancer PHP.

Lorsque vous essayez de relier cela au fait que JIT est intrinsèquement complexe, considérez que la plupart du temps que nous passons à introduire une nouvelle fonctionnalité est en fait consacré à discuter de cette fonctionnalité. Pour la plupart des fonctionnalités, voire des correctifs, l'écriture du code peut prendre des minutes ou des heures, et les discussions peuvent prendre des semaines ou des mois. Dans de rares cas, l'écriture du code d'une fonctionnalité peut prendre des heures ou des jours, mais dans ces rares cas, les discussions prennent toujours plus de temps.

Pour une analyse détaillée de PHP8, veuillez vous référer à "Explication graphique JIT des nouvelles fonctionnalités de PHP8" " Dans quelle mesure les performances de PHP 8 ont-elles été améliorées ? 》

Cet article est directement traduit du site Web chinois php : https://blog.krakjoe.ninja/2019/03/php-gr8.html

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!