Pour les amateurs d'écologie numérique

Général
#1

Une étude interessante sur la consommation pour un grand nombre de langage de developpement vient d’être faite. C’est vachement interessant:

http://repositorium.uminho.pt/bitstream/1822/69044/1/paper.pdf

J’avoue ne pas avoir tout lu car l’article demande un peu de temps libre pour être parfaitement compris.

  • Je note sans surprise que les langages interprété sont les plus consommateurs d’énergie/cpu et de mémoire.

  • Je suis étonné de voir que java n’est pas si mal classé.

  • Je note une chose amusante: JRuby (l’interpréteur ruby en java) est plus performant que Ruby (l’interpréteur ruby en C) alors que le langage Java est moins bien classé que le langage C. A mon avis les personne qui développent l’interpréteur Ruby en C ont de la marge de progression.

Question : pour economiser de l’énergie sur les serveurs, et donc diminuer le nombre de serveurs nécessaires pour rendre un service, qui est prêt à:

  • développer moins vite en utilisant un langage compilé plutôt qu’un langage de script ? (et donc réduire le time to market)
  • payer ses développeurs plus cher car les langages plus complexe demandent des développeurs mieux rémunérés ?
  • avoir du mal à recruter car les langages plus complexes demandent des compétences plus rares ?

Je pense que ce ne sont pas les choix écologiques qui vont prendre le dessus, mais plutôt les choix économiques.

Je note toute fois que Go propose un mix interessant entre la rapidité d’écriture et la performance du langage. Il consomme seulement 3x plus d’énergie que du C.

Evidement la reflexion peut être étendue:

  • Il est evident que les langages de script utilisent des primitives compilées pour la plupart des taches, aussi la consommation d’énergie données dans cette étude est un maximum qui ne correspond pas aux cas réel, mais cela donne tout de même une bonne idée.

  • utiliser un langage compilé pour baisser la consommation énergétique, c’est bien, mais si on utilise un framework ou une bibliothèque très riche qui font un peu tout (et surtout des choses dont on n’a pas besoin), ne va t-on pas perdre le gain en énergie du au choix du langage ?

7 « J'aime »
#2

J’ai deja lu des etudes similaire, et globalement le probleme qui ressort est le suivant.

Si sur des tests bien precis le C par exemple est plus “ecologique” que le python. En vrai un developpeur moyen, va surement faire plus d’erreur de gestion en C qu’en python et donc avoir une consomation plus grande.

C’est au final un debat qui est impossible trancher.

5 « J'aime »
#3

Si, c’est facille : faut faire du Pascal et du Fortran… Les deux sont plutôt bien placés et les développeurs qui sont prèt à y aller sont error-proof :smiley_cat:

Merci pour ce partage qui va devoir en effet être bien décortiqué, mais ce que j’en retiens avec une première lecture (en travers) pourrait se résumer en :

  • A l’heure des micro-services, il faudrait se poser la question du meilleur compromis energie/temps/mémoire pour chaque type de traitement à accomplir.
  • Chaque traitement pouvant être découpé en un micro-service, utiliser le langage le plus économe peut être décidé assez finement.
  • Dans le triangle Qualité - Couts - Délais, l’impact écologique peut être imputé dans la Qualité (choix d’un développement éco-responsable) ou dans les coûts (subir le surplus de compétances) : ce n’est donc qu’un choix politique de l’entreprise, et ça peut être un atout marketting dans les intérogations actuelles.

Bon, alors, on sauve les abeilles, ou pas ? :slight_smile:

1 « J'aime »
#4

Je ne voit pas pourquoi un développeur moyen en C ferrait plus ou moins d’erreur que dans n’importe quel autre langage, vu qu’on atteint le niveau dit “moyen” en fonction du nombre d’erreurs que l’on fait. En C c’est plus long d’atteindre le niveau “moyen” car la personne souhaitant atteindre un niveau moyen devra apprendre plus de connaissances théoriques sur l’algorithmique et le fonctionnement d’un OS, qui ne sont pas nécessaires en langage scripté.

Les langages de script sont des langages qui économisent le cerveau du développeur une fois, en gaspillant de la resource CPU/mémoire à chaque fois que le programme est utilisé.

A temps de pratique égal un développeur dans un langage de script sera plus efficace qu’un développeur C. Donc, le développeur C est plus rare et plus cher. On peut aussi dire qu’a coût égal (TJM), le niveau d’un développeur C sera moins élevé qu’un développeur de script.

Je ne suis pas sur que des erreur de gestion en C arrivent au niveau de gaspillage d’un langage scripté. En cherchant, on trouvera forcement un example (après tout Ruby est plus lent que JRuby), mais peut-on en faire une généralité ? Je doute vraiment de cette affirmation.

Il y a aussi la question de la consommation de resources induit par le modèle micro-service lui-même. Pour communiquer, il faut nécessairement encoder les données (soit rapidement avec du TCP/IP + ASN/DER ou du Protobuf ou très lentement avec du TCP/IP + HTTP(S) + JSON ou XML), traverser la couche réseau (les règles iptables, le système de conntrack, …), peut être des load-balancer (depuis Kubernetes il sont devenus invisibles sur les schémas), puis decoder tout ça à l’arrivé. A mon avis l’impact énergétique de ces opérations n’est pas neutre.

Globalement, je suis d’accord. L’écologie sera prise en compte dans les développement le jour ou les politique légifèreront. On peut inventer un taxe sur les langage consommateurs d’énergie, ou les interdire. On peut faire comme pour les voitures: si tu n’a pas la vignette sur ton code, tu n’entre pas dans le DC.

J’ai un peu peur de ces gens qui légifère. Il faut pas oublier que:

  • certains préconisent de vider les boites email pour l’écologie
  • d’autres essayent d’estimer le cout CO2 moyen de transfert d’un bit sur internet

Ca ne laisse pas beaucoup d’espoir sur leurs compétences sur le sujet.

3 « J'aime »
#5

Vu que les experts comme les gens qui travaillent sur le kernel ou openssl se font toujours avoir avec la gestion de mémoire et introduisent des failles critiques je sais à 100 % que si je devais faire du C je me planterai :smiley: Et de manière générale je vois pas l’intêret de C (ou Rust soit dit en passant) pour du développement “classique” (en gros pas bas niveau).

Sinon le benchmark est intéressant même si comparer de “vrais” programmes aurait été peut être plus intéressant. Par exemple la JVM va être mal classée sur un merge-sort basique tout simplement car l’overhead de la JVM pour une petite tâche est important, sur une vraie app par contre il devient souvent négligeable.

Personnellement je suis sur Go et JVM pour mes applications, qui sont pour moi les meilleures plateformes en terme de perf/productivité/écosystème/facilité de déploiement aujourd’hui.

#6

Attention, moyen voulais dire ici dans le sens, tu prends quelqu’un au hasard, comme le français moyen. Pas du niveau moyen. Et donc comme tu l’a très bien expliqué, globalement, le niveau moyen est plus dur à atteindre en C qu’en python. Donc le développeur moyen C a plus de chance de savoir-faire moins de chose que le développeur Python ou de faire plus d’erreur

Je ne suis pas d’accord, les langage haut niveau (pas de script) permette à développeur de s’abstraire d’une complexité qui est inutile pour développer une application. Mais ça ne veut pas pour autant dire qu’on gaspille de la ressource CPU/Mémoire.

Je coderai en C plutôt qu’en Java, je ne suis pas sûr de faire un meilleur boulot que la JVM. Au contraire cette JVM peut être améliorer au fil du temps par une poigner de gens qui au final profitera à toutes les applications d’un coup.

De façon micro peut être que tu peux monter une équipe qui fera du plus bas niveau de façon performante et donc tu seras plus écologique. Mais raisonnons à l’ordre de grandeur et de façon macro, il est bcp plus efficace pour le plus grand monde de développer en Java avec des équipes qui s’occupe de la performance de la JVM plutôt que de s’assurer que tout le monde ai une équipe compétente pour faire mieux

Encore une fois vu que le développeur moyen a sans doute un niveau au final plus faible en C qu’un développeur moyen en Python, c’est logique qu’il fasse plus d’erreur ou passe plus de temps à développer

#7

On est bien d’accord sur ce point.

Mon sujet initial était: au vu de cette etude, va-t-on investir dans les moyens nécessaires pour passer ses programmes dans un langage moins consommateur de resources, ou bien tant pis pour le gaspillage induit par les programmes, la métrique budgétaire et time to market avant tout !

Je suis d’accord, j’ai été très surpris par Java qui n’est pas si mal classé, alors que la plupart des programmes java que je teste (perso et en clientèle) sont des gouffres de mémoire, de CPU et donc d’un lenteur affligeante. Je ne pense pas que ce soit du au concept de JVM, mais plutôt au fait d’utiliser massivement des lib & framework mal qualifiés et mal utilisées.

1 « J'aime »
#8

C’est exactement ça. Des frameworks comme Spring sont horribles sur de nombreux points dont celui là. Pourtant la JVM est très optimisée, d’ailleurs de nombreuses applications à haute performance/big data sont écrites en Java.
Le seul truc où la JVM est mauvaise par rapport à la concurrence c’est la consommation mémoire (1 thead = 1mb par exemple donc ça monte vite), et sur le temps de startup parfois aussi (faut parfois quelques secondes). Cela peut se remarquer sur des tâches courtes (comme une CLI ) ou de petits programmes (et c’est ici que Go est meilleur). Sur des programmes de type daemon/server, et avec une consommation mémoire plus importante (donc la taxe JVM est moins visible).

1 « J'aime »
#9

Une alternative c’est de faire du natif avec Graal VM. Je pense que c’est top pour des outils en cli par exemple.

1 « J'aime »