Our results suggest that the choice of programming language has no significant impact on energy consumption beyond runtime. Programmers aiming to reduce energy consumption can do so even in “inefficient” programming languages like Python by using faster language implementations, employing faster algorithms, and using fast third-party (native) libraries.
Voilà, boom !
On est pas bien, là, tranquilles, dans notre biais de confirmation ?
Biais de confirmation peut-être, mais c’était toujours le même tableau plaçant Python dans les dernières places que je voyais ressortir quand la question était évoquée, jouant allègrement sur la confusion entre langage et implémentation et avec une méthodologie parfois contestée (implémentation brute de plusieurs algorithmes).
On reproduit le tableau juste pour souligner les anomalies les plus surprenantes. Faut lire l’article un peu plus à fond: par example, notre article distingue clairement entre les langues et leur implementations.
Je pense alors avoir mal formulé mon message : j’indiquais que j’étais content de voir un autre papier sur le sujet parce que celui habituellement cité me sortait par les yeux (et c’est celui-là dont je critique la confusion et la méthodologie).
Et que donc tant pis si c’est juste un biais de confirmation qui fait préférer le papier dont il est question ici, au moins ça fait plaisir d’avoir une nouvelle référence.
je ne saurai vous contredire étant donné votre expérience en matière de l’ingénierie de compilateurs et l’absence de celle-ci chez moi ;
j’ai toutefois une intuition (qui vaut ce qu’elle vaut) : il me paraît plutôt vraisemblable, pour un langage donné et une architecture de processeur donnée, d’atteindre (ou d’avoir déjà atteint) un seuil incompressible en matière d’optimisation de la compilation ; et que, dès lors, le progrès ne pourrait avancer que par l’accroissement de la capacité et de la puissance de calcul, ce qui passe nécessairement par l’accroissement de l’appétit énergivore…
et enfin, reste un autre problème d’appétit irréductible, lié à la nature humaine même : nos penchants maximalistes, qui font que même si demain on inventait des machines à la fois plus puissantes et qui consommeraient beaucoup moins et chaufferaient beaucoup moins, les utilisateurs feraient tourner encore plus de logiciels dessus, les éditeurs ajouteraient à leurs produits des fonctionnalités et des effets encore plus gourmands en ressources, etc, si bien que le gain énergétique serait vite laminé…
Intéressant ! Et peut-être assez vrai pour les langages compilés (mes connaissances dans les différents compilateurs ne sont pas assez poussées pour discuter le bout de gras).
Mon intuition est qu’avec la puissance des machines qui augmente, les développeurs prennent leurs aises (j’appelle ça « acheter du confort », acheter car on le paye en cycles CPU, et donc en énergie). Par « les développeurs » j’inclus ceux qui créent des bibliothèques et des langages, pas uniquement ceux qui les utilisent.
On se retrouve donc avec toute une variété de langages plus ou moins compilés pour des raisons de confort (bash qui est littéralement interprété caractère par caractère, Java qui compile en bytecode lors d’une étape de compilation (qui peut donc dépenser du temps à optimiser), puis qui exécute le bytecode, Python qui compile en bytecode discrètement avant l’exécution (qui ne peut donc pas trop se permettre de dépenser du temps à la compilation pour optimiser, …), et donc certains langages peuvent et d’autres ne peuvent pas respecter ton intuition (atteindre le seuil incompressible d’optimisation à la compilation), d’où l’envie de certains de comparer les « performances énergétiques » de ces langages.
Et on se retrouve avec toute une variété de pratiques qui évoluent pour gagner du confort : il y a quelques dizaines d’années beaucoup tentaient de stocker le maximum d’information sur le minimum de bits (flags ORés comme l’argument mode du syscall open, ou stocker deux petits ints de deux octets dans un seul int de 4 octets (le return de main), de gagner quelques cycles par ici, quelques bytes par là, etc. pour qu’enfin ça fonctionne en un temps acceptable. Développer prenait du temps. Alors qu’aujourd’hui on prends nos aises (parfois même à raison car on gagne en lisibilité et en maintenabilité).
D’ailleurs les langages « interprétés » c’est déjà pour moi l’apparition d’une forme d’achat de confort qu’on aurait pas pu se permettre sur de vieilles machines. D’ailleurs un compilateur c’est déjà du confort par rapport à écrire de l’assembleur (merci Grace).
Qui n’a jamais fait en Python un sorted(items, key=lambda item: ...)[-1] pour obtenir le plus gros élément d’un itérable en fonction d’un critère ? C’est confortable, c’est vite écrit, ça utilise des briques qu’on connaît bien, ça donne le bon résultat, mais c’est aussi un beau gâchis : pas besoin de trier toute la collection pour trouver le plus gros, pas besoin de faire une copie de toute la collection non plus d’ailleurs. (en passant max(items, key=lambda item: ...) est bien mieux). On ne se rend pas compte du gâchis parce que la machine va vite, mais on s’en serait rendu compte il y a 30 ans sur une machine plus lente, et on aurait implémenté une fonction spécifique et bien optimisée pour faire cette recherche : ça n’aurait pas été très confortable, ça aurait prit du temps à l’humain plutôt qu’en prendre à la machine.
même si demain on inventait des machines à la fois plus puissantes et qui consommeraient beaucoup moins et chaufferaient beaucoup moins, les utilisateurs feraient tourner encore plus de logiciels dessus
Totalement d’accord, je pense qu’on « achèterait » énormément de confort, cProfile serait finalement retiré de Python car considérée « dead battery » On aurait un module natif dans la stdlib de Python fournissant un décorateur pour générer le corps d’une fonction selon sa docstring, utilisant un LLM embarqué. Et la stdlib de Python l’utiliserai à plein d’endroits. Et le binaire Python ferait plus de 800GB pour contenir les poids du LLM. Et juste démarrer l’interpréteur consommerai déjà de quoi faire bouillir 60 litres d’eau. D’ailleurs Python ne démarrerai que sur du hardware spécialisé pour faire tourner ce genre de modèles. Et on trouvera ça confortable.