Ce que l’article de developpez.com se garde bien de préciser, c’est que le papier d’origine a été présenté les 23 et 24 octobre 2017. Il faut donc le prendre comme ce qu’il est : une information qui date de 5 ans – ce qui peut changer pas mal de choses en informatique.
Un truc plus critiquable, c'est le fait que ça ne prends que des programmes indépendants, de ce que j'ai vite lu. Donc j'ai le sentiment que ce qui a été mesuré, c'est la vitesse de démarrage de l’interpréteur python (en C) par rapport à un programme en C.
Ensuite, je ne pense pas que ça change l'ordre fondamental des résultats (au moins dans ses grandes lignes, peut etre que ruby ou python vont pas être dans le même ordre), mais il y a des chances que ça change les ordres de grandeur.
Donc j'ai le sentiment que ce qui a été mesuré, c'est la vitesse de démarrage de l’interpréteur python (en C) par rapport à un programme en C.
Pas sûr. Il est dit :
A 10 reprises, chaque solution a été exécutée et les performances associées mesurées « afin de réduire l’impact des démarrages à froid et des effets du cache, d’analyser la cohérence des mesures et d’éviter les valeurs aberrantes ». Et ils rapportent que « les résultats mesurés sont assez cohérents »
Et surtout vu les algorithmes utilisés. C'est sûr que tous les ordinateurs individuels font tourner des regex-redux en permanence.
C'est une excellente chose que d'avoir cette étude, mais il faut la garder dans son contexte : du calcul CPU intense.
En tant que développeur et possesseur d'une machine faible énergie pour auto-hébergement, j'ai étudié le comportement de pas mal de programme qui font des réveils inutiles. Et souvent, les développeurs en ont qu'une petite considération.
Énormément de serveur font ce genre de truc, parce que juste c'est leur modèle : 1 réveil par seconde. Ça paraît peu, mais pour ma machine qui ne fait rien, c'est énorme. PHP-FPM fait ça par exemple. dnsdist aussi, etc. Ça consomme du courant, littéralement pour rien.
Oui, j'ai commencé à me pencher sur l'activation à la demande (via systemd), mais ça ne sert que si tu as aussi un mécanisme qui arrête le serveur quand rien ne se passe.
Ma forge gitea en local, j'ai pas spécialement besoin de la voir tourner tout le temps, donc qu'elle démarre quand je me connecte et s'arrete plus tard, ça me va aussi.
Pareil pour httpd ou nextcloud.
Et il n'y a grosso modo presque rien qui ne supporte un mode idle. Les seuls logiciels qui me viennent à l'esprit pour ça, c'est iodine et cups (et parce que j'ai codé le patch d'un des 2 y a 9 ans).
Y a aussi systemd-socket-proxyd, qui permet de faire ça. Quand le service principal possède StopWhenUnneeded, ça l'arrête. Inconvénient : ça demande un deuxième socket, juste pour faire transiter les infos et que systemd-socket-proxyd puisse voir s'il y a de l'activité.
Du coup, je l'ai mis que sur les services qui n'ont pas d'activation par socket.
En tant que non-codeur, il me semble évident que les développeurs doivent abandonner de toute urgence tous ces langages polluants et tout refaire en C et ne plus garder que le C à l'avenir.
En plus, ça évitera toutes les futures guerres de clocher en ligne, sur le meilleur langage et "quel langage apprendre en 20xx" ce qui réduira encore plus l'empreinte carbone du numérique mondial!
# developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 06 février 2022 à 23:33.
Ce que l’article de developpez.com se garde bien de préciser, c’est que le papier d’origine a été présenté les 23 et 24 octobre 2017. Il faut donc le prendre comme ce qu’il est : une information qui date de 5 ans – ce qui peut changer pas mal de choses en informatique.
La connaissance libre : https://zestedesavoir.com
[^] # Re: developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par Papey . Évalué à 4.
L'article lui-même date de 2019
[^] # Re: developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par Misc (site web personnel) . Évalué à 3.
Un truc plus critiquable, c'est le fait que ça ne prends que des programmes indépendants, de ce que j'ai vite lu. Donc j'ai le sentiment que ce qui a été mesuré, c'est la vitesse de démarrage de l’interpréteur python (en C) par rapport à un programme en C.
Ensuite, je ne pense pas que ça change l'ordre fondamental des résultats (au moins dans ses grandes lignes, peut etre que ruby ou python vont pas être dans le même ordre), mais il y a des chances que ça change les ordres de grandeur.
[^] # Re: developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par bbo . Évalué à 3.
Pas sûr. Il est dit :
[^] # Re: developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par Glandos . Évalué à 8.
Et surtout vu les algorithmes utilisés. C'est sûr que tous les ordinateurs individuels font tourner des
regex-reduxen permanence.C'est une excellente chose que d'avoir cette étude, mais il faut la garder dans son contexte : du calcul CPU intense.
En tant que développeur et possesseur d'une machine faible énergie pour auto-hébergement, j'ai étudié le comportement de pas mal de programme qui font des réveils inutiles. Et souvent, les développeurs en ont qu'une petite considération.
Par exemple, j'ai beaucoup bossé sur gunicorn : https://github.com/benoitc/gunicorn/pull/502 La démarche a été couronnée de succès (avec l'intégration de https://github.com/benoitc/gunicorn/pull/687) mais c'est un long combat.
Énormément de serveur font ce genre de truc, parce que juste c'est leur modèle : 1 réveil par seconde. Ça paraît peu, mais pour ma machine qui ne fait rien, c'est énorme. PHP-FPM fait ça par exemple. dnsdist aussi, etc. Ça consomme du courant, littéralement pour rien.
[^] # Re: developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par Misc (site web personnel) . Évalué à 5.
Oui, j'ai commencé à me pencher sur l'activation à la demande (via systemd), mais ça ne sert que si tu as aussi un mécanisme qui arrête le serveur quand rien ne se passe.
Ma forge gitea en local, j'ai pas spécialement besoin de la voir tourner tout le temps, donc qu'elle démarre quand je me connecte et s'arrete plus tard, ça me va aussi.
Pareil pour httpd ou nextcloud.
Et il n'y a grosso modo presque rien qui ne supporte un mode idle. Les seuls logiciels qui me viennent à l'esprit pour ça, c'est iodine et cups (et parce que j'ai codé le patch d'un des 2 y a 9 ans).
[^] # Re: developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par Glandos . Évalué à 4.
Y a aussi systemd-socket-proxyd, qui permet de faire ça. Quand le service principal possède
StopWhenUnneeded, ça l'arrête. Inconvénient : ça demande un deuxième socket, juste pour faire transiter les infos et que systemd-socket-proxyd puisse voir s'il y a de l'activité.Du coup, je l'ai mis que sur les services qui n'ont pas d'activation par socket.
[^] # Re: developpez.com à la pointe de l’actualité : c’est une étude de 2017
Posté par Glandos . Évalué à 4.
Allez, ça m'a motivé : https://news-web.php.net/php.internals/117005
# conclusion d'expert
Posté par Maclag . Évalué à 10.
En tant que non-codeur, il me semble évident que les développeurs doivent abandonner de toute urgence tous ces langages polluants et tout refaire en C et ne plus garder que le C à l'avenir.
En plus, ça évitera toutes les futures guerres de clocher en ligne, sur le meilleur langage et "quel langage apprendre en 20xx" ce qui réduira encore plus l'empreinte carbone du numérique mondial!
Ne me cherchez pas je suis déjà dehors.
----> [ ]
[^] # Re: conclusion d'expert
Posté par wilk . Évalué à 8.
C'est déjà le cas, les langages polluants sont eux même des programmes écrits en C.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.