Ce genre de chose est loin d'être nouveau, Roadsend PHP propose depuis bien longtemps un compilateur PHP natif...
Version imprimable
Ce genre de chose est loin d'être nouveau, Roadsend PHP propose depuis bien longtemps un compilateur PHP natif...
HipHop confirme ce que je disais dans mon premier post dans cette thread, à savoir que C++ est en train d'opérer un retour (ou une simple arrivée, en fait) dans le monde des langages pour applications web. Personnellement, je trouve que c'est tout naturel et m'étonne que cette prise de conscience ne soit pas intervenue plutôt. A la base, C++ est conçu pour supporter des charges importantes tout en optimisant la mémoire. Les gros sites web actuels n'ont rien à envier aux larges appli desktop. Bref, c'est une évolution naturelle en l'absence de technologies miracles et qui fassent consensus dans un style JIT (génération de code machine Just In Time). Oui bien sûr, il y a java et .NET.
A ce propos, les info (les bruits de couloir, les rumeurs?) concernant ce que facebook nous préparait allaient plutôt dans le sens d'une solution basée sur du JIT, justement.
Ce que facebook nous propose est différent. hiphop est avant tout un "transformeur de code" (et dans un second temps un runtime 100% détaché du runtime de php). Ca transforme du code php en code C++. Ensuite, ce code C++ est compilé de manière traditionnelle pour créer un executable.
Actuellement, 2 types d'executables sont possibles:
- un "tout en un" qui fait office de server web en plus du travail spécifique implementé initialement en php. Il s'agit d'un process multithread.
- un simple programme en ligne de commande
A terme, facebook veut proposer une solution spécifiquement adaptée à apache, ainsi que du fastcgi.
Quelque part, on ne peut pas faire mieux que ce que facebook propose en terme de performances et de ressources utilisées: laisser un compilo C++ faire le travail final à partir d'un code C++ optimisé (ça c'est ce qu'ils prétendent, mais bon, en théorie, ça se tient). Néanmoins, cela implique quelques restrictions, et non des moindre.
Tout d'abord, hiphop ne supporte qu'environ 90% de php 5.2 (core et extensions standard). Supporter php 5.3 est dans la roadmap (heureusement!). De plus, un certain nombre de features vraiment dynamiques de php ne sont et ne seront pas implémentées. Parmis lesquelles:
- eval()
- create_function()
- preg_replace() avec /e
- bidouiller avec l'ordre de déclarations des symboles (functions, classes..).
Cependant, il faut savoir que facebook tourne à 90% avec hiphop à l'heure actuelle. Il s'agit donc d'un projet déjà en production.. et sur pas n'importe quel site!
D'un point de vue utilisateur, pour bénéficier de hiphop, il faudra avoir accès à un compilo C++ sur le server (g++). Pour les shared hosts, ça risque d'être limité.
Il ne sera pas possible d'utiliser des extensions php non standard, à moins que celles-ci aient été réécrites spécifiquement pour hiphop (ce que facebook semble avoir fait pour certaines).
Le moindre changement dans le code d'un script php entrainera une nouvelle phase de transformation puis de compilation. Pour un "scripteur", ça doit être quelques chose d'assez frustrant (facebook propose aussi HPHPi, un interpreter, mais destiné au dev/debugging).
Pour finir, le plus gros problème à mon avis, est le fait que hiphop fournisse son propre runtime: un changement ou une addition dans le php traditionnel (celui de Zend) ne sera pas automatiquement répercuté dans hiphop. Il faudra que quelqu'un fasse ce réajustement. A terme il pourrait y avoir un décalage entre ces deux implémentations de php. Il y aura le "vrai" php de Zend d'un coté et le php qui marchera avec hiphop de l'autre (et c'est déjà le cas puisque certaines features dynamiques ne sont pas supportées par hiphop).
Oui c'est la solution pour les performances,Pourquoi ne pas faire le pas, personnellement je ne connais que WT,pour faire du C++ en Web !
Connaissez vous d'autres possibilités ?
ASP.NET supporte peut-être C++/CLI, je ne sais pas.
Toujours de Microsoft, il y a ATL Server.
Sinon, si l'on s'en sent le courage, on peut écrire directement des pages avec libfcgi :aie:
J'ai à peine regardé WT, et c'est vrai que ce projet a le vent en poupe. il y a aussi CppCMS (qui n'est pas un CMS).
D'autres projets sont en gestation. Je n'ai plus les liens ici, mais il y a en gros 2 catégories: ceux qui fournissent une full stack, à savoir un server en front end puis tout le reste sous forme de framework (ce que fait hiphop en fait) et l'autre catégorie qui se repose sur le protocole fastcgi (donc en fait, server-agnostique).
Mon blog est écrit en c++ (du fastcgi derrière nginx). MongoDB c++ pour la db et google v8 (c++) pour le templating.
Mwè, je préférerais qu'ils améliorent APC et consors.
Statifié son application dans un binaire c'est sympa, mais cela tue un peu le côté free de php. M'enfin, sur des applications critiques comme celle ci les process doivent être assez bien appliqués.
D'ailleurs, c'est bien un binaire qui résulte de la compilation ? Quid de l'arbo des contenus ? N'ont ils compilés que le core ?
Citation:
Envoyé par kaymak
une info : Hip Hop n'est pas dispo pour windows.Citation:
Envoyé par metagoto
Ouais, mais je prend mon exemple face à cette techno, j'ai 50% des contenus affichés sur les sites que je gère qui sont administrés via un outil de gestion de contenu en ligne.
Hors je me voit mal re compilé l'application pour l'ajout d'un contenu, c'et là une opération simple de l'appli.
C'est ici contre productif, et APC résout ce problème à merveille, hors avec un tels composant c'est tout de suite plus compliqué de ce coté ci.
D'un autre côté on y gagne en simplicité de déploiement, versionning ect.
Et j'en viens à me poser cette question, peut on importer du code php non compilé en c++ dans le process compilé en c++ ? Faire un include en somme...
En tout cas l'idée peut être intéressante pour vendre/louer des applis sans en délivrer le code source.
edit:
http://developers.facebook.com/news....og=1&story=358
Quelqu'un à t'il le source code à dispo ? Je ne le trouve pas...... Il y à semble t'il un mode pour tester sans compiler.
Citation:
We have also developed HPHPi, which is an experimental interpreter designed for development. When using HPHPi you don't need to compile your PHP source code before running it. It's helped us catch bugs in HipHop itself and provides engineers a way to use HipHop without changing how they write PHP.
Encore heureux qu'il ne faille pas faire cela. Je les imagine bien recompiler facebook a chaque fois qu'un utilisateur poste un message :aie:.
L'accès au donnée (fichiers plats, base de donnée relationnel, ...) doit être supporté sinon, bonjour les dégats.
Normalement, même en PHP, on génère rarement du code à la volée (on peut le faire).
L'application est très souvent codée et exécute son code sans le modifier.
Je n'ai pas trouvé le code source non plus, mais je suis tombé sur cet article de blog assez complet en français :
http://jpv.typepad.com/blog/2010/02/...s-limites.html
Ca fait plaisir de voir qu'on me lit :ccool:
j'ai vu pas mal de polémiques sur ce forum pour l'avenir de PHP lui même, je voudrais juste donner mon avis dessus :
- Yahoo! s'est payé Rasmus pendant des années, et PHP ne s'en est que mieux porté : j'ai vu passer dans PHP5.2 des fonctionalités que j'ai utilisé en interne sur la version YPHP développée par Rasmus et son équipe
- Zend a été créée par Zeev qui est un des fondateurs de PHP et est maintenant une boîte privée
- facebook en a terminé avec ce projet autour de PHP, il marche très bien chez eux, donc ils auraient très bien pu se le garder pour eux. Au lieu de ça, en plus des contributions qu'ils font déjà depuis quelques années à PHP, ils le donnent à la communauté pour qu'elle ait une chance d'adapter cette techno innovante à d'autres sites. Pour le moment ils jouent le jeu de l'open source!
donc non je ne pense pas que les intérêts privés aillent forcément à l'encontre de l'avenir de PHP
Je suis impatient que quelqu'un teste ce compilo PHP sur un site de production pour voir quelles librairies seront incompatibles et si les performances sont confirmées en dehors de Facebook.
oui c'est un binaire qui ressort de tout ça, qui fait aussi serveur web. Pour facebook ils disent qu'ils ont obtenu un binaire d'1Go, mais il y a une seule instance par serveur vu qu'il gère lui même le différents threads
apparemment ils ont essayé puis rejeté
zont quand meme bossé dessus à 3 pendant 2 ans ...
+1
Au contraire ces entreprises ne vivent pas par le software mais par les services qu'ils offrent. Du coup il est très intéressant y compris pour eux de proposer leurs softs à la communauté...
Oui.
Par contre perso je suis quand même un peu déçu de l'approche qui a été choisit, c'est à dire de générer carrément un programme natif pur...
:arrow: J'aurais préférer voir un remplaçant du Zend Engine avec un compilation JIT...
a++
le code source se fait loooonnnngggg à arriver.... Le wiki est vide, le git non fonctionnel. N'y à t'il que du bruit autour de ce projet ?
Fin bon, cette solution n'à de sens que dans leur situation où il leur fallait faire des économies de calcul en ne changeant pas l'existant technique, qui est plus que fonctionnel vu comment il cartonne.
Et à ce niveau là l'ingé à apparemment réussi, mais pour un nouveau projet se serait un choix vraiment étrange.
Personnellement, je pense que c'est une excellente chose :)
Je ne pense pas non plus que cela puisse nuire à PHP, au contraire même. Ils n'ont pas tenté de remplacer PHP, ils ont voulu le garder et améliorer ses performances, preuve de l'utilité du langage.
ben moi non plus, mais en faisant une recherche sur tout le code de mon projet actuel, je me suis aperçu qu'un dev m'en avait laissé un par exemple, dans une classe de mailing en intranet (PHP n'est pas son métier premier)
et si j'inclue la recherche dans les libs PHP (PEAR et Zend notamment), j'ai trouvé une dizaine d'utilisations. PHPUnit aussi.
c'est le genre de petite surprise qui peut carrément invalider l'utilisation du biniou
pour revenir sur le problem de l'eval, j'ai recement du l'utiliser pour faire des appelles dynamique de parametre dans un objet avec des membres d'un tableau car l'appelle dynamique ne marchait pas:
ne marche pas du tout, alors que :Code:
1
2 $this->{$attr_array[0][$attr_array[1]]} = $new_value;
toujours est-il je trouve l'idee seduisante mais j'attend vraiment le module apache car le probleme une fois le projet compiler, fini l'utilisation de mod_rewrite, mod_secure, restriction d'access, auto_append, auto_preppend etc...Code:
1
2 eval("\$this->".$attr_array[0]."['".$attr_array[1]."'] = '".$new_value."';");
Quid aussi des frameworks "grand public", malgres ce que j'en pense, ils font maintenant parti integrante de l'ecosysteme php et ne peuvent plus etre ignorer.
Il n'y a pas de raison que ça ne fonctionne pas (tout du moins avec un php récent) :
Au pire:Code:$this->{$attr_array[0][$attr_array[1]]} = $new_value;
Code:
1
2
3 $tmp = $attr_array[0][$attr_array[1]]; $this->{$tmp} = $new_value;
Ca ne devrait pas poser de problème pour une utilisation avec apache et reverse proxy.Citation:
toujours est-il je trouve l'idee seduisante mais j'attend vraiment le module apache car le probleme une fois le projet compiler, fini l'utilisation de mod_rewrite, mod_secure, restriction d'access, auto_append, auto_preppend etc...
Voir aussi la possibilité de faire du fastcgi avec le mode "sans server" embarqué.
Bonsoir,
Rien à voir, mais, vous oubliez de concaténer les deux chaines qui constitue l'identifiant du membre de l'objet $this (surplombée d'une imbrication étrange de crochets) :
Dans tous les cas, ceci fonctionne parfaitement :Code:
1
2 $this->{$attr_array[0].$attr_array[1]} = $new_value;
Je suis d'accord sur le fait qu'eval n'est pas un réel besoin à PHP, avec un code propre on peut (toujours?) faire autrement. Mettre du Code PHP ailleurs que dans des fichiers c'est pas tip-top car peu performant et source d'erreur.Code:
1
2
3 $memberName = $attr_array[0].$attr_array[1]; $this->{$memberName} = $new_value;
À part çà, je trouve çà étonnant que Zend continue d'investir autant dans le langage PHP alors que des gains de performance de l'ordre de 50% sont faisable en compilant via g++. Soient ils sont nuls (clairement), soit HIP-HOP c'est un gros coup marketting (ou alors je dis n'importe quoi <=)
50% de gain constaté en moyenne par facebook pour les pages web de leur site qui fait un usage extensif de memcache, et par rapport à leur précédente implémentation soit disant ultra optimisée (avec des extensions maisons etc).
J'attends de voir, mais à mon avis dans le cas d'un script php ne faisant pas intervenir de systèmes externes (tels que memcache, mysql etc), ni de types "variant" (des types équivalant aux zval pour hiphop), alors les gains doivent être beaucoup plus important que 50%. Probablement 1000%.
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 :mrgreen: