Coucou c'est re moi, ne paniquez pas je viens en paix !!!
Si vous avez pas vu, Epic vient de rendre public un debugger (https://github.com/EpicGames/raddebugger/tree/master) mais c'est pas ça le plus intéressant (on a déjà Remedybg après tout), non ce qui est intéressant c'est la manière dont le projet est codé (et il est fait en partie par ryanfleury, une des premières personnes dont j'ai parlé ici justement). Quand je vous demandais pourquoi vous n'utilisiez pas des arena vous disiez que c'est parce que ce n'est utile que dans certains rares cas et que ça complique le code et moi je vous disais le contraire (cf les extraits de Casey que j'ai déjà donné).
Et bien ce debugger utilise justement des arena de partout et pour la première fois vous pouvez enfin comprendre ce que j'essayais de vous dire puisque maintenant vous avez un vrai projet concret open source pour voir un peu comment ça fonctionne avec cette façon de faire. Vous allez voir que le code est simple et propre. Globalement, toutes les fonctions qui ont besoin de mémoire prennet une Arena en paramètre, et il y a différentes Arena selon la durée de vie voulue, par exemple il y a des arena "permanente" et aussi de la mémoire "scratch" temporaire (par frame, ...) et vous voyez bien que tout est très simple.
Donc en fait c'est ça que je voulais dire quand je disais qu'on a pas besoin de C++ moderne, dans le sens où on peut faire les choses proprement, même en C. Car oui je fais la différence entre un projet C "classique" et les projets comme ce debugger, car les projet C classiques je les trouve assez ridicules en fait, car il font n'importe quoi et c'est pour ça que 70% des bugs de sécurité sont dues au C, c'est parce que c'est juste mal fait, comme Casey le dit ici, il prend curl comme exemple https://open.spotify.com/episode/2TaWQgDpCxxa2edomzCUyg (à 1:32:00) :
"some people take as evidence that we shouldn't program in C [...] but yeah if you look at how curl does things, it's very error prone, everybody allocates things all over the place [...] and it's just bonkers stuff like « allocate these things and pack these things into this string and allocate that thing and put here over here but don't free it if it's still in progress », so yeah, you can create the worst possible architecture that will be subject to memory bugs and I understand why someone might say well the only solution is to change to a new language where none of the things that the curl implementers do are possible, that's one option, but another option would be to just stay in C if we want to, and just not architect that way but in better ways, like one arena per request, and you would have none of these problems. There are much easier solutions to these problems and people are looking at old data that's based on really bad architectural paradigms [...] things like the borrow checker is embracing this old, bad architecture and just prevent the things that curl got wrong from going wrong. That's just backwards."
Du coup si c'est pour faire ça alors là oui clairement il vaut mieux faire du C++ avec du RAII et tout ça car c'est beaucoup plus propre et safe, mais comme vous pouvez enfin le constater avec ce projet, on peut tout aussi bien faire les choses "différemment" et du coup on se rend compte que tout ce qui est RAII et autre ne sont plus si utiles que ça.
Après il y a aussi la façon de gérer l'UI, je vous laisse aller voir le code qui est là aussi très simple et qui n'a aucun rapport avec ce qu'on aurait fait typiquement avec des trucs comme Qt mais ça c'est un sujet pour un autre jour.
Tout ce que j'arrivais pas à expliquer parce que j'avais pas d'exemple sous la main, au point où vous pensiez que "les arena c'est que pour des cas particuliers et ça complique le code", et bien maintenant vous pouvez voir cette technique utilisée en production et peut-être que vous pourrez enfin mieux comprendre tout ça.
Petit apparté au niveau du système de build, comme le dit Casey dans cet article https://www.computerenhance.com/p/msvc-pdbs-are-filled-with-stale-debug , en temps normal c'est absolument infernal, il y a plein de dépendances, il faut attendre plusieurs minutes que ça compile, tout ça pour planter juste avant la fin et perdre du temps à chercher sur internet pourquoi on a telle erreur qui s'affiche... Dans ce projet, il suffit de télécharger le code, lancer le script de build et ça compile instantanément et sans le moindre problème contrairement aux cmake et je ne sais quel autre truc (un extrait fun de Jon Blow à ce sujet https://youtu.be/14zlJ98gJKA?t=1912). Un autre dev pense la même chose d'ailleurs https://twitter.com/ocornut/status/1746899997625319611. Ca c'est un système de build digne de ce nom qui fait pas perdre du temps à tout le monde
Bref je n'ai plus besoin de "défendre" ces pratiques secrètes cachées dans 1200h de vidéos de Handmade Hero vu que c'est maintenant utilisé publiquement chez Epic, je suis trop contente hihihi sinon vous ça va ?
Est ce que Casey tu lui a déjà.... euh... on va dire offert ton corps ?
Car on est toujours dans la vénération la !
Pour ma part j'utilise toujours le debuggueur de visual studio car c'est pratique et intégré.... un petit F5, et hop, ça compile, ça link, ça lance et ça s'arrête sur mon breakpoint. Une touche !
Le seul truc que je trouve intéressant à relever c'est le côté "Epic le fait donc c'est validé", parce qu'au vu de la codebase et des centaines d'ingénieurs qu'ils ont, ça valide à peu près toutes les pratiques de programmation, bonnes comme mauvaises.
Donc encore un gros message pour ne rien dire d'autre qu'un "Haha ! Je vous l'avais dit", en se basant encore une fois sur des arguments fallacieux.
Bref, c'est pas encore pour tout de suite les bonnes résolutions visiblement.
*sarcasm ON* un post de Jade, ça m'avait manqué. *sarcasm off*
Ecrire des outils "maison", c'est une pratique assez courante dans les grosse boîtes de développement. C'est tout, sauf la norme, justement parce que c'est fait "maison", il y a probablement tenants et aboutissants derrière, autre qu'un debugger bête et méchant. Par exemple: Avoir une bonne synergie avec les outils de développement "maison".
Ensuite, tu as découvert un concept: Arena. Tu as écouté des arguments en sa faveur et tu en as retiré une bonne impression. Tu as fais des expérimentations particulières qui t'apportent satisfaction. Pris de doutes, tu as effectué des recherches, et trouvé des arguments supplémentaires qui confortent ta position. Tu en as déduit que c'est la meilleur approche, et tu tentes de l'imposer.
Malheureusement, ton raisonnement est biaisée, tu n'as recherché que des arguments qui vont dans ton sens. C'est ce qu'on appelle un Biais de confirmation.
Alors que tu aurais du avoir un approche sceptique: Tu découvres un concept: Arena. Tu écoutes les arguments en sa faveur. Tu te dis que c'est peut-être la meilleur approche. Fais des recherches et expérimentations qui vont en sa défaveur. Pèse le pour et le contre. Tires-en les conclusions.
Bref, comme une dissertation en français, il faut la thèse, l'antithèse et la synthèse. Mais tu ne nous proposes que la thèse.
Toi, comment vas tu ? As tu passé une bonne année ? Des projets pour cette année ?
Oui ça va très bien merci, j’ai passé une bonne année, j’ai regardé des vidéos de Jonathan Blow c’est intéressant aussi ! Pour cette année j’ai prévu de refaire un visionnage de Handmade Hero histoire de revenir un peu aux sources.
On n'a pas dit que Arena était toujours un mauvais choix, c'est rarement le meilleur "générique"
Heureusement que tu es là pour nous éclairer sur le concept d'arenas (que je nomme memory pool dans mes projets)...
Je sais bien que vous connaissez mais ce que j'essaie de dire c'est que justement c'est pas un concept qu’on utilise une fois de temps en temps, on peut vraiment architecturer tout le programme autour de ça dans la majorité des cas et le résultat est mieux au final.
Vous trouvez que c'est bien d'avoir des fonctions comme std::format ou path::string qui renvoient une string en faisant potentiellement une allocation ? Parce que au contraire c'est pas très propre de devoir se reposer sur un allocateur générique dès qu'on a besoin d'un peu de mémoire, car ce genre d'algorithme ne peut pas être optimal, c'est un problème trop général justement, comme dit ici : "General memory allocators are interesting as there exists no algorithm that is optimal" https://github.com/microsoft/mimalloc#performance
Du coup on fait comment ? Et bien regardons comment c'est fait dans raddebugger, ils prennent tout simplement une arena en paramètre et utilisent directement la mémoire disponible dedans (en faisant un simple bump de pointeur comme la stack, ce qui est on ne peut plus optimal) :
Et du côté appelant c'est très simple, soit on a déjà une arena sous la main qu'on nous a passé et donc on a juste à la passer aussi, soit on en fait une temporaire (à partir de l'arena globale par thread qui est toujours dispo) :
Il utilise aussi la technique de réserver 64 GB dont j’avais parlé pour être sur d’avoir toute cette mémoire contiguë (mais il n’utilise que 8 MB initialement, ça ne va pas allouer 64 GB d’un coup heureusement) https://github.com/EpicGames/raddebugger/blob/057a6f3e8eabacda4ec2ec135c2b3f6e32241e5d/src/draw/draw.c#L103
Du coup autre avantage des arenas (et de la mémoire virtuelle), on peut s’en servir comme vector dont les éléments ne sont jamais déplacés en mémoire, donc on évite le resize et on peut conserver des références sur les éléments.
Donc au final ça illustre un peu ce que disais Casey, que les arenas sont adaptées et même optimales dans "99% des cas" contrairement à ce qu'on pourrait penser, c'est juste qu'il faut creuser un plus loin parce que oui je vous accorde que c'est pas ce qu'il y a de plus intuitif de prime abord surtout si on a l'esprit trop "contaminé" par la pensée POO (ce qui est le cas de la très grande majorité des programmeurs).
en se basant encore une fois sur des arguments fallacieux.
Je vous accorde que c'est un peu fallacieux de dire "Epic le fait donc c'est bien" mais pour les autres arguments ils sont quand même valide.
Si je vous dis que le RAII et les smart pointers sont inutiles et mauvais, est-ce que vous pensez que je dis n'importe quoi ? Si oui alors il faut vraiment (vraiment!) que vous regardiez ce court extrait (de 1:14:43 à 1:24:00) https://guide.handmadehero.org/code/day626/#4483 parce que en fait ce qu'il faut comprendre c'est que oui les RAII/smart pointers sont totalement justifié et bénéfique dans le cas où on pense à chaque objet individuellement, c'est pour ça que le C++ moderne est excessivement mieux que le vieux C où on fait des malloc/free et où c'est le festival des CVE. MAIS justement, si on arrive à passer à l'étape suivante, c'est-à-dire ne plus penser à chaque objet individuellement, c'est là que le RAII/smart pointers deviennent inutiles car en fait, il ne font que rendre "safe" une architecture qui est fondamentalement mauvaise, pas adaptée aux machines modernes, et cetera, contrairement à la pensée par "groupe".
Malheureusement, ton raisonnement est biaisée,tu n'as recherché que des arguments qui vont dans ton sens.C'est ce qu'on appelle un Biais de confirmation
Justement si je viens parler sur ce forum au lieu de juste vénérer Casey comme vous dites, c’est pour avoir un autre son de cloche, que je connaissais déjà d’ailleurs puisque tout le monde dit la même chose, mais après tout ce temps tout ce que je peux conclure comme désavantage c’est que s’il y a un stagiaire qui sait pas ce qu’il fait, il va peut-être plus facilement casser le code que si c’était fait en style classique (et encore j’ai pas la preuve, mais je veux bien supposer que ça puisse être le cas) et que oui il y a des cas (1% ?) où c’est pas adapté (Casey le dit lui-même). Mais sinon globalement ce que fait la communauté Handmade c’est juste trop bien quoi.
Allez un bonus fun pour la route, c'est plus rapide de compiler raddebbuger from scratch puis de commencer à debugger avec, plutôt que de juste ouvrir Visual Studio https://twitter.com/ryanjfleury/status/1747756219404779845
(remarquez aussi comment raddbg fait des jumps "smooth" contrairement à Visual Studio qui jump direct comme dans les années 80, là pour le coup c'est pas juste pour faire joli, c'est réellement plus confortable à utiliser car si on voit que ça "glisse" ça veut dire qu'on s'est déplacé dans le même fichier (et on voit si c'est vers le haut ou vers le bas) et si ça "saute" on sait qu’on est parti dans un autre fichier alors que dans Visual Studio ça saute tout le temps même si c'est juste pour aller 100 lignes plus bas, je sais pas comment vous faites pour vous passer du smooth jump).
Les RAII et les pointeurs intelligents ne sont ni inutiles, ni mauvais.
Leurs but et de faciliter les développement, en déléguant la tâche de gestion des ressources au langage plutôt qu'au développeur.
T'es-tu déjà demandé pourquoi ces concepts sont apparus ? On s'est posé les bonnes questions: Pourquoi les programmes plantent ? A cause des fuites (entre autre). Pourquoi il y a des fuites ? A cause de la gestion manuelle des ressources qui par nature, dépend du facteur humain. La solution apportée, tu la connais déjà.
Enfin, C++ met à disposition des outils, mais tu n'es pas obligé des les suivre. Si tu penses avoir une solution meilleur, libre à toi de la reprendre et d'en faire l'utilisation qui te chante. Gardes bien en tête également qu'une solution peut être particulière à une problématique donnée.
Mais par pitié, ne nous impose pas ta vision. Les gens du comité ISO C++ ont des années d'étude et d'expérience derrière eux, ce sont eux qu'il faut convaincre !
Si je vous dis que le RAII et les smart pointers sont inutiles et mauvais, est-ce que vous pensez que je dis n'importe quoi ? Si oui alors il faut vraiment (vraiment!) que vous regardiez ce court extrait (de 1:14:43 à 1:24:00)
J'ai regardé l'extrait pour voir.
Moi ce que je vois c'est qu'il faut réduire le nombre d'allocations. Et bien sur que c'est vrai, mais ce n'est pas en contradiction avec les pointeurs intelligents ni le RAII.
Evidemment que si tu as plein plein d'objets à gérer et que tu peux les grouper, il faut voir si ces objets ne peuvent pas être en priorité constitués d'éléments statiques, et éviter de surallouer s'il n'y en a pas besoin :
Si tu fais un std::vector<Objet> c'est toujours moins d'allocations qu'un std::vector<std::shared_ptr<Objet> >, qui plus est si l'objet est movable, un push_back ne coutera pas cher. (et c'est même encore mieux si tu connais la taille dès le départ).
Mais moi ce que je vois chez Casey (et surtout chez toi), c'est que vous vous émerveillez de choses qui sont finalement... de l'optimisation classique, mais tout en rejetant des concepts fondamentaux (pointeurs intelligents et RAII).
En réalité, s'il y a une chose à fustiger, ce n'est pas les concepts récents du langage C++, c'est une mauvaise utilisation que ferait un débutant en abusant des petites allocations....
Pour illustrer mon propos : si je vois quelqu'un écrire :
Je ne vais pas dire que std::map est pourri (comme tu le ferais, comme le ferait ton idole), je dirais qu'il faut peut être repenser l'algo pour le simplifier.
- Tes "arena" dans la vraie vie ça s’appelle des memory pool et c'est massivement utilisé, depuis toujours, surtout dans les applications temps réel.
- en fait c'est tellement classique que c'est (entre autre) pour ça que la bibliothèque standard te permet de spécifier quel allocateur tu veux utiliser, au aussi pour ça qu'on a std::pmr.
- Ce n'est absolument pas antinomique avec l'idiome RAII ou les smart pointers, penser l'inverse c'est n'avoir compris ni l'un, ni l'autre. Ton unique_ptr<> peut très bien pointer dans une pool.
- Ce n'est pas adapté a toutes les situations, déjà en multithread tu vas devoir ajouter un mécanisme de synchronisation, ensuite si tu veux faire une seule pool pour toute ta mémoire (càd mélanger des allocations de taille différentes) tu vas devoir garder en mémoire les tailles et du coup gérer la fragmentation mémoire, pour des questions de performances tu va essayer de faire en sorte que les bouts de mémoires d'un thread soient contiguës et donc devoir ajouter le concept de pages mémoires, et pleins d'autres concepts tordus. Et au bout de 2 ans a galérer (car ce ne sont pas des concepts simples du tout), tu te retrouve avec un nouvel allocateur, comme celui de ton OS, jemalloc, tcmalloc, mimalloc ...
- Du coup en général les pool sont utilisées pour les grosses allocations redondantes de taille fixe, par exemple dans une application de traitement vidéo ce sera pour l'allocation des nouvelles frames.
En plus, comme évoque Oroshi, certains ont programmé leur propre pool mémoire en se disant (comme ça ne fais qu'un seul malloc en tout !) et des fonction mymalloc et myfree qui tapent dedans, mais derrière tout un mécanisme qui gère des allocations dans ce pool de façon à ressembler au vrai malloc (je dis malloc car new appelle malloc).
Mais parfois on y perd quand même au change ! On alloue notre pool, et on fait tout plein de choses lors du malloc et du free, mais c'est tout software.... Alors que les processeurs gèrent l'allocation bien souvent en hardware. On n'y gagne même pas forcément !
Evidemment, ça n'empêche pas pour avoir un bon code de ne pas sur-solliciter les malloc et free.
Les RAII et les pointeurs intelligents ne sont ni inutiles, ni mauvais.
Leurs but et de faciliter les développement, en déléguant la tâche de gestion des ressources au langage plutôt qu'au développeur.
Je n'ai pas dit le contraire, relisez bien, je dis bien que ces concepts sont avantageux comme vous dites pour faciliter le développement, mais uniquement dans le cas où on architecture son programme "à l'ancienne" c'est-à-dire avec des objets qui ont leur propre durée de vie individuelle etc.
Deedolith a écrit:
Mais par pitié, ne nous impose pas ta vision.
Je ne veux pas imposer une vision, bien sûr que vous êtes libres de faire ce que vous voulez, mais je trouve que c'est intéressant de voir d'autres façons de faire et vu que vous n'avez pas l'air de bien saisir les tenants et aboutissants de ce que je veux dire, je continue en donnant des exemples comme ce debugger.
Fvirtman a écrit:
Pour illustrer mon propos : si je vois quelqu'un écrire :
Je ne vais pas dire que std::map est pourri (comme tu le ferais, comme le ferait ton idole), je dirais qu'il faut peut être repenser l'algo pour le simplifier.
On est d'accord là dessus, le hic c'est que l'on peut se retrouver à faire ça mais sans que cela saute aux yeux. Comment ? Tout simplement en faisant une map<T>, avec un T qui contient un vector<U>, avec U qui contient une map, et cetera, on se retrouve avec le même genre "d'inefficacité" mais bizarrement tout le monde trouvera ça propre et correct.
Orochi a écrit:
- Tes "arena" dans la vraie vie ça s’appelle des memory pool et c'est massivement utilisé, depuis toujours, surtout dans les applications temps réel.
Oui si vous voulez, chacun a un peu ses propres termes, mais selon les termes courants, c'est pas tout à fait la même chose, une arena c'est vraiment un bump allocator, on est pas du tout obligé de stocker des "blocs".
Orochi a écrit:
- en fait c'est tellement classique que c'est (entre autre) pour ça que la bibliothèque standard te permet de spécifier quel allocateur tu veux utiliser, au aussi pour ça qu'on a std::pmr.
Les arenas ça sert juste à avoir de la mémoire, mais qui n'est pas associée à un conteneur particulier, ça a pas trop de rapport avec le fait de spécifier un allocateur ou d'utiliser std::pmr, ces choses là ça sert plutôt à "sauver les meubles" si jamais on se rend compte qu'on a un problème de performance lié aux allocations, et ça peut être une bonne chose je dis pas le contraire, mais les arenas permettent plutôt de ne pas avoir de meubles à sauver en premier lieu, if that makes sense.
Orochi a écrit:
Ton unique_ptr<> peut très bien pointer dans une pool.
Voilà c'est ce que je viens de dire, faire ça cela revient à sauver les meubles mais pas à faire une architecture propre dès le départ. J'ai même envie de dire que ça ne sert à rien de faire ça, avec des allocateurs modernes comme mimalloc je suis pas sûre que le gain soit substantiel (à vérifier bien entendu si besoin).
Mais vous avez regardé l'extrait ? Je vais vous donner un exemple, si on stocke un unique_ptr<A> dans un vector, qui lui même est stocké dans un Node d'un arbre par exemple, à ce niveau là on a déjà un problème, et le fait de mettre une pool ou une arena derrière ne changera pas grand chose. Quand il faudra libérer tout ça, il faudra parcourir toute la structure pour la détruire, comme dit dans l'extrait. L'idée de penser par "groupe" c'est justement d'éviter ça totalement, puisqu'on n'a pas besoin de faire tout ça si on fait les choses bien. Cela change fondamentalement la structure du programme, il ne s'agit pas du tout de juste mettre un allocateur plus rapide derrière.
Orochi a écrit:
- Ce n'est pas adapté a toutes les situations, déjà en multithread tu vas devoir ajouter un mécanisme de synchronisation, ensuite si tu veux faire une seule pool pour toute ta mémoire (càd mélanger des allocations de taille différentes) tu vas devoir garder en mémoire les tailles et du coup gérer la fragmentation mémoire, pour des questions de performances tu va essayer de faire en sorte que les bouts de mémoires d'un thread soient contiguës et donc devoir ajouter le concept de pages mémoires, et pleins d'autres concepts tordus. Et au bout de 2 ans a galérer (car ce ne sont pas des concepts simples du tout), tu te retrouve avec un nouvel allocateur, comme celui de ton OS, jemalloc, tcmalloc, mimalloc ...
Encore une fois, regardez comment c'est fait dans raddebugger si vous vous posez des questions, chaque thread a sa propre arena donc il n'y a pas du tout de synchronisation à ce niveau là. Je ne comprends pas pourquoi vous dites qu'il faut "garder en mémoire les tailles", non chaque chose qu'on alloue est directement allouée, il n'y a pas d'infos en plus à garder. Sauf si on veut "revenir en arrière" et désallouer des trucs, dans ce cas il y a la struct Temp qui gère de la mémoire "scratch" et qui stocke juste l'endroit actuel pour y revenir plus tard. D'ailleurs oui on pourrait utiliser le RAII pour gérer ça automatiquement au lieu de faire
Temp scratch = temp_begin(arena);
/* ...on utilise toute la mémoire qu'on veut dans le scratch... */
temp_end(scratch);
mais bon c'est pas comme si ça apportait grand chose non plus, ça serait juste un petit plus où le RAII pourrait éviter d'appeler temp_end à la main.
Donc oui le but n'est absolument pas de réinventer un allocateur general purpose comme mimalloc, le but c'est de ne pas avoir besoin de ça justement. Et encore une fois, si vous vous dites que c'est pas possible, regardez juste comment raddebugger fait les choses.
Fvirtman a écrit:
En plus, comme évoque Oroshi, certains ont programmé leur propre pool mémoire en se disant (comme ça ne fais qu'un seul malloc en tout !) et des fonction mymalloc et myfree qui tapent dedans, mais derrière tout un mécanisme qui gère des allocations dans ce pool de façon à ressembler au vrai malloc (je dis malloc car new appelle malloc).
Oui voilà c'est exactement ce qu'il ne faut pas faire et qui est même complètement idiot, si c'est pour faire ça autant utiliser un vrai allocateur éprouvé.
Fvirtman a écrit:
Mais parfois on y perd quand même au change ! On alloue notre pool, et on fait tout plein de choses lors du malloc et du free, mais c'est tout software.... Alors que les processeurs gèrent l'allocation bien souvent en hardware. On n'y gagne même pas forcément !
Encore une fois, on ne veut surtout pas de malloc/free ou d'équivalent dans le code, regardez comment c'est fait dans raddbg. Regardez aussi l'extrait, on ne veut pas "créer un objet" puis "détruire un objet", on veut juste "faire des opérations" et pour cela on a besoin de "mémoire", c'est tout, c'est une autre façon de penser qui se passe totalement des choses modernes qui existent en C++, car comme dit dans le premier message, ces choses là (et tout ce qui est borrow checker et cie) servent surtout à rendre safe une architecture qui n'est fondamentalement pas bonne. Mais c'est mieux de chercher à avoir une bonne architecture vous ne pensez pas ?
Par contre je ne sais pas où les processeurs "gèrent l'allocation en hardware", oui les processeurs gèrent le mapping virtuel/physique en coopération avec l'OS mais les allocateurs general purpose qu'on code par dessus sont bien faits en software (et encore une fois si c'était pas assez clair, on ne veut pas d'allocateur general purpose dans 99% des cas).
vu que vous n'avez pas l'air de bien saisir les tenants et aboutissants de ce que je veux dire
"Vu que vous n’êtes pas d'accord avec moi, c'est que vous n'avez pas compris". La discussion va continuer de tourner en rond pendant longtemps, tant qu'elle n'aura pas accepté que si on n'est pas d'accord, c'est qu'on a de bonnes raisons. En attendant, elle restera sourde a tous les arguments que vous pourrez avancer.
C'est allouer la maximum théorique de mémoire au démarrage de l'application, et ne la libérer qu'a la fin. Il est possible que l'on gagne en perfs, a condition que ce bloc mémoire soit bien géré (qu'est ce qui est cours d'utilisation, qu'est ce qui est libre, attention à la fragmentation, s'assurer qu'on ne se marche pas sur les pieds, multithreads ect ...), gestion qu'il faudra te palucher à la main.
Admettons que tu aies réglé tous ces problèmes de gestion, Félicitation, tu viens de développer un ogre, qui ne laisse que peut de place à ses voisins, au code source bien lourdingue.
Immagine que tu alloue suffisement de ram pour y faire rentrer l'encyclopédie Universialis à chaque fois que tu lance ton programme, et quid des programmes multi-instanciés ? Tu va mettre à genoux n'importe quel PC, et ton appli finira à la poubelle.
Pour l'efficacité, on repassera (et je ne parle pas de la maintenance).
L'astuce est de trouver un bon équilibre, il n'y a pas une seule et unique solution.
Faire une arena, ca peut servir. Est-ce que ca sert tous le temps ? Clairement non.
C'est pas géré. Cf les liens et les codes donnés. Ca alloue et libère uniquement a la fin des blocs.
J'avais expliqué ce problème il y a des mois, dans une précédente discussion.
Réfléchissez à vos projets et pensez a combien d'entre eux ne peuvent pas utiliser ce pattern, rien qu'a cause de cela. Pensez juste a une simple queue FIFO.
Jade et Casey pensent que 99% des projets peuvent utiliser ce pattern. De votre expérience personnelle, quels % de projets pensez vous ne le peuvent pas, rien que sur ce problème ?
Ma propre estimation personnelle est que Jade et Casey sont a côté de la plaque. Faites votre propre estimation.
Deedolith a écrit:
tu viens de développer un ogre
Cf les codes donnés en lien.
Pour utiliser les arenas, il faut passer un pointeur a chaque fonction, appeler manuellement une fonction pour commencer un bloc de mémoire temporaire, puis une autre fonction a la fin pour libérer. Et que faire si en plein milieu d'un bloc temporaire, on veut allouer un bloc non temporaire ? Ben on peut pas.
Et niveau performances, chaque allocation et libération nécessite de voir si on arrive a la fin d'un bloc et qu'il faut allouer ou libérer un bloc. Donc un surcoût a chaque fois.
Casey l'explique dans la vidéo donnée en lien, pour lui, la bonne approche c'est d'avoir une compréhension globale de tous vos objets a tout moment. Ce qui est simple pour lui, sur ses jeux qui datent s'il y a 20 ans, avec des grilles de tiles de taille fixe et un petit nombre d'objets dynamiques. Pensez aux projets sur lesquels vous bosser. Est-ce réaliste pour vous ?
Les arguments donnés sont juste des points de vue. Comme a dit bacelar, il n'y aucune mesure faite pour vérifier que cela a réellement un impact. C'est que du vent.
EDIT :
Deedolith a écrit:
multithreads (...) gestion qu'il faudra te palucher à la main.
En complément, que j'avais oublié de parler : c'est pas thread safe. Et pour la gestion mode paluchage de mains, ça ne gère pas non plus les constructeurs et destructeurs. Donc contrairement au C++ tout moisi qui gère l'allocation et libération de ressources au sens large, ce pattern ne gère que la mémoire.
EDIT 2 :
Et au fait, le memory pool et les bump allocator sont dans le standard C++. Il suffit de lire la doc sur cppreference.com (ou des blogs ou les talks CppCon consacré au sujet) pour voir les défauts (et qualités) de ces patterns et comprendre pourquoi ils ne sont pas utilisé partout...
Tu aimerais faire quoi comme type de projets ? Tu as des idées ? Tu veux de l'aide pour en trouver ?
Je n'ai pas de projet en cours à l'heure actuelle car avant de partir sur un nouveau projet je veux déjà avoir des bases solides au niveau de l'architecture et c'est pas encore tout à fait ça, mais justement raddbg m'aide beaucoup à voir à quoi ressemble une bonne architecture (il y a aussi les vidéos de Allen qui sont intéressantes https://www.youtube.com/@Mr4thProgramming)
Deedolith a écrit:
Si je résume "ce que tu trouves mieux":
C'est allouer la maximum théorique de mémoire au démarrage de l'application, et ne la libérer qu'a la fin.
Alors non, pas du tout en fait, on a absolument pas envie de consommer en permanence le maximum de mémoire ça serait ridicule (sauf pour un tetris ou un pacman à la limite). Quand je dis qu'il alloue 64 GB, ça n'a rien à voir avec faire un std::vector<uint8_t>(64GB). C'est pas surprenant que vous trouviez ça étrange vu que personne n'en parle et c'est un concept qui n'existe même pas dans la STL, c'est le principe de réserver de la mémoire, c'est ce qu'il se passe dans raddbg, il réserve en premier, puis commit à la demande.
gbdivers a écrit:
Deedolith a écrit:
attention à la fragmentation
C'est pas géré. Cf les liens et les codes donnés. Ca alloue et libère uniquement a la fin des blocs.
Justement il y a moins de fragmentation que quand on utilise l'allocateur global générique, vu qu'on a tendance à allouer et libérer à la fin, comme la stack.
gbdivers a écrit:
Réfléchissez à vos projets et pensez a combien d'entre eux ne peuvent pas utiliser ce pattern, rien qu'a cause de cela. Pensez juste a une simple queue FIFO.
On peut totalement faire une FIFO avec ce pattern, regardez par exemple comment sont gérés les events système, au début de la frame il fait une mémoire "scratch", et les events seront stockés dans cette mémoire :
Donc en fait, tout comme les fameux "99% des cas", on voit que ça fonctionne bien de juste allouer à la fin d'un bloc contrairement à ce qu'on pourrait penser de prime abord, d'ailleurs le code qui "libère les events" n'existe pas vu que c'est pris en charge par l'arena temporaire de la frame, donc pas besoin de faire un free manuellement, ni d'avoir un destructeur qui détruit, le code est simple et la mémoire est propre (pas fragmentée) vu qu'à la fin de la frame on rollback le curseur exactement comme la stack, on rince et on répète, simple as that.
gbdivers a écrit:
Pour utiliser les arenas, il faut passer un pointeur a chaque fonction, appeler manuellement une fonction pour commencer un bloc de mémoire temporaire, puis une autre fonction a la fin pour libérer.
De mon opinion, c'est plus propre au contraire de devoir passer une arena aux fonctions qui veulent allouer, ça évite de prétendre que la mémoire est une ressource magique qui sort de nulle part. Et oui si on n'a pas déjà une arena sous la main, il faut faire une mémoire scratch mais c'est pas non plus la mer à boire, et ça a l'avantage qu'on ne fragmente pas la mémoire à chaque allocation temporaire, imaginez std::format qui renvoie une string à chaque fois, ça oblige l'allocateur global générique à trouver de la place, puis libérer, merger les zones si besoin, alors que tout ce travail est superflu, on peut se contenter d'une arena qui bump alloc.
Et que faire si en plein milieu d'un bloc temporaire, on veut allouer un bloc non temporaire ? Ben on peut pas.
C'est plutôt à l'appelant de savoir où il veut stocker sa mémoire, s'il donne une arena temporaire, alors c'est temporaire sinon non. Et si on donne à la fonction une "arena" mais qu'elle a envie d'allouer ailleurs, bah déjà c'est pas propre comme façon de faire, et au pire on peut toujours récupérer une autre arena qui a la lifetime voulue.
gbdivers a écrit:
Et niveau performances, chaque allocation et libération nécessite de voir si on arrive a la fin d'un bloc et qu'il faut allouer ou libérer un bloc. Donc un surcoût a chaque fois.
Je ne comprends pas cette phrase, n'importe quel allocateur doit forcément se demander s'il y a assez de mémoire ou s'il faut en redemander. Ensuite oui on peut avoir plein de "blocs" si on veut mais ça sert un peu à rien, ce qu'on peut faire plutôt c'est avoir un seul énorme bloc de 64 GB par exemple (juste réservé, ça ne prend pas 64 GB de RAM !!), et le reste c'est l'OS qui gère le commit et les pages, donc justement c'est ce qu'il y a de plus simple et rapide. (et si jamais on dépasse les 64 GB, ce qui est assez peu probable, et bien on a qu'à juste réserver un autre bloc de 64 GB et c'est reparti, ou alors réserver 512 GB et on en parle plus).
gbdivers a écrit:
Casey l'explique dans la vidéo donnée en lien, pour lui, la bonne approche c'est d'avoir une compréhension globale de tous vos objets a tout moment
Globalement oui c'est un peu ça, il faut pas voir chaque objet individuellement en se disant "il va avoir son std::string, son std::vector", non il faut plutôt réfléchir aux opérations que l'on veut faire, et avoir une arena pour l'opération en question, autrement dit il faut penser par groupe et pas que chaque objet soit propriétaire de ses propres membres, ça c'est une vieille façon de faire justement, et que le C++ permet de faire d'une manière propre avec le RAII mais on peut justement faire mieux que ces "vieilles méthodes".
Ce qui est simple pour lui, sur ses jeux qui datent s'il y a 20 ans, avec des grilles de tiles de taille fixe et un petit nombre d'objets dynamiques
Comme il le dit souvent, tout ça c'est des excuses que vous essayez de trouver, d'ailleurs je vous ai laissé tranquille avec ça mais l'UI de raddbg est faite en mode immédiat et on voit bien que ça gère des choses complexes, Ryan a de l'espoir que ça permettra de faire prendre conscience de ça, et Casey répond que les gens vont encore trouver des théories pour ne pas admettre la vérité https://twitter.com/ryanjfleury/status/1747871316663992541
c'est pas thread safe
Chaque thread peut allouer ce qu'il veut quand il veut avec les arenas, il n'y a pas de lock ni d'opérations atomiques, chaque thread a ses propres arenas, et pour le fait de lire des données écrites dans un autre thread, les arenas ne résolvent pas magiquement le problème, il s'agit de programmation parallèle tout ce qu'il y a de plus classique.
Tous d'abord, la reseration d'un bloc mémoire est pris en charge dans la STL, ca s'apelle les "placement new" (relis le Lipmann, c'est dedans).
Ton raisonnement est naïf. Ce bloc mémoire sera géré comme la RAM, la seule différence est que ce sera une gestion logicielle et non matérielle. Dans le cadre d'un jeux (puisque c'est ce dont tu parles), après une itération, le bloc mémoire sera "propre". Après quelques millions d'itérations, ou l'on aura chargé / déchargé à la pelle des données (dans un jeux, ca arrives vite), le bloc aura une sale gueule.
Du simple fait que l'on ne peut se permettre d'allouer "a la suite" car le bloc mémoire n'est pas extensible, on alloue "là ou il y a de la place". Et c'est ca qui fait apparaitre de la fragmentation.
Exemple: Pour simplifier, on va prendre un bloc de 30 octets dont l'adresse commence à 00. On a : un objet A de 10 octets. Un objet B de 20 octets. Un objet C de 5 octets.
Allocation de l'objet A: adresses utilisées: 00 à 09. Allocation de l'objet B: adresses utilisées: 00 à 29 (objets A + B). Destruction de l'objet A: adresses utilisées: 10 à 29. Allocation de l'objet C: Adresses utilisées 00 à 04 et 10 à 29 (tiens ? il y a un trou). Destruction de l'objet B: adresses utilisées: 00 à 04. Allocation de l'objet A: adresses utilisées: 00 à 04 et 05 à 14. Destruction de l'objet C: adresses utilisées: 05 à 14 (tiens ? il y a un trou). Allocation de l'objet B: Crash, il n'y a pas de place pour allouer ce dernier, le plus grand espace disponible fait 15 octets, mais on a besoin de 20).
Les "trous", c'est la fragmentation, et c'est inévitable.
PS: Je parle d'allocation, mais dans le cadre d'une arena, c'est un abus de langage, on parlera plutot de "reservation", ou "marqué comme utilisé".
Maintenant, il faut faire des comparatif: Reprend l'exemple que je viens de citer. Traduis le en C++ "classque". Traduis le en C++ "avec une arena". Poste les codes sources. Compares ces deux derniers (avantages / inconvénients). Conclusions ?
Les RAII et les pointeurs intelligents ne sont ni inutiles, ni mauvais.
Leurs but et de faciliter les développement, en déléguant la tâche de gestion des ressources au langage plutôt qu'au développeur.
Je n'ai pas dit le contraire, relisez bien,
Ah, bon? Attend, je relis, et je vois...
JadeSalina a écrit:
Si je vous dis que le RAII et les smart pointers sont inutiles et mauvais, est-ce que vous pensez que je dis n'importe quoi ?
A ce stade, il faut commencer à faire attention, car la sénilité précoce commence à tout age...
JadeSalina a écrit:
gbdivers a écrit:
Tu aimerais faire quoi comme type de projets ? Tu as des idées ? Tu veux de l'aide pour en trouver ?
Je n'ai pas de projet en cours à l'heure actuelle car avant de partir sur un nouveau projet je veux déjà avoir des bases solides au niveau de l'architecture et c'est pas encore tout à fait ça,
L'idée est louable, cependant, tu fais fausse route car, pour espérer acquérir de "bonnes bases", que ce soit en architecture logicielle ou en programmation pure, la seule technique valable consiste en quatre règles:
Pratiquer
Pratiquer encore
Pratiquer toujours plus
et surtout,confronter à chaque étape ce que l'on a fait au jugement d'autres personnes en acceptant les remarques qui nous sont faites et en acceptant l'idée que l'on puisse êre faillible.
JadeSalina a écrit:
mais justement raddbg m'aide beaucoup à voir à quoi ressemble une bonne architecture (il y a aussi les vidéos de Allen qui sont intéressantes https://www.youtube.com/@Mr4thProgramming)
Justement non. Raddbg ne te permet que de voir une approche possible, envisagée par une équipe particulière, dans une situation donnée
Le problème est que cette approche n'est en rien différente de celle dont tu es persuadée qu'il s'agit du "saint graal", de "la meilleure approche de tous les temps", de la "seule solution permettant d'obtenir quelque chose de correct".
Dans ton cas, il ne s'agit donc que d'un biais de confirmation: ils pensent visiblement comme moi, c'est donc que mon approche est la bonne, la seule, l'unique.
Si cette approche était totalement nouvelle pour toi, si tu avais déjà appris et mise en oeuvre d'autres approches et que tu avais déjà pu te faire une idée précise des avantages et des inconvénients de chacune de celles-ci, radbg aurait effectivement pu t'apporter quelque chose de nouveau, t'ouvrir une nouvelle voie de réflexion, que tu aurais pu confronter aux autres possibilités et qui t'aurait amené à te poser les bonnes questions:
quels sont les avantage?
quels sont les inconvénients?
quand est il utile de l'utiliser?
quand est il préférable de faire autrement?
Malheureusement, tu es arrivée sur ce forum avec une idée fixe : les memory pools (que tu appelle arena) sont le graal, sont ce qu'il y a de mieux.
Et lors de toutes les recherches que tu as pu entreprendre depuis -- nous sommes bien conscients que tu en a effectué beaucoup, ce qui est à ton honneur -- tu es systématiquement tombée dans le même travers de confirmation:
Si ca utilise les memory pool, c'est génial
Si ca n'utilise pas les memory pool ou, pire encore -- crime de lese majesté -- si ca parle négativement de ceux-ci, c'est de la merde.
JadeSalina a écrit:
Quand je dis qu'il alloue 64 GB, ça n'a rien à voir avec faire un std::vector<uint8_t>(64GB). C'est pas surprenant que vous trouviez ça étrange vu que personne n'en parle et c'est un concept qui n'existe même pas dans la STL, c'est le principe de réserver de la mémoire, c'est ce qu'il se passe dans raddbg, il réserve en premier, puis commit à la demande.
C'est vrai, la mémoire réservée par ton arena est de la mémoire virtuelle... Mais as tu conscience de ce que cela veut dire?
Cela veut dire, pour faire simple, que cette mémoire est réserevée (quoi que cela implique) au niveau ... du fichier pagefile.sys, voire du fichier swapfile.sys (sous windows).
Mais que va-t-il se passer, selon toi, lorsque nous voudrons accéder aux informations contenues dans cet espace mémoire? Car il faut bien se rendre compte que si l'on place des informations en mémoire, c'est bien pour pouvoir y accéder et les manipuler!
Eh bien, je vais te le dire: la partie des informations à laquelle on souhaite accéder qui se trouve en mémoire virtuelle va ** forcément ** devoir passer en mémoire physique (RAM), et, même si cela se fait "automatiquement" au niveau du système d'exploitation, il ne faut pas se leurrer : pour que cela puisse se faire, le système n'aura pas d'autre choix que de ... réserver un espace suffisant en mémoire physique pour contenir ces informations pour l'application en cours.
Et, une fois qu'il ne sera plus pertinent de garder ces informations en mémoire physique, le système devra s'arranger pour les renvoyer en mémoire virtuelle afin de pouvoir ... libérer la mémoire physique afin d'être en mesure de l'utiliser pour "autre chose".
C'est lors de ces deux processus que se trouvent les équivalent à malloc et à free : tu as un joli équivalent à malloc lorsque tu indiques au système que tu veux accéder à une donnée qui se trouve en mémoire virtuelle, et un joli équivalent à free lorsque tu indique qu'il n'est plus pertinent de garder l'information en mémoire physique.
Le gros avantage d'utiliser la mémoire virtuelle est que tu peux -- en théorie -- travailler avec une quantité de mémoire bien supérieure à celle de ta mémoire physique. C'est génial lorsque tu as besoin de garder des informations en mémoire en sachant que tu n'en a pas l'usage "pour l'instant".
Le gros inconvénient étant que, du coup, les informations se trouent sur un disque dur et que le temps d'accès à ces informations est largement plus important que si elles se trouvaient effectivement en mémoire physique.
Cela n'aura que peu d'importance dans le cadre d'un débugger, car on s'attend à ce qu'il doive de toute manière suspendre l'exécution très régulièrement, que ce soit parce que l'on travaille "pas à pas" ou parce qu'il y aura un breakpoint quelque part, et que le temps passé à "rapatrier" les données de la mémoire virtuelle vers la mémoire physique (et inversement) est suffisamment court pour n'être que très peu perspectible par l'humain.
Mais lorsque tu travailles sur un jeu video et que tu n'as que 0.016 seconde pour faire tout ce que tu as à faire afin d'afficher l'image suivante en respectant les 60 fps; lorsque chaque milli seconde compte, tout le temps perdu dans ce mécanisme de transfert entre la mémoire virtuelle et la mémoire physique est ... perdu.
Que faut-il faire alors? utiliser la mémoire physique pour éviter ces transferts incessants de données entre la mémoire physique et la mémoire virtuelle?
Si on transpose l'idée d'un memory pool en mémoire physique, comment va-t-on s'assurer de réserver correctement tout l'espace mémoire dont on prévoit d'avoir besoin?
Une fois que ce sera fait, qu'en sera-t-il des autres applications et processus qui doivent s'exécuter en même temps que notre application?
JadeSalina a écrit:
De mon opinion, c'est plus propre au contraire de devoir passer une arena aux fonctions qui veulent allouer, ça évite de prétendre que la mémoire est une ressource magique qui sort de nulle part.
Mais, que crois tu? Que tout le monde est incompétent au point de savoir que la mémoire n'est pas une ressource magique qui sort de nulle part?
N'importe quel développeur C++ un tant soit peu habitué sait exactement -- ne serait-ce que dans les grandes lignes -- ce qui se cache derrière un new, un delete, un malloc ou un free
Crois tu vraiment que l'arena est le seul moyen de faire prendre conscience de ce fait? Crois tu vraiment que l'arena est la seule solution?
Peut être que si tu étais un peu moins concentrée sur la recherche de confirmation de ce que dit ton idole, tu te serait rendue compte que ces arguments ne sont que des faux problèmes!
Pourquoi crois tu que, lorsque l'on sait à peu près le nombre d'éléments dont on aura besoin dans un tableau de taille dynamique, on prenne la peine d'indiquer ce nombre dans le constructeur, voire d'appeler la fonction reserve avant de commencer à le remplire?
JadeSalina a écrit:
C'est plutôt à l'appelant de savoir où il veut stocker sa mémoire, s'il donne une arena temporaire, alors c'est temporaire sinon non. Et si on donne à la fonction une "arena" mais qu'elle a envie d'allouer ailleurs, bah déjà c'est pas propre comme façon de faire, et au pire on peut toujours récupérer une autre arena qui a la lifetime voulue.
Le problème, vois tu, c'est que les données temporaires sont forcément liées à des données "plus globales"
D'où viennent, selon toi, les informations qui permettent de créer une donnée temporaire si ce n'est d'une information "plus globale"? Que fait-on -- selon toi -- du résultat obtenu à partir d'une d'une donnée temporaire, si ce n'est l'introduire dans un système de données "plus globales" ?
Les données "globales", peu importe leur niveau de "globalité", et les données locales sont intrincèquement liées, car on ne peut ni créer une donnée temporaire sans aller en cherchere les éléments dans les données globales, ni espérer effectuer une modification importante unique sur une donnée globale sans passer par les temporaires afin d'évaluer les résultats intermédiaires.
Casey l'explique dans la vidéo donnée en lien, pour lui, la bonne approche c'est d'avoir une compréhension globale de tous vos objets a tout moment
Globalement oui c'est un peu ça,
Globalement, l'idée n'est pas mauvaise... Attends d'avoir travaillé -- même pendand deux ans -- sur un projet composé de 170 000 (*) fichiers dont le but est de manipuler des tonnes de données issues de tonnes de sources différentes.
Je suis presque sur que tu nous diras qu'il est souvent impossible d'avoir une compréhension globale de tout nos objets à tout moment. Et je parle d'expérience
(*) D'ailleurs, il te suffira sans doute de travailler sur un projet qui comporte ne serait-ce qu'un petit millier de fichiers pour t'en rendre compte
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Pour simplifier, on va prendre un bloc de 30 octets dont l'adresse commence à 00. On a : un objet A de 10 octets. Un objet B de 20 octets. Un objet C de 5 octets.
Allocation de l'objet A: adresses utilisées: 00 à 09. Allocation de l'objet B: adresses utilisées: 00 à 29 (objets A + B). Destruction de l'objet A: adresses utilisées: 10 à 29. Allocation de l'objet C: Adresses utilisées 00 à 04 et 10 à 29 (tiens ? il y a un trou). Destruction de l'objet B: adresses utilisées: 00 à 04. Allocation de l'objet A: adresses utilisées: 00 à 04 et 05 à 14. Destruction de l'objet C: adresses utilisées: 05 à 14 (tiens ? il y a un trou). Allocation de l'objet B: Crash, il n'y a pas de place pour allouer ce dernier, le plus grand espace disponible fait 15 octets, mais on a besoin de 20).
Les "trous", c'est la fragmentation, et c'est inévitable.
C'est ce que je disais : c'est pas géré du tout. Dans le code donné en lien, il n'y a pas de fonction pour libérer A avant B. Tu peux pas faire ça, donc pas de fragmentation. Il faut libérer dans l'ordre ou tout libérer. Point.
Empêcher la fragmentation n'est pas réellement un bénéfice des arenas (ou autres), c'est avant tout un bénéfice due au fait qu'on a une telle contrainte.
Et sur ce point, c'est vrai : c'est plus performant. On retrouve ca par exemple dans les monotonic allocator de std::pmr.
Casey et Jade pensent que c'est possible, dans 99% des cas, de respecter cette contrainte. Et donc d'utiliser des arenas. Et donc de pas avoir de fragmentation. Et donc d'avoir un code plus performant.
Ce que Casey et Jade ne comprennent pas, c'est pas qu'on n'est pas d'accord qu'un tel pattern est plus performant. C'est qu'on n'est pas d'accord sur le fait que cette contrainte et ce pattern sont utilisables dans 99% dans cas.
Et la discussion avec eux est inutile parce qu'ils considèrent que si on n'est pas d'accord, c'est qu'on n'a pas compris et qu'on est des cons, bloqués dans nos idées du "passé" (sachant que ce genre de pattern n'est pas du tout récent, ils datent de plus de 30 ans). Casey dit que tous les devs sont incompétents.
Il n'y a pas moyens de discuter avec eux, parce qu'ils pensent qu'on est juste idiots. On peut pas les convaincre du contraire.
(D'ailleurs, au boulot, on utilise des arenas et du mode immédiat dans nos codes. Quand c'est pertinent de le faire. Donc l'argument de Jade de dire qu'on n'a pas compris a quel point c'est mieux est complètement idiot, puisqu'on utilise)
koala01 a écrit:
une approche possible, envisagée par une équipe particulière, dans une situation donnée
(...)
(*) D'ailleurs, il te suffira sans doute de travailler sur un projet qui comporte ne serait-ce qu'un petit millier de fichiers pour t'en rendre compte
Une personne seule. Comme pour le projet de Casey.
A titre d'exemple, le code du débuggeur, c'est une centaine de fichiers, de la centaine au millier de LOC.
C'est un petit projet, d'un point de vue pro. Si je compare avec les projets au boulot, on est sur un facteur entre 10 et 50 en termes de LOC. Un tel "petit" projet, c'est un side project ou un POC, dans une équipe de devs pro classique. C'est un projet conséquent pour un dev seul, mais ça reste un projet d'un seul dev, sur une courte période.
koala01 a écrit:
Cela veut dire, pour faire simple, que cette mémoire est réserevée (quoi que cela implique) au niveau ... du fichier pagefile.sys, voire du fichier swapfile.sys (sous windows).
Non. C'est en fait un abus de langage de Jade, c'est pas de la mémoire virtuelle au sens classique. Elle utilise improprement ce terme pour parler de mémoire qui est réservé (ce terme n'est pas non plus a comprendre comme pour std::vector::reserve) mais pas encore utilisée (cf VirtualAlloc dans la doc microsoft).
koala01 a écrit:
Mais, que crois tu? Que tout le monde est incompétent au point de savoir que la mémoire n'est pas une ressource magique qui sort de nulle part?
N'importe quel développeur C++ un tant soit peu habitué sait exactement -- ne serait-ce que dans les grandes lignes -- ce qui se cache derrière un new, un delete, un malloc ou un free
Crois tu vraiment que l'arena est le seul moyen de faire prendre conscience de ce fait? Crois tu vraiment que l'arena est la seule solution?
Oui. Casey et Jade pensent que la majorité des devs sont incompétents. Ca était dit explicitement.
(Bon, Casey ajoute qu'on n'est pas forcément stupide, parce qu'on fait que reproduire ce que font les autres... mais ça fait juste de nous des bons gros moutons sans cervelle)
koala01 a écrit:
Attends d'avoir travaillé -- même pendand deux ans -- sur un projet composé de 170 000 (*) fichiers dont le but est de manipuler des tonnes de données issues de tonnes de sources différentes.
Elle ne le fera pas. Jade a déjà dit qu'elle voulait pas devenir dev pro. Elle veut que cela reste un loisir, pour justement ne pas avoir les contraintes d'un projet pro.
Donc si un jour elle bosse sur un projet, ca restera un projet simpliste, sur du temps libre, seule. Et ne comprendra pas ce qu'on essaie d'expliquer.
Tous d'abord, la reseration d'un bloc mémoire est pris en charge dans la STL, ca s'apelle les "placement new" (relis le Lipmann, c'est dedans).
J'ai l'impression qu'on ne parle pas de la même chose.
Ce bloc mémoire sera géré comme la RAM
Justement non, il sera géré comme la stack, pas avec un allocateur générique qui va essayer de trouver de la place, compacter les espaces libres lors de libérations, et autres joyeuseutés qui prennent du temps pour rien. Le but est justement de ne pas avoir besoin de faire ça, ni de désallouer en plein milieu (ce qui entrainerait un trou).
koala01 a écrit:
A ce stade, il faut commencer à faire attention, car la sénilité précoce commence à tout age...
Ma phrase était tournée pour titiller votre attention, mais le propos complet est que oui le RAII est très utile quand on fait les choses de façon classique (allouer/désallouer individuellement), mais qu'il devient moins intéressant quand on repense entièrement la façon de gérer les allocations avec par exemple des arenas.
Cela n'aura que peu d'importance dans le cadre d'un débugger [...] Mais lorsque tu travailles sur un jeu video et que tu n'as que 0.016 seconde pour faire tout ce que tu as à faire
Je rappelle quand même que c'est avec Handmade Hero et donc un jeu que j'ai entendu parler pour la première fois des arenas, et on me répondait justement que « Oui mais c'est un jeu c'est pas une vraie application, on peut pas faire ça en pratique », et là maintenant vous voulez dire que « oui on peut faire ça dans un debugger mais c'est pas une vraie application critique ». Casey appelle ça "the excuse parade" (cherchez ses tweets avec le mot “excuse”), c'est assez comique
Pourquoi crois tu que, lorsque l'on sait à peu près le nombre d'éléments dont on aura besoin dans un tableau de taille dynamique, on prenne la peine d'indiquer ce nombre dans le constructeur, voire d'appeler la fonction reserve avant de commencer à le remplire?
Et ce n'est pas mal en soi de faire ça, tout comme le SSO, mais encore une fois ce sont des solutions à des problèmes qui n'existent pas avec les arenas.
gbdivers a écrit:
C'est qu'on n'est pas d'accord sur le fait que cette contrainte et ce pattern sont utilisables dans 99% dans cas.
Je vous accorde que ce n'est pas facile à imaginer, moi-même il m'a fallu du temps, et ce debugger m'a permis de comprendre encore un peu mieux le concept, c'est la première fois que je vois ça appliqué sur un vrai projet, absolument personne n'en parle. On nous dit de créer nos objets, qui contiennent des vector, string, qui seront ensuite libéré à la fin du scope, globalement on a en permanance une problématique d'ownership, et après on nous dit que s'il y a des problèmes de performance, on peut toujours changer l'allocateur sous jacent en utilisant un operator new custom pour telle classe par exemple. L'idée des arenas change radicalement la façon de penser, qui ne tourne plus autour de chaque objet individuel, et comme le disait Casey dans l'extrait que j'ai donné, avec les arenas, “ownership is obvious and trivial in 99% of cases” (après c'est un chiffre qui sort de nulle part mais c'est pour donner l'idée).
Elle utilise improprement ce terme pour parler de mémoire qui est réservé
Voilà c'est exactement ça, je bien parle de réservé au sens de VirtualAlloc
Il n'y a pas moyens de discuter avec eux, parce qu'ils pensent qu'on est juste idiots. On peut pas les convaincre du contraire.
Je ne pense pas que vous soyez idiots, tout ce que je pense c'est que vous êtes trop « attachés » à la façon moderne de faire au point que vous ne pouvez pas bien envisager de faire les choses différemment. Les arenas ce n'est vraiment pas juste un allocateur, ça change fondamentalement la façon de faire, au point où on n'a plus besoin de classe “vector” ou “string”, plus besoin que chaque objet gère individuellement ses données, tout se simplifie.
Mais en fait je me demande pourquoi je me fatigue à expliquer, je suis cruche des fois, justement la personne qui est derrière ce debugger a écrit une explication avec des mots simples sur le raisonnement derrière les arenas, ce que ça apporte, pourquoi malloc/free c'est moisi, pourquoi le RAII et autres ne sont pas vraiment la bonne solution, en fait il y a tout ce dont vous avez besoin pour comprendre ici : https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator
on me répondait justement que « Oui mais c'est un jeu c'est pas une vraie application, on peut pas faire ça en pratique »
Je vais encore répéter, même si je pense que ça sert à rien, parce que tu ne veux pas comprendre.
On t'a dit que c'était pas applicable partout, tout le temps.
C'est toi qui lit systématiquement ce qu'on écrit de travers, comme ça t'arrange. C'est pas simplement qu'on n'est pas d'accord, c'est que tu es juste de mauvaise foi (ou trop butée dans tes idées pour comprendre).
JadeSalina a écrit:
c'est que vous êtes trop « attachés » à la façon moderne de faire au point que vous ne pouvez pas bien envisager de faire les choses différemment.
Encore une fois, ton raisonnement est stupide (j'ose le mot).
1. parce c'est pas du tout nouveau. D'après wiki, les articles qui parlent de ce type de technique datent des années 80, donc il y a plus de 40 ans ! C'est même le fonctionnement classique pré-système d'exploitatio, pré-ordinateur "moderne".
2. c'est dans le standard C++. Ca n'est pas du tout quelque chose d'inconnu, de fondamentalement différent, de quelque chose de tellement révolutionnaire qu'on aurait du mal à accepter ce concept. Il y a des blogs sur le sujet et même des talks à la CppCon.
C'est tout le contraire. C'est un concept ancien, bien connu et largement utilisé. Le concept même de std::vector, qui peut reserver de la mémoire et simplement ajouter des éléments a la fin de la zone utilisé, est en fait un exemple de buffer linéaire comme les arénas.
Je trouve ce sujet intéressant, même si je développe très rarement en C++ (utilisé pour créer des modules python dans mes projets) et plus souvent en C pour les mêmes raisons.
ça change fondamentalement la façon de faire, au point où on n'a plus besoin de classe “vector” ou “string”, plus besoin que chaque objet gère individuellement ses données, tout se simplifie.
J'ai pas compris, quel est l'avantage de ne plus savoir sur quel objet on travaille ? À savoir que je me suis très peu renseigné sur le sujet, je suis la discussion en diagonale, j'ai donc peut-être zappé un point important dans celle-ci.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
quel est l'avantage de ne plus savoir sur quel objet on travaille ?
L'avantage n'est pas là.
L'avantage, c'est que comme l'allocation de la mémoire se fait sur un buffer préalloué, il n'y a plus d'allocations ensuite (ce qui est couteux). Et donc on gagne en performances, du fait que l'on évite les allocations.
Il y a pleins de méthodes pour éviter les allocations. Par exemple, avec std::vector, on va conseiller d'utiliser std::vector::reserve() avant de faire des push_back, pour allouer dès le départ un buffer assez grand et éviter les allocations et copies pendant qu'on ajoute des éléments au vector.
Dans le cas des arénas, c'est qu'on appelle un buffer linéaire : on ajoute les éléments a la fin (un peu comme un FILO) et on libère tout d'un bloc. Ce qui permet aussi d'éviter des allocations. Mais cette approche (comme les autres approches de gestion de la mémoire) a des avantages et défauts. Par exemple, pour les arénas, on peut pas supprimer des éléments s'ils ne sont pas à la fin du buffer (on parle aussi de buffer monotonique). Il faut également que les classes soient trival constructible et destructibles (ce qui est toujours le cas en C, mais pas en C++). Cela implique également de gérer la mémoire manuellement, ce qui complique les choses dans la majorité des cas.
Bref, c'est juste un moyen, parmi d'autres (cf par exemple les pool allocators, les stack allocators, les buddy allocators, etc), chacun avec des avantages et défauts. Et donc avec chacun ses domaines d'applications. On va par exemple utiliser souvent de genre d'approche en programmation embarqué, parce que sur les micro systèmes, la mémoire est critique et cela tourne souvent sans système d'exploitation, en mono process. Ou pour la programmation graphique, parce qu'il est plus efficace d'envoyer un buffer complet au GPU, plutôt que faire des petites allocations mémoire (à cause de la latence et le débit de transfert avec le GPU).
Je vais essayer de reprendre les propos de @JadeSalina sans les dénaturer.
@JadeSalina met en avant le concept d'arena, qui est vieux comme le monde, même avant le C, t'imagine, qui est "plus performant" que toutes ces cochonneries "new age" du C++- comme l'allocateur "standard" ou les pointeurs intelligents.
Nous, on lui dit juste que c'est plus compliqué à utiliser et que cela n'est pas adapter à 100% des cas.
@fred1599, rien ne t'empêche de jeter un œil sur ces concepts comme arena ou memory pool, c'est des concepts intéressants et efficaces dans les cas qui vont bien. (Pas dans 100% des cas)
Comme l'indique @JadeSalina, les utiliser demande à changer de paradigme de penser par rapport à des outils "plus répandus".
>J'ai pas compris, quel est l'avantage de ne plus savoir sur quel objet on travaille ?
Ce n'est pas le cas dans une arena, on travaille toujours au niveau de "l'objet", c'est juste la manière d'obtenir "sa" mémoire qui change.
Il y a des paradigmes qui déstructure le concept d'objet, comme dans un ECS, mais là, c'est même pas le cas.
Mais bon, on est trop con pour voir tout le potentiel quasi mystique d'une arena, nous, pauvres pisseurs de code "moderne".
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Le monotonic buffer ( https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource ) n'est pas strictement une arena, c'est ce qui se passe dans 1 arena. On peut voir cela comme une arenas allocator, avec une seule arena. Les areneas, c'est plusieurs blocs monotoniques, quand on arrive a la fin d'un bloc (une arena), on en ajoute un nouveau et on continue avec.
A voir aussi, tous les flat containers de boost, qui sont des implémentations des containers classiques mais avec la mémoire qui est dans un buffer contiguë, plutôt que pleins de petites allocations dynamiques. https://www.boost.org/doc/libs/1_49_0/doc/html/container/non_standard_containers.html. Ce le même principe, mais appliqué individuellement sur un container.
JadeSalina a écrit:
Deedolith a écrit:
Tous d'abord, la reseration d'un bloc mémoire est pris en charge dans la STL, ca s'apelle les "placement new" (relis le Lipmann, c'est dedans).
J'ai l'impression qu'on ne parle pas de la même chose.
C'est un lié, dans le sens où le placement new est un moyen de construire un objet à un endroit de la mémoire. Quand on utilise un objet non trivial constructible en C++ avec une gestion manuelle de la mémoire (arena ou autre), il faudra faire cela pour construire correctement l'objet. La doc de placement new prend justement comme exemple un objet construit dans un buffer https://en.cppreference.com/w/cpp/language/new#Placement_new
Dans les exemples d'implémentation d'aréna donné par Jade, ils ne font pas cela parce que c'est des codes en C, qu'il n'y a pas de constructeurs a appeler, ni de new. Mais si c'est des objets qui ont besoin d'être initialisé avant utilisation, il faudra quand même appeler manuellement les fonctions d'initialisation.
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Si vous ne trouvez plus rien, cherchez autre chose.
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Si vous ne trouvez plus rien, cherchez autre chose.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Discord NaN. Mon site.
Discord NaN. Mon site.