Finalement je vois que je peux continuer à programmer en Pascal pour être à la pointe de la lute contre le changement climatique
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
Discussion :
Finalement je vois que je peux continuer à programmer en Pascal pour être à la pointe de la lute contre le changement climatique
C'est bien de tester Dart en interprété mais j'aurai aimé les perf en compilé....
Parce que la différence, c'est le jour et la nuit.
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 ? »
La FAQ JavaScript – Les cours JavaScript
Touche F12 = la console → l’outil indispensable pour développer en JavaScript !
Cette étude est mal faite. J'ai sursauté sur la difference x8 entre Typescript et Javascript.
Du coup je me suis permis de regarder le framework de test disponible ici. https://sites.google.com/view/energy...ency-languages
J'ai pris l'étude, la première ligne du premier tableau (binarytree) et comparé les algos de deux langages que je connais: Ruby et Javascript:
https://github.com/greensoftwarelab/...es.yarv-5.yarv
https://github.com/greensoftwarelab/...narytrees.node
(On passera sur les extension de fichier yolo yolo hein...).
Long story short: La version de Ruby est une version parallelisable qui fork un process Unix, forcement moins efficace energetiquement et probablement moins éfficace en mono-coeur ou en "load" average.
Pareillement, la différence entre typescript et javascript dans "fannkuch-redux" s'explique par le code source completement différent (algorithme different).
Après, j'ai eu la flemme d'aller plus loin je dois dire. Bref, étude à jeter.
petite erreur ?
je crois avoir relevé un leger decalage sur la date de parution qui aurait due être au 1/4/2019 ?
L'intêret ECOLOGIQUE
Pour moi de telle étude est d'une importance majeure sur le plan ECOLOGIQUE surtout pour les fournisseurs qui ne prévoient pas un passage à l'électricité verte...
Si les données sont fausses l'étude ne sert à rien.
Et sinon l'électricité verte ça n'existe pas.
Le Python est un langage vorace car celui ci sert dans des appli utilisant des moteurs 3D .. rien de révolutionnaire . Idem le C++ peut servir pour du 2D et des minis jeux genre snake ou puissance 4.
Bonjour,
C'est intéressant comme étude, même si le résultat et la méthodologie laissent encore à désirer.
Certains langages permettent d'économiser du temps de développement, donc si le développeur a besoin de moins d'efforts pour coder il consomme donc lui-même moins d'énergie. Ensuite, il y a tout ce qui est annexe, et consommateur également : compilation, installation de plateforme, conception du projet, utilisation des éditeurs de code, tests/débogage, phases d'évolution/correction/maintenance du projet, donc grosso-modo si nous voulions vraiment être plus précis il faudrait prendre tout cela en compte dans le bilan énergétique "global". Car le temps passé derrière l'ordinateur par chaque intervenant est également énergivore.
Ensuite, séparer les langages par type de langage me semble incohérent : c'est plutôt par cas d'utilisation que cela convient. Par exemple, dans le cadre d'une application web, est-il plus énergivore de la développer en PHP ou en Java ? Dans certains cas, en PHP c'est mieux car suffisant pour les besoins de l'application, dans d'autres, Java est plus adapté car il est mieux outillé pour certaines situations. Mais les cas d'utilisations sont larges et différents et ne peuvent pas se résumer à un simple algorithme.
Mais est-ce vraiment tant cela l'important ? La quantité d'énergie consommée est un facteur important lorsqu'il y a véritablement un choix entre plusieurs options, et que l'application va être souvent sollicitée. Mais en général, les choix s'orientent autour du projet lui-même, et donc peut-être que ce qui serait plus intéressant, serait de détecter tout d'abord à quel cas d'utilisation s'applique quel langage, puis quelles sont les pratiques de programmation énergivore PAR langage/plateforme, ainsi par exemple on pourrait transformer toutes les concaténations de String en Java en appels à une classe type StringBuilder serait une recommandation "verte", mais les exemples sont innombrables, utiliser les bons types de variables quand il faut, faire des boucles que quand c'est nécessaire (parfois préférer la récursion) etc :-)
A+
Souvent, dans les grosses sociétés, on va vers le langage que l'on utilise en standard même si ce n'est pas le plus efficace pour un projet... Peur de l'investissement nécessaire pour appréhender un nouvel écosystème... En plus, certains n'aiment pas sortir de leur zone de confort aussi... Du coup on utilise un bazooka pour tuer une mouche en ce disant que qui peut le plus peu le moins...Envoyé par KiLVaiDeN
Quand à choisir le bon type de variable, il y aurai beaucoup à dire là dessus... Même chose dans les bases de données quand on voit dans des progiciels que la quasi-totalité des colonnes sont définies en VARCHAR, y compris pour stocker des dates et des valeurs numériques...
Le choix du bon langage (adapté au projet), une bonne réflexion préalable, des pratiques raisonnables, un peu d'optimisation, tout ça pourrait faire économiser à la fois l'énergie du développeur et celle consommé par la solution....
Les langages ont été testés sur des programmes identiques, même si on peut douter que le niveau d'optimisation de chaque implémentation, voire même l'algorithme, soit comparables.
Pas sûr que Python soit destiné particulièrement pour de la 3D (certainement moins que C++ qui permet d'utiliser OpenGL ou DirectX et dans lequel sont codés la plupart des moteurs 3D, à l'exception notable d'Unity). C'est en plus justement sur ce type d'applications gourmandes qu'il faut s'orienter vers un langage efficient, tant en perfs qu'en économie d'énergie.
Comment dire ça ... Les premiers Quake engine ont été écris avec du C++ , le C++ à été le Python des années 1990 . Je ne serais trop te conseiller de lire , de regarder des vidéos sur l ' histoire de l ' informatique
Bonjour,
Etude intéressante, j'aurais aimé plus de détails.
Par exemple selon le type d'utilisation (site web avec base de données, info indus, ...)
Eh puis qu'on nous fournisse la version des langages/compilos
Le C++ 1.56 fois plus lent que le C!?
C'est une blague?
J'allais poser la question...
franchement perdre du temps pour ce genre de lapalissade
c'est vraiment ne rien connaitre a la programmation...
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.
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
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.
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.
Répondre avec citation
Partager