barmic 🦦 a écrit 5946 commentaires

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

Je me demande si un point trop lumineux ne pose pas de problème de surexposition ?

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

Alors android utilise les 3 il me semble. La compilation AOT doit permettre d'alléger la compilation à l'installation.

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

qui déterminent la platforme a partir de l'archi du CPU

Ah ! Oui effectivement je comprends mieux de quoi il s'agit. Je n'y ai pas pensé de prime abord.

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

C'est quand même un métier à part entière le support de la vulnérabilité d'un soft.

C'est justement eux qu'ils ont gardé, ça tombe bien.

Parmi les 250 personnes licenciées se trouvent majoritairement des développeurs qui travaillaient sur le projet Servo (un moteur de rendu expérimental) et l’équipe de réponse aux incidents de sécurité de l’entreprise.

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

Est-ce que c'est un intérêt pour le JIT ou les contraintes de performance de compilation de JIT empêche d'avoir ce genre d'optimisation.

Sinon il faut, (comme le fait android maintenant et c'est ce que peuvent proposer les distributions "sources" comme gentoo) une compilation à l'installation

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