Une deux trois mots : HipHop (va servir|sert) à générer du code C++ à partir de votre code php, pour le compiler, et avoir votre site web plus rapide (car en en C++).
Comme cela je suis pas convaincu -outre les problèmes de compatibilités qui vont surement venir avec telle ou telle extension-, j'y attends pas grand chose en ce moment.
Mais vous qu'en pensez-vous?
Texte d'annonce :
http://developers.facebook.com/news.php?blog=1&story=358
Vidéo de présentation :
http://www.ustream.tv/recorded/4409735
PS: rien à voir ou presque, je me rappel d'un vieu journal sur linuxfr (peut être encore DaLinuxFrenchPage alors, pour vous dire si c'est vieux) ou il a été question d'un framework Web en C ou C++ (ou base sur langage de "script" dérivé du C/C++) du nom de Spike il me semble. J'ai du mal à retrouver des infos dessus. C'est mort ou pas?
Journal HipHop For PHP : Facebook php-to-C++ translator
3
fév.
2010
# blitzen
Posté par Anonyme . Évalué à 5.
[^] # Re: blitzen
Posté par fcartegnie . Évalué à -5.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...)
De plus, c'est un voie déjà explorée:
http://www.roadsend.com/home/index.php
http://www.phpcompiler.org/
[^] # Re: blitzen
Posté par ckyl . Évalué à 10.
Finding new ways to improve PHP performance isn't a new concept. At run time the Zend Engine turns your PHP source into opcodes which are then run through the Zend Virtual Machine. Open source projects such as APC and eAccelerator cache this output and are used by the majority of PHP powered websites. There's also Zend Server, a commercial product which makes PHP faster via opcode optimization and caching. Instead, we were thinking about transforming PHP source directly into C++ which can then be turned into native machine code. Even compiling PHP isn't a new idea, open source projects like Roadsend and phc compile PHP to C, Quercus compiles PHP to Java, and Phalanger compiles PHP to .Net.
Needless to say, it took longer than that single Hackathon. Eight months later, I had enough code to demonstrate it is indeed possible to run faster with compiled code. We quickly added Iain Proctor and Minghui Yang to the team to speed up the pace of the project. We spent the next ten months finishing up all the coding and the following six months testing on production servers. We are proud to say that at this point, we are serving over 90% of our Web traffic using HipHop, all only six months after deployment.
Tu penses sincèrement que les mecs ont passé un an à développer leur truc et à le mettre en prod sans avoir évalué les solutions déjà existantes ? Vous prenez vraiment tout le monde pour des abrutis ou quoi ?
> Si c'est pour gagner 50%, c'est vraiment pas optimisé... pas plus qu'un cache-op.
Par ce que tu as benchmarké un cache op sur leur prod ? T'as pas l'impression de comparer des choux et des carottes ?
[^] # Re: blitzen
Posté par __o . Évalué à 7.
Ils ont gagné 50% sur une plateforme sur laquelle ils utilisaient déjà un cache d'opcode.
[^] # Re: blitzen
Posté par Samos . Évalué à 5.
Il n'y a pas vraiment d'activité sur sourceforge car je n'ai rien uploadé depuis un sacré bout de temps, mais le projet n'est pas du tout abandonné :
C'est un serveur d'applications en C/GObject qui peut exécuter des applications( sites webs ) elles-mêmes codées soit directement en C, soit en Vala(mais pas en C++).
Ces derniers mois je n'ai vraiment pas eu beaucoup de temps à lui consacrer, et durant ce peu de temps, j'ai travaillé sur un moteur de génération de documentation qui soit capable de générer d'un seul coup la doc pour l'API Plain-C et la doc pour l'API Vala.
En effet, actuellement, la documentation de référence est générée directement par gtk-doc( pour la partie Plain C), tandis que la doc Vala est «générée» à la main en éditant une copie de la doc Plain C ce qui est évidement loin d'être viable.
Pour résoudre ce problème, j'ai travaillé sur une petite «moulinette» capable de générer du docbook à la fois pour l'API Plain C comme le fait gtk-doc mais aussi pour l'API Vala.
Cette moulinette est fonctionne presque bien depuis aujourd'hui. D'ailleurs, comme j'ai quand même pu avancer un tout petit peu sur le code, je ne suis plus très loin de la première milestone qui consiste à avoir tous les widgets HTML de base implémentés, et je prévois de sortir une nouvelle pré-version avant la fin du mois.
# Mon fork amwa!
Posté par Nicolas Blanco (site web personnel) . Évalué à -1.
Ce super fork réintegrera les numéros de lignes obligatoires en début de ligne !
Comme en BASIC dans les années 80. Ça ira bien avec l'instruction goto qui a été réintroduite récemment.
Ça fera fureur je te le dis !
[^] # Re: Mon fork amwa!
Posté par Thierry . Évalué à 3.
http://www.gotopp.org/presentation.html.fr ?
[^] # Re: Mon fork amwa!
Posté par Gui13 (site web personnel) . Évalué à 6.
http://forum.mac4ever.com/post671298.html#p671298
# Pas convaincu
Posté par Guillaum (site web personnel) . Évalué à 1.
Je ne suis pas convaincu pour plusieurs raisons.
Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même, mais tout ce qui tourne autour, notamment les entrées sorties et la BDD. De plus la plupart des fonctions PHP étant écrite en C derrière, PHP n'est pas si lent que cela (globalement le temps gagné se fera sur le temps de dispatch des instructions de la machine virtuelle, ce qui est proche d'être négligeable dans le cas d'une utilisation WEB standard où l'on fait principalement des appels de fonction de traitement de chaîne et de base de donnée).
Donc je ne suis pas convaincu pour le gain en vitesse. D'autant plus que l'on parle d'un gain de performance sur la partie qui peut être facilement dupliquée, il suffit de créer un serveur clone du premier et de repartir la charge entre les deux et c'est bon (enfin presque ;)
Maintenant ce genre de compilation de code risque de provoquer des incompatibilités et des problématiques de maintenance tordue. Je ne suis pas près à sacrifier la maintenabilité et la simplicité de développement pour un millième de seconde gagné à chaque requête.
A mon avis il serait plus rentable de payer pour auditer le code à la recherche d'algorithmes mal écrits / requêtes mal faite plutôt que de payer quelqu'un pour s'assurer que ce bordel fonctionne correctement ;) A partir du moment ou l'on utilise un langage comme PHP c'est que l'on à comprit que la perte en performance ce fait en échange d'un gain énorme en maintenabilité, portabilité et facilité de développement. Quitte à revenir en arrière, autant faire du web en C.
Sinon j'ai un exemple tout bête, il existe pour Python pyrex (ou cython) qui permet de compiler du code python en C. Le gain de performance est presque nul tant que l'on ne fournit pas des indications à pyrex sur le code (par exemple les types de données), mais à ce moment là ce n'est PLUS du python, c'est un autre langage au typage statique qui permet, du fait de son typage statique, des optimisations hardware intéressante.
Conclusion, soit HipHop prend du PHP pur et en fait du C++ et je ne vois pas le gain que cela peut apporter, soit HipHop définit un nouveau langage basé sur PHP et (attention troll), je trouve cela inutile car il y a pleins d'autres langage qui répondent à ce besoin (langage de plus/moins haut niveau avec typage statique permettant des optimisations agressives) et si j'avais à faire cela je n'aurais pas pris php comme base de départ (bouh, moche ;)
[^] # Re: Pas convaincu
Posté par ploum (site web personnel, Mastodon) . Évalué à 9.
Dans un monde idéal, on combine les deux.
Et oui, ça existe.
Cela s'appelle J2EE : maintenabilité illusoire, portabilité difficile à maintenir, développement réservé aux autistes, le tout avec des performances de merde.
Elle est pas belle la vie ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Pas convaincu
Posté par Zarmakuizz (site web personnel) . Évalué à 1.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Pas convaincu
Posté par kahal (site web personnel) . Évalué à 5.
Et depuis le changement de nom ça môrche mieux ...
[^] # Re: Pas convaincu
Posté par ckyl . Évalué à 10.
> Donc je ne suis pas convaincu pour le gain en vitesse. D'autant plus que l'on parle d'un gain de performance sur la partie qui peut être facilement dupliquée, il suffit de créer un serveur clone du premier et de repartir la charge entre les deux et c'est bon (enfin presque ;)
Ils annoncent une réduction de la charge de 50% sur leur frontend en prod. Tu veux faire le calcul du pognon gagné quand tu as un datacenter de cette taille ? Autrement dupliquer bêtement ça n'a jamais marché tout seul, et surtout pas à cette échelle... Je pense même qu'ils sont déjà un peu au courant.
> Maintenant ce genre de compilation de code risque de provoquer des incompatibilités et des problématiques de maintenance tordue. Je ne suis pas près à sacrifier la maintenabilité et la simplicité de développement pour un millième de seconde gagné à chaque requête.
Sur 10 milliards de pages vues par jour ça peut commencer à se défendre de gagner un millième de seconde. C'est une bête histoire de coût de dev VS coût opérationnel.
Après pour toi et ton site web, personne n'a dit que ça sera utile. Mais dire que leur outil ne sert à rien, j'attendrais d'avoir un peu plus de recul et de données en main...
[^] # Re: Pas convaincu
Posté par guppy . Évalué à 2.
Chaque développement est un compromis entre différents critères, notamment la performance et la facilité de développement.
Effectivement le PHP offre un développement plus facile que du C++, et une performance qui doit n'être qu'un peu plus faible. Pour une application classique, PHP est souvent "le meilleur" compromis (encore que ça dépende de l'équipe de développement, mais passons). Mais Facebook, c'est une application qui est quand même singulière, qui est loin de rentrer dans les critères. Il y a des dizaines de milliers de serveurs PHP apparemment.
Visiblement, ils ont choisi de complexifier la maintenance (il risque d'y avoir un paquet de régression) pour bénéficier d'un peu de performance supplémentaire. Ils parlent de 50 % de serveurs en moins. J'imagine qu'ils ont du peser les inconvénients / avantages avant de se lancer. Peut-être qu'ils se trompent, mais ça c'est difficile à dire.
[^] # Re: Pas convaincu
Posté par Bertrand Mathieu . Évalué à 4.
La problématique de facebook c'est d'avoir au moins 30000 serveurs actuellement (http://www.datacenterknowledge.com/archives/2009/10/13/faceb(...) ), alors la solution "y qu'à doubler les serveurs" a un cout pas marginal du tout.
A plus petite échelle: par exemple une asso qui a un beau site mais peu de sous et beaucoup de visites, si ça peut éviter de payer la location d'un 2eme serveur qui a de grosse capacités, c'est peut-être bon à prendre aussi.
Je vois surtout dans cet outil une possibilité de plus dans l'arsenal qui permet d'affronter une montée en charge.
Maintenant ce genre de compilation de code risque de provoquer des incompatibilités et des problématiques de maintenance tordue.
Perso je demande à voir ce que ça donne. Ce qui est sûr c'est que tant si le compilateur n'est pas encore vraiment stable ça peut vite devenir l'enfer!
Dans un genre comparable il y a le google web toolkit (GWT), qui propose d'écrire la partie client en java (avec tests en java), GWT servant à compiler ce code en HTML + JS (de ce que j'en ai compris). Et vu leurs produits web on ne peut nier que ça marche.
Ton exemple pyrex/cython est intéressant, mais je pense que ces outils doivent être approchés comme des facilités pour avoir des parties de code aux performances proches du C dans le meilleur des cas, et non pas comme des moulinettes "magiques" pour faire tourner n'importe quel programme python plus rapidement. Certes ils peuvent induire des contraintes par rapport au python standard. Mais d'un autre côté nul besoin de connaître le C pour écrire une fonction "native". La maintenance et la portabilité sont plus simples qu'avec du C, ainsi que le temps de mise au point. Je les vois donc comme des intermédiaires entre le python haut niveau et l'écriture de code C.
A ce sujet l'article du développeur facebook est intéressant car il explique clairement ce qui les a motivés pour se lancer là-dedans. L'un des points concerne notamment le fait d'écrire des extensions PHP en C++: cela réduit considérablement le nombre de personnes qui peuvent intervenir sur ces parties du code, ce qui chez eux n'était pas envisageable.
[^] # Re: Pas convaincu
Posté par Antoine . Évalué à 3.
Il vaut mieux le connaître, ne serait-ce que pour comprendre ce que "natif" peut vouloir dire.
[^] # Re: Pas convaincu
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même,
De mon expérience, si et de plus en plus. Et les caches de opcode n'y peuvent rien d'ailleurs.
Tu dis php mais tu veux dire php bien écrit. Or php est une plate-forme particulièrement adapté au code de merde qu'il a le mérite de le faire tourner convenablement.
Je me permettrais donc de nuancer ton propos en remplaçant php par php correct et maîtrisé.
Ce que je vois de php, c'est que les principaux cms ont besoin de plus de mémoire (memory limit) et de plus de temps (max_execution_time) pour un resultat à peu près équivalent à ce qu'ils faisaient avant. Pour le memory_limit par exemple on est en passe d'arriver à un pseudo standard de 128 MO là ou il y a 3 ans on était entre 2 et 8. Tu peux passer ton serveur de 2 à 16 GO, le compte n'y est pas.
Je suis désolé mais je ne comprends pas pourquoi un site sous drupal presque vide ne tourne pas avec 32 MO de mémoire possible pour chaque script.
Je n'ai rien contre php en soit. Mais dire que "Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même" c'est un peu fort.
La tolérance de php au code pourris est sans doute avec, la méconnaissance de l'algèbre relationnelle et le spam, l'une des plus grande cause de surconsommation électrique actuelle.
Maintenant si tu parles de php utilisé convenablement, déployé en trois tiers avec par exemple nginx et spawn-fcgi, du code testé et tout le tintouin là c'est autre chose.
Toutefois il ne faut quand même pas oublier que php reste dans sa plus large acception le langage des jean-kevin qui ne comprennent pas comment utiliser plesk pour faire pointer "le CNAME de www.mondomaine.com/index.php vers le dns de 42.128.196.32".
Je te jure, il faut les avoir au tél toute la journée les "webmasters" qui te demande ce que tu entend par "maintenance du code" ou par "version de pre prod"
Brrrrrrrrrrr
J'en tremble encore
# Pourquoi n'y ont-ils pas pensé ?
Posté par Anonyme . Évalué à 6.
[^] # Re: Pourquoi n'y ont-ils pas pensé ?
Posté par Erwan Scouarnec (site web personnel) . Évalué à -2.
[^] # Re: Pourquoi n'y ont-ils pas pensé ?
Posté par Régis . Évalué à 0.
Tu aurais dû poster ton message le 2 février pour que cela prenne ton sens.
À l'an prochain :)
# économie ; écologie...
Posté par David (site web personnel) . Évalué à -1.
c.f. http://www.greenit.fr/article/energie/hiphop-for-php-faceboo(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.