Discussion :

[Phelim]

Je ne dirai pas que "Zend est nul". Et puis il ne suffit pas de compiler avec g++. Il faut générer le code c++ au préalable. Zend ne peut pas faire ça en un claquement de doigt. Personne ne peut faire ça. Ca a pris 3 ans à une équipe de gros geeks chez facebook

Si je me souviens des interviews que j'ai lu de Rasmus Lerdof, il est très clair sur les limites du PHP et conseille dès que possible de développer une extension en C++.

Je ne connais pas spécialement la feuille de route par rapport à l'API Zend, ni le fonctionnement détaillé de cet API.

J'espere que Zend ne suit pas la même voie que Facebook et se focalise davantage sur l'évolution de l'api interne de PHP pour l'intégrer à l'architecture objet de PHP.

Actuellement les extensions de PHP fonctionne sur un shéma fonctionnel.

Néanmoins si demain il devient possible de structurer une API avec un format objet utilisable dans PHP, Zend aura réellement fait un pas extraordinaire.

Les frameworks abandonneront peut etre le tout PHP pour se focaliser sur le déploiement d'une architecture optimisée en terme de performance.

Mieux, le pas effectué par Facebook permettra de générer d'envisager de générer du code C++ qui s'intégre à l'API de Zend pour migrer certain système tout PHP pour la performance.

Les perspectives ouvertes seraient extraordinaires. Nous conserverions la simplicité de PHP pour les personnes souhaitant l'utiliser de façon simple (page personnelle, site à faible montée en charge) et aurions un socle commun solide et performant (le passage de l'un à l'autre pouvant se faire naturellement en changeant de langage).

PHP ne serait plus un langage à part entière mais une surcouche du C / C++ (un peu comme le LUA pour le monde du jeu vidéo). (même si dans la pratique, il l'est depuis un bon moment déjà, on l'oublie facilement)

Par une telle évolution, PHP gagnerait ses lettres de noblesse en temps que langage de développement pour le web (sans perdre sa véritable identité)

[metagoto]

Si je me souviens des interviews que j'ai lu de Rasmus Lerdof, il est très clair sur les limites du PHP et conseille dès que possible de développer une extension en C++.

Je ne connais pas spécialement la feuille de route par rapport à l'API Zend, ni le fonctionnement détaillé de cet API.

J'espere que Zend ne suit pas la même voie que Facebook et se focalise davantage sur l'évolution de l'api interne de PHP pour l'intégrer à l'architecture objet de PHP.

Actuellement les extensions de PHP fonctionne sur un shéma fonctionnel.

Néanmoins si demain il devient possible de structurer une API avec un format objet utilisable dans PHP, Zend aura réellement fait un pas extraordinaire.

Les frameworks abandonneront peut etre le tout PHP pour se focaliser sur le déploiement d'une architecture optimisée en terme de performance.

Mieux, le pas effectué par Facebook permettra de générer d'envisager de générer du code C++ qui s'intégre à l'API de Zend pour migrer certain système tout PHP pour la performance.

Les perspectives ouvertes seraient extraordinaires. Nous conserverions la simplicité de PHP pour les personnes souhaitant l'utiliser de façon simple (page personnelle, site à faible montée en charge) et aurions un socle commun solide et performant (le passage de l'un à l'autre pouvant se faire naturellement en changeant de langage).

PHP ne serait plus un langage à part entière mais une surcouche du C / C++ (un peu comme le LUA pour le monde du jeu vidéo). (même si dans la pratique, il l'a toujours été, on l'oublie facilement)

Par une telle évolution, PHP gagnerait ses lettres de noblesse en temps que langage de développement pour le web (sans perdre sa véritable identité)

Plusieurs choses.
Tout d'abord, il y a un léger courant qui tend à promouvoir un nettoyage de l'API de php. Cela concerne le développement même du core de php/ZE et aussi les extensions.
http://wiki.php.net/rfc/remove_zend_api
http://wiki.php.net/rfc/php_native_interface
Franchement, je pense que ça ne se fera pas. Il faudrait pratiquement tout réécrire de zero. php a une trop longue histoire et trop de patches derrière lui. php 6 ne prend pas cette direction, ça ne va pas arranger les choses.

Ce que fait hiphop (d'après ce qu'on peut lire à droite et à gauche) ne va pas dans le sens de "générer du code C++ qui s'intégre à l'API de Zend". En fait hiphop se débarrasse le plus tôt possible de tout ce qui a un rapport avec php et son runtime. hiphop prend des fichiers sources php en l'entrée mais après tout le boulot consiste à se débarrasser de php. Donc de ce point de vue là, je doute que cela soit d'une grande utilité pour garder ou améliorer de quelconques liens avec php (son runtime).

Dans la conférence en video de hiphop (voir les liens dans cette thread), ils disent bien que les extensions php actuelles (en C ou C++) doivent être entièrement réécrites pour hiphop (et d'ailleurs ce n'est pas étonnant). Moi c'est le truc qui m'interesse le plus en fait, car ça implique la mise à disposition d'une API/lib/framework en C++ pour hiphop. On a donc un peu le meilleur des 2 mondes: on peut coder en php mais aussi "étendre" les possibilités en codant directement en C++. Là je fais confiance à facebook pour que leur API soit plus propre que celle de Zend. Dans une même veine, on a un autre projet de facebook: http://developers.facebook.com/phpembed/docs/index.html qui lui facilite l'intégration du runtime php dans une appli host.

En tout cas, je ne pense pas que php ait eu à attendre hiphop pour gagner ses lettres de noblesse. Rien que le fait que facebook repose (ou reposait, OK) en grande partie sur php suffit pour assoir les qualités émérites de ce langage de script.

[mon_nom_est_personne]

En tout cas, je ne pense pas que php ait eu à attendre hiphop pour gagner ses lettres de noblesse. Rien que le fait que facebook repose (ou reposait, OK) en grande partie sur php suffit pour assoir les qualités émérites de ce langage de script.

+1 auquel il faut aussi ajouter yahoo (flickr etc...) qui n'est pas rien non plus.

[Baptiste Wicht]

Le créateur de PHP a répondu à quelques questions sur HipHop ici.

C'est en anglais, mais c'est plutôt intéressant.

[Aquaa]

+1 auquel il faut aussi ajouter yahoo (flickr etc...) qui n'est pas rien non plus.

yahoo tourne sous php ?

[jpvincent]

yahoo tourne sous php ?

yes they do (j'y ai bossé) et ils se sont même payé Rasmus pendant quelques années, pour de la formation et du développement de la version interne de PHP

[Aquaa]

d'après ce comparatif entre les différents compilateurs php existant dont HipHop, il n'est pas le plus.
http://www.phpclasses.org/blog/post/...rformance.html

[Mikushi]

J'ai eu l'occasion de tester HipHop de maniere intensive depuis mi-Janvier.
Globalement c'est une grosse deception, lorsqu'on le compare aux alternatives que sont PHC et Roadsend PCC, HipHop est assez loin derriere, et n'offre aucun avantage vis a vis de la concurrence.
Le gain de performance annonce par Facebook est bel et bien present, mais 50% n'est vraiment pas grand chose, avec PHC j'ai eu des gains montant jusqu'a 200%.
Mais il faut replacer HipHop dans son contexte, pour une entreprise tel que Facebook, ou 90% du code base est en PHP, il est juste inimaginable de tout reecrire en C/C++, le temps que cela prendrait est juste enorme, HipHop se presente a Facebook comme une solution rapide d'ameliorer les performances de leur existant, tout en passant a des solutions plus rapides pour leur nouveaux developpements.
C'est une discussion que j'ai eu l'an dernier avec Marcus Börger de chez Google, si on souhaite vraiment avoir un gain de performance substantiel en PHP, l'unique solution est de se tourner vers l'ecriture d'extensions, c'est ce que font Google, Yahoo et les autres quand ils utilisent PHP, comme le dit jpvincent plus haut Yahoo est majoritairement sous PHP, a titre de "template langage" et derriere un nombre enorme d'extensions maisons.

Bref, personnelement je ne vois rien qui soit vraiment interessant dans HipHop (ou meme les alternatives), tant le gain est assez ridicule. Si vous souhaitez ameliorer les performances de vos applications, soit vous les decoupez de maniere a pouvoir utiliser differents langages la ou ca fait du sens (typiquement nous on utilise des combinaisons de PHP/Python/C a differents noeuds de nos sites/applications), soit vous vous mettez serieusement a l'ecriture d'extensions si vous n'etes pas famillier d'autres langages que PHP/C.

[metagoto]

@Mikushi

Des benchmarks de divers compilers php:
http://www.phpclasses.org/blog/post/...rformance.html

HipHop est celui qui performe le mieux dans ces résultats. On notera que Roadsend n'a pas été pris en compte pour cause de bug (et sa nouvelle branche, Raven, non plus)

Jusqu'à très récemment (hier en fait), les optimisations de base (flags g++) n'étaient pas activées pour les binaires générés par hiphop. phpclasses.org a mis à jour son article. Le gain en perf est substantiel.

Le "problème" avec les extensions php, est que le runtime reste celui de php. Selon la nature des extensions, le gain n'est pas forcément conséquent. Mais il est clair que passer par une extension est la solution à privilégier avant de s'embarquer dans des solutions telles que hiphop.

hiphop est non seulement la solution de facebook pour remplacer apache+php, mais c'est aussi le moyen de réutiliser leur code base php conséquent pour s'interfacer avec d'autres langages. Apparemment facebook ne veut pas forcément réécrire des codes en python ou que sais-je encore. hiphop a un mode pour générer des librairies compatibles avec SWIG. Il s'agit donc bien plus qu'un simple compiler php, c'est un outil central (pour facebook tout du moins).

[Mikushi]

hiphop est non seulement la solution de facebook pour remplacer apache+php, mais c'est aussi le moyen de réutiliser leur code base php conséquent pour s'interfacer avec d'autres langages. Apparemment facebook ne veut pas forcément réécrire des codes en python ou que sais-je encore. hiphop a un mode pour générer des librairies compatibles avec SWIG. Il s'agit donc bien plus qu'un simple compiler php, c'est un outil central (pour facebook tout du moins).

J'irais pas dire le contraire, puisqu'il a ete assez claire de la part de FB a la mi-Janvier que la version actuelle est vraiment oriente Facebook. Et c'est aussi pourquoi ils l'ouvrent a l'openSource, pour que la communaute l'adapte a un usage plus general.
En attendant je pense que les cas d'utilisations de HipHop reste tres restraint, et meme dans le tres haut traffic/high availability on l'a vite oublie tellement ca vaut le coup d'investir dans des langages/solutions plus robustes, surtout compte tenu du fait qu'on a pas un code base aussi enorme que celui de Facebook.

[metagoto]

@Mikushi

Je me trompe peut être, mais je ne serai pas étonné que d'ici quelques temps, hiphop soit utilisé sur de nombreux sites, et pas forcément de "très" gros sites.
Je ne serai pas non plus étonné que des sites qui utilisent actuellement une technologie quelconque pour leur système d'API passent discrètement à hiphop. Pourquoi pas twitter ?

Certaines extensions très usuelles ne sont pas encore dispos pour hiphop (je pense à session, pdo, memcache..). L'utilisation de hiphop en production doit être actuellement très limitée (cependant, sur la mailing-list, on apprend que certains font déjà tourner hiphop en prod). De plus, le build system de hiphop est limite archaïque. A base de CMake il n'est franchement pas user-friendly ni aussi fonctionnel que celui de PHP par exemple en ce qui concerne l'ajout/dev d'extensions. Les developers de Hiphop sont en train de bosser sur ce problème.

Dans quels langages/solutions plus robustes voudrais-tu investir ? Apparemment, facebook a considéré un passage à python, java et du plain c++ après avoir contribué à améliorer php et surtout APC. Mis à part le c++, ces solutions alternatives ne leur donnaient pas satisfaction (en terme de perf, mémoire, scalabilité, déploiement..). hiphop est une sorte de projet désespéré pour tenter de concilier la facilité de développement de php et les caractéristiques des applications natives (code compilé). Ces avantages sont dorénavant disponibles pour toute la communauté (moyennant le fait que hiphop soit buggé et trop jeune en général). "investir" dans hiphop sera probablement une solution plus simple et moins couteuse pour pas mal d'acteurs plutôt que de changer radicalement de plateforme/langage.