PHP 8 va proposer un compilateur Just In Time
Qui devrait produire une amélioration des performances en vitesse
Le 2019-04-01 11:44:54, par Patrick Ruiz, Chroniqueur Actualités
La nouvelle est tombée il y a peu par le biais d’un billet de blog d’un membre de la communauté du langage de programmation web côté serveur le plus utilisé au monde d’après les chiffres de la plateforme W3Techs – PHP.
Envoyé par Joe Watkins
Les détails techniques de ce changement au sein de la proposition par Dmitry Stogov et Zeev Suraski :
« Nous proposons d'inclure un compilateur JIT à PHP 8 et de fournir des efforts supplémentaires pour augmenter ses performances et sa convivialité. En outre, nous proposons d'envisager l'inclusion d'un compilateur JIT dans PHP 7.4 en tant que fonctionnalité expérimentale (désactivée par défaut).
PHP JIT est implémenté comme une partie d'OPcache. Il peut être activé ou désactivé au moment de la compilation et au moment de l'exécution. Lorsqu'il est activé, le code natif des fichiers PHP est stocké dans une région supplémentaire de la mémoire partagée OPcache et op_array→opcodes[].handler(s) conserve des pointeurs vers les points d'entrée du code généré par le compilateur JIT. Cette approche ne nécessite aucune modification du moteur.
Nous utilisons DynAsm (développé pour le projet LuaJIT) pour la génération de code natif. C'est un outil très léger et très avancé, mais il suppose une bonne et très faible connaissance du développement des langages assembleur cibles. Par le passé, nous avons essayé LLVM, mais sa vitesse de génération de code était presque 100 fois plus lente, ce qui le rendait prohibitif à utiliser. Actuellement, nous supportons les processeurs x86 et x86_64 sur les plateformes POSIX et Windows. DynAsm supporte également ARM, ARM64, MIPS, MIPS64 et PPC, donc en théorie, nous devrions être capables de supporter toutes les plateformes qui sont populaires pour les déploiements PHP.
PHP JIT n'introduit pas représentation intermédiaire. Il génère du code natif directement à partir du bytecode PHP et des informations collectées par le framework d'analyses statiques SSA. Grosso modo, le code est généré de façon séparée pour chaque instruction PHP. Seules quelques combinaisons sont prises en compte ensemble (par exemple : les comparaisons et les sauts conditionnels). »
Illustration du passage du PHP au code natif pour un processeur x86 avec les deux portions de code suivantes :
L’introduction d’un compilateur JIT devrait permettre une accélération significative des tâches ultra gourmandes en ressource processeur. L’équipe de mainteneurs annonce des gains de performance de 2x quant à ce qui est de l’exécution de l’interpréteur PHP ; les utilisateurs devraient également constater une accélération de 1,3x de l’exécution de l’analyseur de texte du langage. L’équipe de mainteneur a également publié les résultats d’un benchmark qui montrent que PHP (avec le compilateur JIT activé) peut mieux faire que des langages comme le C sur le terrain de la génération des fractales de Mandelbrot.
Noter à ce propos que ces changements n’auront pas d’apport important sur les performances d’applications qui, pour l’essentiel de leurs opérations, génèrent des entrées-sorties sur divers ports : Wordpress, etc. Dit autrement, il ne faudra pas s’attendre à une accélération significative des sites web.
PHP 7.3 est disponible depuis la fin d’année dernière. PHP 7.4 pour sa part est attendu à la fin de l’année en cours et il faut souligner à ce propos que les votants ont décidé de la non inclusion du compilateur JIT. Il faudra attendre fin 2020 qui coïncide en principe avec la sortie de PHP 8 pour en faire usage.
Sources : billet de blog, résultats du benchmark
Et vous ?
Qu’en pensez-vous ?
Quel commentaire faites-vous de ceci que l’équipe de développement de PHP n’a pas choisi sa propre représentation intermédiaire ? Quelles conséquences sur le plan technique ?
Voir aussi :
Les benchmarks réalisés sur la dernière préversion de PHP 7.3 sont prometteurs, et la sortie de la version stable se profile à l'horizon
W3Techs : plus de 60 % des sites Web tournent sur PHP 5.x, une version qui ne sera plus supportée après le 31 décembre 2018
PHP 7.2 est disponible en version stable avec la bibliothèque de cryptographie Sodium, et d'autres améliorations et nouvelles fonctionnalités
PHP 7.1.0 disponible avec le support des types nullables et de nombreuses autres fonctionnalités, mais aussi des gains de performance
PHP 7.0.0 officiellement disponible, et son code source téléchargeable sur le site officiel du langage de programmation
« Nous proposons d'inclure un compilateur JIT à PHP 8 et de fournir des efforts supplémentaires pour augmenter ses performances et sa convivialité. En outre, nous proposons d'envisager l'inclusion d'un compilateur JIT dans PHP 7.4 en tant que fonctionnalité expérimentale (désactivée par défaut).
PHP JIT est implémenté comme une partie d'OPcache. Il peut être activé ou désactivé au moment de la compilation et au moment de l'exécution. Lorsqu'il est activé, le code natif des fichiers PHP est stocké dans une région supplémentaire de la mémoire partagée OPcache et op_array→opcodes[].handler(s) conserve des pointeurs vers les points d'entrée du code généré par le compilateur JIT. Cette approche ne nécessite aucune modification du moteur.
Nous utilisons DynAsm (développé pour le projet LuaJIT) pour la génération de code natif. C'est un outil très léger et très avancé, mais il suppose une bonne et très faible connaissance du développement des langages assembleur cibles. Par le passé, nous avons essayé LLVM, mais sa vitesse de génération de code était presque 100 fois plus lente, ce qui le rendait prohibitif à utiliser. Actuellement, nous supportons les processeurs x86 et x86_64 sur les plateformes POSIX et Windows. DynAsm supporte également ARM, ARM64, MIPS, MIPS64 et PPC, donc en théorie, nous devrions être capables de supporter toutes les plateformes qui sont populaires pour les déploiements PHP.
PHP JIT n'introduit pas représentation intermédiaire. Il génère du code natif directement à partir du bytecode PHP et des informations collectées par le framework d'analyses statiques SSA. Grosso modo, le code est généré de façon séparée pour chaque instruction PHP. Seules quelques combinaisons sont prises en compte ensemble (par exemple : les comparaisons et les sauts conditionnels). »
Illustration du passage du PHP au code natif pour un processeur x86 avec les deux portions de code suivantes :
Code PHP : |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | function iterate($x,$y) { $cr = $y-0.5; $ci = $x; $zr = 0.0; $zi = 0.0; $i = 0; while (true) { $i++; $temp = $zr * $zi; $zr2 = $zr * $zr; $zi2 = $zi * $zi; $zr = $zr2 - $zi2 + $cr; $zi = $temp + $temp + $ci; if ($zi2 + $zr2 > BAILOUT) return $i; if ($i > MAX_ITERATIONS) return 0; } } |
Code ASM : |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 | JIT$Mandelbrot::iterate: ; (/home/dmitry/php/bench/b.php) sub $0x10, %esp cmp $0x1, 0x1c(%esi) jb .L14 jmp .L1 .ENTRY1: sub $0x10, %esp .L1: cmp $0x2, 0x1c(%esi) jb .L15 mov $0xec3800f0, %edi jmp .L2 .ENTRY2: sub $0x10, %esp .L2: cmp $0x5, 0x48(%esi) jnz .L16 vmovsd 0x40(%esi), %xmm1 vsubsd 0xec380068, %xmm1, %xmm1 .L3: mov 0x30(%esi), %eax mov 0x34(%esi), %edx mov %eax, 0x60(%esi) mov %edx, 0x64(%esi) mov 0x38(%esi), %edx mov %edx, 0x68(%esi) test $0x1, %dh jz .L4 add $0x1, (%eax) .L4: vxorps %xmm2, %xmm2, %xmm2 vxorps %xmm3, %xmm3, %xmm3 xor %edx, %edx .L5: cmp $0x0, EG(vm_interrupt) jnz .L18 add $0x1, %edx vmulsd %xmm3, %xmm2, %xmm4 vmulsd %xmm2, %xmm2, %xmm5 vmulsd %xmm3, %xmm3, %xmm6 vsubsd %xmm6, %xmm5, %xmm7 vaddsd %xmm7, %xmm1, %xmm2 vaddsd %xmm4, %xmm4, %xmm4 cmp $0x5, 0x68(%esi) jnz .L19 vaddsd 0x60(%esi), %xmm4, %xmm3 .L6: vaddsd %xmm5, %xmm6, %xmm6 vucomisd 0xec3800a8, %xmm6 jp .L13 jbe .L13 mov 0x8(%esi), %ecx test %ecx, %ecx jz .L7 mov %edx, (%ecx) mov $0x4, 0x8(%ecx) .L7: test $0x1, 0x39(%esi) jnz .L21 .L8: test $0x1, 0x49(%esi) jnz .L23 .L9: test $0x1, 0x69(%esi) jnz .L25 .L10: movzx 0x1a(%esi), %ecx test $0x496, %ecx jnz JIT$$leave_function mov 0x20(%esi), %eax mov %eax, EG(current_execute_data) test $0x40, %ecx jz .L12 mov 0x10(%esi), %eax sub $0x1, (%eax) jnz .L11 mov %eax, %ecx call zend_objects_store_del jmp .L12 .L11: mov 0x4(%eax), %ecx and $0xfffffc10, %ecx cmp $0x10, %ecx jnz .L12 mov %eax, %ecx call gc_possible_root .L12: mov %esi, EG(vm_stack_top) mov 0x20(%esi), %esi cmp $0x0, EG(exception) mov (%esi), %edi jnz JIT$$leave_throw add $0x1c, %edi add $0x10, %esp jmp (%edi) .L13: cmp $0x3e8, %edx jle .L5 mov 0x8(%esi), %ecx test %ecx, %ecx jz .L7 mov $0x0, (%ecx) mov $0x4, 0x8(%ecx) jmp .L7 .L14: mov %edi, (%esi) mov %esi, %ecx call zend_missing_arg_error jmp JIT$$exception_handler .L15: mov %edi, (%esi) mov %esi, %ecx call zend_missing_arg_error jmp JIT$$exception_handler .L16: cmp $0x4, 0x48(%esi) jnz .L17 vcvtsi2sd 0x40(%esi), %xmm1, %xmm1 vsubsd 0xec380068, %xmm1, %xmm1 jmp .L3 .L17: mov %edi, (%esi) lea 0x50(%esi), %ecx lea 0x40(%esi), %edx sub $0xc, %esp push $0xec380068 call sub_function add $0xc, %esp cmp $0x0, EG(exception) jnz JIT$$exception_handler vmovsd 0x50(%esi), %xmm1 jmp .L3 .L18: mov $0xec38017c, %edi jmp JIT$$interrupt_handler .L19: cmp $0x4, 0x68(%esi) jnz .L20 vcvtsi2sd 0x60(%esi), %xmm3, %xmm3 vaddsd %xmm4, %xmm3, %xmm3 jmp .L6 .L20: mov $0xec380240, (%esi) lea 0x80(%esi), %ecx vmovsd %xmm4, 0xe0(%esi) mov $0x5, 0xe8(%esi) lea 0xe0(%esi), %edx sub $0xc, %esp lea 0x60(%esi), %eax push %eax call add_function add $0xc, %esp cmp $0x0, EG(exception) jnz JIT$$exception_handler vmovsd 0x80(%esi), %xmm3 jmp .L6 .L21: mov 0x30(%esi), %ecx sub $0x1, (%ecx) jnz .L22 mov $0x1, 0x38(%esi) mov $0xec3802b0, (%esi) call rc_dtor_func jmp .L8 .L22: mov 0x4(%ecx), %eax and $0xfffffc10, %eax cmp $0x10, %eax jnz .L8 call gc_possible_root jmp .L8 .L23: mov 0x40(%esi), %ecx sub $0x1, (%ecx) jnz .L24 mov $0x1, 0x48(%esi) mov $0xec3802b0, (%esi) call rc_dtor_func jmp .L9 .L24: mov 0x4(%ecx), %eax and $0xfffffc10, %eax cmp $0x10, %eax jnz .L9 call gc_possible_root jmp .L9 .L25: mov 0x60(%esi), %ecx sub $0x1, (%ecx) jnz .L26 mov $0x1, 0x68(%esi) mov $0xec3802b0, (%esi) call rc_dtor_func jmp .L10 .L26: mov 0x4(%ecx), %eax and $0xfffffc10, %eax cmp $0x10, %eax jnz .L10 call gc_possible_root jmp .L10 |
Noter à ce propos que ces changements n’auront pas d’apport important sur les performances d’applications qui, pour l’essentiel de leurs opérations, génèrent des entrées-sorties sur divers ports : Wordpress, etc. Dit autrement, il ne faudra pas s’attendre à une accélération significative des sites web.
PHP 7.3 est disponible depuis la fin d’année dernière. PHP 7.4 pour sa part est attendu à la fin de l’année en cours et il faut souligner à ce propos que les votants ont décidé de la non inclusion du compilateur JIT. Il faudra attendre fin 2020 qui coïncide en principe avec la sortie de PHP 8 pour en faire usage.
Sources : billet de blog, résultats du benchmark
Et vous ?
Voir aussi :
-
rawsrcExpert éminent séniorJ'ai du mal à comprendre la conclusion relative au gain minime de performances...
Si le parseur mouline avec un gain de temps de 30% et que les tâches gourmandes processeur divisent leur temps d'exécution par 2, je pense quand même que les gains seront plus que significatifs et pas juste "acceptables".
Rien ne vous empêche de loger tout le code source d'un framework (généralement immuable) en OPcache et bénéficier du coup pleinement du compilateur JIT, dans ce cas de figure les gains devraient être juste énormes dans la mesure où les point d'accès mémoire ne sont pas perdus entre les appels... Plus de parseur, plus de génération d'arbre syntaxique, plus d'allocation dynamique mémoire sur cette partie ... je ne vous dis pas les gains en production.
Déjà que PHP 7+ a mis tout le monde d'accord (ne serait-ce qu'avec le typage statique, les perfs x2~3 par rapport à PHP 5), PHP 8 devrait encore enfoncer le clou.
A matériel équivalent, la charge supportée devrait grimper en flèche.le 01/04/2019 à 13:57 -
grunkModérateurle vote s'est terminé aujourd'hui, dans le calme, avec une large majorité en faveur de la fusion avec PHP 8le 01/04/2019 à 14:56
-
Le billet de blog en source l'explique assez bien, le compilateur JIT augmente significativement toutes les opérations basées sur le CPU (genre opérations mathématiques), mais très peu sur tout ce qui est I/O (genre connexion BDD). Le gain est donc minime pour les applications web qui sont le plus souvent un ensemble de connexions entre applications (BDD, cache, serveur web,...). En revanche si tu es dans le cas où ton application est gourmande en opérations CPU tu auras un gain significatif de performances.
Dans le billet il ajoute que c'est une ouverture de PHP vers le scientifique, on sent une volonté d'utiliser PHP pour plus que du web.
Personnellement je suis très curieux de voir ce que ça va donner avec qqch comme ReactPHP pour du websocket.le 01/04/2019 à 23:20 -
grunkModérateurLa majorité des sites web "classique" ne consomme peu ou pas de CPU , ou en tout cas c'est négligeable par rapport au temps que prend l'IO , je pense que c'est ça dont on veux parler. Du coup gagner 50% sur pas grand chose , ça fait toujours pas grand chose ^^
Si aujourd'hui certains de tes applicatifs prennent beaucoup de CPU du genre traitement d'image , ou calcul lourd , tu vas voir un gain c'est certains.le 02/04/2019 à 14:10 -
redcurveMembre extrêmement actifLe mieux est d'utiliser PeachPie, c-a-d Php qui utilise la CLR .net core, tout soft php fonctionne sans problème tout en bénéficiant d'une plateforme moderne sous licence MIT et qui envoie du gros bois niveau perf...le 01/04/2019 à 18:12
-
rawsrcExpert éminent séniorJ'avais lu le billet de blog, je trouve juste la conclusion un peu légère.
Compte tenu du fait que le core du moteur tournera beaucoup plus vite, les parties dévolues aux traitements internes (ce qui n'est pas anodin) devront produire un gain significatif.
Après qu'il n'y ait pas de gros gain sur les parties dépendantes de services tiers, c'est somme toute logique.
Si demain, une autre annonce amène officiellement l'implémentation d'un petit serveur d'applications qui conservera certaines ressources de manière persistante entre les appels, là les gains en globalité devraient être très importants.le 02/04/2019 à 8:36 -
redcurveMembre extrêmement actifRegarde et test ça https://www.peachpie.io/le 02/04/2019 à 12:23
-
domi65Membre éclairéSi aujourd'hui certains de tes applicatifs prennent beaucoup de CPU du genre traitement d'image , ou calcul lourd , tu vas voir un gain c'est certains.
Donc, à mon avis, ça peut être intéressant même pour le web.le 07/04/2019 à 19:05 -
grunkModérateurSauf cas particulier c'est jamais fait en live , mais plutôt à l'insertion puis on réaffiche les miniature stockées. Mais peut être qu'on pourra aller vers du rééchantillonage en live tout en gardant des performances correctes.le 08/04/2019 à 10:36
-
domi65Membre éclairé@grunk
Oui, et c'est tellement évident que je n'imaginais pas qu'on puisse avoir l'idée, sur un site standard, de ré-échantillonner des images à chaque appel à une page web !le 08/04/2019 à 15:09