Le langage C ne sera-t-il jamais battu en termes de rapidité d'exécution et de faible consommation d'énergie ?
Voici les résultats d'une étude sur 27 langages de programmation les plus populaires
Le 2020-03-12 10:39:07, par Victor Alisson, Membre chevronné
L’étude réalisée par des chercheurs portugais révèle que C se positionne comme le langage de programmation le plus performant en termes de temps d’exécution et de faible consommation d’énergie (du CPU et de la RAM). C’est le résultat issu du benchmark ainsi effectué se basant sur le Computer Language Benchmarks Game (CLBG) pour comparer les 27 langages les plus populaires auprès des développeurs. Le papier relatant cette étude a été publié pour la première fois en 2017 dans International Conference on Software Language Engineering (SLE) ; une mise à jour de cette analyse comparative a été effectuée pour l’année 2020, mais concernant uniquement les langages fonctionnels.
Pour revenir aux résultats de l’étude initialement réalisée (2017), C affiche les valeurs les plus faibles par rapport à celles des 26 autres langages considérés en ce qui concerne le temps d’exécution (2019.26 ms) et la consommation d’énergie (57.86 J) dans l’exécution des solutions relatives aux dix problèmes retenus dans l’initiative CLBG. En revanche, c’est Pascal qui affiche la consommation de mémoire la moins élevée (65.96 Mb). La normalisation des valeurs de ces trois variables (en divisant les valeurs associées à chaque langage par ces valeurs minimales) a permis de dresser le tableau ci-après, les valeurs étant rangées de manière croissante :
Tableau des valeurs normalisées de l’énergie consommée, du temps d’exécution, et de la mémoire occupée pour chaque langage
L’on constate que C figure tout de même en troisième place en matière de consommation de mémoire, derrière Pascal et Go. Sur ce point, la différence entre C et Pascal est de l’ordre de 11.21 Mb, c’est-à-dire que le premier est 1.17 fois plus consommateur de mémoire que le second.
La mise à jour 2020 (voir tableau suivant), quant à elle, considère uniquement dix langages fonctionnels, dont le nouveau venu : Julia, un langage de programmation de haut niveau créé en 2009 et publié au grand public en 2012. Dorénavant, Julia aurait gagné un certain succès auprès de la communauté scientifique en 2018, justifiant alors son intégration dans l’échantillon du benchmark. En fait, Julia vient se placer juste derrière Rust.
Tableau des valeurs normalisées pour les langages fonctionnels
Il faut tout de même dire que les rangs présentés dans ce tableau de la mise à jour 2020 n’ont pas beaucoup changé par rapport à ceux de l’étude de 2017. Ainsi, Rust tient toujours la première place du classement dans cette catégorie de langages (fonctionnels). L’on remarque tout simplement la remontée de Lisp en termes de performance énergétique et la descente de Haskell en ce qui concerne la rapidité d’exécution.
Certes, dans l’étude de 2017, Rust suit de près le langage C avec des différences de l’ordre de 80.77 ms en temps d’exécution et de 1.74 J en énergie consommée (ce qui peut être considéré comme faible comparé aux valeurs associées aux autres langages de programmation en bas de classement). L’on constate ensuite que la nouvelle version de Rust consomme moins d’énergie et s’exécute plus rapidement par rapport à celle qui est prise en compte dans l’étude de 2017.
Toutefois, les différences ne sont pas encore suffisantes pour dépasser C dans le classement, car le ratio entre l’énergie consommée et le temps d’exécution (l’équivalent de la puissance exprimée en kW) pour Rust reste inchangé (0.039). De plus, ce dernier devient plus vorace dans la consommation de mémoire. En tout cas, la performance de la nouvelle version de Rust ne dépasse pas encore celle de C en valeur absolue (pour les trois variables étudiées).
En somme, le langage C reste indétrônable, et l’on se demande jusqu’à quand il préservera cette position. Il convient toutefois de noter que cela ne permet pas de conclure qu’il y a une relation fonctionnelle entre les trois variables de l’étude (énergie consommée, temps d’exécution, mémoire consommée).
Sources : Software Language Engineering (SLE), GitHub (Energy Languages)
Et vous ?
Voir aussi :
Pour revenir aux résultats de l’étude initialement réalisée (2017), C affiche les valeurs les plus faibles par rapport à celles des 26 autres langages considérés en ce qui concerne le temps d’exécution (2019.26 ms) et la consommation d’énergie (57.86 J) dans l’exécution des solutions relatives aux dix problèmes retenus dans l’initiative CLBG. En revanche, c’est Pascal qui affiche la consommation de mémoire la moins élevée (65.96 Mb). La normalisation des valeurs de ces trois variables (en divisant les valeurs associées à chaque langage par ces valeurs minimales) a permis de dresser le tableau ci-après, les valeurs étant rangées de manière croissante :
Tableau des valeurs normalisées de l’énergie consommée, du temps d’exécution, et de la mémoire occupée pour chaque langage
L’on constate que C figure tout de même en troisième place en matière de consommation de mémoire, derrière Pascal et Go. Sur ce point, la différence entre C et Pascal est de l’ordre de 11.21 Mb, c’est-à-dire que le premier est 1.17 fois plus consommateur de mémoire que le second.
La mise à jour 2020 (voir tableau suivant), quant à elle, considère uniquement dix langages fonctionnels, dont le nouveau venu : Julia, un langage de programmation de haut niveau créé en 2009 et publié au grand public en 2012. Dorénavant, Julia aurait gagné un certain succès auprès de la communauté scientifique en 2018, justifiant alors son intégration dans l’échantillon du benchmark. En fait, Julia vient se placer juste derrière Rust.
Tableau des valeurs normalisées pour les langages fonctionnels
Il faut tout de même dire que les rangs présentés dans ce tableau de la mise à jour 2020 n’ont pas beaucoup changé par rapport à ceux de l’étude de 2017. Ainsi, Rust tient toujours la première place du classement dans cette catégorie de langages (fonctionnels). L’on remarque tout simplement la remontée de Lisp en termes de performance énergétique et la descente de Haskell en ce qui concerne la rapidité d’exécution.
Certes, dans l’étude de 2017, Rust suit de près le langage C avec des différences de l’ordre de 80.77 ms en temps d’exécution et de 1.74 J en énergie consommée (ce qui peut être considéré comme faible comparé aux valeurs associées aux autres langages de programmation en bas de classement). L’on constate ensuite que la nouvelle version de Rust consomme moins d’énergie et s’exécute plus rapidement par rapport à celle qui est prise en compte dans l’étude de 2017.
Toutefois, les différences ne sont pas encore suffisantes pour dépasser C dans le classement, car le ratio entre l’énergie consommée et le temps d’exécution (l’équivalent de la puissance exprimée en kW) pour Rust reste inchangé (0.039). De plus, ce dernier devient plus vorace dans la consommation de mémoire. En tout cas, la performance de la nouvelle version de Rust ne dépasse pas encore celle de C en valeur absolue (pour les trois variables étudiées).
En somme, le langage C reste indétrônable, et l’on se demande jusqu’à quand il préservera cette position. Il convient toutefois de noter que cela ne permet pas de conclure qu’il y a une relation fonctionnelle entre les trois variables de l’étude (énergie consommée, temps d’exécution, mémoire consommée).
Sources : Software Language Engineering (SLE), GitHub (Energy Languages)
Et vous ?
Voir aussi :
-
UtherExpert éminent séniorA peut près tous les gros (Microsoft, Oracle, Mozilla, Apple, Google, ...) qui ont fait la mesure sur leurs applications C++ sont arrivés au même résultat : plus des 2/3 des failles de sécurité critiques sur ces applications sont causées par des erreurs qui sont impossible en Rust "safe". Pourtant elles ne sont pas codées par des charlots ni des débutants et ils ont une vraie politique de revue et d'analyse de sécurité.
Mais un développeur reste un humain faillible, sur une quantité de code significative et complexe, même les meilleurs finissent fatalement par laisser passer des erreurs.
Avoir des développeurs compétents et bien formés, c'est bien mais pas suffisant. Avoir un bon outil qui empêche de faire certaines erreur, c'est aussi une bonne chose. Les deux ne sont pas du tout exclusif.le 23/02/2022 à 7:42 -
bizulkMembre confirmé"De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C."
Je t'invite à tenter de concurrencer un compilateur C avec ton source en langage d'assemblage.le 01/12/2021 à 10:48 -
walfratMembre émériteCombien ça représenterais d'énergie vraiment économisée ?
Combien ça pèserai face au flx stream 4k voir 8k qui saturent nos réseaux ?le 01/12/2021 à 9:21 -
Il est clair que les codes compilés statiquement apportent un gros plus en terme d'usage CPU et d'empreinte mémoire par rapport aux langages interprétés ou compilés à la volée.
Mais il est fort illusoire de croire que les devs JS migrent massivement vers Rust. Et JS est une catastrophe à tout point de vue, pas qu'environnementale.le 01/12/2021 à 8:32 -
Python reste bien plus performant énergétiquement parlant qu'un fichier Excel bourré de macros et de formules circulaires, puisque c'est a cette catégorie d'utilisateurs que ce langage s'adresse.
Ajouté à cela, la plupart des bibliothèques du langage sont des bindings vers des briques codées en C/C++.le 06/10/2022 à 18:24 -
UtherExpert éminent séniorComme expliqué, par d'autres, Python est censé être un langage de script qui n'est pas fait pour être utilisé directement pour de la performance brute. S'il est utilisé judicieusement dans son domaine, ça n'est pas un problème.
Malheureusement c'est devenu un langage généraliste très utilisé dans la data science et l'IA et souvent par des non-informaticiens pas toujours très au courant des problématiques de performance. Du coup c'est une vraie problématique sur laquelle il faut informer, d'autant que de nos jour où avec le Cloud c'est assez tentant de simplement augmenter la puissance de calcul pour compenser un manque de performances.le 06/10/2022 à 18:43 -
esperantoMembre émériteDonc, l'écologie aujourd'hui, c'est utiliser son pc puissant comme un simple terminal pour se connecter à une machine Azure, avec toute la lourdeur de l'interface Windows 10, lancer un IDE écrit en C# genre Visual Studio... mais programmer en C parce qu'il consomme 3 pour cent de moins que Rust, c'est bien ça?le 22/02/2022 à 15:14
-
rawsrcExpert éminent sénioren tout cas, je suis sacrément impressionné par Rust.
Sur la programmation système et autres logiciels bas niveau, c'est carrément bluffant.
Je vais sortir ma boule de cristal et comme plusieurs personnes autour de moi, je prédis un avenir de dingue à ce langage.
À titre perso, je suis en train de le découvrir. Comme disent les jeunes : c'est d'la ballele 12/03/2020 à 14:41 -
herr_wannMembre confirméCe n'est pas vraiment comme cela que je l'interprète ( jeu de mot pourri insideTous les 5 ans on tourne la grande roue des langages de programmation.
Cette année c'est tombé sur Rust.
Un langage à la syntaxe hyper compliquée, qui est accessible uniquement pour les "déjà" développeurs.
Pourquoi les langages sont devenus aussi compliqués à installer et à utiliser ? Y a aucune raison pour cela.
Tu m'étonnes que les entreprises manquent de bons développeurs, s'il faut réapprendre un langage tous les 2 ans parce qu'il est devenu tendance.
). Rust a été conçu comme un C/C++ amélioré afin d'éviter les erreurs les plus fréquentes de gestion de la mémoire et de programmation asynchrone/parallèle, sans impacter les performances. Il est donc apprécié malgré la courbe d'apprentissage un peu raide par les programmeurs système, drivers, jeux vidéo et blockchain. Même si on peut tout faire, ce sont surtout ces domaines où il apporte le plus de valeur ajoutée. Il est donc censé remplacer un langage vieux de 40 ou 50 ans.
De plus il est très simple à installer, il est libre et gratuit, possède de bons utilitaires de gestion de packages, le compilateur est strict mais il apporte une grande aide pour résoudre les problèmes à la compilation et non après.le 22/02/2022 à 15:41 -
smartiesExpert confirméAvant d'accuser Python, il faudrait agir en amont :
- garder le plus longtemps ses ressources informatique et ne pas renouveler tant que ça ne tombe pas en panne (et on peut généralement réparer)
- mutualiser les ressources, tous les serveurs ne demandent pas 100% de puissance ou de RAM tout le temps !
Python est certes pas très rapide mais il est adossé à plusieurs bibliothèques natives aussi ! Donc quand le programme Python ne fait pas de calcul, il ne doit pas avoir une forte emprunte énergétique.
Dans le milieu scientifique, quelle est l'emprunte de Matlab et de Scilab ?le 06/10/2022 à 19:28