Hello, je viens de tomber sur un article rédigé en 2017 par des chercheurs portugais sur la thématique du "green computing", centré sur la question :

Quels sont les langages les plus efficaces en termes de consommation énergétique ?

Un article sur Medium qui résume les résultats de ces recherches : https://medium.com/codex/what-are-the-greenest-programming-languages-e738774b1957
Le lien vers l'article complet : https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

Sans grande surprise on retrouve C et C++ dans le haut du panier, mais je remarque aussi la présence de Rust sur le podium.

Sans forcément se limiter à l'aspect écologique, j'ai toujours trouvé le green computing intéressant à la simple idée de tirer le meilleur profit des architectures modernes de nos machines. L'idée de pouvoir faire tourner des plateformes complètes sur de petits CPUs ARM, quitte à scaler horizontalement au lieu de juste tout bourrer sur un Xeon Gold qui fera juste office de grille-pains en idle la moitié du temps... je sais pas, c'est motivant.

Des avis sur tout ça ?

Javascript à 4.45 et typescript à 21 ??
Comment cette étude peut encore être crédible...

Salut a toi GoogleBot.

De facon general, je suis d'accord avec toi. La question centrale a mon avis est une question de "total cost" et pas juste du cout operatif local. Si tu as une application super inefficace mais qui ne tourne que sur une machine et moins de 2% du temps. Alors tu t'en fous complement qu'elle soit super inefficace.

Quand j'enseigne mon cours de calcul haute perf, c'est le calcul que je presente en debut de cours. Combien ca coute une machine a acheter et a operer? Combien ca coute un ingenieur en performance? Et la question devient a quel moment ca devient rentable de payer un ingenieur en perf pendant un mois pour couper/ne pas acheter combien de machine. Et en gros, le cout d'un ingenieur est equivalent a une 20aine de machine.

Donc ce que ca montre c'est qu'optimiser un systeme qui ne sature pas beaucoup de machine n'en vaut probablement pas le cout. Mais si tu as une application qui scale sur des centaines de machines alors meme une optimization de quelques pourcent peut etre rentable a cause de l'echelle.

Penses au cout de facebook. Travailler sur php et gagner 2% de perf sur les workload php de facebook, c'est probablement l'equivalent de 100aines de machines que tu peux eteindre. Et ca justifie completement le cout d'une equipe d'ingenieur de perf php.

Le 13 septembre 2022 à 14:07:30 :
Javascript à 4.45 et typescript à 21 ??
Comment cette étude peut encore être crédible..

Le papier est de 2017. Il faut donc probablement prendre les résultats avec des pincettes. Les machines ont changer, les compilateurs ont changé et les workload ont change. Mais la méthodologie et les conclusions dans les grandes lignes sont probablement toujours correcte.

Cela étant dit, c'est un point de départ de discussion et pas la donnée unique a utilisé pour prendre des décisions techniques.

Le 13 septembre 2022 à 22:13:44 :

Le 13 septembre 2022 à 14:07:30 :
Javascript à 4.45 et typescript à 21 ??
Comment cette étude peut encore être crédible..

Le papier est de 2017. Il faut donc probablement prendre les résultats avec des pincettes. Les machines ont changer, les compilateurs ont changé et les workload ont change. Mais la méthodologie et les conclusions dans les grandes lignes sont probablement toujours correcte.

Cela étant dit, c'est un point de départ de discussion et pas la donnée unique a utilisé pour prendre des décisions techniques.

C'est surtout que Typescript est transcompilé en javascript donc la consommation et le temps d'éxecution devrait être quasiment le même...

C'est surtout que Typescript est transcompilé en javascript donc la consommation et le temps d'éxecution devrait être quasiment le même...

Ah! Je vois ce que tu veux dire. C'est pas forcement etonant. Il y a des tas de trucs qui sont transpile en autre chose et ou les deux langages performent assez differement. Souvent ce sont des cas d'overhead lie a a la transpilation, les semantiques sont legerement differente et pour assurer la compatibilite du code, il faut rajouter une verification qui tue les perfs.

Si tu lis le papier, tu vera que ca depends des workloads. Il y a des workloads ou ils sont quasiment pareil et des workload ou ils sont signifiativement different. J'imagine qu'une question naturelle est en effet: pourquoi est ce que ces deux langage sont si differents dans ce cas en particulier? Mais ce n'est pas le but de cette etude la en particulier.

Si tu savais le nombre de fois ou j'ai dit "X et Y devrait etre pareil" et en fait pas du tout une fois que tu regardes les details...