metagoto's blog

Beaucoup de choses ont été dites à propos du truc révolutionnaire que facebook nous préparait pour php. Les spéculations sont allées bon train. On a eu droit à du JIT (très en vogue actuellement, notamment grace à LLVM), une réécriture du runtime de php, j'en passe et des meilleurs.

Finalement, l'info officielle est tombée le 2 fev via un post du lead developer en personne, Haiping Zhao. Inutile de vous dire que ce mec là, aux allures très sympathiques par ailleurs, va être soit adulé soit haï par toute la communauté php, du simple rédacteur de templates aux membres les plus influents du PHP Group.

OK. Donc le truc s'appelle HipHop for PHP (lien de github, qui n'existe pas encore à cet instant précis). Je ne vais pas revenir sur ce que l'on apprend à partir du post officiel de Haiping. Pour ça, je vous conseille ces deux billets en fançais ou encore celui là.

Maintenant, que pouvons-nous dire d'autre sur HipHop? Tout d'abord, j'ai comme l'impression que le code source ne sera pas divulgué de si tôt contrairement à ce que l'on pouvait attendre d'après le post officiel (en fait, j'espère que je me goure). HipHop et toute sa suite doit être une usine à gaz, tout du moins sous sa forme actuelle, c'est à dire spécifique à facebook. Voir les interventions de Scott MacVicar et Haiping Zhao ici et ici sur le google group du projet. HipHop utilise CMake comme build system. SCons ça l'aurait mieux fait quand même!

Ensuite, comme attendu, toutes les extensions de php (standard et tiers) doivent être réécrites. Haiping dévoile une liste du travail déjà accompli. Un peu plus bas dans cette même thread, on apprend que PDO sera supporté, tout du moins l'interface pour les quelques drivers les plus utilisés. Je n'ose pas imaginer le chantier que ça doit être. Un travail de forçat. Toujours plus bas, il parle d'une extension memcache maison qui devrait également être mise à disposition du public (avide de sensations fortes?).

Pour ceux qui ne dorment plus depuis l'annonce du non support de eval() dans HipHop: lâchez les calments et les somnifères, la fonction est déjà implémentée et fonctionne en partie via HPHPi (l'interpreter). Inutile de dire qu'il vaut mieux s'en passer et qu'il n'a pas fallu attendre HipHop pour ça! Même chose concernant create_function('with literal string'), c'est bon, ça fonctionne.

Autres goodies, et non des moindres car potentiellement très utile: FFI ou comment générer des librairies statiques et dynamiques (.a et .so) à partir de sources php pour un interfaçage avec d'autres langages (apparement avec SWIG). Source. Imaginons que ça fonctionne bien. Putain, ça le fait carrément!

Personnellement, j'attends avec impatience la release du projet, et je suis parfaitement détendu, probablement parce que je n'ai rien à perdre ni à gagner: je ne suis pas un développeur php ;) J'imagine une certaine angoisse latente chez les responsables de frameworks (Symfony, Drupal etc). Est-ce que ça va compiler? Dans quelle proportion va-t-on devoir réécrire notre code? Qui est le connard qui a insisté pour utiliser eval()? J'ai comme l'impression que certaines roadmaps vont subir quelques légers bouleversements...

En tout cas, je note une chose: C++, tu es vraiment le meilleurs ;)

A tous les abonnés du flux et les intrépides qui utilisent encore leur browser pour se rendre sur des sites, non, je n'ai pas oublié qu'il faut que je fasse la partie 2 après avoir publié la partie 1 sur les extensions php.

En parlant d'extension, SplClassLoader a fait son petit buzz sur twitter... enfin, je me comprends. Moi qui suis un noob de twitter, j'ai pu assister aux razias de bots et autres api sniffers qui déferlent sur ce site dès qu'un tweet est balancé ou RT. On n'arrète pas le progrès. Toujours est-il que j'ai obtenu un accès au PHP Standards Working Group mais j'ai comme l'impression que les protagonistes s'en foutent (et c'est leur droit). C'est juste histoire de clarifier les choses puisque par ailleurs certains me poussent pour que l'extension fasse son entrée sur PECL. Mais en tant qu'outsider, ma philosophie c'est plutôt du style "démerdez-vous" ;)

Ressortir les vieux projets des cartons, d'habitude, je déteste ça. Toujours est-il qu'à mes heures perdues, je suis actuellement en train de réécrire une extension php (encore?) qui embarque V8, le fameux moteur javascript de google. Son api est en C++, l'extension est en C++. J'ai viré une dependance initiale à la libraire boost pour simplifier l'installation (au cas où quelqu'un daigne s'y pencher). J'en reparlerai un de ces 4.

Voilà, maintenant vous savez tout. Non, en fait, vous ne savez rien mais c'est pas grave.

UPDATE (2010-01-09T22....Z): a small change (yet to be properly benchmarked) yields linear performance gains: the extension brings about 30% more RPS than the user code in all tests. /UPDATE

Ok, the C implementation of SplClassLoader is here on github. I am afraid I won't have much time in the coming days to follow what is going on. Anyway I took the time to do some benchmarks with ApacheBench. I will present the results in this post.

In order to ease things, I wrote a python script that generates a dummy directories subtree filed with php files containing blank classes with their proper namespace. The script also generates a php file named batch_instances.php (by default) which is responsible for instantiating all the generated classes in a row. It looks like that:

$a = new \vendor0\AA;
$a = new \vendor0\AAA;
$a = new \vendor0\B_B;
$a = new \vendor0\B_BB;
$a = new \vendor0\sub0\AA;
$a = new \vendor0\sub0\AAA;
...
$a = new \vendor1\sub0\AA;
$a = new \vendor1\sub0\AAA;
...
$a = new \vendor1\sub1\sub1\AA;
$a = new \vendor1\sub1\sub1\AAA;
$a = new \vendor1\sub1\sub1\B_B;
$a = new \vendor1\sub1\sub1\B_BB;

That php file is then included for the various benchmarks. The python script (fs_gen.py) is located under tests/for_bench but it is not integrated with the extension tests suite.

Setup

• MacBook Pro 2.53ghz 4gb ram
• nginx 0.8.27
• PHP_5_3_FPM trunk compiled with --disable-all --enable-maintainer-zts. Unix sockets.

Note: APC was not loaded (nor any other accelerator.. I would have to install it btw).

Protocol

I did 3 kind of tests:

• SplClassLoader() used without namespaces nor path arguments. We have to configure the include_path.
• SplClassLoader('vendorN') where N goes from 0 to 3 at maximum. It means we have several 'vendor' namespaces. Note that the second argument (the path) is not passed to the constructor.
• SplClassLoader('vendorN','/pathN') where the path is absolute. The php include_path is not used.

For example, the second test bootstrap file looks like this:

<?php
// 'vendorN' directories are under lib/
set_include_path(
   __DIR__.PATH_SEPARATOR
  .__DIR__.DIRECTORY_SEPARATOR.'lib'.PATH_SEPARATOR
  .get_include_path() // mine is empty btw
);

$v0 = new SplClassLoader('vendor0');
$v0->register();

$v1 = new SplClassLoader('vendor1');
$v1->register();

include 'batch_instances.php';

Since both implementations declare the same class SplClassLoader be it a user script or an extension, the php implementation has been renamed to SplClassLoaderUser.

I noted each result returned by ApacheBench. For each test, a few warm ups then 10 runs in a row. Results in the following tables are in requests per second. Also, the lowest and the highest numbers were removed prior calculating the mean.

The exact arguments passed to ab are not known at that time ;) Depending on the number of classes loaded, sometimes it was -n 3000 or -n 1000 but always -c 1 and of course always the same for a given test.

Results

24 classes under a unique 'vendor0' namespace containing several sub namespaces:

        test 1     test 2      test 3
        simple     with ns     with ns+path

user    496        429         449
ext     554        543         576
ratio   1.117      1.266       1.282

70 classes under two namespaces containing several sub namespaces:

        test 1     test 2      test 3
        simple     with ns     with ns+path

user    221        182         192
ext     232        228         246
ratio   1.050      1.252       1.281

Note: there were no underscore characters in the classes names used for the above bench.

126 classes under two namespaces containing several sub namespaces:

        test 1     test 2      test 3
        simple     with ns     with ns+path

user    119         99         104
ext     126        124         133
ratio   1.059      1.253       1.279

Conclusions

Results are indeed extremely regular. In fact I performed several other tests with different directories layouts but ratios were roughly the sames.

Internally, the C implementation does nothing more than the php implementation. spl_autoload_register() is called through the Zend Engine. There is no magic door. When more computations are involved as in the test number 3 (comparing namespaces and appending paths) the C implementation is ahead.

In fact these numbers suggest that we better have to pass both a namespace and an absolute path to the SplClassLoader constructor when using the extension. On the contrary the php implementation performs better with no argument at all, ie. no namespace comparison. Low level string manipulations are faster in C. All in all, both implementations call include() through the ZE.

One advantage of course concerning the extension is that the class is registered at module initialization (MINIT). The class remains in the engine between requests (if the sapi allows it).

PS. Why did I write that extension? I was looking for a simple (no dependencies) extension to illustrate a tutorial I am supposed to write (second part) for this blog (in french). I came up with SplClassLoader but I am by no way a ZE specialist.

Intro:

Qui n'a jamais rêvé de ces mondes souterrains, de ces mers lointaines peuplées de légendes ou d'une richesse soudaine qui se conquérerait au détour d'un chemin de la Cordillière des Andes ?

Okee. En fait je voulais juste dire qu'aujourd'hui on va débuter une série d'articles (probablement entrecoupés de conneries à 2 balles) dont la futile existence consiste à vous apporter les bases nécessaires pour que -un jour peut être- vous soyez en mesure d'écrire votre propre extension php en C ou C++.

Inutile de tergiverser, nous allons nous focaliser sur un environnement UNIX. Bien que de gros efforts ont été faits, développer sous Windows pour PHP est encore légèrement chiant, notamment lorsque l'on fait intervenir des librairies tierces. Néanmoins, je ne dis pas que -par chance- il se peut que un jour -par hasard- je complète la série avec un article focalisé sur Windows.

Si tout s'est bien passé, le titre parle d'installation du matos

Il nous faut:

• Les sources de php
• autoconf, automake, libtool, bison
• GCC

En fait je pense que c'est à peu près tout. De toute façon, si ce n'est pas suffisant, on le saura: ça va merder. Plus tard, on pourra ajouter re2c lorsqu'on abordera (qui sait?) la customisation de la grammaire de php, par exemple autoriser la syntaxe courte pour les array [1,2].

Votre distrib linux contient probablement déjà tout le nécessaire. Si ce n'est pas le cas, vous pouvez surement installer ces tools via le système de packages ou directement via les sources. Ca fonctionne généralement très bien. Sous OSX, il faudra que vous installiez les developer tools c.a.d. Xcode et sa suite, mais rassurez vous, nous n'aurons pas besoins de le lancer.

Voici ce que nous allons faire: On va compiler et installer une version de php qui sera dédiée pour nos expérimentations. Notre extension php sera compilée avec les sources de cette version fraichement installée. Dans un premier temps, nous utiliserons exclusivement la version CLI de php: plus simple à mettre en oeuvre, notamment pour les tests.

Organisation des fichiers

On va bosser chez nous. Nul besoins de polluer /usr, NUL BESOINS D'ETRE ROOT.

$HOME/                <-- /home/machin ou /Users/machin etc
     vrac/            <-- tout sera ici
         php-5.3.1/   <-- les sources de php
         php/         <-- là où sera installé php
         phpext/      <-- le répertoire de nos extensions
               part1/ <-- la première extension

Choper et compiler les sources de php

Ca se passe ici. Je prends PHP 5.3.1 Complete Source Code en tar.gz.

$ cd ~/vrac
$ wget http://fr.php.net/get/php-5.3.1.tar.gz/from/this/mirror

Une fois les sources téléchargées, une petite vérif qui va bien:

$ md5sum php-5.3.1.tar.gz
41fbb368d86acb13fc3519657d277681  php-5.3.1.tar.gz

Sous OSX, si vous n'avez pas installé GNU Coreutils, ceci devrait fonctionner:

$ md5 php-5.3.1.tar.gz 
MD5 (php-5.3.1.tar.gz) = 41fbb368d86acb13fc3519657d277681

OK. C'est bon. On extrait le tarball compressé:

$ tar zxf php-5.3.1.tar.gz
$ cd php-5.3.1

Avant de compiler php, passons rapidos en revue ce que contiennent les sources:

configure <-- configure et génère les Makefile
ext/      <-- les extensions (core et optionnelles)
main/     <-- les sources "basiques" de php (IO, networks...)
sapi/     <-- Server Application Programming Interface (cli, cgi, apache..)
tests/    <-- les fichiers de tests (make test)
TSRM/     <-- Thread Safe Resource Manager
win32/    <-- trucs spécifiques à Windows
Zend/     <-- le Zend Engine (gestion mémoire, opcodes etc)

On va compiler et installer une version ultra light de php cli. Pour voir la liste des options de compilations:

$ ./configure --help

Ce qui nous intéresse est ceci:

$ ./configure --prefix=$HOME/vrac/php \
  --with-config-file-path=$HOME/vrac/php \
  --disable-all --enable-cli

Ensuite, si tout s'est bien passé, les dernières lignes doivent ressembler à ça:

Generating files
updating cache ./config.cache
creating ./config.status
creating php5.spec
creating main/build-defs.h
creating scripts/phpize
creating scripts/man1/phpize.1
creating scripts/php-config
creating scripts/man1/php-config.1
creating sapi/cli/php.1
creating main/php_config.h
creating main/internal_functions.c
creating main/internal_functions_cli.c
+--------------------------------------------------------------------+
| License:                                                           |
| This software is subject to the PHP License, available in this     |
| distribution in the file LICENSE.  By continuing this installation |
| process, you are bound by the terms of this license agreement.     |
| If you do not agree with the terms of this license, you must abort |
| the installation process at this point.                            |
+--------------------------------------------------------------------+

Thank you for using PHP.

On enchaine avec un grand classique:

$ make

La compilation est rapide puisque notre configuration est très light. Encore une fois, si tout est OK, on doit voir un truc du genre:

Build complete.
Don't forget to run 'make test'.

Avant d'installer les fichiers, on obtempère en lançant les tests. Ca ne coute rien. A si, ça coute pas mal de temps. C'est bien plus long que la compilation...

$ make test

Là sur ma machine, j'obtiens ceci:

=====================================================================
TEST RESULT SUMMARY
---------------------------------------------------------------------
Exts skipped    :   71
Exts tested     :    7
---------------------------------------------------------------------

Number of tests : 10899              5974
Tests skipped   : 4925 ( 45.2%) --------
Tests warned    :    0 (  0.0%) (  0.0%)
Tests failed    :   28 (  0.3%) (  0.5%)
Expected fail   :    6 (  0.1%) (  0.1%)
Tests passed    : 5940 ( 54.5%) ( 99.4%)
---------------------------------------------------------------------
Time taken      :  306 seconds
=====================================================================

La plupart des tests non skippés sont passés (99.4%). C'est bon. S'il y avait eu un sérieux problème, comme ça m'est déjà arrivé, c'est l'ensemble des tests qui auraient échoué.

On continue en installant les fichiers. Rappellez-vous, il seront installés dans $HOME/vrac/php. Encore une fois, pas la peine d'être root puisque nous restons dans notre home.

$ make install

OK, les fichiers ont normalement été installés dans $HOME/vrac/php. Sous OSX, php cli est nommé php.dSYM. On va le renommer en php. Sans changer de répertoire (toujours sous php-5.3.1), on fait:

$ mv ../php/bin/php.dSYM ../php/bin/php

Pour être sur que toute cette daube fonctionne, quoi de mieux que de tester notre php fraichement installé?

$ $HOME/vrac/php/bin/php --version
PHP 5.3.1 (cli) (built: Dec 26 2009 22:32:35) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

Si vous n'obtenez pas quelque chose de fortement similaire, alors il y a un prob! Je conseillerai dans ces cas là de prendre un café et une clope, puis de reprendre à zéro. Pour rappel, quand on est dans php-5.3.1 ceci permet de cleaner le chantier:

$ make clean

Ne pas hésiter à checker par 3 fois les paramètres passés à configure.

RAS pour php. (N)ext

Ce premier billet ne s'occupe que de l'installation des trucs nécessaires. Nous allons tout de même compiler une extension absolument bidon et la tester via le système de tests fourni par php. Ca nous sera utile pour la suite. Les sources sont sur github. A vous de vous démerder pour que part1 soit placé dans $HOME/vrac/phpext. Ceci fonctionne:

$ cd ~/vrac
$ git clone git://github.com/metagoto/phpext.git

Comme vous pouvez le voir, les sources de cette extension nommée part1 sont en dehors du source tree de php. On va donc utiliser le tool phpize que nous venons juste de compiler: ce dernier se charge de créer un fichier configure pour notre extension.

$ cd ~/vrac/phpext/part1
$ $HOME/vrac/php/bin/phpize 
$ ./configure --with-php-config=$HOME/vrac/php/bin/php-config

Ensuite, on build, mais on n'installe pas car ça ne sert à rien pour ce qu'on veut faire.

$ make
...
Build complete.
Don't forget to run 'make test'.

Et on ne lance pas les tests! Tout du moins, on ne va pas faire ce qui nous est proposé. Pour tester notre extension, la commande utilisée est plus subtile.

Tester une extension

Le lecteur consciencieux aura remarqué la présence d'un répertoire part1/tests. Dedans y figure un misérable fichier nommé 001.phpt. Ce dernier est au format compatible avec le lanceur de tests de php qui par chance a été créé lors de notre précédent appel à ./configure. Ce fichier est nommé run-tests.php.

Aussi, si tout s'est bien déroulé, notre extension compilée a été placée dans le répertoire part1/modules sous le nom part1.so. Il va donc falloir que php charge cette extension puis lance l'unique test 001.phpt. Nous sommes toujours dans le répertoire part1. La commande est la suivante:

$ TEST_PHP_EXECUTABLE=$HOME/vrac/php/bin/php \
  $HOME/vrac/php/bin/php run-tests.php \
  -d "extension=$HOME/vrac/phpext/part1/modules/part1.so"

Là le test est immédiat. Si ça passe, et ça DOIT:

=====================================================================
PASS part1 test [tests/001.phpt] 
=====================================================================

Maintenant, que fait la commande bizarre que nous venons d'exécuter ? En gros, on exécute le fichier run-tests.php avec notre php. Habituellement, ce fichier est lancé via un make test. Sauf que là nous ne sommes pas dans un source tree de php, nous sommes dans le source tree de notre extension. run-tests.php a besoins de savoir explicitement quel est l'exécutable utilisé pour les tests, c'est pourquoi on définit la variable TEST_PHP_EXECUTABLE. Aussi, nous voulons que php charge notre extension. C'est chose faite en passant l'argument -d qui permet de définir un couple clé/valeur au format ini.

Mais qu'y a-t-il dans part1/tests/001.phpt? Ceci:

--TEST--
part1 test
--SKIPIF--
<?php if (!extension_loaded('part1')) die('part1 not loaded'); ?>
--FILE--
<?php 
part1_test();
?>
--EXPECT--
test from part1

Ca me parait assez explicite. Le test est skippé si l'extension part1 est absente. Oui c'est notre extension! Le test à proprement parler consiste à exécuter la fonction part1_test(). Il s'agit de la seule fonction exportée de notre extension. Cette fonction se contente juste de faire l'équivalent d'un print 'test from part1'.

Dacodac. Nous avons maintenant en main les bases pour compiler, charger et tester des extensions php.

Pour moi c'est RAS.