[Devoxx FR 2012] – Obésiciel et impact environnemental : Green Patterns appliqués à Java

En regardant l’agenda Devoxx France du vendredi, un titre a attiré notre curiosité : “Obésiciel et impact environnemental : Green Patterns appliqués à Java”. A l’heure où l’on nous sert du “développement durable”, “écologie” et autres “recyclages” à toutes les sauces, on s’est dit : “Il est vrai que le monde de l’informatique est relativement gourmand en terme de ressources énergétiques. Allons voir comment nous, petits développeurs, pouvons être acteur à notre niveau.”

Nous allons vous faire un résumé de la conférence d’Olivier Philippot et vous donner notre ressenti.

Il commence tout d’abord par un état des lieux. Pour vous donner une idée de la consommation actuelle, une petite illustration : le film “Le Chat Potté” a coûté 70 millions d’heures de calculs. Ce qui correspond à 25T joules et plus concrètement à l’énergie consommée par les humains de toute la planète pendant 20 minutes (rien que ça). Et là on ne parle que de la production, il faut encore additionner la consommation du marketing, de la diffusion…

Bon là je sens que vous ne vous sentez pas forcément concerné… par contre si l’on vous dit que les TIC (Technologies de l’Information et de la Communication) représentent 2% des émissions de CO2 ça vous parle non? Toujours pas ? Bon… et si je vous dit que cela est équivalent aux émissions des transports aériens ? Ou que la consommation de Facebook est équivalente à la puissance d’un TGV qui roulerait 24h/24h ?

L’un des principaux problèmes énoncé est l’apparition de l’obésiciel ou bloatware. Il s’agit d’un logiciel qui au fil du temps, suite aux différentes versions, prend de plus en plus de ressources. Ces ressources utilisées n’augmentent cependant pas forcément la rapidité d’exécution et cela est bien illustré par la loi de Wirth : “Les programmes ralentissent plus vite que le matériel n’évolue” !

Pour pouvoir améliorer la consommation de ces obésiciels il faut tout d’abord pouvoir la quantifier en analysant le coût énergétique (à la fois du soft et du hard) du logiciel de la naissance à la mort du projet.

Cela est illustré par cette citation de Peter Drucker : “Ce qui ne peut pas être mesuré ne peut pas être géré”.

On peut améliorer ces métriques en faisant de l’éco-conception, que l’on axera sur 3 piliers : le social, l’économie et l’écologie.

Il apparaît que ces logiciels sont souvent sur-équipés. Il est donc possible d’optimiser leur qualité de service, par exemple via une installation modulaire. Si un des modules du logiciel n’est pas utilisé, le programme propose sa désinstallation (comme pour les plug-in de Mozilla Thunderbird).

Mais plus important, il est nécessaire de mieux identifier les besoins. Quand on sait que 40% des fonctionnalités d’un logiciel ne sont pas utilisées, on se dit qu’on aurait bien utilisé ce temps et ces ressources autrement. Microsoft, par exemple, a étudié l’usage de son moteur de recherche Bing. Il est apparu que les utilisateurs n’utilisaient que les 20 premiers résultats de la recherche et suite à la prise en compte sur de ce facteur, une baisse de 80% de consommation s’en est suivi.

Olivier aborde ensuite le concept de Green Pattern.

Il indique qu’il ne faut pas réfléchir en %CPU consommé mais plutôt en temps CPU. Un des but de l’éco-design étant de laisser au processeur les plus longues périodes continues dans l’état endormi, car ce sont les transitions entre l’état endormi et l’état de travail qui sont coûteuses.

Pour cela, les instructions doivent au maximum éviter les timers, surtout ceux très rapides (<15ms), qui provoque une alternance répétés des phases endormi/travail.

Le logiciel doit également s’adapter au contexte. Par exemple, en arrêtant les traitement si l’utilisateur ne l’utilise pas. Il doit également prendre en compte la gestion d’énergie et ne pas empêcher la mise en veille. Pour illustrer ce dernier conseil, il évoque le bug du Wavelock qui empêchait l’extinction de l’écran lors de l’exécution de certaines parties du code.

Tout ça est bien joli mais comment peut-on concrétiser ces approches au niveau du code? En appliquant des Green Patterns dont voici quelques exemples.

Premièrement, s’intéresser à la synchronisation. Il recommande de synchroniser les données et non pas le code. Le but est de diminuer le temps passé en synchronisation et de ce fait éviter des attentes trop longues du processeur. Voici une illustration.

De plus, de manière plus classique il faut éviter d’utiliser, sauf nécessité, des classes avec gestion innée de la synchronisation telles que Vector et HashTable. L’utilisation de classes avec une granularité fine, pour synchroniser seulement l’écriture et non la lecture est recommandée (par exemple ConcurrentHashMap).

Ensuite, l’éco-design passe également par la surveillance des entrées/sorties (IO), celles-ci étant très consommatrices en ressources. Une des pratiques serait alors de regrouper les IO afin de réduire leur consommation. L’exemple de l’application mobile Angry Birds est donné : 45% de sa consommation s’effectue pour afficher des publicités et cela passe notamment dans de nombreuses requêtes IO (communication via 3G). Cet exemple donne un apport concret de l’éco-design, car vu que moins de ressources seront utilisées, les applications consommeront moins de batterie.

Finalement, il évoque la sérialisation, qui est très coûteuse en terme de ressources. Que faire ? Il est typiquement possible d’utiliser le mot clé “transient” pour indiquer qu’il ne faudra pas sérialiser une variable pour, encore une fois, ne pas trop consommer.
La question de l’efficacité au niveau du type de donnée se pose également. La réduction de place en mémoire passe par l’emploi de types appropriés. De cette manière on minimise la perte d’espace alloué. Il est vrai que la mémoire ne coûte pas cher, mais pourquoi mal l’utiliser et devoir en rajouter pour cela.

La présentation se conclue sur quatre points :

  • Opter pour des solutions Keep It Simple, Stupit (KISS);
  • Oublier un peu la course à la technologie;
  • Regarder sous le capot (pour savoir comment est géré la mémoire, par exemple)
  • Et une demande aux développeurs de framework d’intégrer l’éco-design, dès le bas niveau.

 

Quel a été notre ressenti par rapport à cette conférences ? Globalement, on a trouvé que le sujet avait été abordé de manière trop légère (en même temps 50 minutes c’est assez court). Mais notre regret principal vient du fait qu’en sortant de la conférence on n’a pas été réellement séduit ni notre curiosité assez aiguisée pour avoir envie d’approfondir le sujet. Peut être que d’avantages d’exemples concrets sur un réel gain (que se soit au niveau de temps de production, performances de l’application, coûts de mise en service..) aurait pu nous faire changer d’avis. A voir comment ces idées évolueront au fils des mois qui viennent mais nous pensons quand même qu’il s’agit de concepts porteurs dont on n’a pas encore fini de parler. Encore merci à Olivier Philippot pour cette conférence.

Quelques liens utiles :

Nombre de vue : 48

COMMENTAIRES 2 commentaires

  1. Bonjour

    Merci pour ce résumé ! Effectivement le sujet est vaste et 50 mn sont courtes pour l’aborder. Je prends notre pour les gains concrets pour ma prochaine présentation 😉

  2. […] Un très bon résumé chez Soat. […]

AJOUTER UN COMMENTAIRE