« PHP Next Generation » : le noyau de la prochaine génération de PHP officialisé
Le projet vise à intégrer un compilateur JIT
Le 2014-05-28 14:34:02, par Hinault Romaric, Responsable .NET
Il y a quelques jours, Dimitry Stogov, ingénieur chez Zend Technologies, dévoilait les résultats de ses travaux qui permettaient une optimisation des performances de PHP.
Celui-ci avait procédé à un refactoring du code PHP, avec à la clé une augmentation des performances d’applications comme Wordpress 3.6 de 20% et Drupal 6.1 de 11,7%.
Le projet avait pris naissance depuis plusieurs années sous l’appellation de « PHP Next Generation » et avait entraîné la création d’une branche séparée de PHP baptisée « phpng », qui était maintenue par trois développeurs (Dmitry Stogov, Xinchen Hui et Nikita Popov).
Ce projet interne qui avait été tenu secret a atteint un stade assez avancé permettant son officialisation par les développeurs de PHP. PHP Next Generation vise à créer le noyau de la prochaine génération de la plateforme de développement Web, en procédant à une refonte, l’optimisation et le nettoyage du code de base de PHP pour le rendre plus efficace et permettre d’avoir recours à un compilateur JIT (Just in time).
Ainsi, le but initial de phpng n’a pas été l’intégration des capacités JIT, mais plutôt de résoudre les problèmes qui pourraient être un frein à une mise en œuvre future d’un compilateur JIT fournissant des performances optimales.
Sans même inclure des technologies JIT, le refactoring du code PHP présente déjà des résultats très intéressants et désormais, l’équipe du projet peut se pencher sur le support d’un compilateur JIT. « Le travail sur phpng a été une source d’inspiration et nous sommes très optimistes. Mais, il faut garder les pieds sur terre, rester honnête et dire qu’il y a encore beaucoup de travail à faire pour rendre ‘Next Generation’ une réalité. Ce n’est que le début », conclut l’équipe de PHP dans un billet sur le site du projet.
Actuellement, phpng n’est donc pas une branche de production que tout le monde devrait déployer. Mais les plus curieux peuvent déjà installer et tester cette branche, qui sera la base du « futur PHP ».
Source : Site du projet
Et vous ?
Celui-ci avait procédé à un refactoring du code PHP, avec à la clé une augmentation des performances d’applications comme Wordpress 3.6 de 20% et Drupal 6.1 de 11,7%.
Le projet avait pris naissance depuis plusieurs années sous l’appellation de « PHP Next Generation » et avait entraîné la création d’une branche séparée de PHP baptisée « phpng », qui était maintenue par trois développeurs (Dmitry Stogov, Xinchen Hui et Nikita Popov).
Ce projet interne qui avait été tenu secret a atteint un stade assez avancé permettant son officialisation par les développeurs de PHP. PHP Next Generation vise à créer le noyau de la prochaine génération de la plateforme de développement Web, en procédant à une refonte, l’optimisation et le nettoyage du code de base de PHP pour le rendre plus efficace et permettre d’avoir recours à un compilateur JIT (Just in time).
Ainsi, le but initial de phpng n’a pas été l’intégration des capacités JIT, mais plutôt de résoudre les problèmes qui pourraient être un frein à une mise en œuvre future d’un compilateur JIT fournissant des performances optimales.
Sans même inclure des technologies JIT, le refactoring du code PHP présente déjà des résultats très intéressants et désormais, l’équipe du projet peut se pencher sur le support d’un compilateur JIT. « Le travail sur phpng a été une source d’inspiration et nous sommes très optimistes. Mais, il faut garder les pieds sur terre, rester honnête et dire qu’il y a encore beaucoup de travail à faire pour rendre ‘Next Generation’ une réalité. Ce n’est que le début », conclut l’équipe de PHP dans un billet sur le site du projet.
Actuellement, phpng n’est donc pas une branche de production que tout le monde devrait déployer. Mais les plus curieux peuvent déjà installer et tester cette branche, qui sera la base du « futur PHP ».
Source : Site du projet
Et vous ?
-
JEDI_BCMembre à l'essaiIl n'y a rien d'officialisé du tout. Il n'y a eut aucune RFC de proposée pour l'instant pour intégrer ces modifications au core de PHP.
Ces modifications font même débat sur la liste Internals des core devs.
Le post "PHP Next Generation" d'hier sur la front page de PHP lui même fait clairement débat.
Certains y voit une tentative de passage en force du patch par Zend (la société) pour reprendre la main sur le dev du core qu'ils avaient abandonné depuis un moment. Libre à chacun d'en tirer ses conclusions.le 28/05/2014 à 15:31 -
GasprodMembre à l'essaitout à fait d'accord. le futur de PhP serait Wordpress ... Drupal ... et surtout Zend ? ... pas surle 28/05/2014 à 15:44
-
dorian53Membre habitué1/ Quelles différences entre une compilation JIT et les systèmes de cache tels que APC ou OPCache ?
2/ Quelles sont les raisons d'être contre une compilation JIT ?le 28/05/2014 à 16:00 -
OPiMembre actifLes systèmes de cache stockent le bytecode (code intermédiaire résultat de la compilation du source PHP) pour être réutilisé d'une exécution à l'autre.
Les compilateurs JIT compilent (à la volée, lors de l'exécution du programme) le bytecode en code natif (donc propre à la plate-forme utilisée) qui peut ainsi être exécuté plusieurs fois (dans une boucle par exemple) lors d'une seule exécution du programme.le 28/05/2014 à 16:32 -
GugelhupfModérateurJusqu'à preuve du contraire, il n'y en a pas (Java, C# utilisent des compilateurs JIT, et affichent de très bonnes performances).
Un inconvénient par contre, pourrait-être la consommation mémoire. Mais là encore, aujourd'hui la RAM n'est pas un composant très couteux.
Par contre il y a quelque chose que je ne comprends pas dans cette article ! Il me semble que la technologie PHP possède déjà un compilateur JIT pour faire de la compilation à la volée (qui agit à chaque chargement de page PHP, puis si APC est activé stockage dans un cache).
L'objectif ne serait-t-il pas plutôt de mettre en place une machine virtuelle PHP ?le 28/05/2014 à 20:39 -
LynixMembre habituéJustement non, le PHP est bel et bien compilé à la volée mais en bytecode (Comme beaucoup d'autres langages interprétés comme le Lua), c'est une étape coûteuse mais nécessaire qui accélère le traitement par la suite (L'interpréteur n'a plus qu'à se préoccuper d'une série de bytecode qu'il sait déjà syntaxiquement valide).
Ce que les systèmes de cache comme APC font, c'est de stocker ce bytecode, évitant la compilation à chaque exécution et accélérant le chargement de la page
En revanche, un compilateur JIT c'est vraiment tout autre chose, j'espère juste qu'ils vont avoir la sagesse de stocker la sortie du compilateur, parce que sinon avec un langage comme PHP dont les scripts sont lancés et relancés sans cesse, ça ne servira pas à grand chose.le 29/05/2014 à 9:47 -
GugelhupfModérateurUn 1er problème en PHP, c'est qu'il n'y a pas d'API pour gérer les threads, et de machine virtuelle.
Un 2ème problème, c'est que le bytecode produit n'est pas multiplateforme...
Ce sont là 2 ingrédients clés pour avoir un compilateur JIT. Mais je ne sais pas s'ils iront jusque là (je pense aux hébergeurs).
Et quand on y pense, PHP suit encore plus le modèle des plateformes Java et .NETle 30/05/2014 à 20:29 -
ShutyMembre éprouvéZend est sur tous les front depuis que la concurrence s'est endurcie avec l'arrivé de Symfony dans sa version 2.le 02/06/2014 à 17:42