barmic 🦦 a écrit 5976 commentaires

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

Faire un processeur est extrêmement capitalistique, contrairement à ce que fait MS ou Facebook, un nouveau processus de fabrication coûte des milliards pour la mise en oeuvre, ne pas être à niveau aujourd'hui c'est l'être encore moins demain ;

Pour le reste je en sais pas, mais on a annoncé la mort d'AMD une fois ou 2 aussi. Après la génération Athlon64/P4, Intel a sorti les pentium M et rapidement et Core alors qu'AMD n'a pas su gérer le passage au multicore. Il gravaient des 4 cores en désactiver 1 qui fonctionnait mal et vendaient ça comme 3 cores… Ça en dit long sur la qualité de ton processus de fabrication et ça représente des puces la marge sur la vente est largement diminuée. Et ça venait après que le P4 se soit vautré face à l'Athlon64.

Ça ne coûte pas aussi chère que tu l'annonce. Sinon le Cell ne serait jamais sorti avec la PS3. Oui c'est chère quand tu pars d'une feuille blanche. Intel a déjà montré qu'ils étaient en mesure de se reprendre quand ils avaient fais de mauvais choix architecturaux (justement avec le P4 par exemple).

Quand tu as les reins aussi solides qu'une boite comme Intel, il en faut beaucoup pour pouvoir dire que c'est la fin.

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

RDRAND n’est pas vraiment considérée comme une source d’entropie

Tout à fait. Entre la suite d'algo et la gueule de chacun d'entre eux. Ils font vraiment du bonneteau avec de bits ^^ (c'est l'objectif je sais).

Le seul pool qui reste désormais est le « pool d’entrée ».

Oh oui tout à fait ! Je ne devais pas être bien réveillé quand j'ai lu…

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

Ce que je trouve fou dans ta description, c'est qu'on voit grosso modo des chainage d'algo. Par exemple RDRAND → pool d'entrée entrée (le brassage) → pool d'entrée en sorti → pool de sortie en entrée (le brassage) → pool d'entrée en sortie (chacha20). Là où moi, pauvre développeur, quand je manipule ce genre de données, je les modifie le moins possible pour éviter tout risque de péter l'aléatoire.

D'ailleurs j'ai une question, maintenant que le pool de sorti bloquant n'existe plus quel est l'intérêt de distinguer le pool d'entrée du pool de sorti ?

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

Formellement, un PRNG est un CSPRNG s’il n’existe pas d’algorithme en temps polynomial capable, à partir de n bits produits par le générateur, de prédire le bit n + 1 en se trompant moins d’une fois sur deux.

J'ai personnellement un algo en temps constant qui arrive presque à prédire chaque bit, mais j'ai du mal à dépasser une efficacité de 50%…

Merci pour le journal très intéressant

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

Le dépôt d'exa inclut des fichiers pour l'intégration continue, de la documentation, du packaging,… Ce n'est pas très fairplay.

Après oui un logiciel qui cherche à en faire plus et plus gros qu'un logiciel qui chercher le minimalisme.

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

Encore une fois plus que SpaceX, BlueOrigin ou OneWeb, on goûte ici la dominance américaine. C'est la FCC qui l'a autorisée. Je ne doute pas que la NASA a elle aussi donné son feu vert.

Je n'ai pas la moindre idée de comment est géré légalement l'espace, mais c'est évident que les USA y font bien ce qu'ils veulent.

Tu a la même chose avec les moyens de contrôles d'internet par les USA, avec l'usage du dollar comme étalon, avec…

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