Les développeurs aussi doivent se mettre au vert

Introduction

Selon une récente étude, l’industrie informatique représente à elle seule 2% de la consommation énergétique mondiale. Autant que l’industrie aéronautique. À l’heure des data-center gigantesques et des gadgets portables en tout genre, les fabricants de processeurs et de composants ont depuis quelques années multiplié les efforts pour réduire la consommation électrique des équipements informatiques.

Mais ses efforts (notamment en matière de processeurs) sont souvent réduits à néants par le comportement des logiciels qui tournent par-dessus. Les programmeurs sont donc désormais  directement pointés du doigt. Ce que l’on met principalement en cause? L’absence d’optimisation des applications ! Un fait notamment soulevé dans le rapport “TIC et Développement Durable” remis au gouvernement Fillon en Mars 2009. Ses auteurs écrivent : “De 1970 à 2000, l’informatique est passée d’un extrême à l’autre. En 1970, le programmeur comptait soigneusement toutes les ressources qu’il utilisait : mémoire, nombre de cycles processeur, nombre d’accès disque etc. … En 2000, les méthodes de développement logicielles visent avant tout la rapidité de développement, et la facilité de maintenance. Les outils utilisés ne permettent aucune optimisation de la consommation de l’application. Bien souvent, les maîtres d’ouvrages sont les premières victimes de ces méthodes : on arrive en fin de développement à une application lourde, incapable de respecter les performances requises.“

La vision est un peu simpliste bien sûr. Performances et consommation énergétique ont une relation de cause à effet plus complexe. Mais elle a le mérite de replacer les développeurs et leur pratique au cœur des problématiques “Green IT”, autrement dit au cœur des économies d’énergie désormais imposées à l’univers informatique.

Comme le résumait Arjan  Van De Ven, patron de la branche Linux d’Intel, lors d’une récente conférence, “le matériel est aujourd’hui capable de réduire automatiquement sa consommation, encore faut il que le logiciel le lui permette!“. Il est temps pour les développeurs de se mettre au “vert”. Techniques, bonnes pratiques, outils et opportunités… Voici un tour d’horizon de l’univers du “Green Developer”.

Chiffres pour mieux comprendre les enjeux

Avant de nous plonger dans les techniques de programmation, il est essentiel de garder à l’esprit quelques faits essentiels et quelques chiffres pour le moins édifiants:

• Il y a en France 40 millions de PC (20 millions en Entreprise, 20 millions dans les foyers).

• En France, la consommation liée aux TIC est d’en 40 TWh par an, soit 13,5 % de la consommation d’électricité globale. Elle augmente de 10% par an. La consommation résidentielle (audiovisuel et informatique) pèse 17 TWh (6,1 TWh rien que pour l’informatique), la consommation du secteur professionnel (ordinateurs, serveurs, télécoms) pèse 23 TWh.

•  Une étude parue en début d’année montrait qu’aux USA, près de 50% des employés qui utilisent un PC au travail ne l’éteignent pas pour la nuit. A l’échelon mondial, on estime que ces PC constamment allumés représentent une dépense énergétique inutile de près de 2,8 milliards de dollars par an !

• En France, la veille des appareils informatiques et audiovisuels pèsent environ 200 kWh/an/ménage, soit une consommation d’environ 5 TWh ce qui équivaut à une tranche nucléaire (rien que pour de la veille) !

• L’étude REMODECE évaluait en 2007 la consommation d’un poste informatique à 396 kWh/an, la consommation en veille représentant 48kWh, celle en marche 348 kWh.

• Les serveurs des entreprises, à eux seuls, représentent 1% de la consommation électrique française globale, soit 4 TWh (climatisation comprise).

• D’après IBM, seule 45% de l’électricité d’un centre de données alimente les baies de serveurs, et dans cette part, seulement 30% alimente le processeur (le reste étant lié aux alimentations internes, à la ventilation, aux disques…). La totalité de l’énergie consommée est transformée en chaleur et il faut presque autant d’énergie (et le coût associé) pour évacuer cette chaleur !

• Une enchère sur eBay consomme 30 W/h.

• Un simple billet sur le blog de Sun représente 850 grammes d’émission CO2.

• Contrairement à une idée très répandue, la distribution et la fin de vie des ordinateurs ne comptent que pour 2 % dans l’émission CO2 de ces produits.

Vers une programmation verte

Qu’est-ce qui définit une programmation verte, autrement dit une programmation économe en ressource énergétique? A première vue, il paraît évident qu’un code efficace en terme de CPU met moins de temps à s’exécuter qu’un code inefficace. Etant plus rapide, il aboutit plus rapidement et consomme donc moins. L’optimisation du code source est la première clé d’une économie d’énergie.

Pas de règle inscrite dans le marbre

Pourtant, dans la réalité, les règles sont un peu plus subtiles. Tout d’abord chaque ressource peut se chiffrer en termes de consommation. Chaque ressource a sa propre empreinte carbone. Plus on économise les ressources, moins on rejette de carbone et plus on est écologique. Un code source « écologique » est donc aussi un code qui économise sur les ressources les plus consommatrices.

Ensuite, les nouvelles techniques comme le multi-cœur, le many-cores ou les P-States influencent notre idée et notre définition d’un code plus performant. Ainsi, est-il plus économe écologiquement parlant d’optimiser son code sur un cœur ou sur plusieurs ? Comment l’utilisation des many-cores (ces processeurs qui utilisent des cœurs multiples non identiques, certains étant spécialisés dans certaines tâches) affectent elles l’efficacité d’un code et sa consommation ? Comment les P-States affectent l’exécution et l’économie énergétique d’un code donné ?

Ces questions n’ont pas de réponse unique. Elles dépendent des tâches à réaliser et des algorithmes qui les réalisent. C’est au développeur, au cas par cas, d’opter pour la solution algorithmique la plus écologique. Développer “Vert” consiste à sans cesse trouver le meilleur rapport “Energie consommée/temps d’exécution”.

Cependant, on peut en général considérer qu’un code parallèle sera plus efficace et plus économique qu’un code séquentiel. Et d’une manière générale, il est souvent préférable de consommer davantage d’énergie durant un temps plus court, que de consommer moins d’énergie durant un temps plus long. Pourquoi ? Parce que rien ne vaut “l’Idle Time” :

La botte secrète c’est l’Idle Time

Un processeur ne connaît au final que deux états (même si les fondeurs ont désormais introduit des sous-états comme les P-States, T-States et C-States) : soit il exécute des instructions (il est actif), soit il n’exécute aucune instruction (il est inactif, ou en Idle). Et tout l’art d’une programmation verte consiste à créer un code offrant les temps d’inactivité consécutifs les plus longs.

Prenons l’exemple d’un processeur moderne qui consomme 34 W à pleine puissance et 24 W à mi-puissance. En mode “Idle” (CPU à 0%) sa consommation est réduite à 1 W. Sur ce processeur, un décodage MP3 peu optimal prend 1/2 seconde en utilisant le processeur à mi-puissance. Un code optimisé pour en tirer la pleine puissance s’exécute en 1/4 de seconde. Sur une seconde, la consommation à mi-puissance est de 12,5 Joules (24 W durant 0,5 s + 1 W durant 0,5 s) contre 9,25 Joules à pleine puissance (34 W durant 0,25 sec + 1 W durant 0,75 sec).

Conclusion : plus vite vous faites les choses, plus le système est susceptible d’être “Idle” plus longtemps et moins votre algorithme consomme d’énergie.

On en déduit une autre règle corollaire : mieux vaut rester Idle le plus lontemps possible et éviter autant que possible les interruptions du mode Idle. Car il faut savoir qu’une période Idle de 50 ms  est nécessaire pour que les fonctions d’économie d’énergie du processeur soient pleinement opérationnelles.  Pour respecter les temps d’inactivité du CPU, les systèmes d’exploitation se sont adaptés. Le Kernel de Linux à partir du 2.6.21 (et sa fonction “tickless idle”) évite le réveil du processeur lorsqu’il est en Idle. Le Kernel de Windows Server 2008 R2 et celui de Windows 7 disposent aussi d’un mécanisme de préservation du mode Idle.

Mais que l’on soit sous Linux ou sous Windows, le véritable problème est que les applications utilisateurs continuent de réveiller inutilement les processeurs par des timers souvent inutiles et mal pensés, des timers jamais éteints même lorsqu’ils sont inutiles, des timers définis sur des intervalles de temps plus courts que vraiment nécessaires.

Quelques techniques à privilégier

L’activité périodique des applications et les timers logiciels ont une influence néfaste sur le nombre de cycles d’inactivité du processeur et sur la durée de ces cycles d’inactivité. Dès lors, la première chose à faire pour un développeur qui veut rendre son code plus “vert” consiste à se pencher sur les timers qu’il a implémenté et de rechercher toute opportunité de supprimer partiellement ou totalement les activités périodiques. De même, le programmeur veillera à supprimer les pollings puisqu’il est souvent possible de les remplacer par la prise en compte d’évènements provenant du système (comme le File System Watcher de Windows par exemple qui déclenche un évènement quand un nouveau fichier apparaît dans le répertoire surveillé).

Pour contrecarrer le réveil du CPU par les applications, le kernel de Windows 7 implémente une technique dénommée “Timer coalescing” (littéralement Fusion des Timers). Ce système semi-automatique est capable de regrouper les différents timers des multiples processus en cours d’exécution de sorte qu’ils s’exécutent de façon concentrée et expirent tous en même temps, laissant davantage de chances au CPU de profiter d’un plus long temps d’inactivité (nous reverrons ce concept plus loin dans les API). Lorsque votre code a définitivement besoin d’un timer, il est important de le modifier pour tenir compte du “Timer Coalescing”.

Autre technique utile au “Green développeur”, l’analyse des boucles. Ces dernières sont à proscrire autant que possible puisque, par définition, elles ont de fortes chances d’empêcher un passage en mode Idle du processeur. C’est au développeur d’étudier si les boucles qu’il a mises en œuvre permettent effectivement de gagner un temps d’exécution important et d’offrir un gain dans l’exécution ou si une autre approche peut s’avérer énergétiquement plus rentable.

Autre règle, il faut utiliser le multithreading et le multi-core, autrement dit la parallèlisation, le plus possible. La parallélisation des codes reste l’un des grands défis à relever par les développeurs d’aujourd’hui. La programmation parallèle est un art difficile à maîtriser car assez incompatible avec le cheminement cognitif humain, par nature très séquentiel. Ce sujet dépasse largement le cadre de cet article. Mais s’il est important de souligner qu’un code parallèle exécuté sur un processeur multi-core s’avère presque toujours plus économe que son équivalent séquentiel, il faut aussi noter qu’une parallèlisation à l’extrême d’un code peut s’avérer parfois moins économe en raison de la dépense énergétique qui en découle : plusieurs tests ont démontré que certains calculs parallèles se montraient plus économes en termes d’énergie lorsqu’ils s’exécutaient sur 12 cœurs/processeurs plutôt que sur 24 ou 32 cœurs/processeurs. Au-delà d’une certaine limite, certains algorithmes présentent un gain de temps trop négligeable en regard de la surconsommation d’énergie. D’où l’importance pour un développeur de sans cesse calculer le ratio entre le temps d’exécution et la puissance consommée.

Dernière technique de programmation utile au niveau CPU, sachez utiliser les instructions MMX, SSE, SSE4 pour accélérer les traitements. Certes, ce point concerne essentiellement les développeurs en assembleur. Mais les autres peuvent aussi s’en préoccuper en pensant à utiliser les MMX/SSE Intrinsics en C++ et les options de compilation qui privilégient leur utilisation (/arch:SSEx.x sur le compilateur Intel).

Tenir compte des ressources…

Chaque ressource consomme de l’énergie et chaque ressource a son propre bilan carbone. Programmer en tenant compte de la consommation des ressources, tel est l’autre secret des “programmeurs verts”. Trois grandes règles sortent du lot :

• Economiser la mémoire et soigner les allocations de sorte à éviter une utilisation abusive de la mémoire virtuelle sur disque par le système. Prenons l’exemple d’une application Kiosque, celle-ci doit tourner 24H sur 24, et probablement ne pas autoriser l’ordinateur à passer en veille. Le programmeur peut toutefois faire en sorte que les ressources disques basculent quand même en veille en évitant les accès disques et en évitant au système de rallumer les disques pour pomper dans sa mémoire virtuelle.

• Economiser les accès disque et CD. Typiquement les applications audio/vidéo doivent être conçues pour éviter que le CD tourne sans arrêt ou que le disque soit tout le temps maintenu actif. Il faut donc privilégier les buffers importants et systématiquement les adapter à la mémoire disponible.

• Economiser l’écran. La mise en veille est une évidence. Mais elle n’est pas toujours possible. Si on reprend l’exemple de l’application kiosque, celle-ci devant afficher toujours quelque chose à l’écran, il n’est pas possible de la mettre en veille. En revanche il n’est pas inutile de se souvenir qu’un écran qui affiche un fond noir consomme moins qu’un écran qui affiche un fond blanc! Un écran CRT consomme 15 W de moins en affichant un fond noir plutôt qu’un fond blanc. Un écran LCD consomme 3 W de moins en basculant d’un fond blanc à un fond noir.

Les grandes règles à ne jamais perdre de vue

Outre l’optimisation CPU et le soin apporter dans l’utilisation des ressources, trois autres règles de programmation sont “économes” par nature et ne doivent pas être négligées :

• Un logiciel fiable et stable est naturellement plus écologique qu’un logiciel qui plante tout le temps et qui demande à l’utilisateur de sans cesse recommencer son travail. Cela peut sembler risible. Pourtant regardez les productions actuelles: tous les éditeurs ont pris l’habitude de mettre à disposition à large échelle leurs versions Bêtas ! Des éditeurs comme Google ont bien davantage de versions bêtas que de versions stabilisées déployées. Cette pratique va exactement à l’encontre d’une informatique “verte” !

• La reprise sur erreur est une façon intelligente de concevoir un code “vert”. Un programme capable de reprendre ses traitements là où ils ont été abandonnés plutôt que de tout reprendre à zéro se montre bien plus écologique. Là encore, cela ressemble à une Lapalissade. Mais sur des data-centers qui comportent des milliers de machines, la probabilité d’en avoir une en panne est de… 1. Autrement dit de 100% ! On est certain qu’à un instant donné au moins une machine sera en panne. On comprend dès lors mieux l’impact de la “reprise sur erreur” sur la consommation énergétique. L’utilisation de Meshs, de redondances intelligentes, de solutions de replis contribuent à l’obtention d’un code capable de gérer les panne.

• Faire attention à ne pas interférer avec les fonctionnalités de gestion d’énergie du système. Certaines applications désactivent les interruptions naturelles du système. Typiquement, les applications plein écran et les jeux. Le développeur doit alors réfléchir à ce qu’il peut mettre en œuvre pour compenser la surconsommation entraînée par la désactivation des systèmes de mise en veille de l’OS.

Drivers : vers des systemes plus verts

Jusqu’ici nous avons surtout vu les rapports étroits qui existent entre applications et consommation énergétique. Mais il est un autre aspect de l’économie d’énergie sur lequel les développeurs ont un impact direct: les pilotes. Situés au cœur du système, ils influencent directement sa consommation d’énergie.

Car en matière de logiciels et de consommation énergétique, tout commence avec le système d’exploitation. Le rapport « TIC et développement durable » pointait d’ailleurs directement un doigt accusateur sur Microsoft : “S’agissant des ordinateurs résidentiels, comme professionnels, il convient de promouvoir les labels tels que Energy Star, afin que les ordinateurs se mettent automatiquement en veille après quelques dizaines de minutes d’inactivité. Ceci suppose une sensibilisation des utilisateurs, mais aussi une politique plus active par le biais de la commande publique notamment pour obliger les constructeurs et éditeurs de logiciels (Microsoft en particulier) à prévoir des modes veille performants : économes en énergie, mais aussi à des temps de retour rapide. De nombreux utilisateurs désactivent les fonctions de veille parce que le retour à la fonction marche est trop long”.

Microsoft n’est pas le seul acteur directement mis en cause par ce paragraphe du rapport. Les développeurs de pilotes sont ici aussi pointés du doigt. D’une part, les drivers sont souvent responsables des temps d’attente qui ralentissent le démarrage et l’extinction du système. D’autres parts, ils sont souvent développés sans tenir compte des capacités d’économie d’énergie proposées par le matériel. Par exemple, rares sont les pilotes Audio qui gèrent correctement les suspensions sélectives en USB ou qui supportent les dernières spécifications “Low Power” Intel HD Audio. De même, les pilotes radio Bluetooth n’exploitent pas toujours les mises en veille lorsque les connexions sont placées en mode “sniff”. Encore un exemple : combien de pilotes réseau placent automatiquement le NIC en mode “D3” lorsque le média est déconnecté ?

Parmi les autres scénarios sur lesquels les développeurs doivent se pencher pour diminuer la consommation électrique du système, il y en a un qui revient de manière récurrente : l’optimisation de l’activité en tâche de fond. Elle est d’ailleurs souvent liée aux pilotes et aux utilitaires qui les accompagnent. Une étude réalisée par Microsoft auprès d’entreprises partenaires montrait récemment que l’utilisation CPU de systèmes en Idle (c’est-à-dire sans activité utilisateur) pouvait être multipliée par 7 entre un système neuf (clean install) et un système déployé avec tous ses enrichissements (les logiciels installés, les pilotes et utilitaires rajoutés, entraînant une surconsommation inutile) !

Microsoft ne rejette pas pour autant toute la faute sur les développeurs. L’entreprise reconnait sa responsabilité et a d’ailleurs fait des efforts comme en témoigne une comparaison directe à charge égale entre Windows Server 2003 et Windows Server 2008. Des gains non négligeables ont été obtenus par la prise en compte des contraintes énergétiques au cœur du système, l’optimisation de certains codes, la mise en œuvre d’astuces qui optimisent l’utilisation des ressources. Pour aller encore plus loin, Windows 7 bénéficie d’un nouveau gestionnaire des processus exécutés en tâche de fond, l’UBPM (Unified Background Process Manager), qui permet une gestion plus économe des services Windows.