Merci pour vos réponses et vos sources ! Comme je l'ai exprimé précédemment ce sujet m'intéresse... je vais sans doute revenir plus tard après lectures et écoutes sur le sujet, mais je peux déjà conclure sur une partie du sujet : Ça dépend du domaine d'applications (qui est aussi le cas en python et je pense dans quasi tous les langages pour divers sujets techniques). Question de recul et d'expériences, en python, beaucoup de sujets techniques amènent à ce type de discussion, avec toujours la même conclusion.
Donc à plus tard sans doute pour des questions techniques, mais peut-être plus indirectes au sujet principal.
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)
On t'a dit que c'était pas applicable partout, tout le temps.
Oui ce n’est pas applicable strictement partout, je n’ai jamais dit le contraire, ce que je dis c’est que c’est applicable dans la majorité des cas.
parce c'est pas du tout nouveau
Si justement, ce dont je parle est bien nouveau, il ne s’agit pas de juste faire un memory pool occasionnellement ou de faire un reserve avec std::vector, c’est vraiment une approche architecturale différente.
qui est "plus performant" que toutes ces cochonneries "new age" du C++- comme l'allocateur "standard" ou les pointeurs intelligents.
C’est pas tellement le C++ la cochonnerie, au contraire c’est beaucoup mieux que de les vieux Malloc/free du C, ce que je veux dire surtout, c’est qu’on peut faire mieux que ça, les RAII / smart pointers c’est une manière propre de faire un truc moisi, mais pourquoi ne pas faire quelque chose de propre en premier lieu ? C’est là que les arenas interviennent. Il faut absolument que vous lisiez ça tranquillement à tête reposée : https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator
Parce qu’on est quand même d’accord sur le fait que des pool allocators et autre peuvent être intéressants dans certains cas mais il vous manque un ingrédient qui permet de comprendre comment passer de "c’est un outil utile occasionnellement" à "on utilise des arenas pour pratiquement tout et ça fait mieux le job à tout point de vue (simplicité du code, maintenabilité, performance, …)". La réponse se trouve dans cet article, et c’est expliqué simplement et bien mieux que tout ce que j’essaie de dire depuis tout ce temps.
Parce que c'est bien gentil de vouloir venir nous donner des "conseils", mais, et si tu les appliquais à ton propre code ? Comme ça t'auras un code top moumoutte performances maximales surpuissant, et ce sera cool...
Si vous ne trouvez plus rien, cherchez autre chose.
Parce qu’on est quand même d’accord sur le fait que des pool allocators et autre peuvent être intéressants dans certains cas mais il vous manque un ingrédient qui permet de comprendre comment passer de "c’est un outil utile occasionnellement" à "on utilise des arenas pour pratiquement tout et ça fait mieux le job à tout point de vue (simplicité du code, maintenabilité, performance, …)". La réponse se trouve dans cet article, et c’est expliqué simplement et bien mieux que tout ce que j’essaie de dire depuis tout ce temps.
En fait, quand tu écris "Il vous manque", tu pars du principe que tu détiens la vérité, et que nous on est trop bête pour ne pas l'avoir vu mais que tu es là pour nous éclairer.
Pour ma part, je regarde d'abord à quel problème j'ai à faire, et ensuite je cherche une méthode efficace pour résoudre CE problème.
Et du coup, je rejoins dragonjoker sur sa question : qu'est ce que TOI, JadeSalina, a codé dernièrement qui illustrait parfaitement ce que tu veux nous vendre ?
(...) il vous manque un ingrédient qui permet de comprendre c
"Si, si, j'insiste : si vous n'êtes pas d'accord, c'est que vous n'avez pas compris. Vous êtes trop cons pour accepter cette nouveauté (qui date d'il y a 30 ans...)"
Bon, sérieusement, va bosser sur des projets.
Heureusement que ce type de discussion n'est pas inutile pour tout le monde (poke fred1599)
J'ai lu attentivement les vidéos, mes compétences techniques en C++ ne sont pas suffisantes, mais voilà ce que j'ai pu comprendre :
Les PMR sont suffisamment flexibles pour être configurer et se comporter comme des arenas.
Les PMR semblent offrir une couche d'abstraction et de flexibilité supplémentaire qui va au-delà de la simple gestion d'une arena de mémoire.
Ça ne semble pas entrer dans mes besoins, nous avons des modules comme pandas, numpy, ... sont optimisés pour la manipulation de grandes données, avec des techniques comme la gestion efficace des tableaux sous-jacents et la possibilité de charger des données de manière incrémentale ou en utilisant des types de données catégoriels pour économiser la mémoire.
Cela pourrait être pertinent pour des cas d'utilisation très spécialisés ou des calculs intensifs sur des ensembles de données extrêmement volumineux, mais à partir de quel niveau, je ne sais pas, car je n'ai jamais été limité et j'ai toujours pu optimiser (threads, multiprocessing, ...)
En python on cherche simple, lisible, et là très clairement, l'utilisation des PMR apporteraient une couche de complexité dont le jeu n'en vaudrait pas la chandelle, à tel point qu'il vaudrait mieux développer en Full C++.
Et donc on en revient à la conclusion : ça dépend du domaine d'application.
P.S intéressant la méthode emplace_back à comparer avec push_back, je ne connaissais pas.
Est-ce que je suis dans le vrai ?
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)
Ça ne semble pas entrer dans mes besoins, nous avons des modules comme pandas, numpy, ... sont optimisés pour la manipulation de grandes données, avec des techniques comme la gestion efficace des tableaux sous-jacents et la possibilité de charger des données de manière incrémentale ou en utilisant des types de données catégoriels pour économiser la mémoire.
Globalement, ça me surprend pas comme conclusion, sans connaitre spécifiquement tes besoins. Les pmr sont des cas d'utilisation très spécifiques.
J'ai bossé aussi sur du calcul intensif (mais avec R, pas Python) et des gros volumes de données (centaines de Go à To). Et la stratégie de simplement éviter les allocations multiples suffisait (dans mon cas, je chargeais juste un gros bloc de données en mémoire en 1 seule fois et je bossais dessus. Et quand j'avais fini, je chargeais le bloc suivant). J'avais split le pré-traitement des données (gros volume, en C++) et l'analyse proprement dite (volume de données réduit après le pré traitement, en R).
Il est assez difficile de donner des cas d'utilisation concret des pmr dans des vrais codes, parce que c'est extrêmement contextuel. Et il est difficile de savoir a l'avance le gain exacte et si c'est pertinent (en comparaison avec d'autres techniques de buffers, comme par exemple juste resize un vector a la bonne taille). Pour cela qu'on conseille en general d'avoir un premier code qui marche et qui est propre, de façon a faire des tests de performances et avoir un code qui se change facilement pour tester différentes approches.
Pour emplace_back, cela évite, quand tu veux créer un nouvel objet, de devoir le créer puis de le déplacer dans le container.
Pas grand chose en ce moment, je n'ai pas le temps à vrai dire, je dois d'abord propager la bonne parole parce que justement je ne veux pas garder tout ça pour moi, je préfère partager pour que d'autres puissent en profiter.
Fvirtman a écrit:
En fait, quand tu écris "Il vous manque", tu pars du principe que tu détiens la vérité, et que nous on est trop bête pour ne pas l'avoir vu mais que tu es là pour nous éclairer.
Vous semblez dire péjorativement que vous êtes trop bêtes et que vous avez besoin d'être éclairés, mais ce n'est pas si péjoratif que ça, c'est même une situation banale qui arrive fréquemment, par exemple un chercheur qui teste des choses inexplorées peut finir par faire une découverte et il va donc pouvoir "éclairer" les autres sur ça mais ça ne veut pas dire du tout que les autres sont bêtes.
Fvirtman a écrit:
Et du coup, je rejoins dragonjoker sur sa question : qu'est ce que TOI, JadeSalina, a codé dernièrement qui illustrait parfaitement ce que tu veux nous vendre ?
Si vous voulez un exemple qui illustre tout ça, vous avez justement RAD debugger qui est fait par la même personne qui a écrit l'article donc vous pouvez voir le résultat appliqué en pratique.
gbdivers a écrit:
"Si, si, j'insiste : si vous n'êtes pas d'accord, c'est que vous n'avez pas compris. Vous êtes trop cons pour accepter cette nouveauté (qui date d'il y a 30 ans...)"
Encore une fois, je ne dit pas que qui que ce soit est c*n, si on ne travaille pas sur un sujet, c'est normal que ceux qui travaillent dessus peuvent apporter des infos que les autres n'ont pas, ce n'est pas du tout être bête. Et il y a plein d'exemples de papiers qui ont en quelque sorte apporté une petite révolution et qui sont considérés comme des références, même si le truc en question vient d'une seule personne au fin fond de son garage. Ca ne veut pas du tout dire que tous les autres sont des idiots.
Par contre je maintiens que tant que vous n'aurez pas lu l'article (https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator) vous ne pourrez pas "comprendre" ce que je veux dire. L'ingrédient manquant ce n'est pas le concept d'allouer des données à la suite dans des pool ou autre, c'est la façon d'utiliser des arenas pour gérer pratiquement toute la mémoire du programme et surtout de se rendre compte que ça fonctionne très bien et qu'on peut se passer du RAII pour la gestion mémoire, c'est ça qui est récent et que je n'ai vu que dans Handmade Hero. La preuve que c'est récent, vous dites que c'est trop limité car ça alloue/désalloue uniquement à la fin alors que justement ça fonctionne très bien dans "99% des cas", parce que oui, ça parait contre intuitif, mais il faut juste creuser un peu pour "voir le truc" et l'article donne les explications nécessaires.
Si vous ne voulez pas appliquer ce qui est dit dans l'article, ça n'est pas un problème du tout vu que le C++ apporte des solutions pour la gestion mémoire (RAII / smart pointers) et même si ça part pas forcément sur les bonnes bases, ça fait quand même le job et on peut contextuellement faire mieux si besoin (par exemple stocker les objets dans un std::vector plutôt que faire un std::make_unique pour chacun). Donc oui on peut s'en sortir sans arena, mais c'est vrai que j'en vois certains en C++ qui se compliquent la vie en faisant des choses très lourdes alors qu'une arena résoudrait le problème facilement, donc c'est quand même bien de savoir au moins d'avoir ce genre de technique en tête (je parle de ce qui est dit dans l'article, pas de juste faire un pool allocator classique d'il y a 30 ans).
Par contre pour ceux qui sont en C, là vous n'avez vraiment pas d'excuse et ça en devient presque ridicule, parce que certes on peut cracher sur le C++ mais au moins il apporte une solution (bien que pas forcément la bonne), mais si vous êtes encore en train de malloc/free vos objets individuellement à la main en C, franchement faites vous une faveur et lisez l'article.
Je ne veux pas entrer dans ces discussions, les interprétations sur les forums sont toujours complexes, bref c'est pas toujours simple de se comprendre, même quand on croît être clair. Il n'y a pas de mauvaises compréhensions, que de mauvaises explications !
-------------
Ce que je souhaiterai si possible (n'hésite pas à me dire si c'est pas faisable) que tu puisses m'apporter un exemple avec deux codes minimaux (RAII et arena) apportant un avantage visible pour arena. Peut-être faudra-t-il le démontrer via un scénario de tests, un benchmark, utilisation d'outils de profilage, etc... ? Tu dois être bien meilleur que moi en C++, je l'utilise peu !
Aussi le côté lisibilité et complexité, car la facilité à maintenir un code est extrêmement important !
On pourrait aussi analyser l'empreinte mémoire, etc...
Bref la preuve par le code, la pratique, il n'y a que ça de vrai !
EDIT: @gbdivers,
Toutes mes excuses, merci pour ta réponse
Pour emplace_back, cela évite, quand tu veux créer un nouvel objet, de devoir le créer puis de le déplacer dans le container.
puis-je reformuler cette phrase par : Pour emplace_back, cela évite, quand tu veux ajouter un nouvel objet, de devoir le créer puis de le déplacer dans le container.
- Edité par fred1599 26 janvier 2024 à 19:36:54
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)
Je lis et regarde systématiquement les liens que tu donnes. Je ne donne pas mon avis sans avoir avant regardé tes arguments, ça n'aurait pas de sens.
Donc je te confirme, au cas où ce n'était pas clair : j'ai regardé l'article et je pense que tu es quand même à coté de la plaque. Et je rappelle (je l'ai déjà dit) qu'on utilise ce type d'approche à mon boulot, quand c'est pertinent.
JadeSalina a écrit:
un chercheur qui teste des choses inexplorées peut finir par faire une découverte et il va donc pouvoir "éclairer" les autres sur ça
Sauf que tu es à coté de la plaque :
1. ce n'est pas un chercheur. (Le problème n'est pas qu'il n'a pas le status de chercheur, c'est surtout qu'il en a pas la démarche)
2. c'est pas du tout inexploré, c'est des vieilles techniques.
3. il n'éclaire rien du tout, parce qu'il n'y a pas d'argument autre que "ma propre estimation personnelle est que c'est utilisable dans 99% des cas".
JadeSalina a écrit:
je dois d'abord propager la bonne parole parce que justement je ne veux pas garder tout ça pour moi, je préfère partager pour que d'autres puissent en profiter.
que vous avez besoin d'être éclairés
il va donc pouvoir "éclairer" les autres sur ça
quelque sorte apporté une petite révolution
vous ne pourrez pas "comprendre" ce que je veux dire
pour "voir le truc"
Tu es juste une idiote de fanatique. Tu es une croyante convaincue d'une chose et veut que tout le monde pense comme elle.
Mais tu n'as aucune chance de nous convaincre de cette façon. On n'est pas dans une démarche idéologique. On regarde tes arguments et ils ne sont juste pas convainquant. Tu perd ton temps à répéter encore et encore la même chose, en espérant que ton insistance finisse par convaincre.
En reprenant le petit concours que j'avais posté il y a quelques années (Concours - sudoku par Deedolith - page 1 - OpenClassrooms), choisit un source (il y en a plusieurs proposés), adapte le avec une (ou plusieurs) arena, et on compare les perfs.
Pas grand chose en ce moment, je n'ai pas le temps à vrai dire, je dois d'abord propager la bonne parole parce que justement je ne veux pas garder tout ça pour moi, je préfère partager pour que d'autres puissent en profiter.
Fvirtman a écrit:
En fait, quand tu écris "Il vous manque", tu pars du principe que tu détiens la vérité, et que nous on est trop bête pour ne pas l'avoir vu mais que tu es là pour nous éclairer.
Vous semblez dire péjorativement que vous êtes trop bêtes et que vous avez besoin d'être éclairés, mais ce n'est pas si péjoratif que ça, c'est même une situation banale qui arrive fréquemment, par exemple un chercheur qui teste des choses inexplorées peut finir par faire une découverte et il va donc pouvoir "éclairer" les autres sur ça mais ça ne veut pas dire du tout que les autres sont bêtes.
Fvirtman a écrit:
Et du coup, je rejoins dragonjoker sur sa question : qu'est ce que TOI, JadeSalina, a codé dernièrement qui illustrait parfaitement ce que tu veux nous vendre ?
Si vous voulez un exemple qui illustre tout ça, vous avez justement RAD debugger qui est fait par la même personne qui a écrit l'article donc vous pouvez voir le résultat appliqué en pratique.
En quoi ce debuggueur illustre quoique ce soit par rapport à l'utilisation mémoire ?
Donne nous un code imparable pour tenter de nous prouver que ton concept est mieux (mais par contre, ne prend pas un code écrit n'importe comment avec des shared_ptr pour nous faire croire que le soucis vient des shared_ptr).
Sinon, c'est ce que je pensais : tu ne programmes rien, et tu viens pour.... je cite et j'ai mis en gras "propager la bonne parole" ?
Vraiment, c'est une secte Casey ? Il sait qu'il a un groupie aussi fanatique ? Je suis sûr que même lui ça lui ferait peur de voir qu'un mec comme toi s'amourache de cette manière à lui !
En quoi ce debuggueur illustre quoique ce soit par rapport à l'utilisation mémoire ?
Il montre que ça fonctionne très bien d’utiliser des arena pour à peu près tout contrairement à ce que certains prétendent. Car justement quel est le type d’allocateur qui est le plus utilisé et qui est celui que tout le monde préfère ? La pile du programme ! 🙂
Donc c’est tout à fait logique de prendre ce principe de stack allocator et de simplement lui permettre de conserver des données au delà du scope de la fonction, au lieu de systématiquement utiliser l’allocateur générique (malloc).
Par exemple c’est très moche d’utiliser l’allocateur générique pour certaines opérations temporaires comme « formater une chaîne » ou « convertir une chaîne de utf8 vers utf16 juste avant de la passer en paramètre », ça serait plus performant et plus intelligent d’utiliser une arena spécialement pour les opérations temporaires. Alors d’accord ça oblige à passer un paramètre de plus :
auto str = format(temp_arena, "hello {}!", name);
mais ça en vaut la peine car c’est fondamentalement plus performant. Il y a même des langages (Jai et Odin) qui permettent de passer implicitement un "contexte" qui contient entre autre l’allocateur à utiliser, ce qui fait que l’on peut avoir du code optimal tout en n’ayant pas besoin de le passer explixitement.
Je vous ai fait passer les informations , ça ne sert à rien que je continue à essayer de vous convaincre, faites ce que je voulez ce n’est pas grave, il est temps pour moi de rendre le tablier. Tant que vous avez besoin de moi mais que vous ne voulez pas de moi , je reste, mais quand vous voulez de moi mais que vous n’avez plus besoin de moi, je part.
Je vous ai fait passer les informations , ça ne sert à rien que je continue à essayer de vous convaincre, faites ce que je voulez ce n’est pas grave, il est temps pour moi de rendre le tablier. Tant que vous avez besoin de moi mais que vous ne voulez pas de moi , je reste, mais quand vous voulez de moi mais que vous n’avez plus besoin de moi, je part.
Partager des informations est toujours intéressant.
Répéter encore et encore les mêmes choses, en espérant que les gens changent d'avis et en prenant les gens pour des idiots s'ils ne sont pas d'accord, c'est très chiant.
Par exemple, dans ton dernier message, tu ne réponds absolument pas à la question, autrement qu'en répétant les mêmes arguments, sans preuve. Quand tu dis par exemple "ça serait plus performant", tu n'as aucune preuve de cela. Montre nous un benchmark qui montre que cela a un impact significatif sur les performances du raddebugger, comparé avec d'autres approches (malloc, pile, etc en C++). Sans cela, tes arguments sont juste du vide, c'est juste "trust me bro".
Donc tant que tu ne seras pas prête a réellement vouloir dialoguer, il est effectivement mieux que tu partes.
(J'ajouterais même que les benchmarks il y en a eu sur ce forum, et qu'ils ne démontraient pas de bénéfice particulier, encore moins par rapport à la charge que cela apporte).
> Vous semblez dire péjorativement que vous êtes trop bêtes et que vous avez besoin d'être éclairés, mais ce n'est pas si péjoratif que ça, c'est même une situation banale qui arrive fréquemment, par exemple un chercheur qui teste des choses inexplorées peut finir par faire une découverte et il va donc pouvoir "éclairer" les autres sur ça mais ça ne veut pas dire du tout que les autres sont bêtes.
Justement, le chercheur qui trouve un truc, il présente ses découvertes à ses pairs, reçoit des critiques. Il arrive qu'on lui dise que ce travail avait déjà été fait (à peu près) par d'autres personnes, que ses résultats ne sont pas applicables en pratique, etc. Et tu sais quoi ? Le chercheur fait un truc incroyable... Il prend les critiques en compte ! Il peut discuter pour dire qu'il trouve que certaines remarques ne sont pas réellement fondées, mieux expliquer certains trucs, mais globalement il les prend en compte.
Là, voici ce que tu as fait en tant que chercheuse : regardez cette technique, elle est géniale et applicable quasiment tout le temps vu que ce jeu l'utilise.
Les réponses : mouais, on connaît depuis longtemps, mais, c'est pas applicable tout le temps, on l'utilise quand on en a besoin et voilà, tu as des arguments pour dire que c'est applicables presque tout le temps ?
Ta réponse : mais si, regardez, il dit que c'est applicable tout le temps, vous avez juste pas compris comment la mettre en place. Et regardez, voici un autre projet qui l'utilise. La preuve qu'on peut l'appliquer.
Un autre projet qui utilise les memory pool, ça montre pas que c'est applicable tout le temps. Ça montre, au mieux, qu'il y a des projets avec des contraintes qui font que c'est une bonne idée, et ça c'est vrai, personne n'a dit le contraire. Tout comme certaines contraintes font que le C++ est un meilleur langage que d'autres pour certains projets. Et pourtant, tu ne vas pas sur les autres forums dire aux gens qu'ils font de la merde à utiliser Python ou autre, et qu'ils feraient mieux de passer à C++ + memory pool, alors même qu'avec tes deux exemples, on a une preuve que c'est le meilleur choix pour quasiment tous les projets... Je pense que tu devrais étendre ta croisade et aller convertir tous les infidèles des autres langages...
Tant que vous avez besoin de moi mais que vous ne voulez pas de moi , je reste, mais quand vous voulez de moi mais que vous n’avez plus besoin de moi, je part.
V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style. There are 4 ways to manage memory in V. The default is a minimal and a well performing tracing GC. The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object. Autofree is still experimental and not production ready yet. That's planned for V 1.0. For developers willing to have more low level control, memory can be managed manually with -gc none. Arena allocation is available via v -prealloc
Pour être honnête, je sais pas très bien ce que l'on peut faire de cette information. Qu'un GC utilise des pré allocations, c'est pas trop une surprise. Cette information n'apporte pas grand chose à la discussion.
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)
Si vous ne trouvez plus rien, cherchez autre chose.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
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.
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.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.