Discussion :

[KiLVaiDeN]

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+

[sergio_is_back]

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...

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....

[Grool]

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.

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.

[ParseCoder]

Le C++ 1.56 fois plus lent que le C!?
C'est une blague?

[darklinux]

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.

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

[Bktero]

Le C++ 1.56 fois plus lent que le C!?
C'est une blague?

J'allais poser la question...

[el_slapper]

(.../...)en optimisant "à la main" le programme C déjà compilé, un humain pourrait probablement trouver des spots améliorable et vaincre le compilateur(.../...)

ça se fait dans l'armement. Et dans cet ordre : ils compilent en C, le compilateur leur fait plein d'optimisations, et ils en rajoutent à la main en assembleur. Au combat, chaque opération CPU de moins peut faire la différence entre la vie et la mort. Évidemment, ce n'est pas donné-donné, leur matos...

[esperanto]

Au combat, chaque opération CPU de moins peut faire la différence entre la vie et la mort.

Vraiment? Franchement, j'ai moins peur des conséquences d'un cycle CPU en trop que de celles d'un bug rajouté par une optimisation ratée. Je pensais que c'était justement pour ça que l'armée préférait des langages comme Ada, plus lents mais avec des contrôles d'erreur très forts avant d'accepter la compilation.
Voir l'exemple, parfaitement authentique, du premier vol Ariane 5, le bug à l'origine de l'explosion étant juste la désactivation d'un mécanisme de contrôle anti-débordement... débordement qui ne se produisait jamais avec Ariane 4 mais qui s'est produit immédiatement dès qu'on a réutilisé le même programme pour une fusée plus puissante.
Maintenant si l'armée privilégie la vitesse comme tout le monde, je ne donne pas cher des adversaires en cas de bug...

[Steinvikel]

Bah il gagnerait :-)

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 !

[KiLVaiDeN]

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 !

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é 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.

[Jamatronic]

Bref. Le C n'est pas près de mourir. Et une fois de plus, les langages "top trop modernes top moumoute" sont des croûtes.

[darklinux]

Bref. Le C n'est pas près de mourir. Et une fois de plus, les langages "top trop modernes top moumoute" sont des croûtes.

Tout dépend de l ' usage et de la destination .... Il n ' y a qu'a voire l ' évolution de Javascript ou de Python , d ' abord aide à la mise en page pour le WWW pour évoluer du côté serveur et datascience , le C c'est très bien pour le système , pas pour le reste

[KiLVaiDeN]

Tout dépend de l ' usage et de la destination .... Il n ' y a qu'a voire l ' évolution de Javascript ou de Python , d ' abord aide à la mise en page pour le WWW pour évoluer du côté serveur et datascience , le C c'est très bien pour le système , pas pour le reste

Oui, chaque langage est adapté à un besoin. Par exemple PERL qui est mal classé dans ce comparatif, est (était?) adapté à certaines utilisations, par exemple pour manipuler des fichiers textes complexes grâce à son intégration des expressions régulières, puis c'est un langage interprété en bytecode donc il n'y a pas besoin de le compiler donc facile de tester ses routines en incrémental, c'est un ancien langage certes mais il a eu sa place au sein de nombreuses architectures logicielles, bon maintenant il perd un peu de terrain car l'informatique évolue (Python, moins performant, tend à vouloir le remplacer malgré tout) mais il y a encore de nombreuses routines PERL par ci par là qui font le job dans des entreprises, j'ai moi-même eu à m'y frotter et bien que ça n'était pas ma tasse de thé je dois reconnaitre que c'était pas trop mal. Il était pratique de créer un fichier .pl puis de l’exécuter en ligne de commande, puis de le configurer en batch, par exemple de nuit, pour traiter ces fichiers d'échange qui avaient besoin d'un parsing, ou d'une transformation. Un nouveau fichier à traiter ? Copier/coller du fichier .pl, et édition des nouvelles zones, et boom le job était fait :-) Pour cette utilisation, il était souvent inutile "fonctionnellement" d'avoir une performance "élevée" (même si il faut le dire, pour les cas d'utilisations où il y a besoin des expressions régulières, PERL est très puissant) car de nuit ça ne gène pas que le script prenne un peu de temps, donc même si de nos jours la réflexion semble se porter sur une optimisation des performances pour une économie d'énergie, PERL reste adapté pour ces situations.

De nos jours on critique un peu Python pour ses performances, mais il ne faut pas oublier la simplicité de ce langage, et donc le fait qu'il est beaucoup plus rapide de développer en python que dans d'autres langages: ce gain de temps est parfois grandement appréciable! Surtout quand la performance est non recherchée, mais plutôt la "fonctionnalité"... Et puis avoir une équipe d'informaticiens qui travaillent sur Python, c'est quelque part plus rassurant que les mêmes qui travailleraient sur C... Je vous raconte pas les cas où, dans des architectures en C/C++, j'ai du retoucher du code ou m'intégrer dans un projet existant et certains bouts de code étaient tout simplement incompréhensibles. Car la puissance de C/C++ peut être contrebalancée par son fort potentiel à générer du code illisible au sein d'une équipe d'informaticiens aux niveaux de programmation différents! (D'ailleurs inutile de se lancer à plusieurs sur un projet sans conventions de codage préalables pour ces langages).

Chaque cas d'utilisation, chaque système, chaque type de fichier à traiter, peuvent potentiellement avoir des candidats différents, et la capacité des équipes de développement aussi impose des contraintes quant aux choix des langages à utiliser. Mais il ne faut pas oublier l'aspect sécurité, un langage comme C permet d'obtenir des performances élevées mais notamment parce qu'il est permissif, on peut taper dans la mémoire avec des pointeurs, alors qu'en Java par exemple, oubliez les pointeurs à tout jamais, et bien que cela peut être pénalisant pour certaines applications, pour d'autres c'est presque rassurant ! La plupart des vulnérabilités exploitées par les hackers se situent dans les traitements de données par des langages "permissifs" qui peuvent alors exposer des failles de logique, un manque de validation de données pouvant être comme une porte ouverte, et certains langages ou librairies prémunissent d'office de ces dangers.

Un dernier exemple, SQL : vous connaissez certainement le principe de l'injection SQL, sinon, Un puriste vous dira que des librairies comme Hibernate, qui est un ORM, produit du code SQL à jeter à la poubelle vous dira le DBA (et il n'a pas tord) mais par exemple en utilisant cette librairie, on obtient d'autres avantages, on peut directement mapper la structure objet à la base sans avoir ni même à écrire la moindre ligne de SQL et puis le problème d'injection SQL est inexistant. Un exemple du "plus de fonctionnalité, plus de sécurité, mais moins de performance, plus de lourdeur". C'est sans cesse des compromis comme ceux-là qui s'offrent à nous, jusqu'au jour où peut-être les outils en question deviennent de plus en plus puissants, qu'un langage sorte du lot pour toutes les utilisations tout en étant simple (what about golang?), enfin voila j'en fini là car je doute que beaucoup aient lu ce pavé jusqu'ici

[transgohan]

Les codes pour l'armée modifiés en assembleur par le développeur cela n'est valable que pour les vieux compilateurs (et on en utilise encore... Le temps qu'un processeur soit déclaré stable il s'écoule facilement 10ans).
Rien de comparable entre un gcc qui compile du x86 et un vieux compilateur qui compile du 68302...

[KiLVaiDeN]

Les codes pour l'armée modifiés en assembleur par le développeur cela n'est valable que pour les vieux compilateurs (et on en utilise encore... Le temps qu'un processeur soit déclaré stable il s'écoule facilement 10ans).
Rien de comparable entre un gcc qui compile du x86 et un vieux compilateur qui compile du 68302...

La spécificité de cette situation fait donc que ça ne s'applique pas au cas général, et l'assembleur est voué à progressivement disparaitre pour de bon. Sachez que personnellement, j'aime bien l'assembleur, sa logique, et puis cette sensation de communiquer "directement" avec le CPU, manipuler ses registres, c'était une de mes passions étant plus jeune; mais voila, le temps passe, les technologies évoluent, et ceux qui aiment les télévisions cathodiques n'en trouvent plus des neuves, bientôt ceux qui aiment l'assembleur ne trouveront plus de programme nouveau codé en assembleur, de toutes façons un jour on pourra coder en "MindL" : on pensera aux fonctionnalités de notre programme, et un casque d'analyse des ondes cérébrales se chargement de transmettre ça à un éditeur avancé qui générera le code pour nous, même le code, la programmation, ça disparaitra un jour pour laisser place à la pure logique, un programmeur n'aura rien de plus à faire que de déclarer ses besoins et tout sera codé automatiquement derrière, ou peut-être même directement compilé, déployè, disponible, testable, itératif, visuel, peut-être même en réalité virtuelle...

Ca n'est pas si loin, regardez déjà les progrès que nous avons fait en 20 ans! Nous avons aujourd'hui l'équivalent de 1000 ordinateurs dans la poche avec un écran portable qui à une époque pesait 20kg pour la même résolution...

[Grool]

de toutes façons un jour on pourra coder en "MindL"
[...]
même le code, la programmation, ça disparaitra un jour pour laisser place à la pure logique

M'est d'avis que ça nous promet des applis bien bugguées

Ou alors, ton édito/compilo à ondes cérébrales pourrait, en écoutant le "donneur d'ordres", devenir aussi schizophrène que le HAL 9000 de 2001 l'odyssée de l'espace.

[Andnotor]

Schizophrène ? Dave, fait attention à ce que tu dis

[Grool]

Fais attention à ce que tu penses!

[tralloc]

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

[Steinvikel]

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é 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. (...)

Donc pour résumer, un compilateur que ce soit pour l'assembleur, ou tout autre langage : il vérifie, puis optimise.
Seulement les langages plus haut niveau, intègrent des informations supplémentaires, permettant au compilateur des optimisations plus poussés, ou plus pertinentes. Ok.
J'avais perdu ce contexte de vu, a force de lire par ci par là tant de mérites à l'assembleur...

Je me rappel encore sur une tentative de mesure d'interruption, j'essayai de voir combien coûte une division par rapport à une opération classique, et la division apparaissait plus rapide (incompréhension totale).
Puis le prof est passé, à vérifié 2-3 truc, puis a sorti : "aah, j'ai compris ! --> le chiffre que tu divises est une puissance de 2 (512), le diviseur aussi (2), les réglages du compilo demandent une optimisation maximale --> il a sûrement transformé ta division en un décalage du registre (un chenillard quoi)."
PS: le programme était plus que rudimentaire. ^^'

L'étude porte sur l’efficacité de codes optimisés aux petits oignions, ça aurait été d'autant plus putaclic de lire "une étude révèle les langages les plus voraces en énergie ...l'assembleur n'est pas le plus efficace."