Facebook libère son compilateur PHP just-in-time HipHop Virtual Machine (ou HHVM)

Posté par  (site web personnel) . Édité par Benoît Sibaud, Nÿco, Malicia, patrick_g et Nils Ratusznik. Modéré par Mouns. Licence CC By‑SA.
Étiquettes :
28
13
déc.
2011
PHP

HipHop pour PHP transforme le code source PHP en C++ en utilisant g++. Il a été développé par Facebook et son code source a été mis à disposition en 2010.

Facebook a ajouté sur le compte GitHub du projet HipHop l'HipHop Virtual Machine (HHVM). Selon Facebook, celui-ci permettrait d'augmenter l'exécution du code PHP de 60 % (par rapport à HipHop) et d'utiliser 90 % de mémoire en moins (NdM : information erronée démentie depuis).

NdM : l'HipHop pour PHP est sous licences PHP 3.01 et Zend 2.0. Le README indique qu'il est disponible sous Linux et FreeBSD.

Aller plus loin

  • # Performances

    Posté par  . Évalué à 2.

    Facebook a ajouté sur le compte GitHub du projet HipHop l'HipHop Virtual Machine (HHVM). Selon Facebook, celui-ci permettrait d'augmenter l'exécution du code PHP de 60 % et d'utiliser 90 % de mémoire en moins.

    D’après ce que j’ai compris, ces valeurs sont celles obtenues en comparant la HHVM à leur interpréteur précédent, pas à HipHop for PHP.

    • [^] # Re: Performances

      Posté par  . Évalué à 1.

      According to Facebook, this PHP execution engine is 60 percent faster than its current PHP interpreter and uses 90 percent less memory.

      A priori, il parle bien de l’interpréteur PHP officiel (c'est vrai que le "its" est ambigu)

      • [^] # Re: Performances

        Posté par  . Évalué à 3. Dernière modification le 14 décembre 2011 à 18:19.

        According to Facebook, this PHP execution engine is 60 percent faster than its current PHP interpreter

        Il est plus rapide que l'interpréteur actuellement utilisé par Facebook, qui est hphpi (pas l'interpréteur officiel).

        Ils utilisent cet interpréteur pour développer, et utilisent le compileur en production.

        D'après http://news.ycombinator.com/item?id=3349331 leur compileur static (HPHP donc) est toujours plus rapide que le JIT (the static compiler is beating our jit at most benchmarks at this writing).

    • [^] # Re: Performances

      Posté par  . Évalué à 6.

      Quelqu'un s'est attelé à faire quelques bench il y a peu par rapport à la version officielle de php sur une installation de drupal. Les résultats semblent intéressants en matière de consommation proc, mais il manque toutefois les informations concernant la conso mémoire.

      http://php.webtutor.pl/en/2011/05/17/drupal-hiphop-for-php-vs-apc-benchmark/

  • # si je resume

    Posté par  . Évalué à 4.

    En gros, ils ont réécrit un interpréteur PHP, parce que l'officiel bouffe trop de CPU et de mémoire.

    Par contre je n'ai jamais compris pourquoi ils ne sont pas simplement passé pluq tot à un autre langage. Je ne donnerai pas d'exemple, vu que nous sommes que mercredi, mais PHP n'a jamais été réputé pour ses performances...

    • [^] # Re: si je resume

      Posté par  (site web personnel) . Évalué à 8.

      C'est un compilateur JIT pour PHP, certes un interpréteur, mais quand même un peu plus évolué.

      Ça doit être ultra spécifique x86 ou x64, mais c'est toujours bon à prendre!
      Je ne serais pas surpris si PHP intégrait quelques unes de ces fonctionnalités pour améliorer leur interpréteur.

      Pour ce qui est d'un autre langage... je pense que chaque boite a ses préférences: Google ne jure que par Python (et maintenant Go), GitHub a choisi Ruby, Facebook a bien le droit de prendre PHP; surtout si les performances envoient du pâté.

      • [^] # Re: si je resume

        Posté par  . Évalué à 1.

        Ça doit être ultra spécifique x86 ou x64, mais c'est toujours bon à prendre!

        Dommage qu'ils n'utilisent pas quelque chose comme llvm.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: si je resume

      Posté par  . Évalué à 4.

      mais PHP n'a jamais été réputé pour ses performances...

      Ni pour sa cohérence :)

    • [^] # Re: si je resume

      Posté par  . Évalué à 5.

      pourquoi

      Parce qu'on ne choisit pas un langage uniquement pour ses performances.
      Mais aussi pour

      • l'infrastructure proposé
      • la quantité/qualité des bibliothèques/framewroks proposés
      • le nombre de développeurs ayant la compétence
      • les objectifs pour lequel il a été conçu (PHP => Html)
      • etc.

    • [^] # Re: si je resume

      Posté par  . Évalué à 0.

      Par contre je n'ai jamais compris pourquoi ils ne sont pas simplement passé pluq tot à un autre langage.

      Pour pas réinventer la roue ?

      • [^] # Re: si je resume

        Posté par  . Évalué à 1.

        Si j'ai bien compris, ils ont une base de code énorme en PHP (qui se chiffre en millions de lignes) parce qu'ils ont commencé avec (startup, quick and dirty, etc.). Réécrire tout ça dans un autre langage prendrait énormément de temps et d'efforts, du coup ils font ce qu'ils peuvent pour rendre PHP plus utilisable (pour les perfs, mais aussi pour la correction du programme avec de l'analyse statique tout ça).

        Si les devs facebook devaient tout refaire de zéro, je doute qu'ils feraient les mêmes choix :)

        The cake is a lie.

        • [^] # Re: si je resume

          Posté par  . Évalué à 3.

          Je trouve dommage de Zukerberg n'ai pas utilisé perl qui est bien plus polyvalent que PHP et qu'il semble qu'il connaît.

          Troll : peut être que facebook contribuerait à Perl6 aujourd'hui :)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Peu chiffré et partiellement faux

    Posté par  . Évalué à 10.

    Ce n'est pas la faute de l'auteur de la dépêche, mais l'histoire des "90% de mémoire en moins" est fausse:

    Due to an error on the part of The OutCast Agency, Facebook’s PR agency, this article originally stated incorrectly that HHVM provided a ”90 percent reduction in memory cost” over Facebook’s existing HipHop interpreter. The agency sent us this incorrect information based on an early unpublished draft of Facebook’s post on HHVM that was later corrected by Facebook’s engineers.

    Par ailleurs, comme le souligne spider-mario, les 60% de performances en plus sont par rapport à l'interpréteur HipHop. Ça ne dit rien en soit des performances par rapport à l'implémentation PHP officielle ou aux autres implémentations se voulant plus performantes.
    En gros cet article permet de savoir que les gens de Facebook améliorent leur solution interne, mais ne dit rien de ses performances dans l'absolu.

  • # Du code

    Posté par  . Évalué à 2.

    Ça fait plaisir de voir que Facebook peut finalement servir à quelque chose.

    Personnellement je pense trouver une application à cet outil.

    • [^] # Re: Du code

      Posté par  . Évalué à 10.

      Facebook a contribué quelques briques sympas: Cassandra, Hive, Thrift, tornado (libéré suite au rachat de FriendFeed) et ils sont des gros contributeurs à MySQL, memcached, hadoop et php, sans oublier les nombreux mirroirs hébergés chez eux: http://mirror.facebook.net/

      Ils sont pas totalement inutile, même si ils ne sont pas éthique.

  • # Pfff

    Posté par  (site web personnel) . Évalué à 6.

    Et signalons Pfff qui permet de faire de l'analyse statique de code php (et autres langages)
    Ecrit en Ocaml.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Pfff

      Posté par  (site web personnel) . Évalué à 7.

      Et le prochain outil qu'ils vont libérer, ils vont l'appeler pBpGG

      • [^] # Re: Pfff

        Posté par  . Évalué à 2.

        Ou pMpZ :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.