IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Programmation : une étude révèle les langages les plus voraces en énergie


Sujet :

Débats sur le développement - Le Best Of

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 976
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 976
    Billets dans le blog
    2
    Par défaut Programmation : une étude révèle les langages les plus voraces en énergie
    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

    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 : Rapport de l'étude

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé Avatar de Belegkarnil
    Inscrit en
    Juin 2005
    Messages
    289
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : Juin 2005
    Messages : 289
    Par défaut Ocaml
    Est-ce que ocaml a été compilé nativement ? Car cela donne une différence significative...

  3. #3
    Membre confirmé
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Décembre 2011
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2011
    Messages : 68
    Par défaut
    Citation Envoyé par Belegkarnil Voir le message
    Est-ce que ocaml a été compilé nativement ? Car cela donne une différence significative...
    Les données viennent de https://benchmarksgame-team.pages.de...enchmarksgame/
    Les programmes Ocaml sont compiler de la manière suivante :
    "ocamlopt -noassert -unsafe -fPIC -nodynlink -inline 100 -O3"

    Donc en natif (ocamlopt) avec toutes les optimisations possible(-O3 -inline 03) dont le retrait des protections sur les tableaux(-unsafe).
    Et quand on regarde la tête des programmes OCaml dans ce bench on est très très loin de l’idiomatique du langage, jamais je n'ai écris mes codes Ocaml de cette manière.
    Par contre je me retrouve bien dans les programmes C/C++ et Java.

  4. #4
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2011
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Gard (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mars 2011
    Messages : 185
    Par défaut
    Bon, le C/C++ s'en sort très bien (c’était à prévoir), je suis étonné des bonnes notes de Java (Top 5, sauf en mémoire!).

    Par contre, je ne sait pas si mon expérience est trop daté,
    mais c'est quoi ces chiffres désastreux de Lua par rapport à PHP/Python/JS ?

  5. #5
    Membre averti
    Profil pro
    Développeur Web
    Inscrit en
    Juin 2010
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juin 2010
    Messages : 38
    Par défaut
    Je suis assez étonné de voir Java si haut dans le classement, ça fait plaisir de voir que c'est pas une usine à gaz, comme on le prétend.
    Sûrement grâce au Bytecode qui est très proche des instructions machine ?

  6. #6
    Membre éclairé Avatar de openlowcode
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juin 2019
    Messages
    40
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2019
    Messages : 40
    Par défaut
    Citation Envoyé par firepolo Voir le message
    Je suis assez étonné de voir Java si haut dans le classement, ça fait plaisir de voir que c'est pas une usine à gaz, comme on le prétend.
    Sûrement grâce au Bytecode qui est très proche des instructions machine ?
    En fait, c'est surtout que les languages interprétés sont encore bien pires pour ce qui concerne la mémoire / la CPU, et à mon avis, ce qui est presque plus grave, aussi pour le temps de débugage.

    Je ne suis pas d'accord avec certaines remarques sur le fait que le hardware n'a plus d'importance: le coût total du hardware dans un projet n'est pas négligeable côté serveur, surtout avec les offres cloud qui vendent l'aspect pratique du cloud assez cher. Cela fait partie du top 10 du gaspillage en informatique de gestion. ON peut donc payer cher à la fin l'utilisation d'une technologie pas efficace.

  7. #7
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 197
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par openlowcode Voir le message
    En fait, c'est surtout que les languages interprétés sont encore bien pires pour ce qui concerne la mémoire / la CPU, et à mon avis, ce qui est presque plus grave, aussi pour le temps de débugage.

    Je ne suis pas d'accord avec certaines remarques sur le fait que le hardware n'a plus d'importance: le coût total du hardware dans un projet n'est pas négligeable côté serveur, surtout avec les offres cloud qui vendent l'aspect pratique du cloud assez cher. Cela fait partie du top 10 du gaspillage en informatique de gestion. ON peut donc payer cher à la fin l'utilisation d'une technologie pas efficace.
    C'est d'autant plus vrai que de nombreux outils éditeurs (OS, base de données, etc.) sont vendus avec des licences par coeur, ou avec des limitations en termes de coeurs et mémoire selon les éditions.
    Par conséquent, un programme mal optimisé qui nécessite plus de puissance risque d'impliquer des coûts logiciels supérieurs uniquement car il a besoin de plus de hardware pour travailler.

  8. #8
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 693
    Par défaut
    C'est étonnant de voir un facteur 5 entre JS et typescript puisque le résultat final de ts est du JS.
    A moins que l'étape de transpilage soit compté auquel cas il faut faire de mm pour les compilation.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Membre éclairé
    Inscrit en
    Janvier 2006
    Messages
    756
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 756
    Par défaut Rien d'étonnant
    Je ne vois rien d'étonnant dans ces résultats, on a à peu de choses près dans l'ordre
    1. Les langages de très bas niveau et compilés en code natif (C/C++)
    2. Les langages de haut niveau compilés en natif, comme Ada: le code est un peu moins optimisé parce qu'il faut convertir les types "humains" en types "machine"
    3. Les machines virtuelles
    4. Les interpréteurs : plus lents que les VM parce que modifier des registres, fussent-ils virtuels, est moins cher que de parcourir un arbre syntaxique abstrait
    5. Les interpréteurs dans une VM, type JRuby (au fait: compilé ou interprété?)
    6. Les transpileurs comme Typescript, j'y reviendrai plus loin


    Évidemment vous allez me dire que ça ne correspond pas exactement. Mais il faut ensuite pondérer par d'autres critères comme l'utilisation habituelle d'un langage: par exemple, selon ce critère Fortran devrait être devant Java, mais si on compare une VM récente à un compilateur qui n'a plus connu que des corrections de bugs pendant les dix dernières années, je veux bien croire que Java est mieux adapté aux machines récentes que son ancêtre...
    A une époque ce genre d'étude aurait servi à discréditer Ada, réputé lent mais donnant la priorité à la sécurité. Aujourd'hui on va s'en prendre aux langages de script parce qu'ils sont tout à coup devenus majoritaires

    Citation Envoyé par grunk Voir le message
    C'est étonnant de voir un facteur 5 entre JS et typescript puisque le résultat final de ts est du JS.
    A moins que l'étape de transpilage soit compté auquel cas il faut faire de mm pour les compilation.
    Même si l'étape de transpilage n'est pas comptée, un code transpilé n'est pas équivalent au même code écrit en Javascript par un humain: dans le meilleur des cas le transpileur ajoute toujours un peu de code identique dans tous les programmes, qui équivaut en gros à la "libc" par rapport à l'assembleur. Un exemple: si une fonction Typescript n'a pas exactement les mêmes paramètres que son équivalent Javascript, il est probable que le compilateur va d'abord rajouter une fonction Javascript qui ne fait qu'appeler la fonction habituelle avec les bons paramètres et ensuite partout où la version Typescript est appelée, générer un appel de fonction, coûteux en temps.

    Il serait aussi intéressant de savoir si tous ces programmes ont bien été écrits chacun par un spécialiste du langage en question. Sinon, ça me rappellerait trop comment on a détruit les bases de données objet (ODMG): les benchmarks étaient écrits par des spécialistes Oracle, donc on comparait un programme Oracle hyper-optimisé avec un "équivalent" ODMG écrit à l'arrache...

  10. #10
    Expert confirmé
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 419
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 419
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Même si l'étape de transpilage n'est pas comptée, un code transpilé n'est pas équivalent au même code écrit en Javascript par un humain:
    Et si justement.

    Citation Envoyé par esperanto Voir le message
    dans le meilleur des cas le transpileur ajoute toujours un peu de code identique dans tous les programmes, qui équivaut en gros à la "libc" par rapport à l'assembleur.
    Non. Enfin ça dépend de la target. Si tu target ES5 et que tu utilises des fonctionnalités de ES6+ il va te rajouter plein de choses. Si tu target ESNext il n'y a aucune différence.

    Mais dans ce cas leur test n'a aucune valeur. Il faudrait comparer TS avec ESNext, pas avec une version du langage obsolète. C'est comme si ils avaient fait le test avec Java 5 ou .NET 1.0 ça n'a pas de sens.

    Citation Envoyé par esperanto Voir le message
    Un exemple: si une fonction Typescript n'a pas exactement les mêmes paramètres que son équivalent Javascript, il est probable que le compilateur va d'abord rajouter une fonction Javascript qui ne fait qu'appeler la fonction habituelle avec les bons paramètres et
    Non.

    Citation Envoyé par esperanto Voir le message
    ensuite partout où la version Typescript est appelée, générer un appel de fonction, coûteux en temps.
    C'est pas le cas.

    Citation Envoyé par esperanto Voir le message
    Il serait aussi intéressant de savoir si tous ces programmes ont bien été écrits chacun par un spécialiste du langage en question.
    Je pense qu'on peut largement se mettre d'accord sur le fait que les conclusions de cette étude sont bonnes pour la poubelle, cf en particulier le post de @anykeyh.

  11. #11
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 691
    Par défaut
    Je ne connais pas le détail des compilateur TS actuels, mais en théorie, comme il s'agit d'un langage fortement typé, ils devraient pouvoir générer du code JavaScript de type ams.js qui bénéficie de bien meilleures optimisations par le moteur JavaScript.

    correction : Je n'avais pas fait attention que c'est TypeScript qui est derrière JavaScript et non l'inverse.

    C'est en effet bizarre en théorie. Maintenant les tests viennent du Benckmark game, ce qui signifie qu'il s'agit de programmes réalisés manuellement par des volontaires et que certains sont plus agressif que d'autres en matière d'optimisations. Parfois au point qu'on peut douter que des optimisations si techniques et spécifique soient vraiment utilisées en production.
    On peut supposer que le JavaScript a été très agressivement optimisé, et pas le TypeScript, ça vaudrait le coup de comparer les deux codes.

  12. #12
    Membre très actif Avatar de darklinux
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Novembre 2005
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2005
    Messages : 570
    Par défaut
    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 ???

  13. #13
    Membre Expert
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 149
    Par défaut
    Citation Envoyé par darklinux Voir le message
    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 .
    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.

  14. #14
    Membre très actif Avatar de darklinux
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Novembre 2005
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2005
    Messages : 570
    Par défaut
    Citation Envoyé par transgohan Voir le message
    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.
    Le RPI n ' est qu ' un PC de la fin des années 1990 multicœurs ... Ce n 'est pas plus significatif que le Jetson Nano ...

  15. #15
    Membre Expert
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 149
    Par défaut
    Citation Envoyé par darklinux Voir le message
    Le RPI n ' est qu ' un PC de la fin des années 1990 multicœurs ... Ce n 'est pas plus significatif que le Jetson Nano ...
    Et qu'est ce qui est significatif en systèmes embarqués ? Un octo-coeur avec une carte graphique de 2Gio ?

    La plupart des systèmes embarqués tournent avec du matériel dont la puissance est digne des années 80-90. C'est ça la réalité.
    Je travaille sur des produits utilisant des technologies éprouvées qui datent d'avant ma naissance... C'est la quotidien de tous les développeurs embarqués.

  16. #16
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 693
    Par défaut
    Citation Envoyé par darklinux Voir le message
    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 ???
    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é.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  17. #17
    Membre éclairé
    Homme Profil pro
    Ingénieur validation
    Inscrit en
    Août 2018
    Messages
    42
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur validation
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2018
    Messages : 42
    Par défaut
    Bonjour

    Je suis comme d'autres assez surpris par les bonnes notes de Java (notamment l'écart assez important par rapport à C#).
    A contrario, je suis assez surpris par les mauvaises notes de Python, souvent réputé pour ses performances (relativement aux langages interprétés, bien sûr) grâce à ses bibliothèques intégrant beaucoup de code compilé en natif.

    Bon, maintenant dans le monde réel, les performances en temps et en énergie à l'exécution sont à pondérer par rapport à d'autres critères généralement mis en avant dans les entreprises (rapidité de conception, de développement, de mise au point, maintenabilité, disponibilité des compétences sur le marché de l'emploi, habitudes fortement ancrées...etc)

  18. #18
    Membre éclairé
    Profil pro
    retraité
    Inscrit en
    Décembre 2010
    Messages
    864
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 864
    Par défaut
    Citation Envoyé par darklinux Voir le message
    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 ???
    L'intérêt est triple :
    • 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++)

  19. #19
    Membre éclairé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Octobre 2005
    Messages
    244
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Philippines

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2005
    Messages : 244
    Par défaut
    Citation Envoyé par archqt Voir le message
    L'intérêt est triple :
    • 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++)
    C'est possible de gagner énormement en performance en utilisant un language compilé, MAIS il faut changer de paradigme sur pas mal d'éléments; la plupart du temps passé par le serveur web est dans la mémoire et les E/S. Un service web va literralement passer la plus grande partie de son temps a parser / copier / déplacer / réduire des infos. Du coup si tu pars sur du compilé mais tu gardes un ORM ultra facile à prendre en main, une interface super simple d'accès aux paramètres HTTP, des hash/map/dictionnary partout et bien tu vas pas gagner tant que ça (peut-etre x2 max).

  20. #20
    Membre confirmé
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    99
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 99
    Par défaut
    Citation Envoyé par darklinux Voir le message
    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 ???
    Bah disons qu'en faisant tourner des services implémentés en C plutôt qu'en Python (par exemple) on consommerait 76x moins d'énergie... sur une planète à ressources limitées, ça compte.

Discussions similaires

  1. Réponses: 77
    Dernier message: 17/02/2025, 09h10
  2. Réponses: 11
    Dernier message: 27/03/2024, 08h39
  3. Réponses: 16
    Dernier message: 12/09/2022, 19h46
  4. IDC : une étude révèle une addiction des américains pour les smartphones
    Par Stéphane le calme dans le forum Actualités
    Réponses: 7
    Dernier message: 09/04/2013, 08h32
  5. Réponses: 0
    Dernier message: 30/07/2009, 10h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo