barmic 🦦 a écrit 5782 commentaires

Si tu indiquait un élément concret, ça pourrait peut être amener une discussion.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Compter sur un hypothétique pare-feu qui peut aussi être désactivé par inadvertance ou mal configuré est AMHA une erreur.

Compter sur le fait que tous les services de toutes les machines qui passent sur ton réseau soient bien configurer me semble aussi une erreur, d'autant que tu n'administre pas forcément toutes les machines de ton réseau. Entre le pc du pote qui vient passer la soirée, les smartphones d'amis venu prendre l'apéritif et voulant montrer leur photo de vacances, la console de jeu dont tu n'est pas administrateur, cette ampoule connectée qu'on t'a offert et qui bien que non hackable fait quand même le taff, l'imprimante réseau dont il n'est pas sûr que son implémentation soit solide, etc

Bref ça que l'on cherche à bien configurer ses machines c'est une bonne chose, mais ça ne me semble pas pour autant remettre en cause une solution simple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui, mais il faut aussi le voir à l'envers. Aller voir un médecin pour avoir un arrêt de travail parce que tu as 3 symptômes bénins qui ne t'empêchent pas vraiment de travailler (même moins productif). C'était pas non plus forcément très bien vu.

C'est moins une question de responsabilité personnelle que de prise en compte et d'organisation collective (simplification des démarches, accepter qu'une maladie ou un symptôme n'est pas inventé, mise en place du télétravail, de rendez-vous médicaux à distance, arrêter de regarder bizarrement quelqu'un qui porte un masque, etc).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

• de plus, bien que Chrome était initialement plus lent que Firefox sur presque tous les benchmarks, il s’appuyait sur de nombreuses astuces de conception qui donnaient l'impression que le produit était plus rapide — et les utilisateurs ont adoré cela.

Je trouve ça très intéressant. C'est un super exemple pour montrer comment se concentrer sur des benchmarks sans les remettre en cause et sans prendre le temps de remettre l'utilisateur au centre peut mener à des problèmes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Dans un pays qui ne s'est pas remis de ses difficultés économiques depuis la crise débutée en 2007, je trouve improbable qu'aucun décideur n'ait vu là une occasion exceptionnelle de faire accepter quelques régressions d'un coup ; tester des changements dans une économie souffrante ; tester la société et sa réaction face à des pertes de liberté supplémentaires ; ou, encore, détourner à court terme les inquiétudes d'une partie de la population de la situation économique et sociale.

Tu décris des méchants de totally spies et tu dis que ce n'est pas manichéen ?

Les gens ne se disent pas qu'ils vont tester des lois comme dans les mission impossible on test des virus avant de les répandre sur le monde avec un rire de méchant. Non ils ont juste une idée différente de l'économie et suivent dur comme fer des économistes de renom bien plus caler que nous ne le seront jamais. Ce qu'il y a c'est qu'ils ne remettent pas en question ce qu'ils savent ou croient savoir alors que :

• ces éléments sont moins de la science dure que de la doctrine
• a énormément évolué récemment grâce à l'arrivée de recherches expérimentales dans le domaine

Donc je réfute le machiavélisme que tu semble leur donner.

Pour ce qui est de la communication, encore une fois l'expérience montre qu'ils font peur même quand il n'y a aucun enjeu. Affirmer sans autre argument que "ça doit bien exister" qu'il y a un dessein derrière cela est plus proche de la théorie du complot que de l'argumentation éclairée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

c'est une simple croyance

Non c'est juste la rasoir d'ockham et tes deux arguments ne tiennent pas pour moi.

On ne peut pas être terrorisé en continue donc oui comme tous ils font des erreurs dans la pratique. Ils sont aussi bien plus surveillé. C'est tellement agréable de pouvoir montrer qu'ils fautent.

La mesure de la peur est relativement compliquée et nous avons des exemples précédents le virus qui montrent que l'état français applique une doctrine qui engendre la peur sans la remettre en cause. C'est particulièrement difficile de prendre le risque de remettre en cause ce genre de doctrine pendant la crise. Je pense par exemple à l'incendie de Nantes.

Loin de moi l'idée de tout pardonner juste une explication moins manichéenne et diabolisante.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne connais pas.

Pour les pool d'objets dont tu parlais plus haut, c'est tout de même assez relou à faire. Tu reconstruit un fonctionnement à la malloc/free avec tous les problèmes qui vont avec (use after release, fuite mémoire,…) et ton pool ne doit pas être un point de contention vu que tu va l'utiliser sur une partie du code plutôt stressée.

Je crois que ça peut être plus propre en C++ en utilisant un allocateur personnalisé (c'est transparent à l'usage tant que tu utilise du RAII).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Avec le code des jeux qui l'utilisent, ça fait une majorité du code final sous GC.

Ça n'est pas la partie critique.

Bref les GC modernes ne sont pas un problème dans les jeux.

On ne les utilise pas dans les parties critiques donc ce n'est pas un problème ? Soit.

Dis autrement ce n'est pas une question de performance des gc qui permet ça. Juste qu'on a construit des frameworks pour dissocier la partie critique de l'application. C'est une très bonne chose, hein pas une critique du tout.

Ni dans les applis web

Là c'est encore très différent. Pour un deamon qui aura par nature une durée de vie plus longue, c'est bien plus simple d'utiliser un gc pour limiter la fragmentation mémoire. Mais même comme ça les appli qui ont une certaine criticité vont faire du off the heap.

ni dans 99% des applis

De mon avis perso, « 99 % des appli » devraient plus s'intéresser à la correction qu'à la performance et donc éviter à tout prix de manipuler à la main la mémoire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

libgdx, pygame,… sont en C ou C++ plus qu'en python ou java quand ce n'est pas simplement sdl qui fait toutes la partie critique en terme de perf par exemple

Pourquoi ces jeux sont fluides et n'ont pas de gros ralentissements dû à un ramasse miette Arrête Le Monde?

Parce que la mémoire n'est pas géré par le garbage collector. Quand ut garde une taille de heap petite ça fonctionne bien.

les GC modernes ramassent les mettes de façon incrémentales et concurrentes, d'autre part les développeurs de jeux font la chasse aux allocations/désallocations en pré-allouant un maximum de choses, en utilisant des pools, en préférant des tableaux fixes aux hashmaps dynamiques…

Qu'il y ai des optimisations possibles on est d'accord, mais elles ne peuvent pas tout. Tu ne peux pas allouer directement un objet en old generation par exemple ce qui permettrait de ne pas voir ton gc passer des objets que tu sais qu'ils ne sont pas à détruire.

Cette chasse est faite aussi dans les jeux en C/C++, car comme je l'ai déjà dit aussi, les malloc/free, c'est coûteux pour tout le monde, pas seulement quand c'est un GC qui les fait.

Je crois que l'allocation mémoire est plus coûteuses en natif que dans la JVM qui gère déjà sa mémoire vis à vis de l'OS.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu veux dire le nombre de jeux qui utilisent un gc en frontend ? Oui il y en a pas mal, mais il n'y a aucune contrainte pour ce genre de code. Ce n'est pas la prouesse de leur gestion mémoire qui permet ça, mais leur capacité à s'interfacer avec du code natif. C'est pour ça qu'on trouve lua par exemple.

Pour parler de java, je doute que l'on trouve une application dont la mémoire est crucial qui ne fasse pas du off the heap.

C'est comme dire que la gestion mémoire de python est sacrément bonne parce que si on utilise numpy ça déchire. C'est moins sa gestion mémoire que la qualité de son interface avec du natif que l'on estime.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais ça n'est pas stable non plus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

il faut l'exécuter plusieurs fois (> 1000 ? > 10 000 ?)

Jusqu'à ce que la moyenne se stabilise.

Mais très clairement, un écart-type élevé est bienvenu pour la génération de l'entropie.

Du code qui fait des io est pratique pour ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Aujourd'hui les vraies pauses sont si petites qu'on ne les remarque plus (CTB !).

Dépend des usages, ça. ZGC qui est monstrueux annonce 2ms, ce qui est bien trop important pour un jeu vidéo temps réel.

Il y a même un GC pauseless pour Java, mais il n'est pas libre :(

Je n'ai jamais essayé azul zing.

Note aussi que le temps d'exécution des autres modes de libération de la mémoire n'est pas NULL non plus.

Ils ne bloquent jamais toute l'application, ils sont totalement prédictibles, ils ne prennent pas de temps CPU hors de la libération de la mémoire,…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L'autre "problème" des langages managés en termes de perfs c'est le JIT (compilation à la volée).

C'est discutable. Le JIT a beaucoup plus d'info que la compilation AOT pour faire ces choix et ce n'est pas quelque chose de continue aucun langage managé que je connais ne compile du code continuellement (sinon c'est plus proche d'un code interprété en fait), une fois que le JIT est passé, c'est juste du code natif qui s'exécute. Si ton jeu s'exécute peu de temps ça pose un problème, mais sinon ça ne fait pose pas tant de problème que ça.

Je pense que c'est plus la gestion de la mémoire qui pose problème (les gc créent un overhead en consommation mémoire, ça demande un certains tunning d'avoir un gc qui s'exécute correctement sur du temps réel comme ça,…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les premiers GC stoppaient le monde.

Les derniers aussi. Ils sont plus efficaces, mais oui le stop the world existe toujours.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Euh, les fuites mémoires à cause d'évènements ou d'objets non-disposés (utilisant des connexions à des bases de données, des ressources réseau, des Span, …), ça arrive et ça fait mal.

Tu as bien plus drôle à faire : utiliser des lambda comme callback sans te rendre compte que ce que tu capture dans ta fermeture. Ça touche tous langages objet qui a des lambdas et personne ne peux rien pour toi. C++ est peut être un peu mieux loti car il rends explicite la capture, mais pas au point de voir quel objet est dans la capture.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Sans vouloir être défaitiste, mon expérience m'a rendu dubitatif quant à la mise en place d'un environnement libre à long terme dans un milieu pour lequel l'informatique n'est qu'un outil, au même titre que l'agrafeuse ou le balai: si la relève n'est pas aussi sensibilisée, formée et motivée et que tu ne l'es sur le sujet, il y a de forte chance que, dès ton départ, tout ce que tu auras mis en place soit remplacé par la solution GAFAM du moment, services et postes de travail inclus.

Euh… C'est normal. Tu met en place une solution, il est bien possible qu'une fois que tu parte, la personne qui prendra le relais utilise une autre solution. Ça marche avec le libre ou non, ça. Ça peut être Office 365 de MS, GSuite de Google, les diverses options libres qui sont listées par ici,…

Croire qu'on peut mettre en place un outil (informatique d'autant plus) et qu'il restera à vie d'Homme c'est une chimère. Les besoins auront peut être évolués dans 5 ans, les solutions aussi. Et de toute manière qui sommes-nous pour dire au successeur de cette tâche comment il doit la faire ? Comment prendrais-tu quelqu'un qui te pousse à utiliser une solution qui ne te plaît pas ou que tu ne connais pas (libre ou pas) ?

La seule chose possible c'est de faire au mieux pour ne pas faire de la rétention d'informations.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il faut voir aussi que la surface du die n'est pas ce qui coûte le plus cher (en fait on sait pas trop quoi faire de toute cette place et on remplit avec des mégaoctets de mémoire cache).

Sur ton wafer 32" si tu sort N dice ou 25% de plus c'est quand même une légère différence, non ?

Les trois trucs qui empêchent de minaturiser les cpus aujourd'hui c'est le nombre de pins nécessaires pour les connecter à la carte mère, la dissipation de chaleur, et la consommation électrique qui empêche de faire des connections trop petites au moins pour l'alimentation.

Je comprends le premier point (on arrive probablement a des tailles de soudures en dessous des quels elles perdent en fiabilité), par contre les 2 points suivants je ne vois pas trop, ils sont liés à la densité et pas à la taille. Si tu as besoin de la surface de ton CPU 32 cœurs même pour refroidir 16 cœurs, ça ne doit pas très bien se passer quand tu 32 cœurs sont effectivement utilisés.

Ces critères définissant en gros la taille du package du cpu, autant mettre du silicium qui fait à peu près la même taille dedans.

Alors non parce que tes chaines de productions produisent moins par wafer et il y a une différence énorme entre la taille du PCB et celle du die par exemple :

pour un socket de 37.5mm de côté donc 85% de surface sans die.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

ce qu'un bon compilo pour langage à garbage collector peut gérer automagiquement

Rien compris à cette phrase.

En les interdisant?

Je ne sais pas. Je dis juste que rust gère la mémoire automatiquement, même s'il n'utilise pas de gc pour ça. Tu n'a pas a libérer manuellement ce que tu as alloué sur le tas. Qu'il y ai des contraintes c'est tout à probable, le gc aussi posent des contraintes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une comparaison n'est pas une compétition. Il n'y a rien de con à comparer des langages. Observer des approches différentes et leurs impactes. S'inspirer des autres langages est nécessaire. Rust étant utilisé à des endroits où C ou C++ règnent en maîtres depuis plusieurs décennies c'est difficile de ne pas en parler. Mais encore une fois C++ n'a pas tué C, rust ne tuera pas ses prédécesseurs. Je ne vois pas pourquoi s'en offusquer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ok je trouve ça fou tout de même.

Ils ont cité 80% de dies pleinement fonctionnels en début de production, le reste dégradé.

Ce qui signifie qu'ils vendent un paquet de puces totalement fonctionnel au prix du milieu de gamme (en les ayants évidement configurés pour).

J'ai pas de doute qu'ils ont fais leur choix de manière aussi intelligente que possible.

Merci pour l'info :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

avec gestion de la mémoire à la main.

Au moins par défaut, la mémoire n'est pas vraiment gérée à la main. Il n'a pas de garbage collector, mais ça reste une gestion automatique de la mémoire. Comme le RAII de C++ (sauf que c'est tout à fait optionnel en C++). std::mem::forget n'est pas sensé être systématiquement utilisé.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

De la même façon, par exemple, que les mémoires NAND ont des blocs défectueux et de la correction d'erreur intégrée. Pareil pour les disques durs qui sont vendus avec un stock de secteurs à utiliser en remplacement. Pareil pour les CD et DVD qui ont plusieurs niveaux de détection et de correction d'erreurs pour que la lecture soit fiable.

Ça n'a rien à voir ça. C'est pour gérer de l'usure et pas des ratages en sortie d'usine. Et c'est quelque chose de parfaitement intégré, au départ de ta ligne de production tu connaît ton ratio dépense de production/prix de vente. Tu ne croise pas les doigts au moment des tests pour savoir si tu fait de la marge ou non.

Y'a que comme ça qu'on arrive à faire croire que le matériel fonctionne de manière fiable et prédictible.

Oui et non. Aujourd'hui tu ne trouve plus de CPU avec un nombre de cœur ésotérique (3, 7, 15 cœurs). Soit ils ne vendent plus leurs CPUs ratés (ce qui représente du coup une perte sèche, plutôt qu'une perte limitée), soit ils ont des procédés de fabrication plus fiables.

Bien sûr qu'il y a des ratages. J'ai travaillé dans le test électrique chez ST, j'ai pu le voir. Mais il y a une différence entre voir des problèmes de montée en charge et réduire après production la fréquence de ton CPU (par exemple) et vendre 20% de silicium en trop. Même si dans les 2 cas tu en profite pour segmenter ton offre. De base tout cela est un réelle perte, mais ça me paraît bien plus drastique quand on parle de virer une partie du composant.

Pour le cell, oui les lignes de production n'étaient pas encore chaudes (ce qui est normal).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce a quoi ils ont répondu qu'ils ont bien vu, mais qu'ils ne veulent plus avoir de garbage collector https://medium.com/@jesse_11222/we-tried-several-go-versions-595626d34076

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il me paraît logique de comparer le langage avec les 2 références de son domaine de prédilection (la programmation système et la performance). Ça ne fait pas toujours plaisir, mais c'est ça d'être celui qui est en place.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll