Si vous suivez ce blog, ces derniers temps vous aurez vu quelques posts sur Erlang, le langage utilisé par Ericsson pour son matériel téléphonique et utilisé pour l’implémentation la plus performante du protocole de messagerie XMPP.
L’idée de ce post m’est tombée dessus assez rapidement, et ces derniers temps, j’ai l’impression de voir beaucoup de problématiques exposées dans d’autres langages qui sont résolue de facto par l’architecture du langage.
Deux exemples de ce mois-ci :
Adéquation avec l’orientation du hardware
Jusqu’à récemment les développeurs pouvaient se cacher derrière la loi de Moore pour garantir que leur application fonctionnerait toujours mieux. Si elle est un peu lente à sa sortie, dans 1 an, elle ira beaucoup plus vite, parce que le hardware aura (presque) doublé au niveau des performances. Mais c’est fini. La course à la puissance a lieu en multipliant le nombre de coeurs sur un processeur. Puissance qu’on ne peut récupérer que si on développe en parallélisant notre code. Ce qui pose des problèmes dans tous les domaines de l’informatique. En particulier les jeux. Comme le dit Tim Sweeney, le lead developer d’Unreal :
“Implementing a multithreaded system requires two to three times the development and testing effort of implementing a comparable non-multithreaded system, so it’s vital that developers focus on self-contained systems that offer the highest effort-to-reward ratio.”
Pour ceux qui ne lisent pas l’anglais, il faut 2 à 3 fois plus d’efforts pour mettre en place un système multithread. Les jeux ne sont pas réellement le point de ce post, mais je veux mettre le doigt sur la difficulté de maximiser l’utilisation de la puissance des processeurs actuels (dual-core ou plus).
A un niveau plus élevé, l’approche utilisée par Google et par tous les autres depuis 2000 n’est plus d’acheter un serveur incroyablement puissant (et cher), mais plutôt de prendre des serveurs peu chers (relativement peu puissants). Si j’ai besoin de plus de puissance, j’ajoute des serveurs. On peut même virtualiser complètement les serveurs en allant chez Amazon avec leur service Elastic Computing Cloud (EC2), qui permet d’obtenir une puissance de calcul virtuellement illimitée en parallélisant un grand nombre d’instance.
La grande orientation !
La solution proposée dans les deux articles précédent est toujours la même :
On arrête avec les threads et la mémoire partagée. Du coup si les unités de traitement ne partagent rien, on est plus obligé de synchroniser l’accès.
La transmission d’information se fait par passage de message, IPC-style.
C’est très exactement le schéma proposé par l’article que je citait plus haut :
Nouveau patterns et middleware pour une scalabilité linéaire.
Les avantages de cette approche sont bien détaillées dans l’article de Joe Armstrong l’architecte et concepteur d’Erlang.
La scalabilité par les applications Erlang est quasiment linéaire (J’ai un CPU, la puissance totale vaut 1, j’ajoute un autre CPU la puissance totale vaut presque 2, et non pas 1,66 avec d’autres architectures qui perdent de temps en synchronisation)
L’exemple donné ici, une simulation de colonie de fourmis, le montre plutôt bien.
On note que les performances d’Erlang sont largement inférieures à Haskell, mais lorsque l’application passe d’un simple core à un dual core, le temps d’exécution est divisé par deux.
Le langage est facile
Le langage est facile, oui, une fois qu’on saisi les grands concepts du langage, on comprend rapidement le code source. J’ai passé quelques temps à parcourir le code source d’ejabberd, et on rentre dedans très facilement, malgré le peu de commentaires dans le code.
Evidemment, le seul mérite ne revient pas uniquement au langage, mais évidemment aux développeurs d’ejabberd, qui ont une base de code très claire et dont le style m’apprend beaucoup sur le langage.
Je remarquai la dernière fois que le code d’ejabberd est 3 fois plus compact que le code d’OpenFire. Il faut remarquer toutefois que le code d’OpenFire est bien mieux documenté :)
Mais le langage n’est pas orienté objet ?
Bien que Joe Armstrong s’en défende, il est orienté objet, en utilisant le modèle de l’Acteur, avec des objets (les processus) qui s’envoient des messages.
Certes, il n’y a pas d’héritage de classe et autres habitudes architecturales de l’orienté objet, mais c’est de l’objet. Le post de Ralph E. Johnson (oui, l’un des quatre du Gang of Four) l’explique avec beaucoup de détails.
Au passage, Johnson fait le calcul de la fiabilité des neuf 9 (99,999999% d’uptime) obtenu par le AXD 301 d’Ericsson (celui aux 1,7 millions de ligne de code d’erlang). C’est 1 seconde de downtime tous les 30 ans !
Et de toute manière, le faisait remarquer A. Zaidi sur son blog, faire de l’objet à tout prix, en particulier dans le développement d’application web (ou plus généralement de serveurs basé sur des protocoles texte, comme tous les protocoles internet), est-ce tellement pertinent ?
Finalement on récupère du texte, qu’on case dans des objets, et qu’on stocke ensuite dans une base de donnée relationnel, il faut donc re-marshaller les données pour qu’elles puissent rentrer. Typiquement le genre de truc qui contribue au réchauffement planétaire.
NB : Ok, c’est un peu extrême. J’apprécie certes le modèle objet, mais lisez le post de A. Zaidi : Zen and the Art of Functional Programming.
Best Kept Secret ?
Erlang n’a pas le mindshare de Java et de Ruby et de leurs frameworks phare respectif.
Toutefois, ce langage a résolu dans son coin, là-bas, dans le nord, il y a dix ans, les problèmes de montée en charge qu’affronte les grandes applications d’aujourd’hui.
La publication de Programming Erlang chez Pragmatic Programmer semble être un succès. Et PragDave fait des tutoriaux sur son blog.
Il faut donc s’attendre à un accroissement du nombre de développements dans ce langage.
Il y a déjà une première application publique développée avec le framework ErlyWeb dont je parlais ici : http://beerriot.com/ qui fonctionne aussi en application sur FaceBook.
Le blog de ce dernier est intéressant, en particulier Erlang Observations et FaceBook Development (in Erlang) sur le sujet.
Depuis la mi-avril, la famille était à Bonny/Loire, joyeuse bourgade du Loiret.
Pour la deuxième fois, je fais les poubelles d’
