Économie d'énergie d'un programme informatique

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.

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]).

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.

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.

Toutes les Collections ont des consommations énergétiques très proches, à 5 000 éléments elles se trouvent entre 8 et 10 joules.

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.

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 :

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.

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.

Résultat de consommation en joules des algorithmes de tri selon les processeurs ATMega 16, 32 et 128 :

Résultat du temps d'exécution en milliseconde des algorithmes de tri selon les processeur ATMega 16, 32 et 128 :

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.

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.

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 :

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.

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.

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.

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.