Je pense aussi que l'approche est bien trop grossière pour donner une information pertinente. Entre un programme à durée de vie courte et un à durée de vie longue ça va changer beaucoup les résultats pour les langages qui utilisent du JIT par exemple.
on a besoin de plus de code de qualité quelque soit le langage
Plus sécurisé ? Avec moins de bug ? Qui utilise moins de mémoire ? Moins de CPU ? Dont l'exécutable est plus petit ? Qui a du code dédié à chaque architecture ou gpu disponible ? Qui résiste à du fuzzing ? Qui est capable de traiter pleins de choses en parallèle ou une seule chose en un minimum de temps ?... La moitié de ces critères vont demander des choix pour faire plus l'un que l'autre.
Et tous demandent des tests, tu l'inclus comment dans le calcul ? Parce que les tests ont eux même un coût énergétiques. En plus des tests unitaires, faire des tests de performance seront particulièrement coûteux. Évidemment l'architecture de l'intégration continue sera primordiale pour la consommation énergétique.
Dernier point tu as un équilibre entre la facilité dans un langage d'écrire du code performant (quelque soit ce que tu met derrière le mot performant) et le coût de la compilation ou du runtime du langage. Dis autrement il peut être plus simple d'arriver à un code performant en python qu'en fortran. Tu as aussi des langages qui te poussent à écrire plus de tests car moins de choses sont vérifiées dans le langage.
Bref cela me paraît impossible de donner un tableau de valeur générique et de s'en contenter. Il serait plus intéressant de créer des méthodologies pour évaluer sont coût énergétique et pouvoir en faire une métrique optimisable au même titre qu'une autre.
[^] # Re: Je ne suis pas sûr que les logiciels libres soient moins consommateurs de ressources CPU/Mém
Posté par barmic 🦦 . En réponse au journal Cailloux, joujoux, bijoux. Évalué à 2.
Je pense aussi que l'approche est bien trop grossière pour donner une information pertinente. Entre un programme à durée de vie courte et un à durée de vie longue ça va changer beaucoup les résultats pour les langages qui utilisent du JIT par exemple.
Plus sécurisé ? Avec moins de bug ? Qui utilise moins de mémoire ? Moins de CPU ? Dont l'exécutable est plus petit ? Qui a du code dédié à chaque architecture ou gpu disponible ? Qui résiste à du fuzzing ? Qui est capable de traiter pleins de choses en parallèle ou une seule chose en un minimum de temps ?... La moitié de ces critères vont demander des choix pour faire plus l'un que l'autre.
Et tous demandent des tests, tu l'inclus comment dans le calcul ? Parce que les tests ont eux même un coût énergétiques. En plus des tests unitaires, faire des tests de performance seront particulièrement coûteux. Évidemment l'architecture de l'intégration continue sera primordiale pour la consommation énergétique.
Dernier point tu as un équilibre entre la facilité dans un langage d'écrire du code performant (quelque soit ce que tu met derrière le mot performant) et le coût de la compilation ou du runtime du langage. Dis autrement il peut être plus simple d'arriver à un code performant en python qu'en fortran. Tu as aussi des langages qui te poussent à écrire plus de tests car moins de choses sont vérifiées dans le langage.
Bref cela me paraît impossible de donner un tableau de valeur générique et de s'en contenter. Il serait plus intéressant de créer des méthodologies pour évaluer sont coût énergétique et pouvoir en faire une métrique optimisable au même titre qu'une autre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll