Économie d'énergie d'un programme informatique
La consommation en énergie d'un logiciel est définie par l'ordinateur en fonction des systèmes qui le composent. Plusieurs principes de développement peuvent être utilisés pour limiter la consommation d'un logiciel. Aujourd'hui, avec le nombre d'appareils informatiques utilisés chaque jour, du centre de données au smartphone, l'économie d’énergie est devenue plus importante qu'auparavant.
État des lieux[modifier | modifier le code]
Dans le monde, il est estimé que les appareils informatiques consomment 5,3 % de l’électricité du total[1]. Malgré ce pourcentage peu élevé, cela correspond à une quantité importante d’énergie, et la moindre économie dans cette consommation pourrait permettre de la réduire avec un impact positif sur l'écologie et sur l'économie.
Plusieurs moyens existent pour réduire la consommation. L'une des approches est l'amélioration de la consommation d'énergie des composants. Une autre est de concevoir des logiciels afin qu'ils consomment moins. Cette approche permet de réduire la consommation sans pour autant concevoir de nouveaux appareils car l'énergie grise produite par la construction d'un ordinateur est élevé[2].
Définition[modifier | modifier le code]
La consommation en énergie d'un appareil informatique est définie par le coût énergétique nécessaire aux composants matériels pour réaliser leur tâche. Cette activité est produite par l’exécution d'un logiciel qui est lui-même lié à l'activité d'un utilisateur.
- Puissance
- La vitesse à laquelle le travail est effectué, exprimée en watts ⇒ .
- Énergie
- L'intégrale du temps et de la puissance, exprimée en joules ⇒ .
Le coût en énergie des composants matériel est régi par le logiciel, c'est pourquoi il existe plusieurs moyens de réduire la consommation générale du matériel en travaillant le logiciel. Voici quelques-unes d'entre elles.
Axes d'améliorations[modifier | modifier le code]
Type de collections Java[modifier | modifier le code]
Contexte d'étude[modifier | modifier le code]
Une étude a été réalisée pour définir des profils énergétiques des classes de type Collections en Java[3]. Cette étude montre que choisir une classe de Collections inadaptée peut augmenter la consommation énergétique de 300 % alors que choisir une classe adaptée peut réduire la consommation de 38 %.
Java est un langage largement utilisé dans le monde du logiciel grâce à sa portabilité[4], ce qui fait de lui un langage impactant dans le domaine de la consommation énergétique. L'étude indique que lors de l'exécution d'un programme Java, la consommation énergétique est liée aux opérations effectuées et non à l'utilisation de la mémoire. Les boucles, donc indirectement les classes de type Collections, influent fortement sur la complexité des opérations d'un programme.
Pour mesurer la consommation énergétique en joules, l'infrastructure GreenMiner[5] a été utilisée sur un smartphone Android. Une application vide a été créée, sur laquelle des tests unitaires JUnit[6] ont été exécutés. Ces tests analysent des cas d'utilisation de Collections particuliers sur des entrées de 1 à 5 000 éléments avec 13 tailles de listes différentes.
Cette étude a été effectuée sur les Librairies suivantes : Java Collections Framework[7] (JCF)[8], (ACC), et Trove[9], sur des listes, des tableaux associatifs et des ensembles.
Évaluation[modifier | modifier le code]
Insertion en début de liste[modifier | modifier le code]
L'arbre enraciné (ACC[10]) est plus consommatrice que les autres, par exemple à 5 000 éléments elle implique une consommation proche de 7 joules, alors que les autres se trouvent à peu près entre 1 et 2,5 joules.
La liste chainée (JCF[11]) a la meilleure consommation sur toutes les tailles de listes.
Les autres types de Collections ont des scores similaires jusqu'à 2 000 éléments puis montrent une légère différence sur des tailles supérieures. Voici respectivement les types de Collections de la plus grande consommation à la plus faible : tableau (JCF), TIntArrayList (Trove[9]), TIntLinkedList (Trove[9]).
Insertion en milieu de liste[modifier | modifier le code]
La TIntLinkedList est plus consommatrice que les autres, par exemple à 5 000 éléments elle implique une consommation proche de 25 joules, alors que les autres se trouvent à peu près entre 0 et 10 joules.
La TIntArrayListet le tableau (JCF) sont les moins consommatrices, et sont proches en consommation au moins jusque 5 000 éléments (entre 0 et 3 joules).
Les autres se trouvent entre 5 et 10 joules.
Insertion en fin de liste[modifier | modifier le code]
L'arbre enraciné (ACC) est plus consommatrice que les autres, par exemple à 5 000 éléments elle implique une consommation proche de 7 joules, alors que les autres se trouvent à peu près entre 0 et 2 joules.
La TIntArrayList , la TIntLinkedList, le tableau, et la liste chainée sont les moins consommatrices, et sont proches en consommation au moins jusqu'à 5 000 éléments (entre 0 et 2 joules). On constate quand même que la TIntArrayList est majoritairement la plus basse en consommation.
Itération sur une liste[modifier | modifier le code]
Toutes les Collections ont des consommations énergétiques très proches, à 5 000 éléments elles se trouvent entre 8 et 10 joules.
Accès aléatoires à une liste[modifier | modifier le code]
La TIntLinkedList est plus consommatrice que les autres, par exemple à 5 000 éléments elle implique une consommation supérieure à 30 joules, alors que les autres se trouvent à peu près entre 5 et 15 joules.
La TIntArrayList, le tableau (JCF) et l'arbre enraciné (ACC) sont les moins consommatrices et sont proches en consommation au moins jusque 5 000 éléments (entre 5 et 10 joules).
La liste chainée se trouve entre 10 et 15 joules.
Bilan[modifier | modifier le code]
L'article[3] a fait une notation de la qualité de consommation d'une Collection allant de 1 pour la meilleure à 6 pour la pire, voici les résultats :
| Insertion | Itération | Accès aléatoire | |||
|---|---|---|---|---|---|
| Au début | Au milieu | A la fin | |||
| Tableau | 4 | 2 | 3 | 1 | 2 |
| TIntArrayList | 3 | 1 | 1 | 2 | 1 |
| Liste chainée | 1 | 3 | 4 | 2 | 3 |
| TIntLinkedList | 2 | 5 | 2 | 2 | 3 |
| Arbre enraciné | 5 | 4 | 5 | 3 | 3 |
| Insertion | Itération | Requête | |
|---|---|---|---|
| Table de hachage | 1 | 1 | 1 |
| TIntHashMap | 2 | 2 | 2 |
| HashedMap | 2 | 2 | 2 |
| LinkedHashMap | 2 | 2 | 2 |
| LinkedMap | 3 | 2 | 2 |
| TreeMap | 4 | 2 | 3 |
| Insertion | Itération | Requête | |
|---|---|---|---|
| HashSet | 2 | 1 | 1 |
| TIntHashSet | 1 | 1 | 1 |
| MapBackedSet | 4 | 1 | 1 |
| LinkedHashSet | 3 | 1 | 1 |
| ListOrderedSet | 5 | 1 | 1 |
| TreeSet | 6 | 1 | 2 |
De manière générale la TIntArrayList est la meilleure liste suivie par le tableau, La table de hachage est le meilleur tableau associatif et la HashSet est le meilleur ensemble suivi par la TIntHashSet.
Algorithmes de tri[modifier | modifier le code]
Contexte d'étude[modifier | modifier le code]
Une étude[12] a été réalisée sur des smartphones, pour mesurer leur consommation en fonction de certains algorithmes de tri. La problématique est que les appareils embarqués fonctionnent souvent sur batteries et leur durée de vie dépend donc de l'énergie consommée par leurs composants. L'étude cible les algorithmes de tri qui ne sont pas uniquement utilisés par les utilisateurs directement, mais aussi indirectement par d'autres algorithmes, en mesurant la consommation énergétique du CPU et de la mémoire.
Le tri rapide est un algorithme de tri standard de plusieurs librairies et langages. Il y a une croyance forte sur le fait que la consommation en énergie dépend directement des performances logiciels, mais d'autres facteurs comme l'utilisation de la mémoire ou les récursions ont aussi un impact. Les expériences menées dans cette étude montrent que le tri rapide peut être le plus rapide mais pas le moins gourmand en énergie.
Algorithmes étudiés :
- Tri à bulle,
- Tri par tas,
- Tri par insertion,
- Tri fusion,
- Tri rapide,
- Tri par sélection,
- Tri shaker/cocktail,
- Tri de shell.
Évaluation[modifier | modifier le code]
Résultat de consommation en joules des algorithmes de tri selon les processeurs ATMega 16, 32 et 128 :
| ATMega 16 | ATMega 32 | ATMega 128 | |
|---|---|---|---|
| Tri rapide | 1.76 | 2.81 | 6.29 |
| Tri rapide récursif | 0.29 | 1.74 | 1.34 |
| Tri par tas | 2.32 | 2.40 | 1.42 |
| Tri par sélection | 4.58 | 4.80 | 7.35 |
| Tri par insertion | 0.85 | 0.89 | 0.19 |
| Tri à bulle | 3.32 | 3.47 | 5.01 |
| Tri fusion récursif | n.a. | 2.52 | 3.79 |
| Tri fusion | 1.21 | 1.26 | 1.77 |
| Tri shaker/cocktail | 1.24 | 1.29 | 0.12 |
| Tri de shell | 1.19 | 1.25 | 0.87 |
Résultat du temps d'exécution en milliseconde des algorithmes de tri selon les processeur ATMega 16, 32 et 128 :
| ATMega 16 | ATMega 32 | ATMega 128 | |
|---|---|---|---|
| Tri rapide | 2520 | 259640 | 237534 |
| Tri rapide récursif | 33120 | 32240 | 201220 |
| Tri par tas | 224920 | 224920 | 224920 |
| Tri par sélection | 442040 | 444120 | 443720 |
| Tri par insertion | 81640 | 81600 | 81640 |
| Tri à bulle | 321320 | 321220 | 321220 |
| Tri fusion récursif | 44920 | 233920 | 233920 |
| Tri fusion | 118400 | 118400 | 118400 |
| Tri shaker/cocktail | 117400 | 117400 | 117400 |
| Tri de shell | 115800 | 115800 | 115800 |
Bilan[modifier | modifier le code]
L'étude montre que finalement l'utilisation de la mémoire a un impact sur la consommation en énergie. Toutefois les algorithmes comme le tri par insertion sont plus efficaces que les autres.
Une autre approche que les expériences ont montré, est que les types de données utilisés avaient un impact sur la consommation, par exemple les types à virgule flottante consomment plus que les types entiers.
Patron de conception[modifier | modifier le code]
Contexte d'étude[modifier | modifier le code]
Un patron de conception en architecture logicielle est un arrangement de rôles et d'actions établis par des modules. Ces patrons, reconnus par les concepteurs et les programmeurs, décrivent des procédés qui permettent d'organiser et de structurer un projet.
Pour permettre d'évaluer la consommation en énergie de ces différents patrons de conception, plusieurs études ont mis en place des bancs d'essais[13],[14]. Ceux-ci ont développé un outil composé d'un FPGA et d'un ordinateur permettant de mesurer avec précision les fluctuations d'énergie.
Évaluation[modifier | modifier le code]
Chaque morceau de code avant et après application d'un patron de conception a été exécuté plusieurs fois afin d'obtenir des données consistantes. Voici les résultats :
| Patron de conception | Consommation avant
(en joules) |
Consommation après
(en joules) |
Différence en pourcentage |
|---|---|---|---|
| Fabrique abstraite | 87.78 | 106.69 | 21.55 |
| Monteur | 111.75 | 113.08 | 1.19 |
| Fabrique | 118.13 | 118.06 | -0.07 |
| Prototype | 99.60 | 98.68 | -0.93 |
| Singleton | 98.70 | 99.11 | 0.42 |
| Pont | 99.78 | 99.54 | -0.24 |
| Objet composite | 97.15 | 102.14 | 5.14 |
| Décorateur | 13.92 | 113.13 | 712.89 |
| Poids-mouche | 92.89 | 38.94 | -58.08 |
| Proxy | 104.33 | 66.28 | -36.47 |
| Commande | 98.32 | 96.53 | -1.82 |
| Médiateur | 120.55 | 109.02 | -9.56 |
| Observateur | 61.62 | 99.95 | 62.20 |
| Stratégie | 115.73 | 115.52 | -0.18 |
| Visiteur | 104.89 | 97.04 | -7.49 |
Bilan[modifier | modifier le code]
Les résultats indiquent que la majorité des patrons de conception n'influent quasiment pas sur la consommation en énergie. Cependant il est intéressant de noter que les patrons de conception Poids-mouche et Proxy économisent respectivement 58 % et 36 % d'énergie.
D'un autre côté, les patrons de conception Observateur et Décorateur consomment respectivement 62 % et 712 % d'énergie en plus. Malgré cela, il est possible d'optimiser l'utilisation d'énergie de ces patrons de conception.
Le patron de conception Observateur peut être optimisé en réduisant le nombre d'appel aux méthodes et accès mémoire de l'observé. Moins d'appel permettra aux observateurs d'être notifiés moins souvent lors d'actions de l'observé.
Le patron de conception (ou décorateur) peut être plus économe en énergie en créant une sous classe de la classe décorée qui contiendra tous les attributs et méthodes de la classe décorée. Ainsi une substitution de l’instanciation de l'objet décorée avec l'objet de la sous classe économisera de l'énergie.
Protocole de sécurité[modifier | modifier le code]
Contexte d'étude[modifier | modifier le code]
Le protocole SSL est largement utilisé pour effectuer des échanges sécurisés sur Internet. SSL offre des services basiques de chiffrement, d'authentification de sources et de protection d'intégrité des données échangées. Il est souvent utilisé comme sur-couche logicielle afin d'éviter de modifier en profondeur un protocole applicatif, comme HTTP. Ce protocole étant beaucoup utilisé, sa consommation en énergie doit être légère étant donné que tout type d'appareil l'utilise, cela inclut les appareils équipés de batteries et donc ayant une faible autonomie.
Afin de mesurer l'impact de SSL sur la consommation en énergie, un banc d'essai a été mis en place lors d'études sur la consommation en énergie des protocoles de sécurité[15],[16]. Celui-ci consiste en un ordinateur de poche sous Linux directement branché sur un appareil de mesure. L'ordinateur de poche qui sert de client, communique directement avec un serveur en utilisant l'implémentation SSL du projet OpenSSL. Le client est constamment branché afin de garder la batterie au même niveau de charge afin que les mesures soient consistantes.
Évaluation[modifier | modifier le code]
Dans un premier temps, l'analyse porte sur la consommation en énergie sur différentes tailles d'échange en SSL. Les résultats indiquent qu'avec des échanges de petite taille, 256 kilo-octets, l'authentification entre le client et le serveur utilisent 98,9 % de l’énergie, le reste étant utilisé pour la phase de chiffrement de l'échange. Plus l'échange est grand, jusqu'à 1 méga-octet, plus la phase de chiffrement consommera, avec cette taille de message, on se rend compte que la phase d'authentification ne consomme plus que 19,6 % de la consommation totale.
Cependant, les phases d'authentification et de chiffrement de l'échange utilisent de nombreux algorithmes de cryptographie, ce qui nous intéresse ici est la consommation de SSL. C'est pourquoi des mesures afin de déterminer la consommation pure de SSL ont été faites. Sur trois tailles d'échange de 1 kilo-octet, 100 kilos-octets et 1 méga-octet, les résultats montrent qu'SSL consomme de 41 % à 45,8 % de l'énergie totale utilisée par les échanges. Le reste étant utilisé par les différents algorithmes de chiffrement.
L'authentification peut être faite de différentes manières en utilisant des algorithmes de chiffrement différents, l'étude montre que selon la taille de l'échange, la consommation en énergie de l'authentification diffère selon l'utilisation du chiffrement RSA ou de la cryptographie sur les courbes elliptiques et même selon les différentes versions de ceux-ci. Pour les petits messages, moins de 20 kilos-octets, il est plus avantageux d'utiliser la version ECC-3DES-SHA de la cryptographie sur les courbes elliptiques, pour les messages plus grands il est plus avantageux d'utiliser la version du RSA-RC5-SHA1 du chiffrement RSA.
Bilan[modifier | modifier le code]
L'étude montre que pour économiser de l’énergie il faut faire varier plusieurs paramètres qui sont :
- L'utilisation ou non de l'authentification par le client,
- Le choix de l'algorithme de chiffrement utilisé lors de l'authentification,
- La taille de la clé utilisée par l'algorithme de chiffrement choisi,
- L'algorithme de chiffrement utilisé pour chiffrer les données de l'échange,
- La taille des échanges, il est plus économique en énergie de faire des échanges plus grand.
Notes et références[modifier | modifier le code]
- (en) itu ICTs for e-Environment site de l'International Telecommunication Union. voir page 78.
- (en) embodied energy of digital technology, sur lowtechmagazine.com
- Samir Hasan, Zachary King, Munawar Hafiz et Mohammed Sayagh, « Energy Profiles of Java Collections Classes », Proceedings of the 38th International Conference on Software Engineering, ACM, iCSE '16, , p. 225–236 (ISBN 9781450339001, DOI 10.1145/2884781.2884869, lire en ligne, consulté le )
- « Qu'est-ce que Java et pourquoi en ai-je besoin ? », sur www.java.com (consulté le )
- Abram Hindle, Alex Wilson, Kent Rasmussen et E. Jed Barlow, « GreenMiner: A Hardware Based Mining Software Repositories Software Energy Consumption Framework », Proceedings of the 11th Working Conference on Mining Software Repositories, ACM, mSR 2014, , p. 12–21 (ISBN 9781450328630, DOI 10.1145/2597073.2597097, lire en ligne, consulté le )
- « JUnit », sur junit.org (consulté le )
- Java Collections Framework
- Apache Collections Framework
- Trove
- ACC
- JCF
- C. Bunse, H. Höpfner, E. Mansour et S. Roychoudhury, « Exploring the Energy Consumption of Data Sorting Algorithms in Embedded and Mobile Environments », 2009 Tenth International Conference on Mobile Data Management: Systems, Services and Middleware, , p. 600–607 (DOI 10.1109/MDM.2009.103, lire en ligne, consulté le )
- C. Sahin, F. Cayci, I. L. M. Gutiérrez et J. Clause, « Initial explorations on design pattern energy usage », 2012 First International Workshop on Green and Sustainable Software (GREENS), , p. 55–61 (DOI 10.1109/GREENS.2012.6224257, lire en ligne, consulté le )
- Adel Noureddine et Ajitha Rajan, « Optimising Energy Consumption of Design Patterns », International Conference on Software Engineering, (lire en ligne, consulté le )
- Nachiketh R. Potlapally, Srivaths Ravi, Anand Raghunathan et Niraj K. Jha, « Analyzing the Energy Consumption of Security Protocols », Proceedings of the 2003 International Symposium on Low Power Electronics and Design, ACM, iSLPED '03, , p. 30–35 (ISBN 158113682X, DOI 10.1145/871506.871518, lire en ligne, consulté le )
- N. R. Potlapally, S. Ravi, A. Raghunathan et N. K. Jha, « A study of the energy consumption characteristics of cryptographic algorithms and security protocols », IEEE Transactions on Mobile Computing, vol. 5, no 2, , p. 128–143 (ISSN 1536-1233, DOI 10.1109/TMC.2006.16, lire en ligne, consulté le )
