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

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+

Envoy� par KiLVaiDeN

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

Envoy� par tanaka59

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.

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

Envoy� par tanaka59

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

Envoy� par ParseCoder

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

J'allais poser la question...

Envoy� par Shepard

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

Envoy� par el_slapper

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

Envoy� par archqt

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 !

Envoy� par Steinvikel

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.

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.

Envoy� par 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.

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

Envoy� par darklinux

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

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

Envoy� par 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...

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

Envoy� par KiLVaiDeN

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.

Schizophr�ne ? Dave, fait attention � ce que tu dis

Fais attention � ce que tu penses!

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

Envoy� par KiLVaiDeN

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