Romain Rouvoy : « Réduire la consommation énergétique des logiciels »

Vous vous intéressez au développement logiciel durable, pouvez-vous nous décrire de quoi il s’agit ?

Romain Rouvoy : Nous avons tous constaté dans notre quotidien que nos appareils, par exemple nos smartphones, sont de plus en plus puissants, mais aussi de plus en plus gourmands en énergie. Les constructeurs font des efforts pour essayer de réduire la consommation des composants électroniques, mais on s’est peu occupé pour l’instant de la consommation des logiciels. Imaginez l’efficience d’une voiture intégrant la dernière génération de R&D pour consommer le moins possible, avec un conducteur qui passe ses vitesses n’importe comment ! 
Je travaille donc sur l’axe logiciel pour qu’il soit plus économe, qu’il puisse ajuster sa consommation énergétique suivant le contexte dans lequel il se trouve. Nous jouons sur l’ensemble des phases du cycle de vie du logiciel, pas uniquement lors de son développement, mais depuis sa conception jusqu’à son exécution. Nous étudions les différents leviers d’optimisation logicielle que l’on peut appliquer dans chacune de ces phases pour réduire de manière efficace la consommation énergétique. 

Tout d’abord, pour savoir si nous avons optimisé un logiciel et en quantifier le bénéfice, il est important de pouvoir en observer la consommation avec précision. Nous travaillons donc sur une forme de wattmètre virtuel, PowerAPI, qui permet de mesurer la consommation de chaque logiciel qui s’exécute sur une machine, afin de savoir par exemple quelle application arrêter en priorité quand on n’a plus de batterie. 

Grâce à PowerAPI, nous avons pu mettre en évidence l’importance du choix du langage de programmation dans la consommation d’un logiciel en production. Pour une même application, un langage interprété comme Python consomme 100 fois plus qu’un langage compilé comme Java. C’est d’autant plus inquiétant que la tendance actuelle est que le Python, comme le JavaScript, s’emploient de plus en plus sur les serveurs applicatifs. Nous alertons donc les DSI pour souligner que le coût de la consommation en production est un critère à prendre en compte par rapport à un langage à la mode. Nous avons également pu mettre en évidence des différences notables entre deux langages du même type. Par exemple, pour les langages compilés orientés objets, Java consomme moins que C++ par défaut.

Au-delà de la conception du logiciel, quel impact pour la suite ?

R. R. : Le constat d’une consommation énergétique de plus en plus importante est aussi vraie pour les data centers qui stockent les informations du cloud. Nous travaillons sur des leviers pour réduire cette consommation, en recyclant notamment les ressources. Il faut savoir que dans le cloud computing, quand vous payez pour utiliser un service, on vous alloue, au travers de machines virtuelles, des ressources de calcul et/ou de stockage qui doivent rester disponibles même si vous ne les utilisez pas. Quand toutes les ressources sont allouées, pour le moment, la seule solution est d’installer de nouvelles machines. Notre 1er levier consiste donc à prédire quand les machines sont utilisées, pour pouvoir mieux les exploiter le reste du temps. Pour cela, nous déterminons les périodes d’utilisation des machines (chaque matin de la semaine, le week-end, la nuit…) pour libérer les machines et les ressources au profit d’usages alternés avec d’autres utilisateurs aux besoins complémentaires. 

On sous-exploite aussi les ressources des machines. Très souvent, on alloue une ou plusieurs machines pour exécuter des tâches logicielles sans tenir compte du fait que ces machines sont constituées de ressources très différentes : le processeur pour supporter l’exécution du logiciel, le réseau pour échanger les données, la mémoire pour les stocker et le disque pour les enregistrer de manière pérenne. Pour l’instant, dans un data center, si les tâches d’un logiciel épuisent une seule ressource d’une machine, par exemple le CPU, on ajoute une seconde machine, mais sans exploiter le reste des ressources de la première. Notre 2e levier consiste donc à faire en sorte que toutes les ressources soient utilisées de manière appropriée. Pour cela, nous inférons les profil des logiciels en termes d’utilisations des ressources : on les laisse s’exécuter pour observer leur fonctionnement, et permettre un apprentissage non-supervisé de leurs profils. Une fois ces profils constitués, il est possible de mieux réordonnancer les tâches logicielles sur les machines pour qu’elles soient utilisées au maximum de leur capacité. 

On observe aussi une explosion de la consommation énergétique des serveurs. C’est quelque chose qui est étudié depuis longtemps dans des environnements plus contraints comme les smartphones ou les réseaux de capteurs. Dans ce cadre-là, la problématique est un peu différente : on joue notamment sur l’accès à un certain nombre de capteurs. Pour les smartphones par exemple, essaye d’utiliser les capteurs de manière plus intelligente : au lieu que chaque application se serve d’un capteur, nous essayons que l’information produite soit partagée entre différentes applications. Les GPS sont particulièrement gourmands et nous nous efforçons de modéliser leur utilisation pour jouer sur la façon dont ils accèdent aux capteurs. Par exemple, si l’on constate que l’application de navigation en voiture est utilisée quotidiennement pour un trajet vers la maison, on peut en déduire que ce sont les informations de trafic qui sont intéressantes et qu’il n’est pas nécessaire de donner une position exacte du véhicule si une position estimée produit la même qualité d’expérience. On produit ainsi une information un peu dégradée en consommant beaucoup moins. Pour étudier ces principes, nous avons mis en place une plate-forme de mobile crowd-sensing, appelée APISENSE®, qui permet de collecter des données des smartphones des personnes volontaires pour en observer la consommation à des échelles beaucoup plus représentatives que les tests que nous menons en laboratoire.