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

  1. #61
    Futur Membre du Club
    franchement perdre du temps pour ce genre de lapalissade c'est vraiment ne rien connaitre a la programmation...

  2. #62
    Membre expérimenté
    Contrairement à d'autres je ne suis pas surpris des bons résultats de Java, son vrai problème est que le code Java est rarement optimisé pour la performance. En revanche je me demande quelle est la JVM utilisée pour les tests? J'avoue ne pas avoir le courage de lire les 267 pages du rapport.

    Edition : j'oubliais que de nos jours Open JDK et Hotspot sont quasi identiques.

  3. #63
    Membre averti
    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.

  4. #64
    Membre confirmé
    Certes , mais ni Apple et encore moins Google ne le permettent à cause de la sécurité , chose négligeable il y a trente ans , le C et Python ne permettent pas la sandbox , pas conçus pour . Oui nous sommes dans un environnement limité , mais c 'est pour cela qu ' il faut s ' appuyé sur les GPU .

  5. #65
    Expert éminent sénior
    Le C (même s'il a d'autre défauts) et le Python peuvent tout à fait être sandboxé. Même l'assembleur peut être sandboxé.
    Un sandboxing vraiment efficace c'est avant tout du ressort de l'OS pas vraiment du langage.

    D’ailleurs sous Android on peut tout a fait utiliser le C et le C++ même si ce n'est pas le langage le plus mis en avant par la documentation. Je connais moins iOS, mais d'après ce que j'ai lu c'est faisable même si c'est compliqué.

  6. #66
    Membre averti
    Je pense aussi aux serveurs webs. Je me demande quelle est la répartition des langages utilisés pour servir le contenu des sites représentant 90% du trafic mondial.

    Par ailleurs j'ai été chercher les sources de test. Le lien donné dans la publi (http://benchmarksgame.alioth.debian.org/) est mort.
    Il est maintenant ici https://salsa.debian.org/benchmarksg...benchmarksgame, enfin, presque, c'est le GIT du site web, mais le README donne les sources de test... dans des zip. Bah oui, utiliser GIT pour versionner le code, c'est le passé. D'ailleurs, le README pointe aussi sur un répo "archivé" du benchmarksgame. Comme quoi, les répos, c'est vraiment le passé.

    En regardant les sources je n'ai pas trouvé les règles de compilation et d'exécution pour les différents langages (le mainteneur dit ici https://salsa.debian.org/benchmarksg...game/issues/60 qu'il faut le faire soi-même). Du coup on ne sait pas exactement comment ça a été exécuté quand même.

  7. #67
    Membre régulier
    Citation Envoyé par mangobango Voir le message
    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.
    Ou pour dire la même chose d'un point de vue plus égoiste, quand on héberge une application dans le cloud, une application C coûte 76 fois moins cher qu'une application Python. Ce ne sont pas que des scenarios théoriques, je crois que Facebook, à un moment de son histoire, s'est payé un refactoring majeur car le coût des serveurs explosait.

    Après, il faut faire un compromis entre la puissance machine, et le temps nécessaire à la programmation. Je crois, pour avoir pratiqué les deux languages, que je préfère java malgré l'overhead de performance pour la facilité de développement apportée.
    Open Lowcode Applications sur mesure, résultats rapides et à coûts réduits (repo Github)

  8. #68
    Expert éminent
    Je suis très surpris que personne ne s'offusque des résultats particulièrement décevants de C#... notamment comparé à Java.

    J'ai pas suivi l'évolution de Java ces dernières années, mais il y a quelques temps C# était meilleur sur les trois mesures : CPU, temps d'exécution et RAM.
    Java a probablement progressé (il ne pouvait de toute façon plus aller dans l'autre sens) mais de là à devenir deux fois meilleur que C# sur chacun des trois critères, je suis perplexe…


    Ne serait-ce que d'un point de vue architecture, Java est de facto plus lent que C#, dans la mesure où Java reste en bytecode tout le long de l'exécution, là où C# est compilé nativement au moment de l'exécution…


    Sur un for (int i = 1; i < 10; ++i) { write(i); } cette étape de compilation JIT pénalise C#, je veux bien, mais sur un véritable programme qui tourne plusieurs heures ou jours, ça ne peut être que le contraire…
    Le meilleur exemple, c'est feu les Windows Phone : pour du matériel d'entrée de gamme, on avait les mêmes performances que sur du haut de gamme avec Android… C# d'un côté, Java de l'autre.
    On ne jouit bien que de ce qu’on partage.

  9. #69
    Expert éminent sénior
    Citation Envoyé par StringBuilder Voir le message
    Je suis très surpris que personne ne s'offusque des résultats particulièrement décevants de C#... notamment comparé à Java.
    L'explication a déjà été donnée pour d'autres langage est reste tout aussi valable pour C# : les benchmarks ont été effectués à partir du "benchmark game" ou tous les langages n'ont pas bénéficié du même niveau d'optimisation. Si vous vous sentez assez fort pour faire du C# bien optimisé, rien ne vous empêche de soumettre vos programmes.

    Citation Envoyé par StringBuilder Voir le message
    J'ai pas suivi l'évolution de Java ces dernières années, mais il y a quelques temps C# était meilleur sur les trois mesures : CPU, temps d'exécution et RAM.
    Java a probablement progressé (il ne pouvait de toute façon plus aller dans l'autre sens) mais de là à devenir deux fois meilleur que C# sur chacun des trois critères, je suis perplexe…
    Java a en effet bien progressé, mais il n'a jamais été aussi à la ramasse que la réputation que lui faisaient les trolls habituels.

    Citation Envoyé par StringBuilder Voir le message
    Ne serait-ce que d'un point de vue architecture, Java est de facto plus lent que C#, dans la mesure où Java reste en bytecode tout le long de l'exécution, là où C# est compilé nativement au moment de l'exécution…
    Seules les toutes premières versions de Java interprétaient directement le bytecode. La JVM de référence fonctionne par défaut avec du JIT depuis 1996, soit six ans avant la sortie de C#.

  10. #70
    Membre régulier
    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.
    Open Lowcode Applications sur mesure, résultats rapides et à coûts réduits (repo Github)

  11. #71
    Expert éminent
    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.
    On ne jouit bien que de ce qu’on partage.

  12. #72
    Membre à l'essai
    Si je programme ( et j'aime ça ) en python, suis-je considéré comme un criminel pour notre planet ?

  13. #73
    Expert éminent sénior
    Tout dépend du programme. Si c'est un Hello World, sa consommation sera négligeable par rapport a ce qu'ont consommé ton IDE, ton compilateur,... Par contre si c'est un programme qui doit tourner des semaines sur un énorme cluster de serveurs, en effet tu as fait un gros gaspillage.

  14. #74
    Membre éclairé
    Grep etc.
    Bonjour,

    J'aime bien la réflexion sur les traitements de chaînes par les expressions régulières qui seraient particulièrement efficaces dans certains langages interprétés. Quand on sait qu'ils s'appuient sur des fonctions écrites en C...

    Même si cela peut apparaître marginal, l'analyse ne travaille pas en coûts complets (charges de dévelopement, charges de maintenance, charge de portabilité, occupation mémoire des machines virtuelles et des interpréteurs, espaces de caches...). Par exemple, des charges humaines de réalisation multipliées par deux ont un impact direct sur la consommation d'énergie (transports, bureaux, poste de travail etc.) sans compter les délais de mise à disposition.

    Et je ne parle pas des charges induites coté utilisateur qui sont souvent très difficiles à cerner sans être négligeables pour autant. Par exemple au delà de 4s d'attente (les estimations varient entre 3s et 5s) l'attention de l'utilisateur n'est plus assurée, il y aura donc en sus un délai humain de remise en contexte.

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  15. #75
    Expert éminent
    Citation Envoyé par Guesset Voir le message
    Par exemple, des charges humaines de réalisation multipliées par deux ont un impact direct sur la consommation d'énergie (transports, bureaux, poste de travail etc.) sans compter les délais de mise à disposition.
    En même temps, ça dépend totalement du programme.

    Si c'est un script qui tourne pendant 5 secondes 2 fois par an, alors oui, les charges humaines ont un très grand impact.

    Si c'est un OS comme Windows ou Linux, ou un outils de bureautique tel que Microsoft ou Open Office, alors que les développeur passe 100 fois moins ou plus de temps à les développer, c'est moins d'une goutte d'eau comparé à l'énergie consomme par la simple utilisation.

    C'est d'ailleurs la même chose pour le Hello World cité plus haut. Si c'est la popup de notification de réception d'un SMS sur Android, même si elle consomme 0,001 milliampère/heure, multiplié par les milliards de fois qu'elle est affichée à l'échelle mondiale dans une journée, il doit falloir pas loin d'une centrale à charbon entière pour la faire tourner.

    La consommation liée à Internet a explosé littéralement depuis que Facebook lit directement les flux vidéos et que presque tous les jeunes passent leur journée sur Snapchat. La consommation liée aux mails à côté, c'est de l'ordre du milliardième.
    On ne jouit bien que de ce qu’on partage.

  16. #76
    Nouveau Candidat au Club
    Optimisations maîtrisées ?
    Bonjour,

    Je suis curieux de lire les conclusions originales ainsi que la méthodologie complète car de mon constat, Perl (bien utilisé) atteint 99% des performances du C compilé et je ne conçois pas qu'il puisse être classé dernier.

    En général, Java est ultra lourd niveau CPU (à cause de la JVM) et le C++ est très proche du C quand bien implémenté.

    Cette "étude" me semble assez légère d'un point de vue rigueur dans la méthodologie.

    Encore faut-il maîtriser un langage avant de vouloir en mesurer l'efficacité...

    Bref.

  17. #77
    Expert éminent sénior
    Si on se place dans le cas où les pauses IO (accès disques, réseau, ...) prennent bien plus de temps que les traitements effectués par le code, avec Perl, comme avec n'importe quel langage, on a en effet des temps de fonctionnement proche du natif. Mais bon dans ce cas là l'étude n'a pas vraiment de sens, vu que tous les langages sont équivalent.

    Par contre Perl n'est absolument pas un langage taillé pour les performances de manière générale. Dans les cas où il faut exploiter au mieux la puissance du processeur, il n’atteint clairement pas 99% des performances de Java, encore moins du C. C'est pour cela qu'on l'utilise plutôt en tant que langage de script pour l'administration ou du traitement de document textes plutôt que pour des calcul processeurs complexes.

    En gros on peut approximativement classer les langages dans 3 catégories vis à vis des performances :

    • les langages orientés vers le développement rapide : Python, Perl, Ruby, Visual Basic...
      Ces langages visent avant tout à être accessibles, et pour simplifier la tache du programmeurs, ils n'hésitent pas à recourir à des techniques qui ont des impacts sur les performances : typage dynamique, Garbage collector, ...
      Ils se contentent généralement de macro taches et se reposent sur des modules écrits dans d'autres langages pour les parties intensives en calcul.
    • les langages orientés performance avec un Runtime lourd : Java, C#, Go, ...
      Ces langages visent en partie les performance en faisant moins de concessions que la catégorie précédente. Il utilisent généralement un typage statique. Cependant ils reposent quand même sur un Runtime lourd (code exécute en supplément du code utilisateur, notamment pour gérer la mémoire) qui a un impact sensible, notamment sur l'utilisation mémoire et la prédictibilité des performances.
    • les langages sans Runtime : C, C++, Rust.
      Ces langage sont compilés sans quasiment aucun Runtime et ont la capacité d'être utilisé à bas niveau. Il ont généralement des performance optimales mais obligent le développeur a prendre en compte beaucoup de point gérés automatiquement par les langages des catégories précédentes.

  18. #78
    Expert éminent
    Ce message n'a pas pu être affiché car il comporte des erreurs.
    On ne jouit bien que de ce qu’on partage.

  19. #79
    Expert éminent sénior
    Citation Envoyé par StringBuilder Voir le message
    (.../...)Ainsi, autant pour moi il est très compliqué de dire quel langage est plus rapide ou plus consommateur en ressources que tel autre, autant il me semble assez surprenant de retrouver, j'insiste, C# aussi bas dans le classement... à moins que "ne pas se poser de question" se soit appliqué à l'ensemble du programme C# et qu'il en résulte un code abominable.
    Oui, le contexte est fondamental. En COBOL, j'ai toujours écrabouillé tous les JAVAistes opposés sur le plan des performances... mais ça ne prouve pas pour autant la supériorité du COBOL sur JAVA dans tous les contextes. Ni même ma propre supériorité sur ces gens-là. Ca prouve juste que dans les contextes ou j'étais, moi+COBOL était un combo plus performant que autres+JAVA. Et ça vaut pour tous les langages.

    D'ailleurs, tu parles de "code abominable" - à ma connaissance, le code le plus affreux n'est pas forcément le plus lent. C'est orthogonal. Un code très élégant peut être plus rapide - ou plus lent - suivant les manies de l'artiste. Et certaines horreurs cachent des optimisations bien pensées, tandis que d'autres...sont juste des horreurs.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  20. #80
    Expert éminent sénior
    Citation Envoyé par StringBuilder Voir le message
    Ce qu'il ressort de ce test, c'est qu'avant tout, c'est que tous les contextes d'exécution ne se valent pas, et que certains langages à priori plus rapide que d'autres peuvent s'avérer plus lents.
    Mais aussi qu'optimiser son code "pour le benchmark qui va bien" n'est pas forcément significatif, mais ça, j'en reparlerai plus tard.
    Oui rien de bien nouveau : on sait bien qu'en choisissant le bench qui va bien on peut toujours trouver un cas particulier ou le pire langage arrivera a faire l'optimisation parfaite, mais en général dès que l'on va changer quelque détails, ça ne marche plus.

    Certains langages ont bien plus de potentiel que d'autre pour permettre de meilleures optimisations de manière plus consistantes.

    Citation Envoyé par StringBuilder Voir le message
    Première chose qui ressort : C# est réellement portable, là où C++ ne l'est pas. En effet, qu'on soit sur un CPU 32 bits ou 64 bits, le type "long" sera le même en C# (64 bits) alors qu'en C++ il sera de la taille du registre CPU.
    En C et C++, avec les types de base comme "long", c'est même pire que ça niveau portabilité : chaque compilateur est libre de faire ce qu'il veux (le standard impose juste des tailles minimales). Un même type peut avoir des tailles différentes en fonction de l'OS et de l'archi matérielle.
    Heureusement depuis la fin du siècle précédent, le standard a introduit "stdint" qui permet d'utiliser des types de taille garantie, Donc cet argument particulier n'est plus vraiment recevable si on prend la peine d'utiliser des fonctions qui sont standard depuis plus de vingt ans.

    Il reste cependant des centaines de comportement non définis par la spécification de C et C++ qui font que ces langages sont clairement moins bon en matières de portabilité que la plupart des langages modernes.

    Citation Envoyé par StringBuilder Voir le message
    Donc autant ça permet au C++, de prime abord, pulvériser le C# qui s'emmerde à gérer du 64 bits sur un CPU 32 bits, autant cela fera planter le programme C++ lorsqu'on sera en exploitation et qu'on aura réellement besoin d'un long 64 bits.
    Déjà, comme expliqué ci dessus, "long" ne fait pas forcément la taille d'un registre, mais en plus, la taille d'un registre processeur n'est pas forcément la taille idéale pour faire des calculs.
    Utiliser des types plus petits est plus rapide avec certaines instructions, peut permettre une meilleure auto-vectorisation, et peut réduire les "cache misses" en économisant la mémoire. En général, en C++ comme en C#, mieux vaut utiliser des types fixes mieux adaptés à la logique de l'application et laisser le compilateur décider de faire les optimisations qu'il faut. Même si on veut faire de l'optimisation manuelle, stdint est plus intéressant car il permet un meilleur contrôle.

    Citation Envoyé par StringBuilder Voir le message
    La seconde qui ressort : C# arrive à être plus rapide que C++, y compris sur une bête boucle d'incrémentation d'entier. Ceci est en grande partie dû à un avantage indéniable de C# (ou Java) par rapport au C/C++ : la compilation JIT permet d'adapter le code machine au contexte.
    Comme déjà dit, en effet dans certains cas bien choisis, une bonne optimisation particulière va permettre à un langage de s'en tirer particulièrement bien. Dans ton exemple le JIT est efficace, mais on pourrait aussi faire de l'optimisation dirigée par les profils pour bénéficier le ce genre d'optimisation en AOT.
    Le Runtime n'est pas une solution magique qui va résoudre les problèmes. Ça en résout cretains, mais il a un cout moyen le plus souvent supérieur aux gains qu'il apporte en terme de performance. C'est un choix qu'il faut assumer.

    Citation Envoyé par StringBuilder Voir le message
    La troisième, qu'on ne voit pas ici, c'est le temps perdu à gérer la mémoire : en C++, lorsque je crée un objet, je dois déclarer à la mimine exactement à quel moment réserver la mémoire pour son utilisation, et à quel moment la libérer.
    Sauf que là on est en total hors sujet. Certes économiser sur le temps de développement est important dans énormément de situations, c'est même la principale raison d'exister des langages avec des performance moindres (même si là encore il y a beaucoup a discuter), mais là le sujet c'est les performance et l'impact sur la consommation en énergie.

    Citation Envoyé par StringBuilder Voir le message

    Ainsi, autant pour moi il est très compliqué de dire quel langage est plus rapide ou plus consommateur en ressources que tel autre, autant il me semble assez surprenant de retrouver, j'insiste, C# aussi bas dans le classement... à moins que "ne pas se poser de question" se soit appliqué à l'ensemble du programme C# et qu'il en résulte un code abominable.
    Preuve s'il en falait que le Runtime n'est pas un faiseur de miracle absolu en matière d'optimisation du code. Le code du Benchmark Game est dispo et ouvert aux contributions, libre a toi de prouver que le C# peut faire mieux si tu le veux.