On estime que le numérique mondial représente aujourd’hui environ 4% de la quantité de gaz à effet de serre émise sur la planète. Il est en augmentation constante. Ce chiffre regroupe l’ensemble de la production du hardware (de vos smartphones, ordinateurs, écrans, etc.), des data centers, de l’énergie pour les alimenter et du réseau.
Alors que l’on entend souvent qu’il faut, à juste titre, faire attention aux nombreux de gadgets que nous achetons, pouvons-nous agir à notre niveau en tant que développeur en faisant plus attention à notre code ? Ne pouvons-nous justement pas éviter que les gens renouvellent trop souvent leurs smartphones grâce à une optimisation de notre code ?
Nous verrons dans cet article, sous l’axe principal d’une application web, quelles sont les principales sources de consommation d’énergie. Nous allons alors découvrir comment évaluer chacune des parties et comment penser son code potentiellement différemment pour le rendre plus efficient. Rendre son code plus « green » implique de penser autrement.
revue d’une application distribuée et des sources d’énergie
Dans le cas d’une application distribuée, comme une application web, il y a de manière assez évidente 3 consommateurs d’énergie : le serveur qui stocke les données & services, le client qui consomme cette application et bien entendu le réseau pour faire discuter l’ensemble.
Commençons par regarder l’hébergement de votre code. Si vous choisissez l’un des grands fournisseurs de « Cloud », il y a de fortes chances que ces derniers aient déjà fortement optimisé leur empreinte carbone. Pour cela, ils automatisent beaucoup les opérations et surtout utilisent de l’énergie dite « propre », la plus décarbonée possible. Le choix du meilleur fournisseur est donc déjà assez structurant. Ensuite, le pays que vous allez choisir pour héberger votre code va également avoir un impact !
Pour cela, je vous invite à vous rendre sur le site : electricityMap qui permet de visualiser l’intensité carbone de chaque pays en temps réel, en fonction du mode retenu de production.
En France, notre production d’électricité est principalement nucléaire et donc basse en carbone. À l’inverse, en Allemagne, il y a un fort usage du charbon fortement émetteur de pollution. Vous voyez donc que dans la mesure du possible, il vaut mieux privilégier la France comme hébergeur que l’Allemagne. Bien sûr, il faut également prendre en compte l’emplacement géographique des potentiels clients et la latence réseau éventuelle, mais vous voyez l’idée.
Ensuite, vous pouvez bien entendu agir sur votre code pour réduire sa consommation d’énergie sur le serveur et donc son empreinte. Le Cloud Computing fut une invention extraordinaire pour nous les développeurs. Il nous permet de simplifier la gestion de l’infrastructure et de réagir vite grâce à son élasticité. Cependant, cette fausse impression de ressources infinies est un piège et peut amener les développeurs à être fainéants en optimisant moins leur code. Cela aura vite un impact, sur le prix bien entendu, mais également sur la planète.
Pour comprendre l’état d’esprit dans lequel il faut entrer pour agir à ce niveau, je vous invite à lire les 8 principes du génie logiciel durable : https://principles.green/fr-fr/
Passons rapidement maintenant sur le réseau. Ce dernier est assez intéressant. Déjà, il est loin d’être la source principale d’énergie des 3 revus ici. Par ailleurs, son coût a tendance à être fixe quelle que soit la quantité de données véhiculées. Pourquoi cela ? Tout simplement, que vous receviez 10 Mo/s chez vous avec votre fibre ou 1 Go/s, votre routeur, box, fibre vont consommer peu ou prou la même quantité d’énergie. Cela veut-il dire pour autant qu’il ne faut pas faire attention au réseau ? Bien sûr que non. Nous savons très bien qu’augmenter la charge réseau sur l’infrastructure va nécessiter la mise en place de davantage de routeurs pour éviter la congestion et de plus de matériels pour gérer l’augmentation du trafic.
Donc de manière ponctuelle, pour un utilisateur, la différence de trafic réseau est presque nulle énergétiquement parlant mais sur la durée, cela peut avoir de grosses conséquences. Si vous mesurez l’énergie consommée par le réseau dans votre app, vous aurez l’impression que cela n’a que peu d’importance alors que ce n’est pas forcément vrai.
Pour finir, il y a bien évidemment le client. C’est lui le plus gros consommateur d’énergie pour deux raisons : à cause des composants qui le constituent et le grand nombre de périphériques sur le marché. Les principaux composants consommant de l’énergie sur vos smartphones, tablettes et ordinateurs sont : le CPU, le GPU (processeur graphique), l’accès réseau et loin devant tous les autres… l’écran !
Dans ce graphique, on peut voir que le rétro-éclairage d’un écran LCD consomme presque autant que tous les autres composants réunis. Malheureusement, vous pouvez rarement jouer sur la valeur du rétro-éclairage depuis votre code. En revanche, un écran OLED consomme moins d’énergie sur une image noire que blanche. Donc vous pouvez jouer sur votre UX pour tenter de réduire un peu la consommation à ce niveau-là. Mais soyons honnêtes, les 3 composants qui vont être le plus impactés par votre code seront les processeurs et le réseau.
l’importance de la mesure
Tout cela est bien beau mais en tant que scientifique, nous devons certes émettre des hypothèses sur la consommation de notre code mais il faut pouvoir les vérifier en les mesurant.
Pour cela, il y a 3 approches à votre disposition :
- Un Wattmètre
- Des sondes branchées sur chacun des composants cibles
- Des modèles mathématiques, côté logiciel donc, construits à partir de mesures faites par les sondes
Le Wattmètre est assez peu coûteux (une vingtaine d’€) et assez ludique à utiliser. Le principe consiste à brancher votre PC ou périphérique mobile sur le wattmètre et de regarder de manière dynamique la consommation d’énergie évoluer en fonction du morceau de code que vous exécutez. À noter que sur un portable (ou smartphone), il faut absolument le faire avec la batterie chargée à 100%. Sinon, le Wattmètre va mesurer également l’énergie nécessaire pour recharger la batterie. Bien sûr, les mesures seront assez grossières et ne fonctionneront que sur des plages de temps d’exécution assez longues. Vous n’allez pas pouvoir optimiser un code consommant énormément d’énergie pendant quelques secondes seulement. Mais c’est déjà une première sensibilisation que vous pouvez faire pour vous former. À noter qu’il existe aussi des logiciels fournis avec les onduleurs vous indiquant votre consommation d’énergie comme sur mon UPS Pro :
Les sondes sont bien plus complexes à mettre en œuvre. Ce sont bien souvent des fabricants d’ordinateurs ou smartphones qui les branchent sur la machine à cœur ouvert pour obtenir des mesures très précises. La bonne nouvelle, c’est que certains en profitent pour construire un modèle mathématique à partir de toutes leurs mesures et les fournissent ensuite à travers de petits logiciels. On pourrait également envisager de faire du machine learning sur ces données.
Sous Windows, chacun des processus est analysé et ces fameuses données sont collectées pour établir la consommation moyenne de chacune des applications. On retrouve ce principe sur toutes les plateformes désormais, où vous pouvez connaître les applications qui consomment le plus le réseau mais aussi l’énergie.
En tant que développeur, vous pouvez mesurer la consommation de votre code / application avec l’outil utilisé par Windows : powercfg.exe. Vous trouverez comment vous en servir dans cet article : Measuring Your Application Power and Carbon Impact. Il vous donnera un rapport par tranche d’une minute de la consommation du processus associé à votre application : écran, CPU, réseau, etc. À noter que cela ne fonctionne aujourd’hui que sur une machine fonctionnant sur batterie car l’outil est branché sur l’API associée. Mais nous travaillons à rendre l’outil fonctionnel même sur des desktops.
quelques expérimentations
Maintenant que nous savons que ce sont les clients les sources principales de consommation d’énergie, que nous avons un outil pour mesurer cela, qu’il faut viser soit le CPU, GPU ou réseau, essayons de voir comment optimiser certains scénarios.
Dans une application Web, le CPU va principalement être sollicité par votre code JavaScript. Plus vous optimisez votre code pour baisser la charge CPU, moins vous consommerez d’énergie. Mais améliorer les performances de son application veut-il dire baisser sa consommation d’énergie ? Pas toujours !
Pour cela, je vous propose de voir ce petit exemple faisant du « face tracking » en accédant à la Webcam et en suivant votre visage, soit via du pur JS soit via Web Assembly (WASM). Sur mon Surface Laptop 2, la version JS affiche un rendu à 2 fps et le wattmètre indique une consommation de 10W. La version WASM tourne bien plus vite à 30 fps, ce qui indique une meilleure utilisation des ressources de la machine. Cependant… elle consomme 18W ! En termes d’expérience utilisateur, la version WASM est bien entendu nettement meilleure mais au prix d’une consommation quasi doublée. Vous retrouverez d’ailleurs le même problème dans les jeux vidéo par exemple : plus vous allez pousser dans leurs retranchements le CPU et GPU pour satisfaire la rétine du joueur, plus vous allez consommer de l’énergie.
Bon, c’était un cas particulier. J’ai alors continué avec ce benchmark WASM qui simule des opérations de type « Office » dans un fichier PDF. À nouveau, la version WASM est plus rapide que la version JS, réalisant le test en 25s au lieu de 45s. Le wattmètre ne permet pas de se rendre compte de la différence de consommation d’énergie. J’ai alors utilisé l’outil powercfg.exe, qui indique une consommation d’énergie totale sur la durée du test de 382 Joules pour WASM, et 484 Joules pour JavaScript. La même technologie est cette fois-ci plus efficace énergétiquement parlant dans ce scénario.
Dans les autres expérimentations que j’ai faites, j’ai réussi à diviser par 3 la consommation d’énergie en faisant appel aux Web workers. Cela m’a permis de mieux exploiter l’architecture multicœurs de mon CPU dans ce cas précis.
Pour finir, j’ai également réussi à économiser 12% d’énergie sur la partie réseau via l’utilisation d’un service worker conçu explicitement pour atteindre ce but. Si vous souhaitez en savoir davantage sur mes tests, je vous invite à regarder ma conférence sur ce même sujet : FrontSide – Ce qui consomme le plus et peut-on agir sur son code pour réduire son empreinte ?
en conclusion
Vous voyez à travers ces quelques expérimentations qu’optimiser la consommation d’énergie de son code n’est pas forcément synonyme d’une recherche d’une performance supérieure. Il va parfois falloir faire des choix sur le design et l’UX de son application pour réduire la consommation d’énergie. Est-il nécessaire de viser du 30 ou 60 fps ? Faut-il rafraîchir les données si fréquemment ? Cela demande donc un mode de réflexion potentiellement nouveau. Nous n’en sommes qu’au début de cette nouvelle discipline, les patterns & modèles de développement restent à créer et c’est un sujet qui doit être traité par toute l’industrie. C’est pour cela que nous sommes plusieurs à nous être réunis autour de la Green Software Foundation pour tenter de construire ensemble les bonnes pratiques : Green Software Foundation. Je vous invite donc à y participer et à désormais réfléchir un peu différemment à votre code.