Programmation : une étude révèle les langages les plus voraces en énergie Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts 947PARTAGES 30 0 Quels sont les langages de programmation qui consomment le moins d'énergie ? C'est à cette question qu'ont voulu répondre six chercheurs de trois universités portugaises dans une étude intitulée « Energy Efficiency Across Programming Languages ». Dans leur recherche, ils étudient le temps d'exécution, l'utilisation de la mémoire, mais surtout la consommation d'énergie de 27 langages de programmation bien connus.



Lobjectif principal de leurs travaux était de comprendre lefficacité énergétique dans divers langages de programmation. Cela peut sembler une tâche simple, mais ce nest pas aussi trivial que cela puisse paraître. En effet, pour comparer correctement l'efficacité énergétique entre différents langages, il faut obtenir des implémentations comparables de solutions à un ensemble représentatif de problèmes.



D'abord, la méthodologie



Pour obtenir un ensemble de programmes comparables, représentatifs et complets écrits dans la plupart des langages de programmation les plus populaires et les plus largement utilisés, les chercheurs ont exploré le Computer Language Benchmarks Game (CLBG). L'initiative CLBG offre un framework pour exécuter, tester et comparer des solutions cohérentes mises en uvre pour un ensemble de problèmes de programmation bien connus et divers. Son objectif est en effet permettre à ceux qui le désirent de pouvoir comparer des solutions, au sein d'un même langage ou entre différents langages de programmation. Au moment de leur recherche, le CLBG proposait des solutions pour 13 problèmes de référence (ou benchmarks), de telle sorte que les solutions à chacun de ces problèmes respectent un algorithme donné et des directives de mise en uvre spécifiques. Les solutions à chaque problème sont exprimées au maximum dans 28 langages de programmation différents.





Parmi les 28 langages pris en compte dans le CLBG, les chercheurs ont exclu Smalltalk, car le compilateur de ce langage est propriétaire. De plus, pour des raisons de comparabilité, ils ont écarté les problèmes qui avaient une couverture de langages inférieure à 80 %. La couverture de langages d'un problème est le pourcentage de langages de programmation (sur les 27) dans lesquels des solutions sont disponibles pour ce problème. La définition de ce critère a permis d'exclure trois problèmes de l'étude.



Pour chacun des 10 problèmes restants, les chercheurs ont ensuite retenu la version de code source la plus efficace (cest-à-dire la plus rapide), pour les 27 langages de programmation considérés. La documentation du CLBG fournit également des informations sur la version spécifique du compilateur/runner utilisée pour chaque langage, ainsi que sur les options de compilation/exécution considérées. Les chercheurs disent avoir « strictement suivi ces instructions », qu'ils ont installé les versions correctes de compilateur et se sont également assurés que chaque solution était compilée/exécutée avec les mêmes options que celles utilisées dans le CLBG.



Ils ont aussi testé chaque solution retenue pour s'assurer qu'ils pouvaient les exécuter sans erreurs et que le résultat obtenu était celui attendu. L'étape suivante consistait à recueillir des informations sur la consommation d'énergie, le temps d'exécution et l'utilisation maximale de la mémoire pour chacune des solutions compilables et exécutables dans chaque langage.



Il est à noter que le CLBG contient déjà des informations mesurées à la fois sur le temps d'exécution et l'utilisation maximale de la mémoire. Les chercheurs ont mesuré les deux, non seulement pour vérifier la cohérence de leurs résultats par rapport à ceux du CLBG, mais également parce que des spécifications matérielles différentes produiraient des résultats différents.



Pour mesurer la consommation d'énergie, ils ont utilisé l'outil RAPL (Running Average Power Limit) d'Intel, capable de fournir des estimations d'énergie très précises, comme cela a déjà été prouvé dans certaines études. A 10 reprises, chaque solution a été exécutée et les performances associées mesurées « afin de réduire limpact des démarrages à froid et des effets du cache, danalyser la cohérence des mesures et déviter les valeurs aberrantes ». Et ils rapportent que « les résultats mesurés sont assez cohérents ». Pour plus de cohérence, tous les tests ont été réalisés sur un ordinateur de bureau exécutant Linux Ubuntu Server 16.10, avec 16 Go de RAM et un processeur Intel Core i5-4460 cadencé à 3.20 GHz.



Après toutes ces précautions prises pour avoir des résultats pertinents, que révèlent les travaux des chercheurs ?



Maintenant, les résultats de l'étude



Quels sont les meilleurs langages par critère ?



Le tableau ci-dessous présente les résultats globaux (en moyenne) pour la consommation d'énergie (Energy), le temps d'exécution (Time) et la consommation maximale de la mémoire (Mb) normalisés par rapport au langage le plus efficace pour le critère mesuré. La première colonne donne le nom des langages de programmation, précédés des lettres (c), (i) ou (v) qui indiquent respectivement que le langage est compilé, interprété ou est un langage de machine virtuelle. Pour l'énergie consommée, on lit par exemple que C a la valeur 1,00 alors que Lisp a la valeur 2,27. Cela veut d'abord dire que C est le langage qui consomme le moins d'énergie et que Lisp consomme 2,27 fois plus d'énergie que C.





Le top 5 des langages qui consomment le moins d'énergie est donc C (1,00), Rust (1,03), C++ (1,34), Ada (1,70) et Java (1,98). À l'opposé, les langages les plus voraces en énergie sont Perl (79,58), Python (75,88), Ruby (69,91), Jruby (46,54) et Lua (45,98). Je vous laisse repérer votre langage préféré...



Au niveau de la rapidité des langages, le top 5 reste inchangé : C, Rust, C++, Ada et Java. Ainsi, les langages les plus rapides sont-ils ceux qui consomment le moins d'énergie ? Les chercheurs y apportent une réponse dans leur étude, mais on peut déjà voir que ce n'est pas parfaitement le cas, bien qu'il semble y avoir une forte corrélation. Parmi les langages les plus lents, on retrouve encore Lua, Ruby, Perl et Python dans le top 5, qui se voient rejoints par TypeScript.



Pour en venir aux langages qui consomment le moins de mémoire, la palme d'or revient à Pascal (1,00), suivi par Go (1,05), C (1,17), Fortran (1,24) et C++ (1,34) pour fermer le top 5. Cette fois, Python (2,80) remonte dans la première moitié du classement, tandis que Perl (6,26) se retrouve encore dans les 5 pires langages.



Quels sont les meilleurs langages si l'on combine plusieurs critères ?



Le tableau ci-dessous présente quatre classements en combinant plusieurs objectifs : temps d'exécution et mémoire utilisée, énergie consommée et temps d'exécution, énergie consommée et mémoire utilisée, et enfin les trois critères en même temps. Pour chaque classement, chaque ligne représente un ensemble optimal de Pareto, c'est-à-dire un ensemble de langages « équivalents » du point de vue des critères combinés. L'ordre de chaque ligne représente également le rang des langages dans le classement associé.





Certaines applications nécessitent la prise en compte de deux facteurs - par exemple, la consommation dénergie et le temps dexécution. Dans ce cas, comme le montre le tableau ci-dessus, « le langage C est la meilleure solution, car il domine dans les deux objectifs », écrivent les chercheurs. Si vous essayez de gagner du temps en utilisant moins de mémoire, C, Pascal et Go « sont équivalents » et sont les meilleures options. Il en est de même si vous regardez les trois critères (temps d'exécution, consommation d'énergie et utilisation de la mémoire). Mais si vous voulez simplement économiser de lénergie tout en utilisant moins de mémoire, les meilleurs choix possible sont C ou Pascal.



Les chercheurs ont également comparé les résultats des langages compilés et interprétés (avec une catégorie distincte pour les langages exécutés sur des machines virtuelles). Leur étude inclut également une comparaison des différents paradigmes de programmation : fonctionnel, impératif, orienté objet et script.



Langages compilés VS langages interprétés VS langages exécutés sur des machines virtuelles



Comme on peut le voit dans le premier tableau, l'étude montre que « les langages compilés ont tendance à être les plus rapides et les plus écoénergétiques. En moyenne, les langages compilés ont consommé 120 J pour exécuter les solutions, tandis que pour les langages de machine virtuelle et interprétés, leurs consommations moyennes étaient respectivement de 576 J et 2365 J. »



Cette tendance peut également être observée pour le temps d'exécution. « Les langages compilés ont pris en moyenne 5103 ms, les langages de machine virtuelle, 20 623 ms et les langages interprétés, 87 614 ms ». En outre, comme nous l'avons déjà fait remarquer, « les 5 principaux langages nécessitant moins dénergie et de temps pour exécuter les solutions sont : C, Rust, C++, Ada et Java ; parmi ceux-ci, seul Java n'est pas compilé ».



Aussi, les cinq langages les plus lents sont tous interprétés : Lua, Python, Perl, Ruby et Typescript. Et les cinq langages consommant le plus d'énergie sont également des langages interprétés : Perl, Python, Ruby, JRuby et Lua. Les chercheurs précisent toutefois qu'en même temps, lorsqu'il s'agit de manipuler des chaînes avec une expression régulière, trois des cinq langages les plus économes en énergie se révèlent être des langages interprétés (TypeScript, JavaScript et PHP), « bien qu'ils aient tendance à ne pas être très efficaces en énergie dans d'autres scénarios. »



Les langages compilés ont également pris les cinq premières places du classement des langages qui utilisent le moins despace mémoire. « En moyenne, les langages compilés avaient besoin de 125 Mo, les langages de machine virtuelle, de 285 Mo et les interprétés, de 426 Mo », ont indiqué les chercheurs. Les langages interprétés comme JRuby, Dart, Lua et Perl occupaient quatre des cinq dernières places, ce qui signifie qu'ils utilisent en général plus d'espace mémoire.



Comparaison des paradigmes de programmation



Lorsque l'on compare les différents paradigmes, la programmation impérative est souvent la meilleure des solutions. Les langages de ce groupe ont utilisé beaucoup moins d'énergie en moyenne - et se sont exécuté beaucoup plus vite - que les langages orientés objet, fonctionnels et de script. « En moyenne, les langages impératifs ont consommé 125 J et pris 5585 ms, les langages orientés objet ont consommé 879 J et pris 32 965 ms, les langages fonctionnels ont consommé 1367 J et pris 42 740 ms et les langages de script ont consommé 2320 J et pris 88 322 ms », indiquent les chercheurs. « Pour l'utilisation de la mémoire, les langages impératifs avaient besoin de 116 Mo, 249 Mo pour les langages orientés objet, 251 Mo pour les langages fonctionnels et enfin, 421 Mo pour les langages de script. »



Les langages les plus rapides sont-ils les plus verts ?



Les chercheurs ont examiné de près lhypothèse courante selon laquelle un programme plus rapide consomme toujours moins dénergie, et souligné qu'ici ce nest pas aussi simple comme en physique où l'on admet que la consommation d'énergie par un appareil est le produit entre le temps de fonctionnement et la puissance. Les chercheurs estiment en effet que cela suppose que la puissance est constante dans le temps, or la consommation dénergie d'un langage est affectée par de nombreux facteurs (y compris la qualité du compilateur et les bibliothèques utilisées). Ainsi, comme le montrent leurs résultats d'ailleurs, les chercheurs affirment qu'un « langage plus rapide nest pas toujours plus économe en énergie ».



Il est vrai que « les cinq langages les plus économes en énergie conservent leur position lorsqu'ils sont classés en fonction du temps d'exécution et avec de très petites différences entre les scores de consommation d'énergie et de temps d'exécution », mais on ne fait pas le même constat lorsqu'on regarde tous les langages. En effet, « seuls quatre langages conservent le même rang pour la consommation énergétique et le temps d'exécution (OCaml, Haskel, Racket et Python), tandis que les autres sont complètement mélangés », notent les chercheurs.



Source :



Et vous ?



Que pensez-vous de la méthodologie et des résultats de la recherche ?

Confirment-ils vos attentes ?



Voir aussi :



JavaScript s'inscrit-il dans une démarche Green IT ? Les applications Node.js semblent moins voraces en ressources que celles basées sur JEE ou PHP

Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui, selon un expert

Quels sont les langages de programmation que vous voulez apprendre en 2019 ? Et pour quelles raisons ?

Quelle influence les développeurs exercent-ils sur les investissements dans les plateformes et outils de développement ? Partagez votre expérience

Quels sont les langages de programmation les plus utilisés par les développeurs ? Une analyse des évènements publics sur GitHub Quels sont les langages de programmation qui consomment le moins d'énergie ? C'est à cette question qu'ont voulu répondre six chercheurs de trois universités portugaises dans une étude intitulée « Energy Efficiency Across Programming Languages ». Dans leur recherche, ils étudient le temps d'exécution, l'utilisation de la mémoire, mais surtout la consommation d'énergie de 27 langages de programmation bien connus.Lobjectif principal de leurs travaux était de comprendre lefficacité énergétique dans divers langages de programmation. Cela peut sembler une tâche simple, mais ce nest pas aussi trivial que cela puisse paraître. En effet, pour comparer correctement l'efficacité énergétique entre différents langages, il faut obtenir des implémentations comparables de solutions à un ensemble représentatif de problèmes.Pour obtenir un ensemble de programmes comparables, représentatifs et complets écrits dans la plupart des langages de programmation les plus populaires et les plus largement utilisés, les chercheurs ont exploré le Computer Language Benchmarks Game (CLBG). L'initiative CLBG offre un framework pour exécuter, tester et comparer des solutions cohérentes mises en uvre pour un ensemble de problèmes de programmation bien connus et divers. Son objectif est en effet permettre à ceux qui le désirent de pouvoir comparer des solutions, au sein d'un même langage ou entre différents langages de programmation. Au moment de leur recherche, le CLBG proposait des solutions pour 13 problèmes de référence (ou benchmarks), de telle sorte que les solutions à chacun de ces problèmes respectent un algorithme donné et des directives de mise en uvre spécifiques. Les solutions à chaque problème sont exprimées au maximum dans 28 langages de programmation différents.Parmi les 28 langages pris en compte dans le CLBG, les chercheurs ont exclu Smalltalk, car le compilateur de ce langage est propriétaire. De plus, pour des raisons de comparabilité, ils ont écarté les problèmes qui avaient une couverture de langages inférieure à 80 %. La couverture de langages d'un problème est le pourcentage de langages de programmation (sur les 27) dans lesquels des solutions sont disponibles pour ce problème. La définition de ce critère a permis d'exclure trois problèmes de l'étude.Pour chacun des 10 problèmes restants, les chercheurs ont ensuite retenu la version de code source la plus efficace (cest-à-dire la plus rapide), pour les 27 langages de programmation considérés. La documentation du CLBG fournit également des informations sur la version spécifique du compilateur/runner utilisée pour chaque langage, ainsi que sur les options de compilation/exécution considérées. Les chercheurs disent avoir « strictement suivi ces instructions », qu'ils ont installé les versions correctes de compilateur et se sont également assurés que chaque solution était compilée/exécutée avec les mêmes options que celles utilisées dans le CLBG.Ils ont aussi testé chaque solution retenue pour s'assurer qu'ils pouvaient les exécuter sans erreurs et que le résultat obtenu était celui attendu. L'étape suivante consistait à recueillir des informations sur la consommation d'énergie, le temps d'exécution et l'utilisation maximale de la mémoire pour chacune des solutions compilables et exécutables dans chaque langage.Il est à noter que le CLBG contient déjà des informations mesurées à la fois sur le temps d'exécution et l'utilisation maximale de la mémoire. Les chercheurs ont mesuré les deux, non seulement pour vérifier la cohérence de leurs résultats par rapport à ceux du CLBG, mais également parce que des spécifications matérielles différentes produiraient des résultats différents.Pour mesurer la consommation d'énergie, ils ont utilisé l'outil RAPL (Running Average Power Limit) d'Intel, capable de fournir des estimations d'énergie très précises, comme cela a déjà été prouvé dans certaines études. A 10 reprises, chaque solution a été exécutée et les performances associées mesurées « afin de réduire limpact des démarrages à froid et des effets du cache, danalyser la cohérence des mesures et déviter les valeurs aberrantes ». Et ils rapportent que « les résultats mesurés sont assez cohérents ». Pour plus de cohérence, tous les tests ont été réalisés sur un ordinateur de bureau exécutant Linux Ubuntu Server 16.10, avec 16 Go de RAM et un processeur Intel Core i5-4460 cadencé à 3.20 GHz.Après toutes ces précautions prises pour avoir des résultats pertinents, que révèlent les travaux des chercheurs ?Le tableau ci-dessous présente les résultats globaux (en moyenne) pour la consommation d'énergie (Energy), le temps d'exécution (Time) et la consommation maximale de la mémoire (Mb) normalisés par rapport au langage le plus efficace pour le critère mesuré. La première colonne donne le nom des langages de programmation, précédés des lettres (c), (i) ou (v) qui indiquent respectivement que le langage est compilé, interprété ou est un langage de machine virtuelle. Pour l'énergie consommée, on lit par exemple que C a la valeur 1,00 alors que Lisp a la valeur 2,27. Cela veut d'abord dire que C est le langage qui consomme le moins d'énergie et que Lisp consomme 2,27 fois plus d'énergie que C.Le top 5 des langages qui consomment le moins d'énergie est donc C (1,00), Rust (1,03), C++ (1,34), Ada (1,70) et Java (1,98). À l'opposé, les langages les plus voraces en énergie sont Perl (79,58), Python (75,88), Ruby (69,91), Jruby (46,54) et Lua (45,98). Je vous laisse repérer votre langage préféré...Au niveau de la rapidité des langages, le top 5 reste inchangé : C, Rust, C++, Ada et Java. Ainsi, les langages les plus rapides sont-ils ceux qui consomment le moins d'énergie ? Les chercheurs y apportent une réponse dans leur étude, mais on peut déjà voir que ce n'est pas parfaitement le cas, bien qu'il semble y avoir une forte corrélation. Parmi les langages les plus lents, on retrouve encore Lua, Ruby, Perl et Python dans le top 5, qui se voient rejoints par TypeScript.Pour en venir aux langages qui consomment le moins de mémoire, la palme d'or revient à Pascal (1,00), suivi par Go (1,05), C (1,17), Fortran (1,24) et C++ (1,34) pour fermer le top 5. Cette fois, Python (2,80) remonte dans la première moitié du classement, tandis que Perl (6,26) se retrouve encore dans les 5 pires langages.Le tableau ci-dessous présente quatre classements en combinant plusieurs objectifs : temps d'exécution et mémoire utilisée, énergie consommée et temps d'exécution, énergie consommée et mémoire utilisée, et enfin les trois critères en même temps. Pour chaque classement, chaque ligne représente un ensemble optimal de Pareto, c'est-à-dire un ensemble de langages « équivalents » du point de vue des critères combinés. L'ordre de chaque ligne représente également le rang des langages dans le classement associé.Certaines applications nécessitent la prise en compte de deux facteurs - par exemple, la consommation dénergie et le temps dexécution. Dans ce cas, comme le montre le tableau ci-dessus, « le langage C est la meilleure solution, car il domine dans les deux objectifs », écrivent les chercheurs. Si vous essayez de gagner du temps en utilisant moins de mémoire, C, Pascal et Go « sont équivalents » et sont les meilleures options. Il en est de même si vous regardez les trois critères (temps d'exécution, consommation d'énergie et utilisation de la mémoire). Mais si vous voulez simplement économiser de lénergie tout en utilisant moins de mémoire, les meilleurs choix possible sont C ou Pascal.Les chercheurs ont également comparé les résultats des langages compilés et interprétés (avec une catégorie distincte pour les langages exécutés sur des machines virtuelles). Leur étude inclut également une comparaison des différents paradigmes de programmation : fonctionnel, impératif, orienté objet et script.Comme on peut le voit dans le premier tableau, l'étude montre que « les langages compilés ont tendance à être les plus rapides et les plus écoénergétiques. En moyenne, les langages compilés ont consommé 120 J pour exécuter les solutions, tandis que pour les langages de machine virtuelle et interprétés, leurs consommations moyennes étaient respectivement de 576 J et 2365 J. »Cette tendance peut également être observée pour le temps d'exécution. « Les langages compilés ont pris en moyenne 5103 ms, les langages de machine virtuelle, 20 623 ms et les langages interprétés, 87 614 ms ». En outre, comme nous l'avons déjà fait remarquer, « les 5 principaux langages nécessitant moins dénergie et de temps pour exécuter les solutions sont : C, Rust, C++, Ada et Java ; parmi ceux-ci, seul Java n'est pas compilé ».Aussi, les cinq langages les plus lents sont tous interprétés : Lua, Python, Perl, Ruby et Typescript. Et les cinq langages consommant le plus d'énergie sont également des langages interprétés : Perl, Python, Ruby, JRuby et Lua. Les chercheurs précisent toutefois qu'en même temps, lorsqu'il s'agit de manipuler des chaînes avec une expression régulière, trois des cinq langages les plus économes en énergie se révèlent être des langages interprétés (TypeScript, JavaScript et PHP), « bien qu'ils aient tendance à ne pas être très efficaces en énergie dans d'autres scénarios. »Les langages compilés ont également pris les cinq premières places du classement des langages qui utilisent le moins despace mémoire. « En moyenne, les langages compilés avaient besoin de 125 Mo, les langages de machine virtuelle, de 285 Mo et les interprétés, de 426 Mo », ont indiqué les chercheurs. Les langages interprétés comme JRuby, Dart, Lua et Perl occupaient quatre des cinq dernières places, ce qui signifie qu'ils utilisent en général plus d'espace mémoire.Lorsque l'on compare les différents paradigmes, la programmation impérative est souvent la meilleure des solutions. Les langages de ce groupe ont utilisé beaucoup moins d'énergie en moyenne - et se sont exécuté beaucoup plus vite - que les langages orientés objet, fonctionnels et de script. « En moyenne, les langages impératifs ont consommé 125 J et pris 5585 ms, les langages orientés objet ont consommé 879 J et pris 32 965 ms, les langages fonctionnels ont consommé 1367 J et pris 42 740 ms et les langages de script ont consommé 2320 J et pris 88 322 ms », indiquent les chercheurs. « Pour l'utilisation de la mémoire, les langages impératifs avaient besoin de 116 Mo, 249 Mo pour les langages orientés objet, 251 Mo pour les langages fonctionnels et enfin, 421 Mo pour les langages de script. »Les chercheurs ont examiné de près lhypothèse courante selon laquelle un programme plus rapide consomme toujours moins dénergie, et souligné qu'ici ce nest pas aussi simple comme en physique où l'on admet que la consommation d'énergie par un appareil est le produit entre le temps de fonctionnement et la puissance. Les chercheurs estiment en effet que cela suppose que la puissance est constante dans le temps, or la consommation dénergie d'un langage est affectée par de nombreux facteurs (y compris la qualité du compilateur et les bibliothèques utilisées). Ainsi, comme le montrent leurs résultats d'ailleurs, les chercheurs affirment qu'un « langage plus rapide nest pas toujours plus économe en énergie ».Il est vrai que « les cinq langages les plus économes en énergie conservent leur position lorsqu'ils sont classés en fonction du temps d'exécution et avec de très petites différences entre les scores de consommation d'énergie et de temps d'exécution », mais on ne fait pas le même constat lorsqu'on regarde tous les langages. En effet, « seuls quatre langages conservent le même rang pour la consommation énergétique et le temps d'exécution (OCaml, Haskel, Racket et Python), tandis que les autres sont complètement mélangés », notent les chercheurs.Source : Rapport de l'étude Que pensez-vous de la méthodologie et des résultats de la recherche ?Confirment-ils vos attentes ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 130 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Membre éprouvé https://www.developpez.com 13 0 Finalement je vois que je peux continuer à programmer en Pascal pour être à la pointe de la lute contre le changement climatique Membre expert https://www.developpez.com Envoyé par Steinvikel Envoyé par

Savoir que c'est mieux est une chose, pouvoir le mesurer en est une autre forte intéressante ! oui, l'assembleur gagnerait ...mais il aurait été très intéressant de savoir s'il gagnait de 10-20% ou bien avec une avance considérable ...et ce, sur chaque critère, ainsi que sur des critères combinés.Savoir que c'est mieux est une chose, pouvoir le mesurer en est une autre forte intéressante !



Généralement, le programme compilé sera plus rapide qu'un code purement assembleur, car les optimisations qu'il aura faites seront irréalisables par un développeur en pur assembleur, car trop fastidieuses et complexes, rébarbatives même.



Un compilateur peut par exemple mettre à plat des boucles si il constate que la taille est constante, ou bien réutiliser où non des zones mémoires en fonction des options d'optimisations données au compilateur. En GCC par exemple, on peut optimiser pour une taille des exécutables minimum, ou pour une performance maximum. Si on devait passer derrière la phase de compilation pour lire l'assembleur, on pourrait aisément être perdu, car il nous faudrait beaucoup de temps pour comprendre pourquoi il a prit telle ou telle décision.



L'assembleur ce n'est pas un langage magique qui a les meilleures performances dans tous les cas : pour certains cas d'utilisations seulement oui, dans certains contextes où par exemple un traitement simple sera effectué en boucle, l'assembleur pourra se montrer plus rapide exceptionnellement, mais en général, même dans ces cas là, la boucle générée par un compilateur sera optimisée d'une façon même totalement illisible de sorte qu'un programmeur n'aurait jamais pu maintenir un tel code.



Si la plupart des systèmes et logiciels, même nécessitant des hautes performances, sont codés dans un langage dit de "haut niveau" (comme le C), c'est parce que c'est à ce jour le meilleur compromis entre rapidité d'exécution, optimisation des performances, et lisibilité du code. On obtient en quelque sorte du très bien dans les 2 mondes, alors qu'en assembleur pur on "pourrait" obtenir du "parfait" en terme de performance et d'optimisation, mais au lourd prix d'un code illisible et inmaintenable. 10 0 En fait, l'optimisation des compilateurs est telle, que pour qu'un code en assembleur pur batte celui généré par le compilateur, il faut que ce soit un algorithme mathématiquement prouvé applicable au jeu d'instruction de l'assembleur.Généralement, le programme compilé seraqu'un code purement assembleur, car les optimisations qu'il aura faites seront irréalisables par un développeur en pur assembleur, car trop fastidieuses et complexes, rébarbatives même.Un compilateur peut par exemple mettre à plat des boucles si il constate que la taille est constante, ou bien réutiliser où non des zones mémoires en fonction des options d'optimisations données au compilateur. En GCC par exemple, on peut optimiser pour une taille des exécutables minimum, ou pour une performance maximum. Si on devait passer derrière la phase de compilation pour lire l'assembleur, on pourrait aisément être perdu, car il nous faudrait beaucoup de temps pour comprendre pourquoi il a prit telle ou telle décision.L'assembleur ce n'est pas un langage magique qui a les meilleures performances dans tous les cas : pour certains cas d'utilisations seulement oui, dans certains contextes où par exemple un traitement simple sera effectué en boucle, l'assembleur pourra se montrer plus rapide exceptionnellement, mais en général, même dans ces cas là, la boucle générée par un compilateur sera optimisée d'une façon même totalement illisible de sorte qu'un programmeur n'aurait jamais pu maintenir un tel code.Si la plupart des systèmes et logiciels, même nécessitant des hautes performances, sont codés dans un langage dit de "haut niveau" (comme le C), c'est parce que c'est à ce jour le meilleur compromis entre rapidité d'exécution, optimisation des performances, et lisibilité du code. On obtient en quelque sorte du très bien dans les 2 mondes, alors qu'en assembleur pur on "pourrait" obtenir du "parfait" en terme de performance et d'optimisation, mais au lourd prix d'un code illisible et inmaintenable. Modérateur https://www.developpez.com Envoyé par darklinux Envoyé par C 'est quoi l ' intérêt ? j ' aurais approuvé cette étude fin des années 1990 début 2000 à l ' époque ou les CPU étaient monocur et le SMP à la limite de ' expérimental , mais les CPU ont tellement évolué , comme les GPU . À la limite cela pourrait être valable sur smartphone ou tablette , mais qui programme la dessus en C ou Perl ???

Moins dénergie = gain sur la facture énergétique et possibilité d'envisager des sources d'énergie alternative.

Moins d'énergie = moins de chaleur à dissiper = investissement moindre.

L'intérêt financier est à mon avis pas négligeable.



C'est sur que sur ton pc lintérêt est limité. 8 0 A l'échelle d'un géant du web ou même d'un seul datacenter utiliser un langage qui va consommer 5 ou 10x moins d'énergie peut avoir de l'intérêt si il est aussi performant et productif.Moins dénergie = gain sur la facture énergétique et possibilité d'envisager des sources d'énergie alternative.Moins d'énergie = moins de chaleur à dissiper = investissement moindre.L'intérêt financier est à mon avis pas négligeable.C'est sur que sur ton pc lintérêt est limité. Expert éminent sénior https://www.developpez.com Le plus bizarre c'est surtout que TypeScript n'est jamais exécuté. Il transpile vers JavaScript qui lui est exécuté. Donc catégoriser TypeScript qui n'est déjà pas un langage à part entière (superset de JS) comme un langage interprété c'est, pour rester gentil, bizarre. Le plus bizarre c'est surtout que TypeScript n'est jamais exécuté. Il transpile vers JavaScript qui lui est exécuté. Donc catégoriser TypeScript qui n'est déjà pas un langage à part entière (superset de JS) comme un langage interprété c'est, pour rester gentil, bizarre.



La transpilation /compilation d'un langage peut avoir un impact sur les performance en mal, notamment si le langage de plus haut niveau introduit des mécanises qui peuvent impacter les performance (typage dynamique, GC), ou en bien si elle permet de produire du code plus efficace que ce qui aurait été fait manuellement (asm.js par exemple). 8 0 Ce n'est pas si bizarre que ça, en soi, de considérer le TS et le JS différent. Le C, Rust, Go,... pourraient aussi être considéré comme un superset du langage d'assemblage, ils n'en restent pas moins des langages différents.La transpilation /compilation d'un langage peut avoir un impact sur les performance en mal, notamment si le langage de plus haut niveau introduit des mécanises qui peuvent impacter les performance (typage dynamique, GC), ou en bien si elle permet de produire du code plus efficace que ce qui aurait été fait manuellement (asm.js par exemple). Expert éminent sénior https://www.developpez.com

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 balle 8 0 en 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 balle Expert éminent https://www.developpez.com Envoyé par darklinux Envoyé par C 'est quoi l ' intérêt ? j ' aurais approuvé cette étude fin des années 1990 début 2000 [...] mais les CPU ont tellement évolué , comme les GPU .



De plus cela sensibilise, si tu prends celui qui fait mumuse avec un raspberry avec du Python il se rendra compte que si son application est lente malgré toutes ses optimisations il peut obtenir une considérable amélioration en recodant tout en C. 7 0 Il existe toujours et il existera toujours des systèmes embarqués temps réel qui ne tournent pas sur des "machines de guerre".De plus cela sensibilise, si tu prends celui qui fait mumuse avec un raspberry avec du Python il se rendra compte que si son application est lente malgré toutes ses optimisations il peut obtenir une considérable amélioration en recodant tout en C. Membre éprouvé https://www.developpez.com

La méthode compare les langages sur les mêmes programmes, mais cela produit des distorsions curieuses, comme Java plus de deux fois plus rapide que Fortran, ce qui indique plutôt que Fortran est évalué sur des programmes en dehors de son domaine d'utilisation (calcul scientifique intensif). 6 0 Globalement, il vaut mieux être compilé qu'interprété, rien de bien révolutionnaire...La méthode compare les langages sur les mêmes programmes, mais cela produit des distorsions curieuses, comme Java plus de deux fois plus rapide que Fortran, ce qui indique plutôt que Fortran est évalué sur des programmes en dehors de son domaine d'utilisation (calcul scientifique intensif). Membre éprouvé https://www.developpez.com Envoyé par archqt Envoyé par Bah il gagnerait :-) 6 0 Je n'en suis pas sûr du tout, il y a des tas d'optimisations qu'un compilateur fait et qu'un humain ne penserait pas à appliquer. Je ne pense pas qu'un humain puisse rivaliser actuellement avec le boulot fait par gcc. Par contre, en optimisant "à la main" le programme C déjà compilé, un humain pourrait probablement trouver des spots améliorable et vaincre le compilateur, mais du coup ce n'est plus le programme écrit en assembleur d'après moi ^^ Expert éminent https://www.developpez.com

Je vais parler de JavaScript parce que cest le langage que je connais le mieux. Il ne passe pas une journée sans que je voie, sur le forum JS de Developpez.com, du code posté présentant des mauvaises pratiques et des sous-optimisations.

Pour moi, une étude plus pertinente serait « quelle est la proportion de mauvais code dans tel ou tel langage ? » 5 0 Pour faire une mesure pertinente, il faudrait prendre des échantillons représentatifs de codes en situation réelle, et ça inclut des mauvais codes, mal optimisés.Je vais parler de JavaScript parce que cest le langage que je connais le mieux. Il ne passe pas une journée sans que je voie, sur le forum JS de Developpez.com, du code posté présentant des mauvaises pratiques et des sous-optimisations.Pour moi, une étude plus pertinente serait « quelle est la proportion de mauvais code dans tel ou tel langage ? » Membre éprouvé https://www.developpez.com Envoyé par darklinux Envoyé par C 'est quoi l ' intérêt ? j ' aurais approuvé cette étude fin des années 1990 début 2000 à l ' époque ou les CPU étaient monocur et le SMP à la limite de ' expérimental , mais les CPU ont tellement évolué , comme les GPU . À la limite cela pourrait être valable sur smartphone ou tablette , mais qui programme la dessus en C ou Perl ???

pour la planète

pour la facture de l'entreprise

pour la rapidité du programme pour l'utilisateur



Par exemple Flask ou Django en python sont à 5% au nombre de requêtes réseaux par rapport à des frameworks compilés. On gagne peut être du temps au développement (pas sûr non plus) mais ensuite s'il faut déployer 20 serveurs au lieu d'un seul sur le long terme ce n'est pas gagnant....

Je n'ai plus la référence d'un article, dont la société avait refait son logiciel serveur d'envoi de SMS (pour orange de mémoire) en langage C au lieu du PHP et cela permettait d'envoyer 150 fois plus de SMS/seconde qu'avant. Sur le coup cela permet assez rapidement de rentrer dans ses fonds en dépensant moins en matériel/électricité.

Même facebook a fait un transpileur PHP -> C++ puis le code est compilé....et je ne parle même pas de l'embarqué (en général C/C++) 5 0 L'intérêt est triple :Par exemple Flask ou Django en python sont à 5% au nombre de requêtes réseaux par rapport à des frameworks compilés. On gagne peut être du temps au développement (pas sûr non plus) mais ensuite s'il faut déployer 20 serveurs au lieu d'un seul sur le long terme ce n'est pas gagnant....Je n'ai plus la référence d'un article, dont la société avait refait son logiciel serveur d'envoi de SMS (pour orange de mémoire) en langage C au lieu du PHP et cela permettait d'envoyer 150 fois plus de SMS/seconde qu'avant. Sur le coup cela permet assez rapidement de rentrer dans ses fonds en dépensant moins en matériel/électricité.Même facebook a fait un transpileur PHP -> C++ puis le code est compilé....et je ne parle même pas de l'embarqué (en général C/C++) Poster une réponse Signaler un problème

