Discussion :

[Invité]

Salut alors ici je posterais toutes les nouvelles concernant mon devblog http://lolilolightdevblog.wordpress.com/ , le site web (à venir), etc...

Alors comme les billets sont relativement long, j'ai décidé de faire des pages plutôt que des posts.

Comme je l'ai dit dans mon autre post, ce sujet aura pour but d'apporter des news de manière régulière sans polluer l'autre sujet qui est plutôt destiné aux grosses news.

Voilà.

[Invité]

Pour éviter d'avoir le message d'erreur du fait qu'il n'y a pas de billet sur le devblog, j'en ai rajouté un, il traite surtout des erreurs (je les ai faîtes aussi rassurer vous!) à ne pas faire lors du développement de jeux vidéos.

[eclesia]

des petites remarques :

Ne met pas de code dans ton blog. c'est juste illisible avec le formattage, la font et la taille.
met plutot tout ca sur un bitbucket/github avec des liens.

Erreur n°4 : Utiliser un langage qui utilise un garbage collector c’est mieux.

Déconseiller les GC pour des jeux C/C++ peut etre s'ils sont inefficaces mais ce n'est pas le cas de tous les languages. Tu dis indirectement qu'il n'y a QUE le C/C++ de viable pour faire de vrai jeux, car il n'y a qu'eux pour gérer la mémoire directement. c'est de l'ordre du troll.


Honnetement (sans vouloir te vexer), il n'y a pas grand chose d'interessant.
C'est d'avantages des penchants personnels de programmation que de véritable infos utiles.

[CodeurPlusPlus]

Ce ne sont pas des penchants personnels mais des retours d'expérience.

Peut-être que les retours que tu ferais sont différents de ceux de Lolilolight, voire opposés sur tous les points ("Codez vos jeux AAA en Python et vive le GC !"), mais cela ne t'autorise pas à rabaisser ce qu'il dit au rang de "penchants personnels".

J'ai personnellement une expérience de la programmation de jeu qui est encore ridicule... donc si je me permettais de faire part de mes choix ou de parler de ce que j'ai tiré de cette minuscule expérience, je comprendrais qu'on me dise que ce que je raconte n'est qu'inepties et préjugés. Mais Lolilolight, si ma mémoire ne me joue pas de tour, n'est ni un neuneu ni un newbie.

[mintho carmo]

Sérieusement ? Pas des "penchants personnels" ?

les locks ne sont pas gratuit, en effet, cela représente un peu près 30% du temps d’exécution de votre application. (J’ai testé avec un profiler)

J'ai éclaté de rire en lisant cela. Premièrement, il ne connait manifestement les approches lock-free. Deuxièmement, 30% ? Mon "penchant personnel" serait de penser qu'il a mal codé ses tests de performances

De plus chaque thread possède déjà des traitements qui se font en parallèle au niveau de l’os, si vous les séparer, dans plusieurs threads cela sera plus lent.

Quels traitements ?

Et pour les traitements graphique il y a le GPU et les api graphiques qui évolue de manière à pouvoir faire de plus en plus de traitements parallèle avec le GPU de manière optimisée à l’aide de shaders.

Les theads sur CPU et GPU sont complémentaires, pas opposé

Erreur n°2 : Ajouter trop de fonctionnalité à une classe dont ce n’est pas son rôle.

Cela s'appelle le principe de responsabilité unique, pas le YAGNI

certains bon langages de programmations permettent de coder de manière générique de plus en plus simplement tout en respectant le principe de prototype/définition grâce à la méta-programmation.

J'espère que ce n'est pas du C++ qu'il parle, ou alors je ne sais pas de quel principe de prototype/définition rendu possible par la meta programmation il parle.

Erreur n°4 : Utiliser un langage qui utilise un garbage collector c’est mieux.

Pour libérer la mémoire automatiquement il faut compter combien de fois une variable est référencées et cela n’est pas gratuit, de plus, ceci cache la sémantique des classes, le programmeur doit toujours savoir quelle classe est propriétaire de la ressource mémoire. (RAII)

Les GC sont largement critiquables et perfectionnables, mais le principe de gestion automatisé de la mémoire, non. Même en C++

Et quel rapport entre le GC et la sémantique des classes ? Entre l'ownership et le RAII ?

et pour utiliser une ressource de manière temporaire il suffit de récupérer un pointeur nu sur la ressource.

Par contre std::shared_ptr et std::weak_ptr ne sont à utiliser que là ou c’est nécessaire, jusqu’à maintenant je n’en ai pas eu besoin.

Là, c'est un peu plus technique. L'utilisation de pointeurs nus sur une ressource gérée par un unique_ptr pose des problèmes en situation multithreads, problème que l'on aura pas avec shared/weak_ptr.
Et Lolilolight n'a aucune excuse sur ce point, c'est lui qui a lancé cette discussion, dans laquelle j'explique les différents cas d'utilisation des pointeurs intelligents.


Et il y aurait encore pas mal à dire, je n'ai relevé que les choses qui m'ont fait le plus rire. En tout cas, à la lecture, cela ne me fait pas penser à un expert qui maîtrise son sujet. Donc je suis largement de l'avis de eclesia, "il n'y a pas grand chose d’intéressant".

[Neckara]

Bonjour,

Personnellement, je trouve que c'est bien de vouloir partager son expérience via des billets de blogs.

Très franchement, le résultat n'est pas parfait comme vous avez déjà pu le voir.
Mais bon, qui a déjà réussi à écrire un programme qui marchait du premier coup sans aucunes erreurs ?

Après ce n'est qu'un billet de blog sur son "expérience" (bonne ou mauvaise), ce n'est pas un article pour dire "comment vous devez absolument faire". Donc je ne pense pas qu'il soit non plus nécessaire de le lyncher .

Après, il y a pas mal de points dont je me rappelle avoir discuté avec lui.
Par exemple, c'est moi qui lui ai parlé de YAGNI.

Par contre, je pense qu'il n'a pas tout compris ce que je lui ai dit
YAGNI : You ain't gonna need it => pas la peine de programmer des fonctionnalités dont tu n'auras pas besoin.
KISS : Keep it Simple, Stupid !

des traitements qui se font en parallèle au niveau de l’os

Je crois qu'il parle des appels systèmes.
En effet, le noyaux Linux étant monothread, tous les appels systèmes sont exécutés sur le même thread/processus (si mes souvenir sont exacts).

@lolilolight : personne n'est parfait, l'important c'est d'essayer... et surtout d'en tirer des enseignements pour ne pas reproduire ses erreurs et s'améliorer.

Essaye d'argumenter, ne dit pas que c'est "sale et peu performant" sans donner des raisons, des faits.
J'ai un peu plus de connaissance que toi, certes, mais ne me prend pas pour autant pour la "parole unique".
Comme je te l'ai dit, je peux aussi me tromper et il y a des personnes bien plus compétentes que moi.

Je n'ai pas toujours le temps de tout t'expliquer en profondeur, mais s'il y a des choses que tu ne comprends pas, ou que tu n'es pas sûr de comprendre, tu peux aussi poster des questions sur les forums, les autres membres se feront alors un plaisir de te répondre et certains bien mieux que je ne pourrais le faire. Surtout que je ne suis pas toujours très clair dans mes propos.
J'ai d'ailleurs moi-même beaucoup appris en postant et en lisant dans les forums C/C++ (merci koala01 ).

Si tu ne te souviens plus de ce que j'ai dit, tu peux aussi relire l'historique de la conversation, par contre, évite d'aller prêcher "ma bonne parole" en extrapolant 50% à partir de mes dires, c'est un peu embarrassant .
Rien ne t'empêche aussi d'avoir un esprit critique et de demander des approfondissement sur le forum.

Après, j'ai aussi des avis qui n'engagent que moi, par exemple pour les garbages collectors que j'ai en horreur ^^.
Mais il faut aussi comprendre que d'autres personnes adorent les garbages collecteurs (), c'est un débat de type "guerre de religions".
En parler sans avancer de bons arguments, avec un avis aussi tranché en public, c'est un peu du suicide .


Certains concepts mettent aussi du temps a assimiler, pour certains, il m'a fallu plusieurs mois et des claques monumentales pour comprendre. Tout aussi pédagogue que je puisse être, je ne suis pas sûr que tu puisses comprendre toute leur ampleur juste parce que je t'en ai touché quelques mots il y a une semaine. D'autant plus que je ne les ai pas encore forcément tous assimilés à 100%.

Évite aussi de sortir des bêtises du genre :

cela représente un peu près 30% du temps d’exécution de votre application

Je pense que tu peux comprendre que cela dépend très fortement de l'application en question et surtout de son code/architecture.
Cela va dépendre de la durée d'exécution des sections critiques, de la fréquence à laquelle on entre dans ces sections, etc.

[Invité]

Après, il y a pas mal de points dont je me rappelle avoir discuté avec lui.
Par exemple, c'est moi qui lui ai parlé de YAGNI.

Par contre, je pense qu'il n'a pas tout compris ce que je lui ai dit
YAGNI : You ain't gonna need it => pas la peine de programmer des fonctionnalités dont tu n'auras pas besoin.
KISS : Keep it Simple, Stupid !

Ca partait dans la même idée, je voulais plutôt mentionner le principe à responsabilité unique.

Déconseiller les GC pour des jeux C/C++ peut etre s'ils sont inefficaces mais ce n'est pas le cas de tous les languages. Tu dis indirectement qu'il n'y a QUE le C/C++ de viable pour faire de vrai jeux, car il n'y a qu'eux pour gérer la mémoire directement. c'est de l'ordre du troll.

Faux, j'ai pas dis ça.

Je crois qu'il parle des appels systèmes.
En effet, le noyaux Linux étant monothread, tous les appels systèmes sont exécutés sur le même thread/processus (si mes souvenir sont exacts).

C'est ce dont je voulais parler.

Essaye d'argumenter, ne dit pas que c'est "sale et peu performant" sans donner des raisons, des faits.
J'ai un peu plus de connaissance que toi, certes, mais ne me prend pas pour autant pour la "parole unique".
Comme je te l'ai dit, je peux aussi me tromper et il y a des personnes bien plus compétentes que moi.

Le plus drôle c'est que c'est toi qui m'avait dit quelque chose de ce genre là à propos d'un langage de programmation qui utilise beaucoup les threads.

J'ai éclaté de rire en lisant cela. Premièrement, il ne connaît manifestement les approches lock-free. Deuxièmement, 30% ? Mon "penchant personnel" serait de penser qu'il a mal codé ses tests de performances

Ca rejoint ce que j'ai dis faire des locks et free trop souvent comme je faisais ça dégrade les performances, l'utilisation de threads supplémentaire augmentent justement les risques d'accès concurrents.

Les theads sur CPU et GPU sont complémentaires, pas opposé

Je le sais bien d'ailleurs je n'ai pas dis ça.

J'espère que ce n'est pas du C++ qu'il parle, ou alors je ne sais pas de quel principe de prototype/définition rendu possible par la meta programmation il parle.

Non, pas forcément le c++.

Les GC sont largement critiquables et perfectionnables, mais le principe de gestion automatisé de la mémoire, non. Même en C++

Et quel rapport entre le GC et la sémantique des classes ? Entre l'ownership et le RAII ?

et pour utiliser une ressource de manière temporaire il suffit de récupérer un pointeur nu sur la ressource.

Par contre std::shared_ptr et std::weak_ptr ne sont à utiliser que là ou c’est nécessaire, jusqu’à maintenant je n’en ai pas eu besoin.
Là, c'est un peu plus technique. L'utilisation de pointeurs nus sur une ressource gérée par un unique_ptr pose des problèmes en situation multithreads, problème que l'on aura pas avec shared/weak_ptr.
Et Lolilolight n'a aucune excuse sur ce point, c'est lui qui a lancé cette discussion, dans laquelle j'explique les différents cas d'utilisation des pointeurs intelligents.

Non ils ne posent aucun problème à partir du moment ou tu sais comment les utiliser, je n'ai jamais eu de soucis avec les std::unique_ptr.

Et il y aurait encore pas mal à dire, je n'ai relevé que les choses qui m'ont fait le plus rire. En tout cas, à la lecture, cela ne me fait pas penser à un expert qui maîtrise son sujet. Donc je suis largement de l'avis de eclesia, "il n'y a pas grand chose d’intéressant".

Je programme depuis plus de 10 ans et j'ai programmé avec pleins de langages de programmation différent mais je ne maîtrise pas mon sujet.


Bref je ne vais pas insister plus longtemps ce débat ressemble plus à un lynchage ou bien à une vengeance que à un vrai débat (A en voir le nombre de critiques négatives et d'arguments faux bref...), j'ai créer ce blog pour donner des retours sur mes expériences, pas pour lancer la 3ème guerre mondiale et si vous ne trouvez pas ça intéressant ne lisez pas j'ai déjà fait l'effort de créer deux sujets à part pour ne pas vous ennuyer je pense que cela est déjà bien.
A bonne entendeur salut, les prochains posts concerneront plus des news sur mon devblog, je tiens pas à débattre d'avantage là dessus les goûts et les couleurs ce n'est pas quelque chose qui se discute et je n'ai pas spécialement de questions, si certains aiment utiliser un gc bah libre à eux de le faire moi je veux juste partager mon expérience personnelle là dessus, et pas imposer une méthode unique et j'ai déjà eu bien du mal à me mettre d'accord avec Neckara sur les principes et méthodes à utiliser. :/

PS : Maintenant je ne voudrais pas poussez trop loin non plus, il est possible que parfois je me trompe car je n'égale pas tout les programmeurs de la STL non plus..., si je vaut 3 dévs à moi tout seul c'est déjà très bien. (Petit clin d'oeuil à Neckara )

A bonne entendeur salut.

Ne t'inquiète pas neckara si j'ai des questions je t'en poserai mais, bon, là, c'est plus une question de se mettre d'accord sur les principes car il n'y en a pas qu'un.

PS2 : Et sache que je ne veux pas prêcher ta bonne parole d'ailleurs, je ne suis pas toujours d'accord avec ce que tu dis non plus mais bon, il faut bien trouver un accord sur les principes pour que le projet avance.

Voilà j'espère avoir été assez clair.

[maeiky]

Je suis d'accord avec le fait que d'utilisé trop de thead est bien moins performant, si on a par exemple 4 coeurs, on peut donc supposé qu'avec 4 thread on peu obtenir les performances maximal et avec plus de 4, chaque thread qui attend la fin d'un autre consomme le CPU pour rien, en plus de la création/destruction de celui-ci.

Après, j'ai aussi des avis qui n'engagent que moi, par exemple pour les garbages collectors que j'ai en horreur ^^.
Mais il faut aussi comprendre que d'autres personnes adorent les garbages collecteurs (), c'est un débat de type "guerre de religions".
En parler sans avancer de bons arguments, avec un avis aussi tranché en public, c'est un peu du suicide .

Je ne connais pas très bien le principe du GC et j'aimerais avoir votre avis sur ce cas :
Si on prend un objet et un pointeur sur celui-ci, on augmente le nombre de référence de 1, si ce pointeur change et pointe sur un autre objet on diminue le nombre de référence de 1 de l'objet, puis avec une condition on teste si le nombre de référence tombe à 0. Si c'est le cas, on le détruit. Donc à chaque association de pointeur ça prend une incrémentation de variable, puis à chaque perte de pointeur ça prend une décrémentation de variable + une condition. On peu aussi enlever ceux qui s'annule comme un appelle de fonction qui va aouté un pointeur puis en supprimé un.
Donc oui c'est moins performant que ne rien faire du tout mais ça permet bien plus de possibilité et surtout moins de cassage de tête.
Je me demandais si ce principe est le même que le Garbage Collector, car rien n'est conservé ici, il n'y a pas vraiment de notion de garbage?

[Neckara]

on peut donc supposé qu'avec 4 thread on peu obtenir les performances maximal

Ce n'est pas aussi simple.
Il faut vraiment faire des benchmark pour le savoir.
Ce va aussi fortement dépendre de l'algorithme qu'on souhaite parallélisé et comment on va le faire.

Si les traitements sont indépendants, il n'y a aucun problème à parallélisé.
Par contre, s'il y a des dépendances, même sans aucun "lock", ceci va forcer la recherche dans le cache L3 des variables, "impossible" d'utiliser les registres, le cache L1 ou L2 pour "stocker" la variable vu que d'autres cœurs peuvent utiliser cette même variable.
En effet, si le cœur A a dans son cache L1 "var = 2" et le cœur B, "var = 5", on risque d'avoir quelques problèmes .

Après, avec des threads, on peut gagner des facteurs théoriques de 16 (16 cœurs / 8 cœurs + hyperthreading (?) ).
L'optimisation sur un seul cœur, cela peut aller à des facteurs 200 voir plus. Il faut alors voir si en parallélisant, on conserve ces optimisations ou non.

Après, il y a aussi l'hyper-threading, est-ce qu'on peut exécuter plusieurs threads sur le même cœur ?
Cela va dépendre très fortement des instructions des threads. Mais cela permet au moins d'avoir une réactivité d'un thread (ex. affichage) quand l'autre est occupé par un algorithme complexe.
Je me demande si avec l'hyper-threading, ils peuvent partager directement des registres (?), si oui, cela peut aussi dépendre du CPU .

Après, on est pas tout seul, il y a l'OS, d'autres applications qui vont demander le CPU, donc le nombre de CPU, n'est pas nécessairement le nombre de thread "optimal". Mais une chose qui est "sûre", avoir plus de 1000 thread, cela ne sert à rien.
Ensuite, tout le monde n'a pas des 16 ou 8 cœurs, actuellement on a encore des personnes avec seulement 2 cœurs.

chaque thread qui attend la fin d'un autre consomme le CPU pour rien

Non. Un thread qui attend ne consomme rien.
En revanche, les changements de contextes ne sont pas gratuit, et si on a 1000 threads qui attendent 99% du temps, cela veut dire qu'un bon nombre de threads ne servent à rien ici.

Après, le "lock free", ce n'est pas toujours possible pour certaines portions de codes critiques.
Un "lock free", c'est le hardware qui triche. En gros le thread n'attendra plus un autre thread, mais la fin de l'exécution du lock free. Cela doit coûter quelques centaines de cycles (?) tout au plus, donc cela reste relativement négligeable tant qu'on en abuse pas.

en plus de la création/destruction de celui-ci.

Cela ne coûte rien, tu créé les threads au démarrage de ton application puis tu fait un pool de thread.


Après, je ne suis pas "contre les threads", c'est juste que c'est plus compliqué que "plus je fais de threads, plus je serais rapide".
Au delà des performances qui peuvent être remises en cause dans certains cas, il y a aussi la complexité de l'application :

• pour déboguer ;
• pour éventuellement les locks, éviter les dead-locks ;
• éviter d'être trop souvent en "attente" d'un autre thread ;
• pour les variables "partagées" entre les threads, les sections critiques ;
• les bibliothèques qui ne sont pas safe-threads ;
• les bibliothèques dont certaines fonctions doivent être appelée obligatoirement sur le premier thread ;
• les bibliothèques dont certaines méthodes doivent être appelée dans le thread où un certain objet a été construit ;
• etc.

Bref, l'application peut devenir plus complexe à comprendre et à maintenir tout cela pour un gains en performance hypothétique alors qu'on ne sait même pas si on en a réellement besoin.

En résumé, évitons l'optimisation prématurée, faisons simple, un seul thread puis identifions les goulots d'étranglements, faisons des benchmarks.
Avant de faire des threads, déjà regarder si on peut améliorer la complexité, des goulots d'étranglements, etc.
Et si on s’aperçoit qu'il faut vraiment faire des threads, on en fera et on pourra tester et comparer si on gagne vraiment.

Bref, KISS, YAGNI.

Je me demandais si ce principe est le même que le Garbage Collector, car rien n'est conservé ici, il n'y a pas vraiment de notion de garbage?

Le garbage collector ne fonctionne pas sur le même principe.

Pour faire simple, régulièrement, il vérifie si le bloc mémoire est encore "référencées" si elle ne l'est plus, il libère la mémoire.
Par contre il ne me semble pas qu'il compte les références (je ne sais plus comment il fait d'ailleurs).
Si elle est encore référencée, il la mettra dans un autre "groupe" qu'il vérifiera moins souvent.
Le garbage collector se lançant généralement pendant des moments de "pauses", il ne coûte pratiquement rien.

En revanche, tu ne sais pas quand ta variable sera détruite, donc tu ne peux pas vraiment avoir de "destructeur" pourtant souvent très utiles... le Java 7 a essayé de corriger cela avec des try-with-ressources, mais bon....
Tu peux aussi te retrouver avec des fuites mémoires à l'intérieur de boucles car tu alloues plus vite que le garbage collector ne libère.

[Invité]

J'ai tenté d'apporter quelque petites corrections pour que ça soit plus clair, mais bon...

J'ai aussi créé une nouvelle page, sur le multiple dispatch.

[mintho carmo]

@Neckara: je t'accorde que ma réponse fait un peu trop lynchage. C'est le côté "tête de mule" de Lolilolight qui m'a énervé un peu (et en voyant ça réponse, ça n'a pas l'air de changer)

@Lolilolight: honnêtement, ton CV, je ne le connais pas et je m'en moque un peu. Je juge les personnes à ce qu'elles disent sur le forum pour évaluer leur niveau.

unique_ptr + pointeur nu + multi thread != pas de problème. Ce n'est pas parce que tu n'as pas de problème (ou que tu n'as pas réalisé que tu avais des problèmes) que faire cela n'est pas dangereux. Certains font du C++ old school sans avoir trop de problème, ce n'est pas pour autant que c'est une mauvaise pratique.
J'ai redonné le lien de la discussion sur le forum C++, où j'explique le problème. A la rigueur, tu m'aurais dit unique_ptr + pointeur nu == pas de problème si on n'est pas en multi threads, c'est discutable (le fait de considérer que l'on est toujours en multi threads par défaut est un choix de sécurité, on peut faire un choix différent selon le contexte, mais il faut le justifier). Mais là, en multi threads, c'est casse gueule (même si tu ne comprends pas pourquoi)

Pour le CPU/GPU, quand tu dis qu'on a pas besoin des threads sur CPU parce que l'on a le GPU, c'est que tu considères qu'ils effectuent les mêmes tâches, qu'ils sont interchangeables. Ce qui est faux

@all: pour le GC, ce n'est pas le principe en lui même qui est critiquable (cf mon message, le C++ utilise aussi des systèmes de gestion de ressources), mais c'est généralement sont implémentation en Java. C'est à dire qu'il soit obligatoire (ce qui impose god object, hiérarchie d'objet basé dessus, pas de possibilité d'utiliser la sémantique de valeur, pas de possibilité de gérer soi même les ressources) et qu'il ne soit pas prédicable (cf la réponse de Neckara, on ne sait pas quand les ressources sont libérées)

@Neckara: si, c'est un compteur de références (comme shared en gros)

EDIT : je trouve aussi que c'est une bonne chose d'écrire des articles, cela est très formateur. Pour pour que cela soit formateur (et pas simplement de la discussion de comptoir), il faut que l'article soit relu et que l'on ait des retours. Il est préférable d'écrire pour un site qui a un processus de relecture (ici par exemple) que de publier uniquement sur son blog.

[Neckara]

@Neckara: si, c'est un compteur de références (comme shared en gros)

Pourtant, j'avais cru voir sur le forum que justement le GC Java est bien plus performant que les shared justement parce qu'il ne compte pas les références. Après il semble y avoir plusieurs implémentations de GC pour Java.

Mais s'il compte bel et bien les références, je ne comprend pas le choix de Java/de son GC concernant la destruction "non prédictible" des objets avec tous les problèmes que cela peut entraîner.

[maeiky]

Cela ne coûte rien, tu créé les threads au démarrage de ton application puis tu fait un pool de thread.

Le pool ne coute rien? Le pool ça veux bien dire tester sans cesse la valeur? Il y a un Sleep la dedans??

Le garbage collector se lançant généralement pendant des moments de "pauses", il ne coûte pratiquement rien.

Fait attention en disant que ça ne coute presque rien, juste passer en revue toute la mémoire me semble un travail astronomique. L'avantage en performances par rapport à un système de référence est qu'il peu attendre avant de faire le ménage, par exemple un jeu qui tourne à 60 fps, il pourrait faire le ménage à toute les secondes. Sauf que plus on attend et plus il y de chose à nettoyer et plus de chose à détruire simultanément, ce qui pourrait causé de sérieux lag si le jeux utilise déjà en grande partie les ressources CPU. De plus pour une application qui doit normalement laisser du temps d’exécution aux autres tâches ne peu pas réellement dormir, puisqu’il faut sans cesse examiner la mémoire. Tandis que d'un autre coté le comptage par références n'a pas un énorme coût, normalement les changements de pointeurs ne sont pas si fréquent que ça. Ensuite, il reste les problèmes de référence cyclique VS un GC qui crée une mémoire instable pouvant excéder la capacité maximum.

Sur le devblog :

Erreur n°4 : Utiliser un langage qui utilise un garbage collector c’est mieux.

Hum non. x)

Pour libérer la mémoire automatiquement il faut compter combien de fois une variable est référencées, bref, tester si la variable n’est plus référencée et cela n’est pas gratuit, de plus, ceci cache la sémantique des classes, le programmeur doit toujours savoir quelle classe est propriétaire de la ressource mémoire.

D'après moi un comptage par référence et un GC sont 2 systèmes totalement différent. Si tu parle de GC il ne devrait pas y avoir de notion de "compter combien de fois une variable est référencées", puisqu’en comptant les références tu n'as pas besoin de GC. Un GC c'est plus "Est-ce que ma variable est accessible?". C'est soit un, soit l'autre. C'est donc un peu faux de dire ça. Faudrait voir aussi comment Java procède par exemple.

Bon je dis ça, même si Wikipedia semble dire le contraire, ils ont mit le compte par référence dans la section GC alors qu'en réalité c'est plus une alternative
http://fr.wikipedia.org/wiki/Ramasse...nformatique%29

[Neckara]

Le pool ne coute rien? Le pool ça veux bien dire tester sans cesse la valeur? Il y a un Sleep la dedans??

Pas du tout, tu fait une attente passive, surtout pas une attente active !

juste passer en revue toute la mémoire me semble un travail astronomique.

Il ne le fait pas à chaque cycle et ne vérifie pas toute la mémoire.
Et s'il le fait quand ton application ne fait rien... on ne peut pas vraiment dire que cela te "coûte" vraiment.

Sauf que plus on attend et plus il y de chose à nettoyer et plus de chose à détruire simultanément, ce qui pourrait causé de sérieux lag si le jeux utilise déjà en grande partie les ressources CPU.

C'est justement pour cela qu'on évite d'utiliser le GC dans des jeux.

puisqu’il faut sans cesse examiner la mémoire.

C'est tout de même à nuancer. Après je déteste moi aussi le GC, je ne vais tout de même pas le défendre .

Tandis que d'un autre coté le comptage par références n'a pas un énorme coût, normalement les changements de pointeurs ne sont pas si fréquent que ça.

Tout à fait d'accord. Mais d'après des benchmarks obscurs de javaeux, le GC serait "plus performant" que le comptage de référence style shared_ptr.
Va falloir que je redemande à paissad un jour...

Personnellement, on vire le GC de Java, on compte les références, on libère dès qu'il faut libérer, on appelle systématiquement finalize et on résout 100% des problèmes liés au GC Java. Au lieu de tenter des hack maladroit pour résoudre certains problèmes (try-with-ressources).

Ensuite, il reste les problèmes de référence cyclique

Tu met des sortes de "weak_ptr", et tu classes le reste dans des erreurs de conception .

[Invité]

Je ne sais quel méthode le GC de java utilise, comptage de références ou bien parcours de la mémoire mais en tout cas que ça le fasse pendant des temps de pause ou pas cela à quand même un coût surtout si il y a beaucoup de choses à libérer, à éviter dans un jeux. :/

Personnellement, je n'ai jamais eu de soucis dans un contexte multi-thread avec des std::unique_ptr donc je ne vois pas très bien en quoi cela peut poser des soucis.

Le gpu, n'effectue pas les même tâche que le cpu en effet mais il permet déjà de faire du double buffering par exemple, donc on n'a pas besoin de thread pour faire cela.
Bref c'est plutôt cela que je voulais faire passer, il faudra peut être que je change encore quelque trucs pour que cela soit parfait.

[maeiky]

Tout à fait d'accord. Mais d'après des benchmarks obscurs de javaeux, le GC serait "plus performant" que le comptage de référence style shared_ptr.
Va falloir que je redemande à paissad un jour...

Tout ça est très relatif, car comme je disais, beaucoup de pointeur peuvent être évité d'être compté, si on prend par exemple le passage en paramètre d'un pointeur dans une fonction, normalement tu ajoute +1 puis à la fin de cette fonction tu l'enlève -1, donc les 2 s'annulent. J'ai moi même implémenter mon propre système de compte par référence, ma question est donc est-ce que le shared_ptr élimine ces comptes non utile?

[Neckara]

Référence sur shared_ptr ou move semantique.

Ou peut-^etre weak_ptr ?

Après je vois des cas où cela ne serait absolument pas inutile.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

foo ( a.shared_ptr () );

foo met a nullptr a.shared_ptr ()
Mais a besoin que l'objet reste encore un peu en vie.

[mintho carmo]

Personnellement, je n'ai jamais eu de soucis dans un contexte multi-thread avec des std::unique_ptr donc je ne vois pas très bien en quoi cela peut poser des soucis.

Relis la discussion du forum C++ que j'ai link.
Ce n'est pas parce que tu n'as pas rencontré ce problème (ou pas vu que tu l'avais) que ce que tu fais est safe (et que c'est une bonne pratique).

Mais si le raisonnement que je pressente te semble discutable, n’hésite pas a présenter tes arguments et/ou tes codes d'exemples sur le forum C++.

[Invité]

Afin que le projet avance, j'ai décidé de freiner certaines choses au profil d'autres choses :

-Etant donné que je ne peux pas avancer sans que l'autre moteur (LastEngine) soit plus avancé, j'ai décidé de freiner le développement de ce côté là.
En plus, j'ai quelque petite chose à finir au niveau de mon moteur que j'espère avoir terminées pour d'ici la fin de l'année :

-J'ai bientôt fini de générer la documentation, il ne me reste plus que le module réseau, cela devrait donc être terminé bientôt.
-Je dois séparer encore le code à différent endroit, je pense que je vais faire des fichiers séparer pour prototype, implémentation de template, et définition.
-Je dois encore rendre le linkage dynamique fonctionnel.
-Et une dernière chose que je vais ajouter, proposer une implémentation non "threadée" des différents sytème, le développeur aura alors la possibilité de choisir entre les deux, je vais aussi en profiter pour faire pas mal de tests. (essayer d'endormir les threads un certains temps pour éviter des appels trop fréquent à lock sans que cela soit saccader.)
-Je vais également faire des pré-headers pour la compilation.

PS : Il faudrait peut être aussi que j'ajoute une démo, elle ne sera pas extraordinaire mais contiendra au moins tout ce qu'on attend d'un jeux.

-Multi-joueur.
-Sauvegarde.
-Une IA. (basique)
-Des menus.
-Ombres et lumières.
-Des guis.
-Une gestion des collisions.
-Un système de particules
-Gestion d'événements utilisateurs. (Les actions ainsi que les déclencheurs)

[Invité]

J'ai trouvé une manière d'éviter les appels trop fréquent à lock, j'avais peur que cela donne un rendu plus saccadé mais en ayant fait un test, cela ne rend pas le rendu plus saccadé (même à 10 fps), c'est juste que le héro avance moins vite. (Mais pour ça il suffise que je change la vitesse. )

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
while (running) {
            std::chrono::milliseconds dura(100);
            std::this_thread::sleep_for(dura);
            std::unique_lock<std::mutex> locker(g_lock_update);
            g_signal.wait(locker, [&](){return needToUpdate || !running;});
            if (needToUpdate)
                onUpdate();
            g_notified = true;
            needToUpdate = false;
            g_signal.notify_one();
}

La fonction onUpdate peut prendre pas mal de temps à s'exécuter donc l'exécuter moins souvent me semble être une bonne idée.