,Il existe des rumeurs depuis un petit moment comme quoi Facebook aurait refait le moteur de runtime de PHP afin d'y intégrer JIT (Just-In Time, la compilation juste à temps, ou à la volée). Ce projet aurait été entamé depuis 2 ans déjà et améliorerait jusqu'à 80% les performances de PHP.
C'est une super nouvelle de voir PHP évolué à ce point.
PHP avait de bonnes performances face à Java par exemple. Mais Java est de plus en plus rapide, même si PHP ne fait que gagner en vitesse et en mémoire. Mais de là à annoncer 80% de performances, c'est un bon énorme.
Notez, avec un bon cache d'opcode (i.e. de bytecode), les performances PHP sont déjà énormément améliorées. Avec JIT, ce serait encore mieux.
Oui mais qu'est-ce que JIT ? Vous en avez peut-être entendu parlé récemment avec Javascript ? En effet, c'est un procédé qui est arrivé dans les navigateurs pour améliorer les performances de Javascript, un langage lui aussi interprété.
Les langages interprétés sont fortement dynamiques et souvent très hauts niveaux, ce sont leurs principaux avantages (mais aussi un apprentissage et utilisation rapide, pas besoin de déployer l'artillerie lourde et de tout recompiler à chaque fois). Mais à chaque exécution, il faut bien ré-interpréter tout le code. C'est à dire : analyeur lexical, analyseur syntaxique, table des symboles, contrôle de types (s'il y en a), résolution des portées (souvent en même temps que les symboles en fait), interprétation directement en mémoire ou compilation en code intermédiaire (bytecode, ou opcode dans la terminologie PHP) puis exécution dans la VM ou runtime (selon la terminologie des langages, mais notion équivalente).
Dans le cas de PHP, pas d'interprétation directement en mémoire, on passe par un runtime (sauf grosse bêtise de ma part … mais j'en doute), ce qui permet une déploiement multi-plateforme. Bah oui, on écrit un seul bytecode et c'est le runtime qui est dédié à chaque plateforme, on y gagne. C'est comme ça que Java fonctionne par exemple, sauf que lui, il conserve le bytecode ; dans PHP, il est directement consommé (sauf si on utilise des caches justement).
L'idée de JIT est d'aller encore plus loin. On repère tout ce qui est constant dans le bytecode : comme des opérations élémentaires, des conditions toujours vraies ou toujours fausses … bref des branches du code constantes, et on le compile. JIT n'est rien d'autre (si je peux me permettre) que la compilation partielle du bytecode. Ça permet de ne pas exécuter/passer à la moulinette l'ensemble du bytecode dans la VM/runtime ; une partie est directement compréhensible par la machine. On comprend alors pourquoi les performances sont améliorées.
Bien sûr, elles sont améliorées sur certains codes, certains algos, certains contextes. Ce n'est pas général à l'ensemble du bytecode. Il faut l'analyser, repérer des cas « pathologiques », i.e. bien connus, et les traiter. Cette analyse peut être longue et donc plomber les performances si elle n'est pas bien faite. C'est tout le dilemme : on gagne 5ms mais on en perd 10 pour les gagner … Ce n'est pas simple et les règles doivent être formelles/claires. Ça soulève des problématiques intéressantes.
Personnellement, je m'étais intéressé à intégrer JIT dans PHP mais la tâche est hardue. Je suis content que le travail ait été fait (si la rumeur est vérifiée), mais j'espère que Facebook et la communauté PHP sauront s'entendre …
Source possible : Facebook gets faster, debuts homegrown PHP compiler, sur ReadWriteWeb.
.