Tous les langages ne se valent pas

[Case study sur le triptyque énergie, temps d’exécution, mémoire]

Ce n’est pas un scoop, il est essentiel de passer du temps dans la phase de spécification pour concevoir un produit électronique performant et efficient. Quand il s’agit de logiciel embarqué, ces produits électroniques, pilotés par ce même logiciel, vont se comporter bien différemment en fonction du langage choisi. Ce choix du langage peut (et doit !) être abordé durant la phase de spécification. Évidemment, ce choix peut être différent entre les phases de prototypage et les phases de déploiement produit. On peut en effet sélectionner un langage avec un haut niveau d’abstraction pour prototyper de façon efficace et rapide, mais porter son choix vers un langage plus performant une fois l’étape de prototype passée. Néanmoins, de plus en plus de langages sont proposés aux développeurs, et le choix d’un langage n’est pas si simple à effectuer face à une telle diversité.

Et pour ne pas faciliter le choix des développeurs, on se rend compte que la popularité elle-même des langages évolue (parfois fortement) d’une année à l’autre. Par exemple, pour regarder les tendances, on peut consulter l’étude faite par RedMonk^[1], mise à jour tous les ans à l’aide du recueil des données de GitHub et Stack Overflow. Alors, on peut tout de même constater que certains facteurs impactent le choix du langage, notamment les contraintes s’appliquant sur le produit, les développeurs (formés plus ou moins à certains langages, ou aimant plus ou moins certains langages 😉), la rapidité à développer en fonction du langage, car le temps de développement sur les projets notamment embarqués est perçu comme étant la contrainte la plus forte, ou encore les aspects sécurité (avec un choix pouvant exclure certains langages pour lesquels la gestion mémoire est une tâche affectée au développeur).

Choisir le langage en fonction du triptyque.

Une chose est sûre, le choix d’un langage a un impact sur les performances de l’application considérée, c’est-à-dire le triptyque temps d’exécution, mémoire et énergie, et donc du produit conçu, même si, ne nous voilons pas la face, un bon langage ne sauvera pas un code non optimisé. Alors, la question qui se pose est comment être en mesure de faire un choix et de comparer ces différents langages selon ces trois aspects ? La comparaison s’avère, en effet, délicate, car il faut comparer le comparable, et que les benchmarks implémentés dans les différents langages doivent être implémentés de façon “équivalente”. Plusieurs mécontentements à ce sujet, et pourtant, les différentes études tendent vers le même constat…

Prenons cette étude^[2] en exemple où le travail a été réalisé en mesurant les performances de différentes implémentations de benchmarks selon 27 langages. Les benchmarks choisis font partie de The Computer Language Benchmark Game^[3] (CLBG), une référence de benchmarks à utiliser pour pouvoir réaliser ces comparaisons entre différents langages. Pour chaque benchmark implémenté, des règles strictes d’implémentation doivent être respectées de manière à permettre une comparaison juste. En effet, je suis sûre qu’un développeur anti C++ mal intentionné pourrait rendre une implémentation C++ d’un code bien plus lente que du Python 😉 Oups, je spoile les résultats de l’étude.

L’un des objectifs de cette étude était de déterminer si le fait de se concentrer sur des langages permettant d’améliorer la rapidité d’exécution du code avait également un impact positif sur la consommation d’énergie. Les aspects mémoire ont eux aussi été pris en compte à travers cette étude, notamment en mesurant le pic d’utilisation de la mémoire. Concernant la mesure de la consommation d’énergie, RAPL, l’outil proposé par Intel a été utilisé. Il permet de mesurer de façon très fine la consommation d’énergie d’un programme, mais plus sur cet outil à venir ! Chaque mesure a été réalisée à partir d’une moyenne de dix exécutions de chaque implémentation, de manière à modérer les effets de cache à l’initialisation. L’article présentant cette étude ayant été publié en 2017 (et donc les expérimentations ayant sûrement été réalisées avant), vous excuserez le processeur utilisé à l’époque qui était un Intel(R) Core(™) i5-4460 (Haswell, OS de type Ubuntu 16.10, 16GB de RAM, 3.20 GHz), la crème de la crème de l’époque.

Les différents langages considérés dans cette étude sont classés selon différents paradigmes :

• fonctionnel : utilisation de fonctions pour structurer son code avec des liens possibles entre les différentes fonctions et un possible passage de certaines en paramètre d’autres fonctions. Ce paradigme de programmation se rapproche fortement des fonctions au sens mathématique (par exemple, Ocaml, Perl, Rust…).
• impératif : description d’une séquence précise d’instructions pour permettre des changements d’états (par exemple, Ada, C, C++, Go, Rust…).
• orienté objet : définition et interaction entre des briques logicielles qui sont des objets. Un objet a sa propre structure interne et peut interagir avec d’autres objets (par exemple, Ada, C++, Java, Python…).
• script (par exemple, JavaScript, Python, Perl…).

Analyse du triptyque consommation d’énergie, temps d’exécution, mémoire.

L’un des objectifs de cette étude était d’analyser le triptyque consommation d’énergie, temps d’exécution, mémoire, et les différents liens entre ces trois paramètres. L’objectif ultime de cette étude était d’être en mesure de proposer un guide pour permettre aux développeurs de choisir leur langage de programmation en fonction de leurs contraintes, qu’elles soient de l’ordre de la mémoire, de l’énergie, ou du temps d’exécution.

En regardant dans un premier temps le lien mathématique entre la consommation d’énergie et le temps d’exécution d’une application logicielle, on peut facilement se faire avoir et se dire qu’optimiser pour le temps d’exécution permet d’optimiser pour la consommation d’énergie.

Pourquoi ? Parce que la relation est la suivante :

                                                                           E  =  P  x  t

où,

• E est l’énergie en Joules,
• P la puissance en Watts,
• t le temps en secondes.

En effet, si la puissance est constante, ce lien tient. Mais, ce n’est pas forcément le cas (Hello Dynamic Voltage Frequency Scaling 👋🏻). L’étude est donc d’autant plus intéressante qu’elle permet de montrer si les deux évoluent bien dans le même sens ou non !

Et donc… Tadam ! Roulement de tambour ! Les résultats de cette étude indiquent que les langages compilés sont en moyenne les plus rapides et efficaces énergétiquement. Concernant le top 5 des meilleurs langages sur les aspects temps d’exécution et énergie, on retrouve le C, Rust, C++, l’Ada et le Java (le seul n’étant pas compilé).

Le langage impacte les performances d’une application.

Vous le savez bien, chez WedoLow, on est de grands fans des langages C et C++. En termes de popularité, ces langages (avec le C#) restent également dans le top 5 malgré l’apparition écrasante du Python.

Le Python, parlons-en justement. Il est également dans le top 5… des langages les plus consommateurs de temps d’exécution et d’énergie. L’analyse a également été poussée pour déterminer ce qui consommait dans l’exécution de ces programmes, et c’est toujours majoritairement le CPU (le reste étant consommé par la mémoire dynamique). Ce qui peut être également constaté grâce à cette étude est que le rang des langages n’est pas forcément maintenu en fonction du critère analysé, on peut donc dire qu’il y a bien un classement spécifique à regarder en fonction du critère à analyser.

Et forcément, chez WedoLow, on prêche pour notre paroisse. Nous sommes convaincus que le choix du langage impacte fortement les performances de l’application. Dans une tendance d’écoconception, il est essentiel d’avoir en tête ces ordres de grandeur de performances, pour faire des choix éclairés dès la phase de spécification du produit/logiciel.

Contactez notre équipe d’experts pour échanger sur le sujet : sales@wedolow.com

^[1] https://redmonk.com/kfitzpatrick/2021/03/02/redmonk-top-20-languages-over-time-january-2021/

^[2] Pereira, Rui, et al. « Energy efficiency across programming languages: how do energy, time, and memory relate?. » Proceedings of the 10th ACM SIGPLAN international conference on software language engineering. 2017.

^[3] Gouy, Isaac. « The computer language benchmarks game. » URL http://benchmarksgame. alioth. debian. org (2017).