Nous ne pouvons pas le nier : le facteur écologique est un critère de plus en plus présent dans notre société et rien n’y échappe. C’est alors qu’une collègue me demande : est-il possible de rendre son code plus “green” ?
Non loin de moi la prétention d’être un expert dans ce domaine, je souhaite partager un article qui, j’espère, créera débats et discussions. Je ne recherche pas des échanges futiles ou une bataille idéologique mais bien des réflexions de la part des scientifiques que nous sommes. Car oui, la science nous entoure et les TIs elles-mêmes sont régies par les mathématiques (ce n’est pas écrit Computer Sciences sur mon diplôme juste pour se vanter).
Attention cet article parle de mathématiques, de complexité algorithmique, de structures de données, de cloud computing et aussi de gestion de projets. Alors accrochez vos ceintures et tenez bon !
Qu’est-ce que peut vouloir dire “rendre son code plus green” ?
Un programme, une application ou un système au complet utilisent des ressources bien connues telles que le CPU, la RAM, le stockage de données, les GPUs, le réseau…. Tout cela consomme bien évidemment de l’électricité pour les faire fonctionner.
Plus un composant électronique est sollicité, plus sa consommation en Watt augmente.
Alors il est simple à partir de cela de se dire : pour être plus écologique, il faut être plus efficient sur l’usage de ses ressources, afin de diminuer le nombre de Watts nécessaires.
Autre facteur à ne pas négliger : tous les composants électroniques utilisent des minerais rares et difficiles à extraire. Sans rentrer dans les détails, il semble logique que si nous utilisons moins de composants, ou des composants de plus petite taille, ou conçus/utilisés de manière efficiente, alors nous tendons vers du “green”.
Donc tout cela tend vers la même et unique conclusion : réduisons l’impact sur l’usage des ressources matérielles pour diminuer la consommation d’électricité (dont la production peut être polluante) et la consommation de minerais (dont l’extraction et le raffinement sont vraiment polluants).
Le code : source d’algorithmes, de complexités et de structures de données
Pour les personnes qui n’ont pas suivi de cursus universitaire en informatique, je vais parler de complexité algorithmique et de structure de données. Pas besoin d’attacher vos tuques, je vais tenter de faire court et concis.
La complexité algorithmique est une représentation de la quantité de ressources nécessaire pour effectuer une tâche suivant un algorithme donné.
Un des exemples simples est le tri d’un tableau de nombres.
Une première méthode "naïve" consiste à parcourir la liste pour chercher le plus petit nombre et le mettre en première position puis d’itérer sur les valeurs suivantes : cet algorithme s’appelle le tri par sélection.
Rapidement, vous devrez être en mesure de comprendre que la liste de nombres sera parcouru une première fois pour trouver la plus petite valeur, puis une fois encore pour trouver la seconde plus petite valeur et ainsi de suite : la complexité d
e l’algorithme est basée sur le nombre d’éléments dans la liste, noté n. Ici l’algorithme a une complexité de O(n²) : comprenez si la liste possède 10 éléments, il faudra “grossièrement” 100 opérations pour la trier dans l’ordre.
D’autres algorithmes, basés sur le principe de “diviser pour régner”, comme le tri fusion (merge sort), ou le tri rapide (quick sort) ont quant à eux une complexité algorithmique de O(n log n) : pour la même liste de 10 éléments le nombre d’opérations nécessaires est de l’ordre de 10 * log2 (10) soit environ 33.
Maintenant - si je ne vous ai pas perdu - vous comprenez que pour effectuer la même tâche donnée en exemple, il est possible d’utiliser 3 fois moins de temps de calcul soit 3 fois moins de ressources au niveau du CPU.
Par contre, un compromis doit être fait : pour le second algorithme, il faut plus d’espace en mémoire RAM que pour le premier. Souvent, en algorithmique, le facteur d’usage CPU/RAM est à prendre en compte.
C’est ici qu’entre en jeu les structures de données : en effet - et pour être bref - le choix sur la façon dont nous allons représenter nos données ont un impact significatif sur l’usage des ressources.
Si nous revenons encore sur notre tri de liste, si il est primordial que cette liste soit ordonnée, alors pourquoi ne pas le faire dès l’insertion d’un élément ? Avec ce choix, le coût est porté à l’insertion et il sera de l’ordre de la taille de la liste au maximum, soit de 10, soit une diminution encore de l’usage des ressources CPU et RAM.
Donc à toutes les personnes qui adorent faire des structures de données étranges ou des algorithmes sortis du chapeau : rappelez-vous qu’ils existent déjà plein de choses qui peuvent répondre à votre besoin, besoin qu’il faut bien identifier et qu’il vaut mieux réfléchir et faire des recherches plutôt qu’écrire du code au plus vite.
Pour être plus “vert” utilisez votre matière grise.
Zoom out : le langage de programmation
Les choix des technologies ont un impact sur l’efficacité de nos algorithmes. En effet, choisir entre Java ou Python peut avoir une importante influence sur l'efficacité énergétique et par conséquent sur l’aspect écologique de notre application/système.
Dans l’article scientifique "Energy Efficiency across Programming Languages: How does Energy, Time and Memory Relate?" publié dans International Conference on Software Language Engineering (SLE), nous pouvons voir la méthodologie et les résultats comparatifs sur l’usage en termes de Joules (1 joule = 1 watt / seconde), de temps et de mémoire occupée par chaque langage pour des tâches similaires.
En général, plus un langage est proche du langage de la machine (compilé), plus il est efficace alors que les langages interprétés sont souvent ceux étant les moins efficaces.
Je vous encourage vraiment à consulter le site qui héberge le papier publié, les méthodes employés et même le code source pour faire les calculs.
Je vous partage le tableau des résultats normalisés sur les 27 langages comparés dans l’étude : c’est à dire que 1.00 est la norme (et non une valeur en Joules, en temps ou en mémoire).
Si, à partir de ces données, je prends les langages C, Java et Python, je peux dire que Java utilise 1.98 fois plus d’énergie que C (en moyenne) alors que Python utilise 75.88 fois plus d’énergie que C pour effectuer des tâches similaires. Python ne semble pas un langage “green” en terme de consommation de joules.
Par contre, je souhaite nuancer ces résultats : certes C semble le langage idéal mais avons-nous envie de tout coder en C ? Personnellement, pas tous les jours.
En effet, encore une fois, il ne faut pas prendre des résultats et partir tête baissée : c’est un ensemble. Je suis bien curieux de savoir combien de temps est nécessaire pour coder l’équivalent d’une micro application Java Spring Boot avec des REST API, des accès bases de données en C. La nuance se trouve donc dans le temps de développement et les économies de temps - et par conséquent en énergie - que vont offrir des frameworks ou librairies de langages spécifiques. Python n’est pas à jeter à la poubelle s’il vous plaît.
Zoom out again : l’infrastructure
Je reviens encore avec l’aspect matériel : aujourd’hui nous avons la possibilité de déployer sur du bon vieux bare metal / on premise - autrement dit hébergé en interne- , ou dans un fournisseur de service cloud ou , pour les plus chanceux, d’avoir une solution hybride (on premise et cloud en même temps).
Qu’en est-il de l’efficience énergétique de ces infrastructures ?
Soyons clairs et simples : centraliser et mutualiser les ressources sont un moyen efficace de rentabiliser au maximum le matériel, l’énergie (notamment pour le refroidissement). Bien évidemment le nuage nous apporte des arguments incontestables pour l’aspect green.
D’autant plus que, pour des raisons écologiques (ou pour avoir de la redondance sur l’approvisionnement en énergie), la plupart des gros acteurs du marché, comme AWS, se tourne de plus en plus vers les énergies renouvelables pour réduire les émissions de gaz à effets de serre.
De ma vision (et sur le papier), le cloud est un choix à privilégier pour être plus vert.
Une autre version est de penser cluster de machines plutôt que machines individuelles. En effet, si toutes les machines sont exploitées simultanément, grâce à des orchestrateurs comme Kubernetes, cela permet de mieux rentabiliser les ressources matérielles et peut être les ressources énergétiques (même si Kubernetes consomme aussi des ressources pour exister).
En conclusion sur l’aspect écologique sur l’infrastructure, je pense que des systèmes mutualisés tirent mieux parti du matériel, le cloud en avant mais un cluster on premise peut tout aussi être correct. Ce qui serait à éviter est le bare metal, le fameux serveur sous le bureau avec 32Go de RAM et 16 CPU pour faire tourner un batch une fois par semaine (toute ressemblance avec une entreprise dans laquelle j’ai travaillé dans le passé est possible).
La gestion de projet TI : le pilier central qui peut briser tout rêve de voir vert
Tout ce que j’ai énoncé jusqu’à maintenant était quelque peu idyllique. Mais revenons dans le monde réel : la gestion de projet gouverne (parfois un peu trop) les décisions technologiques.
Essayez de parler d’optimiser votre application si personne ne s’en plaint. En général la réponse sera : “on n’a pas le temps”, “on n’a pas le budget”.... Or comme je viens de le démontrer : optimiser, réfléchir aux algorithmes, aux technologies, à l'infrastructure est la base même de tout ce qui peut aller dans le green coding.
D’autant plus qu' en termes de ressources, notamment grâce au cloud, les limites sont repoussées : entre réécrire une partie de l’application ou appuyer sur un bouton pour ajouter des CPUs et de la RAM, le calcul sur le court terme est souvent tout fait dans la tête des gestionnaires de projets.
Cependant, c’est avec ce genre de réflexion court-termiste, basé uniquement sur le facteur financier ou temporel, qu’en plus de créer de la dette technologique et se positionner en dessous d’une énorme épée de Damoclès. qu’il est rendu difficile d’allier efficacité énergétique et développement.
Mais est-ce que économiser des ressources ne feraient finalement pas gagner de l'argent aux entreprises qui disent ne pas avoir le budget ?Amis POs faites des business cases pour convaincre nos gestionnaires d'aller de l'avant. Écologie et économie ne sont pas décorrélés et peuvent très bien aller de pairs !
Conclusion
Nombreux sont les aspects à prendre en considération pour faire du "green coding". Cependant, un point essentiel est à retenir : scientifiquement, en jugeant les facteurs prioritaires et discriminants à notre développement, il est possible d’agir sur la complexité algorithmique, les structures de données, le choix des technologies et des infrastructures.
Il ne reste que la difficile tâche de convaincre des bienfaits du "green coding" à vos gestionnaires de projets.
Sources :
https://sites.google.com/view/energy-efficiency-languages
https://durabilite.aboutamazon.fr/evironnement/le-cloud
https://fr.wikipedia.org/wiki/Tri_par_s%C3%A9lection#/media/Fichier:Selection-Sort-Animation.gif
https://fr.wikipedia.org/wiki/Tri_fusion#/media/Fichier:Merge-sort-example-300px.gif
https://www.youtube.com/watch?v=BKorP55Aqvg&ab_channel=LaurisBeinerts
TL;DR : green coding, complexité algorithmique, structure de données, langages, C, Java, Python, infrastructure, Kubernetes, cloud