Bon en gros, l'article dit: la virtualisation encourage les gens à avoir un bout d'internet à eux, et ça consomme.
Bon. En soit, ça semble logique. Sauf que, l'alternative, en supposant que les "bout d'internet à soit" ont réellement un intérêt, c'est que chacun ait sa machine perso. On ne me fera pas croire que ça serait plus écolo…
Un autre passage parle de la sur-utilisation de la RAM. Ah, ça, ça me parle, p'tet que ça va aborder un truc pertinent?
Ben non. Les solutions abordées, c'est de dédupliquer… Une vraie solution, mais qui casserait énormément de logiciels dont la totalité des navigateurs internets ainsi qu'ASAN et certaines techno de sandboxing (enfin, sur un serveur osef, mais bon, y'a pas que les serveurs qui sont impactés par le problème) ça serait de désactiver l'overcommit, qui est une fonctionnalité qui permets à un logiciel d'allouer plus de ressources qu'il n'en existe réellement.
En quoi ça serait une solution? Tout simplement parce que ça rappellerait aux développeurs que non, ils ne doivent pas faire comme les économistes qui croient que les ressources sont infinies (« Celui qui croit que la croissance peut être infinie dans un monde fini est soit un fou, soit un économiste. » Kenneth Boulding).
Oui, gérer les ressources matérielle, c'est du boulot. Celui des devs.
Je ne parle pas des langages interprétés qui sont ré-optimisés à chaque démarrage de la machine, de chaque machine qui les fait tourner (comparé à un programme compilé qui lui ne sera optimisé que lors de la livraison) ni des programmes compilés (plus ou moins mal codés) qui requièrent de tout recompiler au moindre changement dans un header. Ni, d'ailleurs, des systèmes de build qui sont incapables de remarquer que la seule chose qui a changé dans un fichier, c'est un commentaire ou un espace (encore que… dans certains langages, les espaces sont des éléments de syntaxe après tout…).
Bref, avant de taper sur les data-centres qui sont une conséquence (avoir un serveur chez soi, allumé H24, ça coûte cher, donc on mutualise dans des DC qui eux vont essayer de réduire les coûts d'entretien au maximum, notamment grâce à l'usage de machines virtuelles), je pense qu'il faudrait commencer par regarder la racine du problème, que l'on peut constater ainsi: il y a 20 ans, on pouvait utiliser des tableurs et des logiciels de traitement de texte sur des bécannes qui avaient moins de 200 megs de ram, un seul coeur de calcul cadencé à une vitesse de moins d'un giga hertz. De nos jours, pour le même usage il nous faut au moins 4Gio et 2 coeurs à 2GHz.
Certaines personnes, il paraît, utilisent ces logiciels à fond, et ont donc besoin de toutes les fonctionnalités offertes.
Je ne sais pas où elles se cachent par contre, moi j'en ai pas encore vu. Et vous?
Le rapport avec les data-centres? Il y a 5 ans, j'aurai dit: aucun. De nos jours… ben, ces suites bureautiques… elles tournent dans des navigateurs web. Donc le coeur est sur un serveur. Dans un DC.
En fait, je suis assez d'accord avec ce que tu dis, mais en même temps, je comprend pas pourquoi tu critiques ainsi l'article, puisqu'il semble allez dans le même sens. Je cite :
En d’autres termes, les économies réalisées en efficacité dans les data centers ont été rapidement contrebalancées par une exploitation sous-optimale des ressources matérielles à l’échelle du cloud.
Bref, il ne tape pas sur les datacentres, mais sur la façon dont l'industrie du logiciel utilise les ressources que ces même datacentres essayent de mettre a leur disposition plus ou moins efficacement (mais généralement, plutôt assez efficacement).
Si l'article tape sur quelque chose, c'est justement sur eux :
En conclusion, ces dernières années, l’industrie du logiciel a surtout privilégié le développement rapide de services numériques. Notamment, les contraintes économiques de développement — conjuguées avec l’abondance de ressources offertes par le cloud — et son apparente efficience énergétique — ont plutôt eu pour effet de négliger l’empreinte écologique des services développés au profit de la rapidité de mise en ligne et du retour sur investissement. Développer et opérer des services en ligne plus frugaux, respectant les contraintes de production industrielle, constitue donc un enjeu particulièrement critique pour les années à venir.
J'avoue si j'ai partagé le lien, c'est qu'en tant que pro dans cette branche d'activité, hébergement en datacentre, je suis assez d'accord. Les progrès en termes d'efficacité coté hébergement ont été massif, mais je suis loin de constater autant de recherche d'efficacité dans le dev. C'est même plutôt le contraire, où je trouve que l'on profite de cette abondance de ressources à faible coût. Mais j'ai juste le point de vue de la taule qui m'emploie. D'où l'intérêt de partager le truc. Et ça me rassure que tu sois plus ou moins d'accord, tout en disant plus ou moins que tu ne l'es pas :)
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
Si ça peut confirmer ton expérience, ce phénomène a été formalisé par les sciences économiques il y a 150 ans, sous le nom de paradoxe de Jeavons ou d'effet rebond, et plus spécifiquement, dans une version actualisée, sous le nom de postulat de Khazzoom-Brookes : en améliorant l'efficacité énergétique, on augmente la disponibilité des serveurs. Cela augmente l'offre, donc diminue le prix. La demande augmente donc en compensant partiellement ou complètement les économies réalisées.
Il me semble que c'est l'une des principales raisons pour lesquelles l'injonction aux économies d'énergie n'est pas suffisante pour répondre aux problèmes énergétiques et climatiques.
J'ai du mal comprendre alors, mais le ton me semblait plutôt négatif à l'encontre des DCs lors de la lecture.
Et ça me rassure que tu sois plus ou moins d'accord, tout en disant plus ou moins que tu ne l'es pas :)
Honnêtement, un informaticien de bureau d'étude (dev, admin…) qui ne vois pas le problème devrais vraiment retourner au lycée, pour prendre des cours de philosophie et de français, les deux matières qui à mon époque essayaient de développer le sens critique des élèves (qui n'en avaient souvent pas grand chose à faire, certes).
Un exemple "très récent" du problème du je-m-en-foutisme pour moi est quand je me suis aperçu qu'une installation minimale de Debian via l'installateur ne peux pas démarrer si la VM ne dispose pas d'au moins 250 Megs de RAM. Une fois bien démarrée, la machine n'en consommait même pas 60… la raison?
L'initrd ne rentre pas. Pourtant à l'install j'ai bien sélectionné l'option pour n'avoir que les pilotes nécessaires…
Avant ça, il me fallait moins de 150 megs, il me semble. D'ailleurs, si quelqu'un à des pointeurs qui expliquent comment en pratique il serait possible de faire un initrd minimal, pour un système "moderne" (debian stable, c'est pas non plus si moderne que ça je suppose) ça m'intéresse.
De la même manière, j'ai remarqué pendant un temps qu'utiliser de l'édition de liens dynamique avec glibc6 ajoute "magiquement" 750Kio de ressources dédiées à une application, qui autrement n'en consommerait potentiellement que 4Kio, ce qui peut être vérifié en utilisant un liage statique ou, tout bêtement, muslc (dynamique ou pas, ça ne change rien de ce côté avec cette lib).
Je vois avec plaisir que ça à changé, ps -orss,vsz,comm --sort=rss indique mes processus les plus légers à 60Kio, c'est nettement mieux (il y a un ordre de grandeur d'écart quand même, ça m'intrigue ça, ils ont corrigé un bug sévère chez gcc ou quoi?).
Si je prend juste les 22 processus que sont runit, runsvdir, runsv et svlogd, avant ça aurait donné environ 140Mio de conso "gratuite". Si je regarde la totalité de la ram actuellement utilisée sur ma machine, c'est à dire 291Mio, et que je regarde ce que ça donnerai hypothétiquement, ça ferait grosso merdo 30% ("( 291 + 140 ) / 291"). C'était beaucoup.
Maintenant, ça ne fait plus "que" 3%. Ca reste non négligeable pour des processus qui ne font virtuellement que dalle (j'avais regardé la ram que bouffe systemd aussi: il dépassait le mega de RSS si je me souviens bien, mais son avantage est que son poids n'est que très peu impacté par le nombre de daemons, contrairement à mon archi basée sur runit qui y est plus sensible, mais j'avais caculé qu'il me faudrait une 30aine de démons gérés par runsv+glibc en dynamique pour que ça soit rentable, si ma mémoire est bonne: ça date, donc c'est pas sûr).
Du coup, ce qui est agaçant, c'est que même pas ça ne concerne que le développement applicatif (qui a l'excuse de devoir modifier ses interfaces en permanence je suppose), le gâchis de ressources: même le développement système qui devrais justement se faire le plus léger possible, par exemple pour stocker plus de VMs par machine physique, gâche des quantités de ressources importantes (une fois mis à l'échelle en multipliant les instances, ce qui est, je crois, la méthode moderne?).
Alors évidemment il ne faut pas non plus sur-optimiser, et ces quelques kilo par processus semblent négligeables comparé aux ressources disponibles sur des machines modernes… mais je crois que c'est la mauvaise façon de voir si un système est performant.
Pour moi, ce qu'il faut regarder ce n'est pas la ressource disponible, mais bien les ressources utilisées par le processus et, si possible, les bibliothèques qu'il charge: ça permets de se donner idée du bloat. Dans le cas de glibc6, selon ce que je vois, la, sur mon portable (avec lequel je n'écrit pas ce message) c'est que des processus qui ne devraient consommer qu'une seule page (4Kio) de ram, en consomment 15 fois plus. La conclusion évidente est que glibc, même si ça c'est méchamment amélioré (vraiment une super surprise ça) reste bien bloatée.
J'imagine qu'il faut aussi voir l'évolution de la conso en ressources d'un logiciel lors de son cycle de vie.
Evidemment, tout ça, ça prend du temps, et le client s'en fout "un peu"… si ce n'est pas le client qui s'en fout, alors ça sera le commercial ou le patron. Ou le développeur (parce que bon, c'est facile de rejeter la faute sur les autres échelons, mais ce n'est pas toujours taper sur les bons).
Oui, gérer les ressources matérielle, c'est du boulot. Celui des devs.
Ah non, c'est fini les années '70 et '80 ; on te répondra même que la RAM ne coûte plus chère depuis des lustres. Et puis tu veux pas renvoyer sur les bancs de l'école toute l'armée qui déverse du code sans estimer la complexité des trucs copiés depuis le chat gépéto et n'ont jamais entendu parler d'optimisation et tout ça…
(plus ou moins mal codés) qui requièrent de tout recompiler au moindre changement dans un header.
Je soupçonne que ce soit pour laisser le temps aux adeptes de rouille de lever le pied qui code pour aller boire un café
(encore que… dans certains langages, les espaces sont des éléments de syntaxe après tout…)
Je n'ai pas vu les adeptes de reptile (non pas le langage Logo) moinsser (:
De nos jours, pour le même usage il nous faut au moins 4Gio et 2 coeurs à 2GHz.
Certaines personnes, il paraît, utilisent ces logiciels à fond, et ont donc besoin de toutes les fonctionnalités offertes.
Je ne sais pas où elles se cachent par contre, moi j'en ai pas encore vu. Et vous?
Je ne sais pas non plus ; je crois finalement que c'est le saint graal ou madame Colombo…
Le rapport avec les data-centres? Il y a 5 ans, j'aurai dit: aucun. De nos jours… ben, ces suites bureautiques… elles tournent dans des navigateurs web.
Même là, c'est d'une déception sans nom. Avec un 365 je ne sais quoi (bogues ?) il me faut un navigateur plus gourmand que l'appli lourd il y a cinq ans : j'avais naïvement cru pouvoir me servir de Dillo (ou de Links soyons fou) mais nada.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
on te répondra même que la RAM ne coûte plus chère depuis des lustres
A quoi il est facile de répondre que la SRAM coûte toujours une blinde, elle, et qu'on ne peux pas la changer ou l'augmenter sans changer le CPU ;)
Je soupçonne que ce soit pour laisser le temps aux adeptes de rouille de lever le pied qui code pour aller boire un café
Il y a des headers dans rust? Vraie question, je pensais que ce langage utilisais des modules. Ici je taclais C et C++ pour le coup :D
Et sinon, ça ne sert pas à aller prendre un café.
Je comprend pas, la?
Justement cet article indique:
Most functions and methods need to be declared twice in C++ (one in the header, and one in the implementation file). This isn't needed in Rust, reducing the line count.
Du coup, le problème des headers auquel je faisais allusion ne peux exister en rouille?
Je voulais pointer qu'effectivement il n'y a pas de problèmes de headers mais d'autres et que c'est le même xkcd etc. Puis comme dit dans les commentaires que les devs compilent souvent et c'est pas jojo.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# mouai
Posté par freem . Évalué à 8.
Bon en gros, l'article dit: la virtualisation encourage les gens à avoir un bout d'internet à eux, et ça consomme.
Bon. En soit, ça semble logique. Sauf que, l'alternative, en supposant que les "bout d'internet à soit" ont réellement un intérêt, c'est que chacun ait sa machine perso. On ne me fera pas croire que ça serait plus écolo…
Un autre passage parle de la sur-utilisation de la RAM. Ah, ça, ça me parle, p'tet que ça va aborder un truc pertinent?
Ben non. Les solutions abordées, c'est de dédupliquer… Une vraie solution, mais qui casserait énormément de logiciels dont la totalité des navigateurs internets ainsi qu'ASAN et certaines techno de sandboxing (enfin, sur un serveur osef, mais bon, y'a pas que les serveurs qui sont impactés par le problème) ça serait de désactiver l'overcommit, qui est une fonctionnalité qui permets à un logiciel d'allouer plus de ressources qu'il n'en existe réellement.
En quoi ça serait une solution? Tout simplement parce que ça rappellerait aux développeurs que non, ils ne doivent pas faire comme les économistes qui croient que les ressources sont infinies (« Celui qui croit que la croissance peut être infinie dans un monde fini est soit un fou, soit un économiste. » Kenneth Boulding).
Oui, gérer les ressources matérielle, c'est du boulot. Celui des devs.
Je ne parle pas des langages interprétés qui sont ré-optimisés à chaque démarrage de la machine, de chaque machine qui les fait tourner (comparé à un programme compilé qui lui ne sera optimisé que lors de la livraison) ni des programmes compilés (plus ou moins mal codés) qui requièrent de tout recompiler au moindre changement dans un header. Ni, d'ailleurs, des systèmes de build qui sont incapables de remarquer que la seule chose qui a changé dans un fichier, c'est un commentaire ou un espace (encore que… dans certains langages, les espaces sont des éléments de syntaxe après tout…).
Bref, avant de taper sur les data-centres qui sont une conséquence (avoir un serveur chez soi, allumé H24, ça coûte cher, donc on mutualise dans des DC qui eux vont essayer de réduire les coûts d'entretien au maximum, notamment grâce à l'usage de machines virtuelles), je pense qu'il faudrait commencer par regarder la racine du problème, que l'on peut constater ainsi: il y a 20 ans, on pouvait utiliser des tableurs et des logiciels de traitement de texte sur des bécannes qui avaient moins de 200 megs de ram, un seul coeur de calcul cadencé à une vitesse de moins d'un giga hertz. De nos jours, pour le même usage il nous faut au moins 4Gio et 2 coeurs à 2GHz.
Certaines personnes, il paraît, utilisent ces logiciels à fond, et ont donc besoin de toutes les fonctionnalités offertes.
Je ne sais pas où elles se cachent par contre, moi j'en ai pas encore vu. Et vous?
Le rapport avec les data-centres? Il y a 5 ans, j'aurai dit: aucun. De nos jours… ben, ces suites bureautiques… elles tournent dans des navigateurs web. Donc le coeur est sur un serveur. Dans un DC.
[^] # Re: mouai
Posté par Big Pete . Évalué à 5.
En fait, je suis assez d'accord avec ce que tu dis, mais en même temps, je comprend pas pourquoi tu critiques ainsi l'article, puisqu'il semble allez dans le même sens. Je cite :
Bref, il ne tape pas sur les datacentres, mais sur la façon dont l'industrie du logiciel utilise les ressources que ces même datacentres essayent de mettre a leur disposition plus ou moins efficacement (mais généralement, plutôt assez efficacement).
Si l'article tape sur quelque chose, c'est justement sur eux :
J'avoue si j'ai partagé le lien, c'est qu'en tant que pro dans cette branche d'activité, hébergement en datacentre, je suis assez d'accord. Les progrès en termes d'efficacité coté hébergement ont été massif, mais je suis loin de constater autant de recherche d'efficacité dans le dev. C'est même plutôt le contraire, où je trouve que l'on profite de cette abondance de ressources à faible coût. Mais j'ai juste le point de vue de la taule qui m'emploie. D'où l'intérêt de partager le truc. Et ça me rassure que tu sois plus ou moins d'accord, tout en disant plus ou moins que tu ne l'es pas :)
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: mouai
Posté par sobriquet . Évalué à 3.
Si ça peut confirmer ton expérience, ce phénomène a été formalisé par les sciences économiques il y a 150 ans, sous le nom de paradoxe de Jeavons ou d'effet rebond, et plus spécifiquement, dans une version actualisée, sous le nom de postulat de Khazzoom-Brookes : en améliorant l'efficacité énergétique, on augmente la disponibilité des serveurs. Cela augmente l'offre, donc diminue le prix. La demande augmente donc en compensant partiellement ou complètement les économies réalisées.
Il me semble que c'est l'une des principales raisons pour lesquelles l'injonction aux économies d'énergie n'est pas suffisante pour répondre aux problèmes énergétiques et climatiques.
[^] # Re: mouai
Posté par freem . Évalué à 3.
J'ai du mal comprendre alors, mais le ton me semblait plutôt négatif à l'encontre des DCs lors de la lecture.
Honnêtement, un informaticien de bureau d'étude (dev, admin…) qui ne vois pas le problème devrais vraiment retourner au lycée, pour prendre des cours de philosophie et de français, les deux matières qui à mon époque essayaient de développer le sens critique des élèves (qui n'en avaient souvent pas grand chose à faire, certes).
Un exemple "très récent" du problème du je-m-en-foutisme pour moi est quand je me suis aperçu qu'une installation minimale de Debian via l'installateur ne peux pas démarrer si la VM ne dispose pas d'au moins 250 Megs de RAM. Une fois bien démarrée, la machine n'en consommait même pas 60… la raison?
L'initrd ne rentre pas. Pourtant à l'install j'ai bien sélectionné l'option pour n'avoir que les pilotes nécessaires…
Avant ça, il me fallait moins de 150 megs, il me semble. D'ailleurs, si quelqu'un à des pointeurs qui expliquent comment en pratique il serait possible de faire un initrd minimal, pour un système "moderne" (debian stable, c'est pas non plus si moderne que ça je suppose) ça m'intéresse.
De la même manière, j'ai remarqué pendant un temps qu'utiliser de l'édition de liens dynamique avec glibc6 ajoute "magiquement" 750Kio de ressources dédiées à une application, qui autrement n'en consommerait potentiellement que 4Kio, ce qui peut être vérifié en utilisant un liage statique ou, tout bêtement, muslc (dynamique ou pas, ça ne change rien de ce côté avec cette lib).
Je vois avec plaisir que ça à changé,
ps -orss,vsz,comm --sort=rssindique mes processus les plus légers à 60Kio, c'est nettement mieux (il y a un ordre de grandeur d'écart quand même, ça m'intrigue ça, ils ont corrigé un bug sévère chez gcc ou quoi?).Si je prend juste les 22 processus que sont runit, runsvdir, runsv et svlogd, avant ça aurait donné environ 140Mio de conso "gratuite". Si je regarde la totalité de la ram actuellement utilisée sur ma machine, c'est à dire 291Mio, et que je regarde ce que ça donnerai hypothétiquement, ça ferait grosso merdo 30% ("( 291 + 140 ) / 291"). C'était beaucoup.
Maintenant, ça ne fait plus "que" 3%. Ca reste non négligeable pour des processus qui ne font virtuellement que dalle (j'avais regardé la ram que bouffe systemd aussi: il dépassait le mega de RSS si je me souviens bien, mais son avantage est que son poids n'est que très peu impacté par le nombre de daemons, contrairement à mon archi basée sur runit qui y est plus sensible, mais j'avais caculé qu'il me faudrait une 30aine de démons gérés par runsv+glibc en dynamique pour que ça soit rentable, si ma mémoire est bonne: ça date, donc c'est pas sûr).
Du coup, ce qui est agaçant, c'est que même pas ça ne concerne que le développement applicatif (qui a l'excuse de devoir modifier ses interfaces en permanence je suppose), le gâchis de ressources: même le développement système qui devrais justement se faire le plus léger possible, par exemple pour stocker plus de VMs par machine physique, gâche des quantités de ressources importantes (une fois mis à l'échelle en multipliant les instances, ce qui est, je crois, la méthode moderne?).
Alors évidemment il ne faut pas non plus sur-optimiser, et ces quelques kilo par processus semblent négligeables comparé aux ressources disponibles sur des machines modernes… mais je crois que c'est la mauvaise façon de voir si un système est performant.
Pour moi, ce qu'il faut regarder ce n'est pas la ressource disponible, mais bien les ressources utilisées par le processus et, si possible, les bibliothèques qu'il charge: ça permets de se donner idée du bloat. Dans le cas de glibc6, selon ce que je vois, la, sur mon portable (avec lequel je n'écrit pas ce message) c'est que des processus qui ne devraient consommer qu'une seule page (4Kio) de ram, en consomment 15 fois plus. La conclusion évidente est que glibc, même si ça c'est méchamment amélioré (vraiment une super surprise ça) reste bien bloatée.
J'imagine qu'il faut aussi voir l'évolution de la conso en ressources d'un logiciel lors de son cycle de vie.
Evidemment, tout ça, ça prend du temps, et le client s'en fout "un peu"… si ce n'est pas le client qui s'en fout, alors ça sera le commercial ou le patron. Ou le développeur (parce que bon, c'est facile de rejeter la faute sur les autres échelons, mais ce n'est pas toujours taper sur les bons).
[^] # Re: mouai
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ah non, c'est fini les années '70 et '80 ; on te répondra même que la RAM ne coûte plus chère depuis des lustres. Et puis tu veux pas renvoyer sur les bancs de l'école toute l'armée qui déverse du code sans estimer la complexité des trucs copiés depuis le chat gépéto et n'ont jamais entendu parler d'optimisation et tout ça…
Je soupçonne que ce soit pour laisser le temps aux adeptes de rouille de lever le pied qui code pour aller boire un café
Je n'ai pas vu les adeptes de reptile (non pas le langage Logo) moinsser (:
Je ne sais pas non plus ; je crois finalement que c'est le saint graal ou madame Colombo…
Même là, c'est d'une déception sans nom. Avec un 365 je ne sais quoi (bogues ?) il me faut un navigateur plus gourmand que l'appli lourd il y a cinq ans : j'avais naïvement cru pouvoir me servir de Dillo (ou de Links soyons fou) mais nada.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mouai
Posté par freem . Évalué à 2.
A quoi il est facile de répondre que la SRAM coûte toujours une blinde, elle, et qu'on ne peux pas la changer ou l'augmenter sans changer le CPU ;)
Il y a des headers dans rust? Vraie question, je pensais que ce langage utilisais des modules. Ici je taclais C et C++ pour le coup :D
Et sinon, ça ne sert pas à aller prendre un café.
[^] # Re: mouai
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ah oui on aime beaucoup nef en info. On en a causé récemment ici…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mouai
Posté par freem . Évalué à 2.
Je comprend pas, la?
Justement cet article indique:
Du coup, le problème des headers auquel je faisais allusion ne peux exister en rouille?
[^] # Re: mouai
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je voulais pointer qu'effectivement il n'y a pas de problèmes de headers mais d'autres et que c'est le même xkcd etc. Puis comme dit dans les commentaires que les devs compilent souvent et c'est pas jojo.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.