Je voulais revenir sur l'argument plus haut "les unique_ptr c'est moins performant", et mettre un gros doute dessus.
Si je ne dis pas de bêtise, on doit avoir des implémentations du style :
template <typename T>
class unique_ptr
{
private:
T* pointeur;
// constructeur par recopie et operateur = en private
public
// un constructeur
// un destructeur qui appelle delete
une surcharge de -> et *
};
Si c'est bien ça, alors c'est à la compilation et uniquement à la compilation que les tests sont faits pour voir si on ne recopie pas (on appelle un constructeur par recopie ou un opérateur = en private)... et le compilo est assez intelligent pour inliner les operateurs -> et * ainsi que les autres méthodes.
Si bien que je pense sans dire de conneries qu'une fois compilé, un unique_ptr est juste un pointeur nu. C'est juste le compilo qui a testé la non recopie, et placé le delete lors de la destruction.
Donc pour moi, niveau perf, c'est strictement pareil.
moi franchement j'ai été subitement convaincu par l'argumentaire qui tue tout : les arena c'est mieux. Rien à redire.
Voilà, je me casse la tête pour expliquer des trucs alors que finalement les arguments les plus simples sont les meilleurs
Mais sinon il a quand même dit un truc vrai le robot, c'est que ça permet plus de flexibilité. Avec les unique_ptr, si on veut changer un noeud il faut le détruire, libérer la mémoire et faire une copie du noeud qu'on veut mettre, alors qu'avec l'autre manière on peut directement mettre le pointeur. Alors ok ça change pas grand chose dans le code ("noeud->fils = autre_noeud" au lieu de "noeud->fils = copy(autre_noeud)") mais pour le CPU ça fait quand même moins de choses à faire. Mais c'est pas ça le plus dommage, au pire on fait une copie pour rien et puis voilà c'est pas grave mais imaginez (je sais pas comment marche le compilateur mais imaginez) qu'on ait envie que des noeuds soient partagés, pour que quand on modifie l'un ça modifie l'autre, dans ce cas avec les unique_ptr il va falloir faire une synchronisation manuelle au lieu que ça se fasse tout seul (sinon il faudrait utiliser des shared_ptr mais là on sentirait passer la perte de performance je pense).
Après il y a quand même une chose que je me suis rendue compte en voyant le projet de Lynix c'est que c'est peut-être intéressant de se concentrer sur les fonctionnalités avant de penser à la performance du truc sinon on reste bloqué dans des détails techniques. Par exemple une fois je voulais retrouver des objets à partir d'un nombre qui pouvait être 23 comme 9374898237 du coup je pouvait pas les mettre dans un tableau. Donc il a fallu que je réfléchisse à une fonction de hashage, à où stocker les données, à qui allait les libérer et quand alors que j'aurais pu directement utiliser un unordered_set et "call it a day" comme dit Casey (https://guide.handmadehero.org/code/day508/#8650)
Mais c'est de la fégnardise, c'est pas du travail bien fait je trouve mais c'est vrai qu'il y a un certain attrait dans cette solution de "facilité".
Mais de toute manière je préfère quand même quand les choses sont simples, au niveau de ce que fait le processeur, pas forcément au niveau du code, j'aime cette légèreté, de ne pas me dire que je gache des cycles CPU à faire des allocations et désallocations à tout va, et tant pis si le code est moins clair. Et puis pourquoi vous voulez absolument forcer les gens à faire comme vous voulez ? Si on préfère faire d'une autre manière c'est notre droit c'est pas la peine de nous bruler sur le bucher quand même.
nours59 a écrit:
Nous choisissons d'utiliser les unique_ptr, car bien qu'à priori ils soient légèrement moins performants
On est bien d'accord que ce qui est moins performant dans les unique_ptr c'est l'usage que ça fait faire, à savoir allouer et désallouer à tout va, faire des copies superflues etc, je n'ai pas dis que le unique_ptr en lui-même était moins performant. Si pour une raison x ou y je devait implémenter un pattern PIMPL, au lieu de faire un new dans le constructeur et delete dans le destructeur, j'aurais mis un unique_ptr et dans ce cas j'espère bien que le code généré est le même sinon le compilateur je le jette aux ordures avec les rats
- Edité par JadeSalina 15 décembre 2022 à 23:32:29
Le destructeur fait que le type n'est plus trivial, et du coup ça coute un chouila plus cher au déplacement dans les vecteurs p.ex. Rien qui ne peut être solutionné par des boost::ptr_vector. EDIT: Dans un scénario de push_back, la faute au mauvais réserve. Dans un scénario de tri... l'indirection va couter tellement plus cher AMA (je dis ça au pif, et dehors il fait froid), qu'OSEF aussi.
Quant au surcoût sur les fonctions puits et/ou source (j'ai oublié le détail) on s'en fout un peu un fait. Car si l'unique_ptr circule de la source au puits... c'est dans un chemin fini et négligeable par rapport aux prix des acquisitions et des restitutions.
EDIT-PS: quant au "ça pousse à faire des allocs". Non et non. Le chemin moderne en C++ consiste à maximiser l'utilisation de valeurs. Pas de trucs acquis avec indirection. L'unique_ptr va servir pour donner des garanties de restitution quand on n'a pas le choix. (je sais, je radote...). L'unique_ptr n'est pas une cause. C'est une conséquence. On n'est pas dans "je veux un unique_ptr donc j'alloue". On est dans "bordel, j'ai besoin d'allouer, bon ben ... unique_ptr donc". Ne pas confondre causes et conséquences.
Je voulais revenir sur l'argument plus haut "les unique_ptr c'est moins performant", et mettre un gros doute dessus.
ChatGPT dit que cela "peut", pas l'affirmatif. Je suppose (sans avoir testé en détail sur toutes les implémentations) que dans certains cas particuliers (par exemple avec un deleter personnalisé), il peut y avoir une perte de performance pour certaines opérations (copy/move du pointeur par exemple)
Mais globalement oui, dans la très grande majorité des cas, il n'y aura pas de coût supérieur a un pointeur nu. Au pire, dans les codes critique, on va tester pour être sur.
Non mais JadeSalina fait un biais de confirmation , elle regarde que les arguments qui va dans son sens (tiens clang à utilisé les memory arena en 2009).
Mais je trouve cela amusant (ou inquiétant) qu'elle est resté bloqué encore sur ce genre de "questionnement"...
D'un coté je te le dis franchement ,tu sera toujours "mauvaise dev" , si tu reste à théoriser sur un truc comme ça... Et tu le sera aussi en croyant que tu n'as besoin d'aucun "tools" niveau programmation.
> Alors ok ça change pas grand chose dans le code ("noeud->fils = autre_noeud" au lieu de "noeud->fils = copy(autre_noeud)") mais pour le CPU ça fait quand même moins de choses à faire.
Je pense que c'est ça ton soucis , la "micro-optimisation", le pire c'est que tu t'y connais rien , mais tu veux optimiser des choses inutile.
Oui oui parce que comme on te l'a répété 10 000 fois , quand on optimise , on regarde ce qui prend le plus de calcul. Alors oui je sais que Casey est un Dieu pour toi , mais pour moi , c'est un rigolo ! Je vais prendre un exemple concret , il y'a pas mal de "vieux dev" qui programme en C ou en C++ sur Mega Drive ou Neo Geo , ce sont des processeurs de 8 MHz et 12 MHz. Et pourtant le GCC pour le M68000 est vraiment mauvais, moi même je peut faire du code asm à 2-3 fois plus rapide , mais pourquoi codé en C , ça passe ? Parce que même si 80% du code écrit est pas optimisé, il n'est pas significatif, le plus gros code se trouvera sur les boucles (principalement de rendu ,hitbox,collision) et là a la limite tu fait un peu d'asm pour optimiser le tout. Voilà , là je parle de jeux vidéo un truc que tu semble apprécier , il me semble. Et pourtant je parle de machine 1 000 000 de fois moins puissante que les machine actuel voir plus.
Bref pour les PC actuel , c'est pareil , si tout ton truc de mémoire ne prend que 1% de calcul , et que tu fait un code 2 fois plus rapide, ben ça prend 0.5% et bien sur ce genre de gain est invisible (en plus d'avoir passé du temps à optimiser du code pour rien). Quand on optimise, il faut voir ce qui prend plus de 10% de calcul de ton programme , là tu peux avoir de vrai gain visible.
Bref tout ça a été répété 10 000 fois, mais comme le soucis n'est pas là , mais qui est je pense un soucis bien plus "interne" , on perd notre temps ...
Puisque j'ai été cité à nouveau, deux petits trucs, le premier c'est que non les noeuds d'AST ne sont pas forcément triviaux, dans mon cas ils ont un destructeur (j'ai des noeuds qui possèdent des vector, d'autre des shared_ptr - tout ça est évitable mais à un coût technique énorme pour un gain négligeable, encore une fois).
JadeSalina a écrit:
Mais c'est de la fégnardise, c'est pas du travail bien fait je trouve mais c'est vrai qu'il y a un certain attrait dans cette solution de "facilité".
Si on avait un temps infini, oui. Personnellement au bout de plusieurs années sur un projet je sais que j'ai autre chose à foutre que de me préoccuper de chaque allocation, surtout si elle ne coûte rien (en %) parce qu'ellle n'est pas faite à un moment critique ou qu'il y a des tâches infiniment plus lourdes en même temps. Être un bon développeur c'est savoir choisir les priorités, c'est un truc de débutant de sauter sur la moindre occasion de sur-optimiser pour le plaisir de le faire.
Et je voudrais juste revenir sur la meilleure punchline de toutes les discussions avec Jade confondues.
JadeSalina a écrit:
Et puis pourquoi vous voulez absolument forcer les gens à faire comme vous voulez ?
Venant de quelqu'un qui nous casse les couilles depuis je ne sais combien de temps à la limite de l'insulte parce qu'on ne fait pas les choses de la même façon que son gourou.
Ah tiens je l'ai loupé celle là (faut dire que je lis que le début ) :
"Mais de toute manière je préfère quand même quand les choses sont simples, au niveau de ce que fait le processeur, pas forcément au niveau du code, j'aime cette légèreté, de ne pas me dire que je gache des cycles CPU à faire des allocations et désallocations à tout va, et tant pis si le code est moins clair."
Si tu veux faire quelque chose de simple pour ton processeur , alors ne fait ni du C , ni du C++. Le C et le C++ font des choses très compliqué pour un CPU , et si tu ça te semble "rapide" c'est seulement parce que y'a eu 30 ans d'optimisation des compilateurs C et C++. Sinon sans ça ,t'aurais fait comme tout les programmeurs de l'époque : coder en asm. Pour cela que dans le JV , le C ou le C++ est venu tardivement (vers le milieu des années 90/2000) , avant il était quasiment inconcevable de faire tout un jeu en full C , sans grosse perte de perf.
Le premier alone in the dark était en full asm (pou un jeu 3D).
Et pour ta dernière phrase "et tant pis si le code est moins clair." Bah si ton gain est nul ,t'aura fait un code pourri avec une architecture bancal pour 0 gain en perf , c'est beau Et le pire c'est que tu crois être la "seule" avec "Casey" d'utiliser cette technique, j'utilise des memory arena ,mais quand je vois que le code risque d’être trop complexe, autant utilisé des vector , faire un reserve ,et ça marche aussi bien ,sans différence de perf significative. (et le code est bien plus simple et propre).
Le soucis ,c'est que t'as 0 recul sur ce que tu dis , ni sur un projet. Moi je trouve ça "fou" que tu propose ce genre de technique , alors que le memory arena, il est efficace que dans certain cas, pour un AST , c'est complètement bancal. C'est comme si tu proposais à un gars un marteau , alors qu'il a des vis... Et tu répète depuis 1 an ou plus "le marteau , c'est simple et facile à comprendre on peut tout faire avec" , oui ,oui tu peux tout faire avec , faut voir l'utilisation et le résultat ensuite...
Si bien que je pense sans dire de conneries qu'une fois compilé, un unique_ptr est juste un pointeur nu. C'est juste le compilo qui a testé la non recopie, et placé le delete lors de la destruction.
Donc pour moi, niveau perf, c'est strictement pareil.
Oui pour moi aussi c'est censé être pareil mais apparemment il y a quand même un surcout ce qui est dommage https://youtu.be/rHIkrotSwcc?t=1043
HelbaSama a écrit:
Alors oui je sais que Casey est un Dieu pour toi , mais pour moi , c'est un rigolo !
Il connait vraiment des choses très complexes au niveau du processeur comme les intrinsics par exemple. Mais il va sortir "star code galaxy" ça sera des cours avec plein de détails etc, vous verrez bien qu'il connait plein de choses (par contre il se peut que ça soit payant)
Lynix a écrit:
Puisque j'ai été cité à nouveau, deux petits trucs, le premier c'est que non les noeuds d'AST ne sont pas forcément triviaux, dans mon cas ils ont un destructeur (j'ai des noeuds qui possèdent des vector, d'autre des shared_ptr - tout ça est évitable mais à un coût technique énorme pour un gain négligeable, encore une fois).
Oui mais les destructeurs servent à quoi ? Si c'est juste pour détruire des objets qui eux même ne font que libérer de la mémoire, on peut s'en passer si on alloue toute la mémoire depuis l'arena puisque c'est elle qui va tout libérer en temps voulu (par exemple on pourrait peut être mettre des std::span au lieu des std::vector ?). Mais sinon oui si on veut juste avancer dans le projet etc, pourquoi pas utiliser directement des solutions classiques de la STL au lieu de passer du temps à chercher une alternative, mais je n'avais pas pensé à ça à la base, moi je voulais toujours faire le meilleur truc possible en terme de résultat même si ça prend des mois pour gagner 1% de performance.
Lynix a écrit:
Être un bon développeur c'est savoir choisir les priorités, c'est un truc de débutant de sauter sur la moindre occasion de sur-optimiser pour le plaisir de le faire.
Voilà c'est ça, moi je m'en fiche des priorités je veux faire le truc le plus optimisé possible
Lynix a écrit:
Venant de quelqu'un qui nous casse les couilles depuis je ne sais combien de temps à la limite de l'insulte parce qu'on ne fait pas les choses de la même façon que son gourou.
Non non je veux pas du tout vous forcer à faire d'une manière ou d'une autre, c'est très bien que tout le monde fasse comme il veut
HelbaSama a écrit:
Bah si ton gain est nul ,t'aura fait un code pourri avec une architecture bancal pour 0 gain en perf , c'est beau
Et le pire c'est que tu crois être la "seule" avec "Casey" d'utiliser cette technique, j'utilise des memory arena ,mais quand je vois que le code risque d’être trop complexe, autant utilisé des vector , faire un reserve ,et ça marche aussi bien ,sans différence de perf significative. (et le code est bien plus simple et propre).
Oui c'est vrai que des vector peuvent faire l'affaire mais c'est ça le problème moi je veux pas juste que ça fasse l'affaire, je veux un truc optimisé sinon je dors pas bien la nuit, même si c'est pour gagner 0.00001s au final
HelbaSama a écrit:
Moi je trouve ça "fou" que tu propose ce genre de technique , alors que le memory arena, il est efficace que dans certain cas, pour un AST , c'est complètement bancal.
Alors pourquoi V8 et Clang ont l'air de faire comme ça ? Je trouve pas que ce soit si bancal que ça puisque justement on est dans un cas favorable à l'arena, déjà parce qu'il y a plein plein d'allocations à faire pour chaque noeud et ensuite parce que ces noeuds ont majoritairement la même durée de vie qui est celle de l'AST, je pense pas que ce soit nécessaire de désallouer chaque noeud dès qu'il est plus utilisé (par exemple si on le remplace par un autre), on peut aussi bien le laisser là et continuer la compilation, et une fois qu'on en a fini avec l'AST et qu'on passe à une phase suivante on le détruit d'un coup, ça a l'air intéressant quand même
Il y a plein de gens qui parlent des arenas et qui disent que c'est très utile et qu'on peut faire plein de choses avec https://youtu.be/yCcBo1Kn-tc?t=273
"Il connaît vraiment des choses très complexes au niveau du processeur comme les intrinsics par exemple."
Les intrinsics n'ont rien de compliqué, justement les intrinsics c'est justement la partie "facile" pour pas le faire en asm Apres je conçois un CPU , alors c'est peut être quelque chose de "tres tres compliqué" , mais pour moi , ça reste easy , amuse toi à optimiser sur un Itanium ou un Cell , tu verra la complexité niveau processeur là !
"je veux un truc optimisé sinon je dors pas bien la nuit, même si c'est pour gagner 0.00001s au final"
ah ben on a pas le meme "move" , j'adore optimiser mais en général c'est genre pour afficher des millions de polygone sur une petite machine. Pas optimiser des truc inutile avec "ah ben tiens j'ai passé une semaine pour afficher un polygone en plus, ça en fallait la peine dis donc " Mais pour ma part tu sera toujours mauvaise dev , parce que tu sera incapable d’optimiser un programme ou un jeux vidéo avec cette approche.
" Voilà c'est ça, moi je m'en fiche des priorités je veux faire le truc le plus optimisé possible " Pour le moment vu tes messages, tu serais incapable de bien optimiser , je veux pas être méchant, mais tu comprend rien dans le domaine de la "micro-optimisation" ou oui tu le comprend comme tout les débutants "par rapport au code C ou C++ écrit". Et j'avais justement dit par exemple sur un code que tout le pondre croyait pas optimisé , (meme Lynix) , on disant , bah le compilateur, il est capable de faire qu'un mul sur ce code, bah ça n'a pas loupé
( j'ai pas le code sous la main , mais en gros c'est un code radtodegres, qui appelle la fonction atan ,multiplie par 4 , puis le divise et fait une autre multiplication ).
"Alors pourquoi V8 et Clang ont l'air de faire comme ça ? Je trouve pas que ce soit si bancal que ça puisque justement on est dans un cas favorable à l'arena, " Ben non ,et puis tu sais les arguments d'autorité , Clang était pas top un moment, surtout comparé à GCC ,donc l'argument d'autorité qu'il le faisait bof.
Après non le arena n'est pas dans un bon cas pour l'AST , vu que tu connais pas exactement ton nombre d’allocation au début , même en parsant un peu , t'as aucun idée de la taille de ton AST. s'ils sont allé de façon "fixe" , c'est casse gueule en terme d'opti du code produit
Alors c'est cool pour certain truc, par exemple la gestion des bullet ,c'est très bien en memory arena , c'est facile , et c'est optimisé.
"Il y a plein de gens qui parlent des arenas et qui disent que c'est très utile et qu'on peut faire plein de choses avec https://youtu.be/yCcBo1Kn-tc?t=273 " Oui mais je m'en fiche. Plein de personne dise tout et n'importe quoi , moi je crois que le concret , j'ai programmé sur des machines de quelque MHz avec 60 ko ou de quelque Mo.
Donc ce qu'il en pense, je m'en fiche, je me base sur des faits concrets , comparé à toi qui semble aimé beaucoup la théorie
moi je voulais toujours faire le meilleur truc possible en terme de résultat même si ça prend des mois pour gagner 1% de performance.
JadeSalina a écrit:
Voilà c'est ça, moi je m'en fiche des priorités je veux faire le truc le plus optimisé possible
Ok. Ben c'est une pensée de débutant complet qui ne produira jamais rien. Ça fait 17 ans que je traine sur les forums d'OC, et je ne suis pas celui qui a le plus conseillé les débutants mais je peux déjà te dire que c'est une caractéristique commune de ceux qui débutent, ils veulent absolument être le plus performant possible, j'irais même jusqu'à dire : ils vont essayer d'écrire le code le plus complexe possible parce que c'est ce qu'ils imaginent que les "pro" font.
Sauf que c'est une grosse erreur, les vrais pro cherchent au contraire à simplifier le code le plus possible, un programme informatique passe 90% de son temps dans 10% de son code, ce qui laisse 90% du code non-critique, qui peut être simple, maintenable, avec moins de bugs.
Parce que oui, complexifier son code (ce qui est nécessaire pour "être le plus performant possible") c'est le rendre moins maintenable, avoir plus d'opportunité de bugs, passer plus de temps à optimiser un truc qui ne servira à rien pour au final produire moins de programme.
Bref, tu as beau avoir pas mal de connaissances sur le C++, tu as un esprit de débutante, et je pense que ça vient de ton adoration envers des personnes (d'ailleurs c'est à ça qu'on reconnait des idées bancales : les gens défendent plus les gens qui les émettent que les idées elles-mêmes).
JadeSalina a écrit:
Il connait vraiment des choses très complexes au niveau du processeur comme les intrinsics par exemple.
Big lol, les intrinsics c'est la base.
JadeSalina a écrit:
Oui mais les destructeurs servent à quoi ?
Pas qu'à libérer de la mémoire allouée à chaque passe de ttransformation de l'AST, les noeuds ont par exemple des shared_ptr sur de la mémoire allouée lors du parsing, notamment pour pouvoir mieux gérer les erreurs.
Comme je l'ai dit, je pourrais m'en passer, mais j'y passerais du temps (que je ne passerai pas à autre chose), je rajouterai de la complexité (dont j'essaie le plus possible de me débarrasser) inutile (parce que très peu de gain de performance).
Rends-toi compte que si je programmais avec le même état d'esprit que toi, je n'aurai probablement même pas encore réussi à produire le moindre résultat. Perso j'ai pas assez de temps libre pour me dire que je ne vais pas le prioriser dans les trucs les plus utiles.
Ceci étant dit, tu fais ce que tu veux, mais du coup :
Accepte d'avoir une opinion non-basée sur des pratiques d'entreprise (où le temps est limité)
De ce fait, de pouvoir recommander à tout le monde de faire pareil
D'arrêter de contredire les gens qui bossent dans l'industrie quand ils conseillent les débutants
D'arrêter d'écrire sur ce topic
D'arrêter d'écrire sur ce forum
De supprimer ton compte parce que visiblement même quand tu finis par comprendre quelque chose, il te faut à peine quelques semaines/mois pour régresser et retomber dans des travers idiots, probablement pas aidée par Casey. Je ne perds pas espoir que tu finisses un jour par comprendre durablement, mais ça prendra probablement encore quelques années.
(je sais que tu ne peux pas supprimer ton compte mais je t'ai proposé une solution, tu m'envoies ton mot de passe par MP et je le change pour toi vers une clé aléatoire que j'oublierai aussitôt).
Le mot de la fin :
Voilà un objectif raisonnable : arriver à avoir un point de vue au moins aussi bon que celui d'une IA.
Si bien que je pense sans dire de conneries qu'une fois compilé, un unique_ptr est juste un pointeur nu. C'est juste le compilo qui a testé la non recopie, et placé le delete lors de la destruction.
Donc pour moi, niveau perf, c'est strictement pareil.
Oui pour moi aussi c'est censé être pareil mais apparemment il y a quand même un surcout ce qui est dommage https://youtu.be/rHIkrotSwcc?t=1043
Merci pour ce lien !
Je suis impressionné que tu arrives à retrouver des extraits pertinents dans comme ça !
En écoutant la partie sur le unique_ptr, on voit quand même que le problème arrive lorsqu'il s'agit de faire un move.
En même temps, un move va passer l'adresse, comme un pointeur normal, mais également prendre le temps d'invalider l'appelant, ce que le pointeur nu ferait.
Je me demande si un usage de unique_ptr avec juste des passages par référence de lui même par ci par la, sans move, perdrait aussi en performance.
Je suis impressionné que tu arrives à retrouver des extraits pertinents dans comme ça !
Moi non , vu qu'elle est capable de retrouver un passage de Casey de 5 minute sur plus de 1000 heures de vidéo... Par contre pour moi , je ne trouve pas ça "bien" , on est clairement ici dans le "biais de confirmation" , on occultant tout ce qui contredit cette méthode.
Fvirtman a écrit:
En écoutant la partie sur le unique_ptr, on voit quand même que le problème arrive lorsqu'il s'agit de faire un move.
En même temps, un move va passer l'adresse, comme un pointeur normal, mais également prendre le temps d'invalider l'appelant, ce que le pointeur nu ferait.
Je me demande si un usage de unique_ptr avec juste des passages par référence de lui même par ci par la, sans move, perdrait aussi en performance.
Même réponse que Jade, fait des benchmark , tu aura ta réponse, mais si ce ça prend que 1% de ton programme ,dans le meilleurs des cas tu gagnerais que 0,99999% de gain
Mais comme dit , il y'a un an , ou plus je sais pas, on pourrait débattre "calmement" sur les optimisations, mais clairement pas ici. Fvirtman tu semble apprécié les optimisations des vieux jeu , mais c'est clairement pas ici que t'aura les bon truc pour apprendre quoique ce soit , je dis ça , je dis rien. Mais clairement , le débat memory arena vs dynamique, je l'ai jamais entendu vraiment dans le JV et pourtant on parlait de vielle bécane. Alors y'a eu souvent des memory arena pour des raisons de simplicité (ou si y'a une contrainte mémoire forte), mais j'ai pu voir des allocateurs dynamique sur des machines que je pensais pas voir (genre un Super Nes )
"Il y a plein de gens qui parlent des arenas et qui disent que c'est très utile et qu'on peut faire plein de choses avec https://youtu.be/yCcBo1Kn-tc?t=273 "
Donc ce qu'il en pense, je m'en fiche
Petite précision, pour ceux qui n'ont pas eu le courage de vérifier cette source. Pour ce que j'ai compris par rapport a son YT et son site perso, il s'agit d'un dev débutant (en dev a priori depuis 1 an et en game dev depuis 3 mois), qui est en cours d'apprentissage, qui n'a jamais bossé dans l'industrie du jeu vidéo (et a priori jamais dans l'industrie du dev en général) et n'a jamais créé de vrais jeux (il a 2 démos techniques toutes moisies sur son site -- en vrai, pas "toutes moisies", mais juste "a son niveau").
Le premier commentaire sous la vidéo fait un bon résumé du probleme :
I'd just emphasize that "Because I want to do it this way"
is pretty much the only tenable reason to do this, based
on his stated goals. That's plenty good enough, but any
time he describes engines and what it's like to use them,
take it with a grain of salt.
Il n'y connait rien et ses arguments sont moisis. Il fait juste ça comme ça parce qu'il a envie (et c'est un argument suffisant pour faire ce qu'on veut pour soi, mais qui n'a aucune valeur pour convaincre les autres de faire les mêmes choix).
Bref, jade, en parfait débutant, prend comme exemple un autre débutant qui n'y connait rien, juste parce que ça va dans son sens. (Surprise !)
(EDIT : oh le pauvre randi. Tout le monde se fout de sa gueule dans les commentaires YT. C'est pas possible que jade est choisi cette vidéo sans savoir que c'est réellement moisi comme argument. C'est du pur troll)
D'ailleurs, c'est ce que dit jade explicitement dans son dernier message qu'il veut juste faire ce qu'il a envie. Et c'est son choix. Mais il est juste trop con pour comprendre que c'est pas un argument pour convaincre les autres que c'est un bon choix.
Mais comme dit , il y'a un an , ou plus je sais pas, on pourrait débattre "calmement" sur les optimisations, mais clairement pas ici.
Fvirtman tu semble apprécié les optimisations des vieux jeu , mais c'est clairement pas ici que t'aura les bon truc pour apprendre quoique ce soit , je dis ça , je dis rien.
J'ai bien compris que ce topîc s'enlise, que ça tourne à l'enculage de mouche, et que ce genre de micro-optimisation n'a pas lieu d'être hors des zones critiques des programmes, ça ne m'empêchera pas d'utiliser des unique_ptr
Après non le arena n'est pas dans un bon cas pour l'AST , vu que tu connais pas exactement ton nombre d’allocation au début , même en parsant un peu , t'as aucun idée de la taille de ton AST.
Mais non mdrr c'est vous qui passez vos vacances à Theory Land en vous demandant si les monades sont des monoides dans la catégorie des endofunctors au lieu de se rapprocher de la machine et du concret ! (bon ok peut être que Helba est proche de la machine mais les autres pas trop !)
Lynix a écrit:
Accepte d'avoir une opinion non-basée sur des pratiques d'entreprise (où le temps est limité)
Oui ça je veux bien le reconnaitre, c'est vrai que moi je cherche à faire les choses bien pendant que les entreprises expédient le truc vite fait à la rache Et en plus il y a plein de monde qu'on peut virer dans les grosses entreprises car ils ne servent à rien !! (cf Twitter, Meta, ...)
Lynix a écrit:
Voilà un objectif raisonnable : arriver à avoir un point de vue au moins aussi bon que celui d'une IA.
Mais elle dit n'importe quoi cette IA, elle ne fait que répéter ce qu'elle a lu par là sans réfléchir. Et si jamais par hasard elle dit un truc "juste", c'est comme une horloge cassée qui peut donner la vraie heure à un moment dans la journée
gbdivers a écrit:
Petite précision, pour ceux qui n'ont pas eu le courage de vérifier cette source. Pour ce que j'ai compris par rapport a son YT et son site perso, il s'agit d'un dev débutant (en dev a priori depuis 1 an et en game dev depuis 3 mois), qui est en cours d'apprentissage, qui n'a jamais bossé dans l'industrie du jeu vidéo (et a priori jamais dans l'industrie du dev en général) et n'a jamais créé de vrais jeux (il a 2 démos techniques toutes moisies sur son site -- en vrai, pas "toutes moisies", mais juste "a son niveau").
Le premier commentaire sous la vidéo fait un bon résumé du probleme :
I'd just emphasize that "Because I want to do it this way"
is pretty much the only tenable reason to do this, based
on his stated goals. That's plenty good enough, but any
time he describes engines and what it's like to use them,
take it with a grain of salt.
Il n'y connait rien et ses arguments sont moisis. Il fait juste ça comme ça parce qu'il a envie (et c'est un argument suffisant pour faire ce qu'on veut pour soi, mais qui n'a aucune valeur pour convaincre les autres de faire les mêmes choix).
Bref, jade, en parfait débutant, prend comme exemple un autre débutant qui n'y connait rien, juste parce que ça va dans son sens. (Surprise !)
(EDIT : oh le pauvre randi. Tout le monde se fout de sa gueule dans les commentaires YT. C'est pas possible que jade est choisi cette vidéo sans savoir que c'est réellement moisi comme argument. C'est du pur troll)
D'ailleurs, c'est ce que dit jade explicitement dans son dernier message qu'il veut juste faire ce qu'il a envie. Et c'est son choix. Mais il est juste trop con pour comprendre que c'est pas un argument pour convaincre les autres que c'est un bon choix.
Oui je sais que c'est un débutant mais c'est pas une raison pour ne pas l'écouter, surtout qu'il dit des choses intéressantes. Et c'est pas les commentaires qu'il faut regarder c'est ce qu'il dit lui, les commentaires ils ne comprennent pas mdrr !
Mais après ok peut être que ça marche pas comme ça dans les entreprises ça je sais pas j'y suis jamais allée, mais si j'ai envie de faire les choses d'une certaine manière parce que je préfère, pourquoi vous voulez m'empêcher ? Chacun est libre de faire les choses comme il veut, moi je vous interdit pas d'utiliser des trucs modernes de C++, faites ce que vous voulez !
Moi plutôt que de faire des gros trucs comme fait Lynix ou d'autres je préfère rester sur des petits programmes mais faire en sorte que chaque opération soit optimisée, mais si vous préférez faire comme Lynix faites le c'est très bien aussi, mais moi c'est pas ce que je préfère faire car il y a trop de problèmes "théoriques" au niveau du code, par ex est ce que on prend le truc par référence, constante ou pas, ah flute je veux renvoyer un shared_ptr à partir d'une instance du coup il faut hériter de std::enable_shared_from_this blablabablabla, ça s'éloigne des vrais problématiques physiques de la machine.
Fvirtman a écrit:
HelbaSama a écrit:
Mais comme dit , il y'a un an , ou plus je sais pas, on pourrait débattre "calmement" sur les optimisations, mais clairement pas ici.
Fvirtman tu semble apprécié les optimisations des vieux jeu , mais c'est clairement pas ici que t'aura les bon truc pour apprendre quoique ce soit , je dis ça , je dis rien.
J'ai bien compris que ce topîc s'enlise, que ça tourne à l'enculage de mouche, et que ce genre de micro-optimisation n'a pas lieu d'être hors des zones critiques des programmes, ça ne m'empêchera pas d'utiliser des unique_ptr
Comment ça mes topics s'enlise lol, non non c'est important de faire des choses optimisé, surtout en ce moment avec la crise énergétique il faut économiser l'électricité et pas faire plein d'allocations pour rien !!
- Edité par JadeSalina 21 décembre 2022 à 16:37:01
Les allocateurs systèmes aussi sont souvent basés sur des arenas, même en C et en C++. jemalloc/mimalloc aussi... Mince alors...
JadeSalina a écrit:
Mais elle dit n'importe quoi cette IA, elle ne fait que répéter ce qu'elle a lu par là sans réfléchir.
Ça vous fait un point en commun.
JadeSalina a écrit:
ça s'éloigne des vrais problématiques physiques de la machine.
C'est le principe des langages de programmation de s'éloigner de la réalité physique de la machine, à partir du moment où tu as un OS tu es terriblement éloigné du fonctionnement de la machine propre. C'est notamment pour ça que c'est complètement futile de considérer des langages comme le C comme étant "proches de la machine" (spoiler alert : pas vraiment). Ou de vouloir faire ce que tu fais. Encore une fois tu fais ce que tu veux mais s'il te plait, laisse absolument tout le monde tranquille avec ça, et supprime ton compte.
JadeSalina a écrit:
Comment ça mes topics s'enlise lol, non non c'est important de faire des choses optimisé, surtout en ce moment avec la crise énergétique il faut économiser l'électricité et pas faire plein d'allocations pour rien !!
C'est à ce moment de ma réponse que j'ai hésité à faire comme gbdivers et simplement te dire de la fermer (sérieusement si c'est pour sortir ce genre de connerie abstiens-toi), mais j'ai eu une meilleure idée.
JadeSalina a écrit:
Comment ça mes topics s'enlise lol, non non c'est important de faire des choses optimisé, surtout en ce moment avec la crise énergétique il faut économiser l'électricité et pas faire plein d'allocations pour rien !!
Il est effectivement important de tenir compte de l'impact environnemental de nos programmes informatiques et de faire en sorte de minimiser l'utilisation inutile de ressources, y compris l'électricité. Optimiser les performances de nos programmes peut aider à réduire leur consommation d'électricité et à améliorer leur efficacité en général.
Il existe plusieurs façons d'optimiser les performances d'un programme informatique. Certaines approches courantes comprennent l'utilisation de structures de données et d'algorithmes efficaces, la réduction de l'utilisation de la mémoire et du temps d'exécution, et l'optimisation du code à l'aide de techniques telles que la parallélisation et l'optimisation de la compilation.
Il est également important de se rappeler que l'optimisation des performances peut souvent être un processus itératif et que de petites modifications au code peuvent souvent apporter de significatifs gains de performance. Il peut être utile de mesurer les performances du programme avant et après chaque modification pour s'assurer que les changements apportés ont effectivement amélioré les performances comme prévu.
Enfin, il est recommandé de trouver un équilibre entre les performances et d'autres facteurs tels que la lisibilité du code, la facilité de maintenance et de développement, et la fiabilité du programme. Il ne faut pas sacrifier d'autres aspects importants du programme uniquement dans le but d'améliorer les performances.
pourquoi vous voulez m'empêcher ? Chacun est libre de faire les choses comme il veut
Espece d’idiot, c’est toi qui a lancé cette discussion. Si tu veux faire ce que tu veux dans ton coin, tais toi et fais le. Arrete de venir casser les pieds avec tes opinions toutes moisies sur la programmation (en particulier sur les discussions des autres).]
JadeSalina a écrit:
surtout en ce moment avec la crise énergétique il faut économiser l'électricité et pas faire plein d'allocations pour rien !!
C’est la difference entre les devs pro et toi : les optimisations que tu fais, c’est pour tes petits codes perso, que personne d’autre que toi ne va utiliser. Ton impact sur la crise énergétique est complètement insignifiant.
Les devs pro font peut être moins d’optimisation, mais nos programmes sont utilises par des milliers ou millions de gens dans la vie reelle.
A part polluer ce forum avec des discussions inutiles, tu sers a rien.
Les devs pro font peut être moins d’optimisation, mais nos programmes sont utilises par des milliers ou millions de gens dans la vie reelle.
Et encore moins d'optimisation par rapport à quoi ou a qui ? Par rapport à JadeSalina ou Casey , j'en doute.
Pour ma part quand tu tente d'optimiser en micro-optimisation ,sans profiling , c'est droit dans le mur.
La bonne optimisation actuel (si on fait du C et C++) , c'est comprendre comment marche le compilateur, pas la machine Le compilateur est bon pour optimiser certain "pattern" ,quand on les connais , et qu'on lui fait un code facile à lire, ça passe.
" je préfère rester sur des petits programmes mais faire en sorte que chaque opération soit optimisée"
Oui , mais tu ne sais pas optimisé, ou plutôt "tu crois savoir". Surtout que les calculs ,c'est pas ça qui est long , mais l’optimisation du cache est "infiniment" plus gagnant , pour cela que Lynix a eu des gros gain avec minmalloc , le soucis de ton "arena" ,c'est que tu te dis "c'est 3 calcul pour trouver la prochaine adresse" , mais comme chaque adresse n'est pas réutilisé (ou tres peu), ça créer de conflit de cache , bien plus souvent qu'un minmalloc qui va réutilisé les 256Kio du cache très souvent et qui seront souvent en cache L1/L2 avec peu de cache miss. Et vraiment faut mieux perdre du temps de calcul pour optimiser le cache, que l'inverse
Et encore moins d'optimisation par rapport à quoi ou a qui ?
Par rapport à JadeSalina ou Casey , j'en doute.
Dans l’absolu.
J’assume completement d’avoir fait le choix de ne pas rechercher l’optimisation ”maximale” (meme pas sur de ce que ca veut dire).
Je ne cherche pas a optimiser un code non critique.
Je ne cherche pas a optimiser un code critique plus que necessaire.
Dans un precedent boulot, je faisais du calcul intensif. J’avais un prototype d’algo implemente en R, en C++ “naif”, C++ multithread, et C++/CUDA. L’estimation de la performance de l’implementation C++/CUDA etait de 2-3 fois plus rapide que la version MT (de memoire, une 10aine d’heures vs 4-5). J’ai decide que ce gain en performance n’etait pas suffisant pour justifier de continuer a travailler sur la version CUDA. J’ai garde la version MT, sachant que la version CUDA etait 2-3 fois plus rapide.
Et en plus il y a plein de monde qu'on peut virer dans les grosses entreprises car ils ne servent à rien !! (cf Twitter, Meta, ...)
Et Twitter qui est en train d'exploser. Et Meta qui fait une chute vertigineuse.
C'est surtout Elon Musk qui fait n'importe quoi mais côté technique ça a l'air de tourner encore, et c'est vrai que je suis pas sûre que ce soit nécessaire d'être des milliers pour faire des trucs, il y a des studios indés qui font des trucs cools en étant une 15aine (no man's sky) et je crois aussi (à vérifier) que chez Epic ils sont pas plus d'une centaine à bosser sur le moteur en lui même. Après pour tout le côté marketing et non technique etc oui il faut sans doute d'autres personnes pour le faire.
Lynix a écrit:
Les allocateurs systèmes aussi sont souvent basés sur des arenas, même en C et en C++. jemalloc/mimalloc aussi... Mince alors...
Alors oui ils allouent à partir d'un bloc préalloué mais c'est beaucoup plus complexe qu'une arena. L'arena ça alloue à la suite et ça ne peut pas désallouer des trucs intermédiaires. Et le lien que j'ai donné indique que Rust utilise des arenas pour stocker l'AST, comme Clang et V8 (pour autant que je sache, il y en a peut être d'autres), c'est pour ça que je trouve bizarre que vous trouviez que c'est pas une bonne idée. Peut être que c'est plus error prone, moins lisible ou ce que vous voulez, mais justement en terme de performance ça me parait bien. Dans le test que vous avez fait, il y a au moins 2 choses qu'une arena aurait fait mieux que l'operator new que vous avez mis, c'est de permettre de réutiliser des nodes sans devoir les copier, et s'épargner de devoir appeler des destructeurs pour libérer chaque node individuellement, mais pour faire ça il faut structurer le truc comme a fait V8, ce qui est peut être moins lisible ou moins maintenable si vous voulez, je vous accorde ce point
Lynix a écrit:
Encore une fois tu fais ce que tu veux mais s'il te plait, laisse absolument tout le monde tranquille avec ça, et supprime ton compte.
Je veux pas du tout vous embêter, vous aussi faites ce que vous voulez c'est très bien comme ça, la vie est courte il faut en profiter et s'amuser en faisant ce qu'on aime Je veux pas que ça vienne de moi que je supprime mon compte car j'ai peur de le regretter si un jour je trouve un autre truc intéressant à vous dire, mais si un modo me ban j'accepterais la sentence
Lynix a écrit:
Il est effectivement important de tenir compte de l'impact environnemental de nos programmes informatiques et de faire en sorte de minimiser l'utilisation inutile de ressources, y compris l'électricité. Optimiser les performances de nos programmes peut aider à réduire leur consommation d'électricité et à améliorer leur efficacité en général. [...]
Mais c'est quoi ça on dirait une réponse toute faite de chatGPT avec ses 4 paragraphes là comme une rédaction ptdrr
gbdivers a écrit:
JadeSalina a écrit:
pourquoi vous voulez m'empêcher ? Chacun est libre de faire les choses comme il veut
Espece d’idiot, c’est toi qui a lancé cette discussion. Si tu veux faire ce que tu veux dans ton coin, tais toi et fais le. Arrete de venir casser les pieds avec tes opinions toutes moisies sur la programmation (en particulier sur les discussions des autres).]
Ah flute je voulais pas avoir l'air de forcer à faire d'une certaine manière, je voulais juste discuter de Handmade Hero etc parce que j'ai trouvé que c'était une bonne série assez cool. Par contre c'est vrai que j'aurais pas du m'incruster dans d'autres topics, peut être que ça peut déstabiliser les débutants qui posent des questions
HelbaSama a écrit:
gbdivers a écrit:
Les devs pro font peut être moins d’optimisation, mais nos programmes sont utilises par des milliers ou millions de gens dans la vie reelle.
Et encore moins d'optimisation par rapport à quoi ou a qui ? Par rapport à JadeSalina ou Casey , j'en doute.
Non là par contre c'est faux, moi peut être que je sais pas optimiser mais Casey il sait très bien, je vais pas vous ressortir le topic du terminal Windows où il dit que les performances sont mauvaises (allez si https://github.com/microsoft/terminal/issues/10362) et qu'ils devraient faire différemment etc, et ils lui ont dit que c'était un projet de recherche doctorale alors qu'il a fait le truc en 3 jours qui est ultra performant (mais de l'aveu même de Casey, il est même pas "optimisé", il a juste fait la base du truc) https://www.youtube.com/watch?v=hxM8QmyZXtg
Il est vrai que la taille d'une équipe de développement n'est pas toujours un indicateur de la qualité ou de la réussite d'un projet informatique. Des équipes de développement de toutes tailles peuvent produire des résultats exceptionnels et il y a de nombreux exemples de projets réussis qui ont été développés par de petites équipes.
Cependant, il est important de garder à l'esprit que la taille d'une équipe peut avoir un impact sur la rapidité et l'efficacité avec lesquelles un projet peut être mené à bien. Une équipe plus petite peut être plus agile et plus capable de réagir rapidement aux changements, mais elle peut également avoir moins de ressources et de flexibilité pour gérer des problèmes complexes ou pour traiter de grandes quantités de travail.
Il est difficile de dire si licencier les trois quarts d'une équipe de développement signifie que ces développeurs ne servaient à rien simplement parce que le produit continue de fonctionner. Il y a de nombreux facteurs qui peuvent entrer en jeu dans la décision de licencier une partie d'une équipe de développement, et il est possible que ces développeurs aient contribué de manière significative à la réussite du produit même s'ils ne sont plus là.
Il est important de garder à l'esprit que le développement de logiciels est un processus complexe qui implique souvent de nombreuses personnes travaillant ensemble de manière coordonnée. Les développeurs qui ont été licenciés peuvent avoir contribué à la création de base de code solide et fiable, à la conception de fonctionnalités utiles et à la résolution de problèmes complexes. Même si ces développeurs ne sont plus là, leur travail peut continuer à être utile et à contribuer à la réussite du produit.
En fin de compte, il est important de ne pas trop tirer de conclusions hâtives sur la valeur des développeurs en se basant uniquement sur la continuité du fonctionnement d'un produit. Il y a de nombreux facteurs qui peuvent entrer en jeu dans la réussite ou l'échec d'un projet informatique, et il est important de prendre en compte l'ensemble de ces facteurs pour évaluer de manière juste et équitable la contribution de chaque membre de l'équipe.
Il semblerait qu'un membre ayant plus de pouvoir que vous ait décidé de fermer ce topic. Vous vous demandez peut-être la raison de cette fermeture... Vous ne l'aurez pas.
En effet, les admins jouissent d'un pouvoir sans limite, leur permettant de châtier les zér0s, de fermer les topics et de faire pleuvoir des limaces (seulement en cas de pleine lune, période durant laquelle leurs pouvoirs augmentent considérablement).
Nous vous invitons à prendre peur et à ne plus poster de topic qui pourrait attirer l'attention...
Nous sommes persuadés que vous comprendrez, et vous remercions par avance de votre coopération.
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)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
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
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)