Et le logiciel, alors ?
juin 2, 2008 10:43 logiciel, produits greenUn lecteur m’a interpelée par mail peu après le lancement du blog. Avant toute chose, il a précisé approuver l’idée de traiter le green IT et comprendre également nos contraintes économiques (essentiel par rapport à ce qui suit !). Mais il m’a fait une remarque intéressante à propos de la publicité sur le blog. La plupart du temps, celle-ci prend la forme de petits modules flash. Des modules animés en permanence, qui sollicitent le processeur et consomment donc beaucoup d’énergie.
Il se trouve que je m’interroge depuis un moment sur la raison pour laquelle on n’incrimine que rarement, voire jamais, le logiciel dans les questions de consommation énergétique. Du coté du matériel, on sait déjà beaucoup de choses. On sait que l’on peut réduire la consommation au niveau du processeur, du serveur, du datacenter et que l’on peut concevoir plus proprement les machines pour mieux les recycler. Mais quid du logiciel ?
Dégraissons le code
Certes, c’est un excellent outil de surveillance de la consommation électrique ou du dégagement de chaleur. Il fait merveille dès qu’il s’agit de virtualiser les systèmes, etc. Mais se pourrait-il que certains applicatifs, écrits sans trop de précaution à l’époque bénie où personne ne se souciait trop de la planète (ni du coût de l’électricité) poussent aussi à la consommation d’énergie. Il serait sûrement plus judicieux de revenir à des méthodes de développement qui optimisent le code que de continuer d’empiler les couches au fur et à mesure des versions.
Si j’en crois Bruno Pinna, directeur marketing de Bull, de grands éditeurs entament des démarches dans ce sens. Il ne donne aucun nom, mais bien évidemment, des Microsoft, Oracle ou SAP viennent vite à l’esprit. Selon Bruno Pinna, les logiciels pourraient même d’ici trois ou quatre ans gérer leur propre consommation énergétique. Ils la mesureront à partir de capteurs idoines installés dans les machines. Et ils pourraient même faire en sorte de s’exécuter sans dépasser un certain niveau de consommation.
Moins de matériel à la poubelle
N’oublions pas, enfin, que si les versions successives des logiciels ne demandaient pas systématiquement beaucoup plus de puissance, plus de mémoire, cela n’obligerait pas à renouveler tous les deux ou trois ans le matériel qui permet de les faire tourner. Et l’on retrouverait ainsi moins de machines obsolètes, polluantes, dans la nature.
En bref, même si il reste beaucoup à faire coté matériel, il sera intéressant de suivre la stratégie des éditeurs de logiciel vis à vis de la consommation énergétique de leurs produits.
juin 2nd, 2008 at 14:49
Merci pour votre blog !
Votre remarque est très pertinente.
- Identifier les causes -
Appliquons à la surconsommation des datacenter le principe suivant : pour guérir d’une maladie, il faut agir sur ses causes, pas seulement sur les conséquences.
Regardons alors l’enchainement des besoins qui a conduit à l’utilisation des datacenters :
A) Hardware
On construit des datacenter pour y installer des équipements informatiques (servers, networks,…)
B) Software
on installe ces équipements pour faire fonctionner des logiciels.
C) End-users
on concoit des logiciels pour répondre à des besoins fonctionnels d’utilisateurs.
- agir sur les causes -
Le pourquoi ainsi exprimé nous aide à trouver des pistes d’optimisation. En remontant la chaine de causalité à l’envers, voici un certain nombre de propositions pour réduire la consommation des datacenters :
C) End-Users
Challenger les besoins utilisateurs (performances, fonctionalités, ergonomie,..) pour développer au juste nécessaire.
B) Software
Appliquer des notions de développement durable au développement informatique. Par exemple, en vrac : optimiser les choix d’urbanisme des applications; Introduire des tests de consommation de ressources hardware lors des choix de progiciels; Retenir les outils et langages les plus performants; Tester l’impact des codes spécifiques développés; Disposer de benchmarks…
A) Hardware
Optimiser la consommation de ressources électriques par des choix appropriés d’architecture des plate-formes hardware. Sans oublier l’optimisation de l’architecture du bâtiment lui-même. Un exemple : comment récupérer l’air froid extérieur en hiver pour éviter de climatiser une salle ?
- sensibiliser tous les informaticiens -
En remontant le courant des raisons ayant amené à construire des datacenters, il nous apparait vite que le “Green IT” est l’affaire de tous les informaticiens. Reste à les sensibiliser suffisamment pour que de bonnes pratiques émergent !
EM
20080602
juin 4th, 2008 at 11:24
hmm, sachant que tout test de consommation est par définition une nouvelle source de consommation :
c’est un peu comme les simulations de réchauffement planétaire, la consommation des clusters est terrible mais on n’en parle pas !
une autre façon de voir le problème est de voir que l’on parle de réchauffement climatique sans parler de la consommation inutile et spectaculaire des courses de F1
en informatique, on ne veut pas entendre que Vista consomme 50 Watt de plus qu’XP (consommation en continu de la mémoire RAM, allez savoir pourquoi ?)
bref, vous écrire depuis un portable qui a plus de 15 ans en dit en peu plus sur ma façon de voir la course à l’évolution software/hardware
et d’y réagir à ma façon.
les animations flash sont une consommation dérisoire par rapport au système d’exploitation, autant commencer par le plus important
et
osons dénoncer ce qui est dénonçable (pratique marketing, par exemple, des systèmes qui ont des failles, d’où une nécessiter de mettre des anti-virus qui consomme etc…).
des systèmes avec moins de virus (du côté des unix-linux ou de versions militaires, ça existe je n’invente rien) pourquoi le grand public n’aurait pas accès à quelque chose de plus fiable ?
(pour remarque : des machines des époques amstrad et atari fonctionnent encore très bien pour une utilisation quotidienne)
pour revenir aux logiciels,
le problème peut aussi être abordé dans la façon de développer des logiciels.
j’entends par là qu’un programme mal conçu (pour des raisons marketing parfois, je ne plaisante pas du tout) peut obliger à redémarrer la machine (usure significative du matériel) doit être maintenu, corrigé, etc… donc les postes des développeurs fonctionnent à plein régime sur le codage, débuggage, tests fonctionnels, etc…
au contraire, assurer un code “propre” au sens où il n’y a pas de bug, sera “productif” et ne nécessitera pas de perdre temps et énergie (énergie humaine ou électrique) dans une maintenance.
en un sens, c’est un tout !
on pousse à acquérir rapidement un logiciel, un datacenter (idem pour les biens hors-informatiques)
sous la pression d’une concurrence (des logiciels de plus en plus intégrés, offrant plein de features à l’écran mais d’un point de vue “fonctionnel” on pourrait clairement s’en passer),
(pour les biens non-informatiques, c’est le mot “croissance”)
mais le principe est le même,
pourquoi a-t-on besoin d’autant ?
ensuite, une salle serveur chauffe et l’on pense à refroidir par l’air froid en hiver, oui
une salle serveur peut chauffer d’autres salles ? (en hiver)
est-ce que le test est concluant concernant les salles serveur sous vide (HP ?) ?
la sensibilisation doit se faire mais à tous les niveaux
(dans le désordre) :
informaticiens, distributeurs, architectes, consommateurs, utilisateurs, (j’en oublie sans doute)
parce que tout le monde participe et il serait vain de ne faire porter la réflexion que sur l’un ou l’autre acteur.
pour ma part,
je tiens à m’excuser pour la longueur du billet
(des écrans qui ne consomment pas lorsque l’image est fixe, ça existe pour des panneaux publicitaires, par contre, pour un traitement de texte, 80% de l’écran consomme sans modification de l’info/pixel, là encore doit-on intervenir ?)
et pour l’agressivité latente (du fait de mon expression)
le problème n’est pas simple c’est un tout.
merci.
gardons le moral.
juin 11th, 2008 at 21:36
Votre point de vue est intéressant.
Concernant le logiciel, il serait peut être bon de revenir à la base.
Construire rapidement un ouvrage fiable passe par une utilisation partout où c’est possible de composants pré-fabriqués (les progiciels) que l’on assemble et intègre en suivant des recettes “éprouvées”.
Ce qui s’applique pour les ponts et les maisons est aussi valide pour le logiciel d’entreprise: ils sont construits ’sur-mesure’ à partir d’éléments pré-fabriqués (les progiciels). Et les motivations sont économiques dans le bon sens du terme: vous voulez qu’une maison de qualité vous soit livrée dans les délais et que son coût soit dans le budget annoncé.
Les progiciels sont proposés par des éditeurs qui pour survivre doivent rester compétitifs côté fonctionnalités: impossible de n’utiliser que ce que vous avez besoin sans subir les inconvénients de ce qu’il y a “autour”.
L’assemblage s’effectue avec une colle assez spéciale: potentiellement, nous pouvons ‘intégrer’ presque tout et n’importe quoi, reste à créer une passerelle plus ou moins compliquée pour que çà “colle”.
L’utilisation de progiciels peut difficilement aboutir à autre chose que la construction d’un ouvrage dont la complexité demandera des ressources physiques (réseau, stockage, serveurs) surdimensionnées.
Note: il y a longtemps que le coût du matériel n’est plus un facteur obligeant une certaine modération.
La démarche “construire avec des éléments pré-fabriqués” reste bonne: inutile de ré-écrire à chaque fois, meilleure fiabilité, maîtrise des risques et de délais, réduction des coûts.
Utiliser des composants ‘disproportionnés’ par rapport aux besoins réels est une pratique discutable.
Note: bien sûr, nous avons aussi des trucs construits avec les pieds mais ils respectent le “modèle de construction standard”.
Ceci dit les éditeurs vivent parce qu’ils arrivent à convaincre les clients d’utiliser leurs produits, le constructeur est heureux de renouveler vos équipements, la SSII de passer plus de temps à tester, mettre au point,…
C’est le fonctionnement de tout un écosystème qui est affecté par une remise en cause de ce modèle de construction.
Il y a tellement de gaspillage que nous pouvons certes réduire la consommation des équipements (en déployant des capteurs, des logiciels de supervision et des logiciels “embarqués”,… ou en changeant certaines habitude).
Construire autrement est un sujet beaucoup plus ambitieux mais qui risque d’être autrement plus payant.
merci
juin 12th, 2008 at 18:20
Bonjour,
Je suis en plein dans le Sustainable Software dans la communauté Sustainable IT Architecture que j’ai initié il y a presque une année maintenant. Comment stopper la croissance sale du SI…
A voir ici :
http://www.sustainableitarchitecture.com/home
Cordialement
Pierre Bonnet
juin 17th, 2008 at 10:55
Tiens, ça me fait penser à une discussion avec une petite boîte de maintenance il y a 2 ans.
Le gars me parlait d’un de ses client, une association “PME” (~ 30 personnes) qui était en pleine migration Linux… ces gens voulaient non seulement basculer leurs postes de travail (c’est bien ;-)), mais aussi utiliser un vieux P3 comme serveur d’impression. Il a eu toutes les peines du monde à leur expliquer qu’un serveur ad hoc neuf, type JetDirect, serait bien mieux adapté, en particulier en termes de consommation électrique.
Il est vrai que le domaine d’activité de cette association était… le développement durable.
juin 24th, 2008 at 18:28
juste une petite correction
Linux consomme excessivement la RAM (mais très peu de processeur en fait)
la correction étant faite
j’en profiterai pour rappeler que des projets de “développement minimum” ou rationnel sont très à la vogue :
pour limiter le nombre d’interface entre logiciel, il existe des ETL (convergence des sources de données) ou des EAI (bus logiciel, les données sont déjà centralisées)
mais il me semble - surtout pour les ETL - que cette architecture se superpose sur l’existante et finit par doubler la consommation machine (et saturer le réseau par la même occasion, d’où une nécessité de doubler les équipements etc…)
l’idée de base et d’obtenir une “cohérence forte” (communication entre les composants) et un “couplage faible” (indépendance, composants interchangeables)
c’est-à -dire que l’on vient de prolonger le raisonnement de la séparation des données (bd) du traitement (le reste du programme) et des IHM (portabilité)
ce n’est en aucun cas remettre en cause la guerre des standards, normes, et popularité des logiciels.
donc je pense que l’on ne se bat pas au bon niveau.
pour ma part, je finirai par dire que l’on s’approche d’une 3ème crise du logiciel portant cette fois non pas sur l’efficacité logicielle mais sur son efficience.
Arnaud
juin 24th, 2008 at 19:56
C’est très intéressant comme idée que le logiciel peut avoir sa part à jouer dans la quantité d’énergie dépensée par un ordinateur!
Nous pourrions dire que les programmes en assembleur (très optimisés) sont les plus “verts”!
juin 24th, 2008 at 22:31
Ne pas oublier de compter le temps pour écrire le programme…
Ben oui, généralement on compte qu’un programmeur tape le même nombre de lignes de code (puisque c’est l’unité de mesure) par jour indépendamment du langage (d’où une augmentation de la “productivité” en utilisant des langages de 4ème génération).
Au-delà d’une certaine vitesse de processeur (dont la fréquence ne cesse d’augmenter), le gain n’est pas significatif :
je m’explique
aujourd’hui, il n’y a quasiment plus de différence de vitesse entre les exécutions de codes Fortran et C++ (et l’on s’acquitte rapidement de la différence par l’acquisition d’un processeur performant (coût du matériel cf. billet de wiztricks)
Donc, un code en assembleur rapide à l’exécution sera très long à écrire finalement.
(et la config des claviers datent des machines à écrire, les touches sont éloignées pour que l’on tape lentement et que la machine ne s’enraye pas…
s’interroger sur un code propre remettrait tout en question y compris les périphériques d’entrées, sinon c’est dommage d’avoir une démarche bancale
)
Je crois que c’est le même problème pour le bio-carburant : on commence à se douter que la production de bio-carburant consomme plus qu’une production standard… d’où le paradoxe.
En réalité, on a juste déplacé le problème, on ne l’a pas résolu pour autant (bio-carburant ou informatique)
J’en profite pour signaler une autre idée (décidément)
Ce qui est sûr c’est que les interfaces des logiciels n’ont pas évoluées en 20 ans…
D’un point de vue marketing, on ne parle que de doubler notre productivité avec l’arrivée de processus plus performant (quadri-core, etc…) ce qui est faux !
car il n’y a jamais eu autant de vente de bouquins “l’informatique pour les nuls”
à mon avis, si on veut travailler sur la consommation du logiciel, on pourrait aussi s’interroger très fortement sur la capacité du logiciel à être intuitif pour l’utilisateur (”productivité/utilisabilité”):
parce que s’il faut perdre du temps à trouver l’option que l’on veut sous un logiciel, cela relève bien d’une consommation inutile.
Donc un logiciel propre, pourquoi pas… mais il faut s’attarder sur les phases de conceptions, de développement, de tests, de déploiement, d’utilisation et de maintenance afin de ne pas passer à la trappe des aspects sur lesquels il est possible de faire levier.
Au passage, les protocoles Internet n’ont pas changé depuis le depuis (mais il y a une réflexion en cours) et c’est un casse-tête pour la sécurité réseau :
faut-il considérer cela aussi ?
A mon avis, il nous faudrait un modèle de conception très souple où la moindre faute de conception nous imposerait de réfléchir à faire mieux et de ne pas laisser persister ce genre de problème, de diffuser la ou les solutions
et pourquoi pas de s’excuser.
parce qu’il n’y a que dans le domaine du logiciel où l’on considère que le bug est normal.
c’est une attitude bien étonnante que d’être tolérant ici dans l’utilisation de qqch qui ne fonctionne pas comme souhaité.
Aimeriez-vous une maison mal foutue et que l’on vous dise que l’on a de la chance ?
idem pour une voiture ?
Bonne nuit
décembre 9th, 2008 at 13:10
[…] Il serait effectivement judicieux de commencer à s’intéresser aux systèmes informatiques dans leurs globalité. Et de faire collaborer ceux qui observent le comportement énergétique (et environnemental) des puces, ceux qui s’en occupent pour les périphériques et les postes de travail, ceux qui travaillent au niveau du datacenter, ceux qui observent la communication et les réseaux… Et pourquoi pas ceux qui un jour s’interrogeront sur la consommation des logiciels. […]
février 11th, 2009 at 0:21
N’oublions pas que la véritable pollution electronique se niche dans les SPAM qui occupe une bande passante de plus de 50% du traffic. Du point de vue psychologique, les effets d’irritation et d’aggacement depassent l’effet de serre. Le comble étant bien sûr de recevoir des spam dont l’expéditeur est soi- même. La solution ? la messagerie sécurisée. les solutions existent mais personne ne bouge.
février 17th, 2009 at 1:42
[…] qu’au mois de juin dernier, je m’étais justement interrogée ici même sur l’intérêt d’optimiser les logiciels pour moins consommer d’énergie. S’en était […]
juin 5th, 2009 at 21:25
[…] http://blog2.lemondeinformatique.fr/greenit/2008/06/et-le-logiciel-alors.html […]