La programmation au grand large
On a coutume de dire que le numérique en réseau va à la vitesse de la lumière. Cela impressionne et l’on pense qu’il y a là une réserve de vitesse telle que cela n’en fera jamais un obstacle au développement du numérique en réseau.
C’est pourtant le contraire qui se passe, d’abord parce que l’on est jamais vraiment à la vitesse de la lumière du fait des appareils de routage divers et variés qui tissent la toile (problèmes d’impédance notamment). Mais ce n’est pas cela qui pose réellement problème, ce sont plutôt les problèmes de latence qui ne viennent pas seulement des contraintes physiques du réseau mais de la distance à parcourir. Celle-ci est telle avec les logiciels distribués (logiciels ou composants logiciels qui dialoguent à distance, sur des machines pouvant être sur des continents différents) qu’elle devient un goulot d’étranglement dans les échanges de données de ces architectures logicielles.
Pour bien prendre la mesure de ce phénomène, comparons l’impact de la latence (temps de réponse) sur une architecture logicielle fictive qui doit faire des appels entre des serveurs situés à 30 000 km de distance. Avec une vitesse de la lumière à 300 000 km/s, il faut 0,1 s pour que les données de message passent d’un serveur à l’autre.
0,1 c’est rien du tout pensez-vous ? C’est énorme car il faut rappeler que, surtout en HTTP, le dialogue protocolaire a tendance à comporter de nombreux messages. Il faut également mettre ce temps de transport des données en regard de ce qui se passe du côté du processeur. Un simple processeur à 1Gz des années 90 tourne par définition à 10^9, soit un milliard de cycles par seconde : imaginez ce qu’un programme peut faire comme calculs en 1 s, et même en 0,1 s !
Si un serveur est en “attente” d’une donnée qui va mettre 0,2 s pour être requettée puis reçue, c’est pas moins de 200 millions de cycles d’horloge du processeur qui sont à jamais inutilisées et perdues. Certains en déduisent que chaque développeur devrait connaître un certain nombre de données factuelles sur les temps de latence.
A cette question de latence des architectures logicielles distribuées se surajoute celle de l’efficience énergétique du code. Ce dernier point peut se poser avec une certaine stupeur pour un développeur à qui on demanderait s’il connaît non seulement l’importance de la latence dans son code mais encore combien d’énergie il va consommer en passant en “production”. Il n’en a aucune idée, et pourtant ces questions commencent à se poser avec l’optimisation des grands DataCenter d’une part et avec la croissance des appareils mobiles fonctionnant sur batterie.
Après la crise des multicoeurs qui fait que les développements logiciels doivent utiliser des techniques de parallélisation, se rajoute maintenant la prise en compte de la latence et de l’efficience énergétique du code. Ce sont ces contraintes industrielles et physiques qui surdéterminent les modes et les évolutions des pratiques de programmation : langages fonctionnels, bases NoSQL, code on demand, websocket, HTTP 2.0, etc.
On peut rappeler que Charles Bennet et rolf Landauer on montré que c’est l’effacement de la mémoire qui a un cout thermodynamique autrement dit un cout entropique.
[Reply]