… pour répondre à la question. Je vais me faire moinsser à bloc, je sais, mais bon… il suffit de configurer le noyau linux pour refuser les demandes d'allocations aberrantes qui ne seront pas utilisées, pour s'apercevoir que les outils majeurs que l'on utilise de nos jours sont blindés de problèmes de mémoire. Leak ou hoard, je sais pas exactement, mais ça reviens ça au même. Et ça ne se limite pas à la "RAM CPU", mais ça s'applique à la "RAM GPU" aussi.
Rust est censé améliorer les choses dans firefox, et c'est vrai qu'il bouffe un peu moins que les trucs basés sur chromium, mais bon, quitte a utiliser un truc gourmand je préfère qu'il me file au moins une UI décente (rien que les raccourcis souris par défaut…) hors j'en suis arrivé à avoir un script dans mon ~/.bin/ qui s'appelle: fuck.sh. Son job? Tuer vivaldi, et chromium-crashtruc, avec un bon gros killall -9!
Pourquoi?
Parce que sinon ces bouses de "navigateurs" crashent tellement souvent que soit je garde les cookies (et donc le tracking) soit je le bute sauvagement pour espérer ne pas avoir a me relog sur tous les onglets en cours.
Evidemment, quand on a github ouvert, la ram part vite, et comme il "faut" une double auth "pour la sécurité" (mon cul oui) je dois aussi aller chercher gmail (oui, je sais, je devrais migrer, ça fait des années que je le dis…) qui refuse de se laisser connecter par des MUA normaux!
Bref, la réponse?
Quand les dev, dont j'ai fait partie, sauront mettre la pression à leurs patrons pour refuser de faire de la merde. Ca inclue d'utiliser des langages réputés pour leur performance malgré leur difficulté d'apprentissage: C, C++, Rust, pascal, … au lieu de python, javascript, html5/css4 (je suis p'tet outdated, on est p'tet à html10/css6 maintenant) qui bouffent des ressources de dingue.
On ne fait pas grand chose de plus avec un PC moderne qu'avec un PC d'il y a 10 ans après tout. Et, oui, j'ai vérifié. En terme d'outillage, et pas pas de loisir, sauf usages ultra spécifiques qui vont surtout se concentrer sur le GPU (et donc rust, C, C++ & co n'y changerons rien, c'est plutôt openGL, openCL, vulkan, ici) vraiment avec des outils qui font moins de trucs spécialisés, on se retrouve vraiment avec des trucs plus simples à utiliser et qui sont plus rapides.
Genre, utiliser solvespace à la place de freecad pour concevoir un assemblage simple de, disons, 5, 6 pièces.
On peut aussi parler, ben oui, des systèmes d'init. Pourquoi gâcher 30 megs de rss dans systemd (de mémoire, ils ont p'tet opti depuis) quand runit (par exemple) lié en static ne consomme que 4 kilos?
Ce n'est rien qu'un peu d'octets, mais ils ont refroidit la pièce dans laquelle j'héberge mes machines à la manière d'un frigo, comme dirait l'autre.
Il n’est pas si difficile de se mettre à Pascal, encore plus si tu compares à Rust ou C++
Bon, sinon « p'tet outdated » a oublié Ada entre autre. Et pour JS les devs ne fonnt même pas de pur ECMA mais des framework qui rajoutent des tonnes de couche et continuent de supporter IE…
Ayant dit cela, je m'installe avec du popcorn pour voir systemdevangists te tomber dessus, tellement ce n'est pas assez gros…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par ml .
Évalué à 4.
Dernière modification le 26 mai 2023 à 08:47.
Ca inclue d'utiliser des langages réputés pour leur performance malgré leur difficulté d'apprentissage: C, C++, Rust, pascal, … au lieu de python, javascript, html5/css4 (je suis p'tet outdated, on est p'tet à html10/css6 maintenant) qui bouffent des ressources de dingue.
Prend un dev de base. Fait lui pondre le même code en C et en Python. En C il va devoir réinventer la roue (très mal) et te sortir un algo tout pété en O( n999999 ), en Python il va juste utiliser la lib standard, optimisée et qui travaille en C au final.
On peut aussi parler, ben oui, des systèmes d'init. Pourquoi gâcher 30 megs de rss dans systemd (de mémoire, ils ont p'tet opti depuis) quand runit (par exemple) lié en static ne consomme que 4 kilos?
Faut savoir configurer systemd, tu peux désactiver pas mal de choses si t’utilises pas.
runit n’est PAS un système d’init mais un hyperviseur de service qui propose éventuellement un init. Je boycotte systemd parce que je boycotte tout système d’init qui veut faire autre chose que de l’init. Un hyperviseur de service c’est déjà bloated pour un usage perso (ça sert à assurer la disponibilité des services parce que le noyau Linux est tellement foireux qu’il peut te kill le ssh de ton serveur chéri à 783km de là…). J’utilise l’init historique SysV qui est amplement suffisant (RSS : 1,6K, ton truc est clairement bloated ×2,5)
Sur un poste fixe le hardware change pas, j’imagine que tu as tout ton /dev en static, plutôt que ce bloat de udevd qui tourne en permanence et bouffe du CPU pour rien à chaque démarrage.
Et encore tu semble ne pas connaître les joie du devops où pour compiler un 'Hello world!' il faut faire un commit/push sur un serveur, virtualisé of course, de dépôt qui va lancer un outil d’automatisation de chaîne d’intégration continue qui va demander à un gestionnaire de conteneurs de démarrer des applications isolées dans un conteneur sur le cloud, donc à travers le réseau sur une machine elle-même virtualisée, pour ensuite récupérer le résultat de la compilation qui sera pris en charge pour le déploiement sur la machine de test, elle même virtualisée et remontée à chaque fois.
Mais, magie de l’informatique moderne! tout est fait en toute transparence pour le dév ! Il a même le temps d’aller se faire un petitgros kawa en attendant.
Quand les dev, dont j'ai fait partie, sauront mettre la pression à leurs patrons pour refuser de faire de la merde.
Si tu pars à te tromper d'interlocuteur pour que ça bouge, ça ne risque pas de bouger, juste de conforter dans ton "j'y pense, moi".
Car le sujet n'est pas ce bout (le dev), le sujet est tout l'autre côté (le client), toi dev qui mettra la pression réussira juste à faire perdre un projet car trop cher.
La pression doit venir du client, qui l'aura car ses clients (les utilisateurs) feront la pression.
Et la, il faut que tu me trouves des arguments utiles, parce que en tant que dev et patron de moi-même, je n'ai pas vraiment d'arguments quand mon client priorise le coût (et ce dont tu parles coûte cher) sur la consommation mémoire et CPU (et je les comprend, ça ne leur rapporte pas) alors que j'aimerai bien travailler sur le sujet dans mes programmes.
En pratique, c'est surtout faire pression sur le peuple utilisateur (l'autre bout de "dev") pour que l'impact doive être payé, mais bon courage, pour le moment le peuple aime bien acheter des SUV pour accéder à une grande maison à la campagne donc la RAM et CPU c'est peu en pratique, pas vraiment la prio si tu penses à optimiser.
Genre, utiliser solvespace à la place de freecad pour concevoir un assemblage simple de, disons, 5, 6 pièces.
Pas compris l’intérêt de faire apprendre 1 autre produit juste pour le fun, pour un même taf chaque outil ne devrait pas impacter tant que ça sur la conso, la tu pars dans les détails…
On peut aussi parler, ben oui, des systèmes d'init. Pourquoi gâcher 30 megs de rss dans systemd (de mémoire, ils ont p'tet opti depuis) quand runit (par exemple) lié en static ne consomme que 4 kilos?
Tiens, ça faisait longtemps les attaques contre systemd…
Alors, en pratique, utiliser un truc de 30 Mo est parfois utile, si par exemple comme ça en pratique ça remplace 10000 services de 4K (en pratique, j’émets un doute sur tes chiffres), et tu es libre de travailler sur son optimisation (oui mais tu veux pas travailler gratos dessus à tous les coups… retour à la case départ, donnes des arguments pour que d'autres paye, ou fait si tu penses que c'est utile plus que pour râler)
# Pas besoin de lire...
Posté par freem . Évalué à 5.
… pour répondre à la question. Je vais me faire moinsser à bloc, je sais, mais bon… il suffit de configurer le noyau linux pour refuser les demandes d'allocations aberrantes qui ne seront pas utilisées, pour s'apercevoir que les outils majeurs que l'on utilise de nos jours sont blindés de problèmes de mémoire. Leak ou hoard, je sais pas exactement, mais ça reviens ça au même. Et ça ne se limite pas à la "RAM CPU", mais ça s'applique à la "RAM GPU" aussi.
Rust est censé améliorer les choses dans firefox, et c'est vrai qu'il bouffe un peu moins que les trucs basés sur chromium, mais bon, quitte a utiliser un truc gourmand je préfère qu'il me file au moins une UI décente (rien que les raccourcis souris par défaut…) hors j'en suis arrivé à avoir un script dans mon ~/.bin/ qui s'appelle:
fuck.sh. Son job? Tuer vivaldi, et chromium-crashtruc, avec un bon gros killall -9!Pourquoi?
Parce que sinon ces bouses de "navigateurs" crashent tellement souvent que soit je garde les cookies (et donc le tracking) soit je le bute sauvagement pour espérer ne pas avoir a me relog sur tous les onglets en cours.
Evidemment, quand on a github ouvert, la ram part vite, et comme il "faut" une double auth "pour la sécurité" (mon cul oui) je dois aussi aller chercher gmail (oui, je sais, je devrais migrer, ça fait des années que je le dis…) qui refuse de se laisser connecter par des MUA normaux!
Bref, la réponse?
Quand les dev, dont j'ai fait partie, sauront mettre la pression à leurs patrons pour refuser de faire de la merde. Ca inclue d'utiliser des langages réputés pour leur performance malgré leur difficulté d'apprentissage: C, C++, Rust, pascal, … au lieu de python, javascript, html5/css4 (je suis p'tet outdated, on est p'tet à html10/css6 maintenant) qui bouffent des ressources de dingue.
On ne fait pas grand chose de plus avec un PC moderne qu'avec un PC d'il y a 10 ans après tout. Et, oui, j'ai vérifié. En terme d'outillage, et pas pas de loisir, sauf usages ultra spécifiques qui vont surtout se concentrer sur le GPU (et donc rust, C, C++ & co n'y changerons rien, c'est plutôt openGL, openCL, vulkan, ici) vraiment avec des outils qui font moins de trucs spécialisés, on se retrouve vraiment avec des trucs plus simples à utiliser et qui sont plus rapides.
Genre, utiliser solvespace à la place de freecad pour concevoir un assemblage simple de, disons, 5, 6 pièces.
On peut aussi parler, ben oui, des systèmes d'init. Pourquoi gâcher 30 megs de rss dans systemd (de mémoire, ils ont p'tet opti depuis) quand runit (par exemple) lié en static ne consomme que 4 kilos?
Ce n'est rien qu'un peu d'octets, mais ils ont refroidit la pièce dans laquelle j'héberge mes machines à la manière d'un frigo, comme dirait l'autre.
[^] # Re: Pas besoin de lire...
Posté par Xanatos . Évalué à 2.
2,3 ficelles un peu grosses, Vendredi c'est demain !
[^] # Re: Pas besoin de lire...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Il n’est pas si difficile de se mettre à Pascal, encore plus si tu compares à Rust ou C++
Bon, sinon « p'tet outdated » a oublié Ada entre autre. Et pour JS les devs ne fonnt même pas de pur ECMA mais des framework qui rajoutent des tonnes de couche et continuent de supporter IE…
Ayant dit cela, je m'installe avec du popcorn pour voir systemdevangists te tomber dessus, tellement ce n'est pas assez gros…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas besoin de lire...
Posté par ml . Évalué à 4. Dernière modification le 26 mai 2023 à 08:47.
Prend un dev de base. Fait lui pondre le même code en C et en Python. En C il va devoir réinventer la roue (très mal) et te sortir un algo tout pété en O( n999999 ), en Python il va juste utiliser la lib standard, optimisée et qui travaille en C au final.
Et encore tu semble ne pas connaître les joie du devops où pour compiler un 'Hello world!' il faut faire un commit/push sur un serveur, virtualisé of course, de dépôt qui va lancer un outil d’automatisation de chaîne d’intégration continue qui va demander à un gestionnaire de conteneurs de démarrer des applications isolées dans un conteneur sur le cloud, donc à travers le réseau sur une machine elle-même virtualisée, pour ensuite récupérer le résultat de la compilation qui sera pris en charge pour le déploiement sur la machine de test, elle même virtualisée et remontée à chaque fois.
Mais, magie de l’informatique moderne! tout est fait en toute transparence pour le dév ! Il a même le temps d’aller se faire un
petitgros kawa en attendant.[^] # Re: Pas besoin de lire...
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 26 mai 2023 à 10:02.
Si tu pars à te tromper d'interlocuteur pour que ça bouge, ça ne risque pas de bouger, juste de conforter dans ton "j'y pense, moi".
Car le sujet n'est pas ce bout (le dev), le sujet est tout l'autre côté (le client), toi dev qui mettra la pression réussira juste à faire perdre un projet car trop cher.
La pression doit venir du client, qui l'aura car ses clients (les utilisateurs) feront la pression.
Et la, il faut que tu me trouves des arguments utiles, parce que en tant que dev et patron de moi-même, je n'ai pas vraiment d'arguments quand mon client priorise le coût (et ce dont tu parles coûte cher) sur la consommation mémoire et CPU (et je les comprend, ça ne leur rapporte pas) alors que j'aimerai bien travailler sur le sujet dans mes programmes.
En pratique, c'est surtout faire pression sur le peuple utilisateur (l'autre bout de "dev") pour que l'impact doive être payé, mais bon courage, pour le moment le peuple aime bien acheter des SUV pour accéder à une grande maison à la campagne donc la RAM et CPU c'est peu en pratique, pas vraiment la prio si tu penses à optimiser.
Pas compris l’intérêt de faire apprendre 1 autre produit juste pour le fun, pour un même taf chaque outil ne devrait pas impacter tant que ça sur la conso, la tu pars dans les détails…
Tiens, ça faisait longtemps les attaques contre systemd…
Alors, en pratique, utiliser un truc de 30 Mo est parfois utile, si par exemple comme ça en pratique ça remplace 10000 services de 4K (en pratique, j’émets un doute sur tes chiffres), et tu es libre de travailler sur son optimisation (oui mais tu veux pas travailler gratos dessus à tous les coups… retour à la case départ, donnes des arguments pour que d'autres paye, ou fait si tu penses que c'est utile plus que pour râler)
# efficience matérielle
Posté par bunam . Évalué à 3.
Lorsque Apple a sorti ces M1 et maintenant M2 ils se sont positionnés sur l'efficience matérielle. Ça ne fait pas réfléchir ?
https://www.apple.com/fr/newsroom/2022/06/apple-unveils-m2-with-breakthrough-performance-and-capabilities/
On sait qu'il y a une course sans limite de la part d'Intel et d'Nvidia pour la puissance sans vraiment prendre en compte la consommation.
Je me dis même qu'il y a un coût humanitaire Intel. Qui va payer ??
Pour moi il y a un axe de réflexion majeur sur ce point-là.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.