Discussion :

[Tozenkaun]

Voilà, je programme depuis quelques temps un projet en C++ (un jeu)
Et j'ai constaté que sur mon processeur (un core i7 860) le projet tourne plus vite en terme de frame rate de 10% sur 2 coeurs actifs que sur 4 actifs.

Aussi afin d'optimiser les ressources de mon processeur j'aimerai savoir la meilleur manière de m'y prendre.

J'utilise Visual C++ express edition 2010 (C++ et directX 10)
Je suppose que je dois changer la structure de mes algorithmes pour les rendre parallèles et donc pouvez m'orienter sur les choix à faire (bibliothèques conseillées avec lien sur la doc , maximum de thread à créer... )

Pour allez plus loin afin de rendre mon projet compatible avec d'autres processeurs (simple coeur ou double coeur...) comment acceder en C++ au caractéristique du processeur utilisé ?

Merci d'avance pour vos précieux conseils

[stardeath]

déjà la grande question c'est, je pense, est ce que tes algos sont parallélisables et est ce que la parallélisation va vraiment servir à quelque chose?

je m'explique, tu es dans un jeu, que le proc soit à 100% en permanence tu t'en moques un peu. en plus le rendu doit être fait par le thread principal quoi qu'il arrive, donc pas parallélisable.

en bibliothèque tu as :
- openmp, le moins intrusif
- threading building blocks, où il faut repenser entièrement son découpage de classe
- les threads classiques, où il faut tout gérer à la main

[Tozenkaun]

J'ai pu voir que dans le commerce certains jeux sont optimisés pour les processeurs multi coeurs (c'est écrit dessus ), en ce sens j'ai déjà réfléchi à certaines parallélisations:

par exemple sous traiter à des threads des morceaux de scène à afficher: puis tout synchroniser pour envoyer les infos à la carte graphique,
paralléliser l'IA d'entités avec des ressources différentes (pour éviter des accés critiques au données)...

voilà pour mes idées de parallélisations, donc oui c'est faisable.

Maintenant c'est vrai que c'est peu être pas utile, mais mon expérience des threads (en JAVA) me fait dire que ça vaut peut-être la peine d'essayer...

[Joel F]

J'ai pu voir que dans le commerce certains jeux sont optimisés pour les processeurs multi coeurs (c'est écrit dessus ), en ce sens j'ai déjà réfléchi à certaines parallélisations:

par exemple sous traiter à des threads des morceaux de scène à afficher: puis tout synchroniser pour envoyer les infos à la carte graphique,
paralléliser l'IA d'entités avec des ressources différentes (pour éviter des accés critiques au données)...

voilà pour mes idées de parallélisations, donc oui c'est faisable.

Maintenant c'est vrai que c'est peu être pas utile, mais mon expérience des threads (en JAVA) me fait dire que ça vaut peut-être la peine d'essayer...

si tu parallelise par taches, tu ne passera pas à l'échelle.
La bonne stratégie est de paralléliser sur les entités et d'appliquer en parallele l'ensemble de la boucle de MAJ du jeu sur chaque entité, synchronisé puis pipeliné le rendu sur la GPU.

[Tozenkaun]

en bibliothèque tu as :
- openmp, le moins intrusif
- threading building blocks, où il faut repenser entièrement son découpage de classe
- les threads classiques, où il faut tout gérer à la main

Si éventuellement je commercialise mon jeu (bien plus tard )
-il faut une license pour TBB
-Donc ma question est quel serait la meilleure bibliothèque à utiliser libre de droit
Qu'entends tu par threads classique (où trouver la doc)

Et dernière question pour reprendre mon 1er message du sujet:
Pour allez plus loin afin de rendre mon projet compatible avec d'autres processeurs (simple coeur ou double coeur...) comment acceder en C++ au caractéristique du processeur utilisé ?

[Joel F]

Si éventuellement je commercialise mon jeu (bien plus tard )
-il faut une license pour TBB
-Donc ma question est quel serait la meilleure bibliothèque à utiliser libre de droit
Qu'entends tu par threads classique (où trouver la doc)

pthread ou meiux boost::thread

Et dernière question pour reprendre mon 1er message du sujet:
Pour allez plus loin afin de rendre mon projet compatible avec d'autres processeurs (simple coeur ou double coeur...) comment acceder en C++ au caractéristique du processeur utilisé ?

Jamais, au grand jamais. Ton code doit etre agn ostique de ces details, sinon il ne apssera pas à l'echelle.

[Tozenkaun]

Ok merci, je commence à étudier tous ça en détails...

[etienne.bezout]

Et j'ai constaté que sur mon processeur (un core i7 860) le projet tourne plus vite en terme de frame rate de 10% sur 2 coeurs actifs que sur 4 actifs.

Le core i7 bénéficie de l'Intel Turbo Boost, qui en gros permet d'augmenter la fréquence de la moitié des coeurs en mettant l'autre moitié au repos.

[Emmanuel Deloget]

A ce niveau, voici deux compte rendus de conférence publiés sur mon blog et sur gamedev.net:

Practical multi-threading for game performance, par Leigh Davis (Intel) en se basant sur le travail conjoint de Intel et Crytek lors du développement du CryEngine 2.

Designing a Game for Multi-core Platforms: Pitfalls & Performance Tuning, par Lionel Lemarié (Sony, tools team), recherche d'une architecture pour un hardware massivement multi-coeur (et son application à la PS3).

Ce sont deux approches différentes. J'aime l'approche de Lionel, qui consiste à transformer les différentes action en un grand nombre de tâches indépendantes s'exécutant très rapidement. Il peut ensuite distribuer ces tâches indépendantes sur plusieurs thread hardware. La distribution elle-même est effectuée par un pseudo scheduler externe.

0) (setup) pour chaque thread, on a une liste de tâche et un coût total
1) A chaque tâche on associe un coût.
2) Chaque fois qu'une tâche est créée, elle est ajoutée à la liste dont le coût total est le plus faible, et ce coût total est mis à jour.
3) les threads dépilent les tâches et les exécutent.

Il faut bien évidemment s'assurer que les tâches sont indépendantes entre-elles, sinon se posent des problèmes de synchro qui sont insurmontables (que faire si une tâche doit se synchroniser avec une tâche qui est dans la même file ?). Les questions de synchro se posent de toute façon, car il faut gérer les accès aux différentes ressources (en lecture/écriture). De plus, dans de très nombreux cas, le rendu doit être effectué par une tâche unique.

Il y a de nombreux problèmes à résoudre, mais cette approche n'en reste pas moins très inétressante pour une architecture multi-coeur.

Autre source d'information Intel Software Dispatch, et plus précisément leur manazine Parralel Universe. C'est principalement commercial, mais il y a de temps en temps des informations intéressantes.

[r.talhouk]

La programmation multi-core est inefficace dans un programme unique , voir dangereuse elle pourra entrée en conflit avec le système d'exploitation qui gère , en parallèle l'exécution de centaines processus en faisant appel aux multiprocesseurs , qui arbitre le niveau d'importance de chacune , donc si vous avez besoin de faire fonctionner plusieurs taches dans un programme en utilisant plusieurs processeurs , il faudra savoir quand et comment interrompre le système d'exploitation , sachant que c'est difficile surtout si le système exécute des processus en level 0 , pour urgence surtout avec les vecteurs d'interruptions matériel et logiciel .

[gbdivers]

La programmation multi-core est inefficace dans un programme unique , voir dangereuse elle pourra entrée en conflit avec le système d'exploitation qui gère , en parallèle l'exécution de centaines processus en faisant appel aux multiprocesseurs , qui arbitre le niveau d'importance de chacune , donc si vous avez besoin de faire fonctionner plusieurs taches dans un programme en utilisant plusieurs processeurs , il faudra savoir quand et comment interrompre le système d'exploitation , sachant que c'est difficile surtout si le système exécute des processus en level 0 , pour urgence surtout avec les vecteurs d'interruptions matériel et logiciel .

Pas tout compris
Mais si j'ai bien compris la première phrase (programme unique -> multicore inefficace), clairement non

[Emmanuel Deloget]

Pas tout compris
Mais si j'ai bien compris la première phrase (programme unique -> multicore inefficace), clairement non

Je crois que la réponse est mieux compréhensible formulée en ces termes : l'OS sait mieux que nous quel coeur il doit affecter à quel thread. Ce en quoi je suis presque complètement d'accord (a ceci près qu'on eut tout à fait développer un système qui marche mieux en forçant l'exécution des threads sur tel ou tel coeur. Il faut savoir ce qu'on fait, c'est sûr, et ça n'est pas à la portée de tout le monde. Mais c'est clairement possible).

Sur la première phrase, je pense qu'elle est mal tournée - l'auteur pensant surement que quand on parle de programmation multicoeur, on parle nécessairement de la programmation de l'affinité de chaque thread. Ce n'est pas le cas - on souhaite juste s'assurer que le nombre d'opérations qu'on va pouvoir exécuter dans un temps donné est linéairement dépendant du nombre de coeur ou de thread hardware proposé par le processeur ou l'OS. Ainsi, si demain un processeur avec deux fois plus de coeurs est utilisé, alors l'application sera deux fois plus performante.

Ca parait simple dit comme ça, mais ça ne l'est pas du tout.

[Klaim]

Je suis en train de faire un jeu qui exploite le multicore en montant son architecture autour de TBB (et std::thread pour le thread graphique parcequ'il doit toujours être le même).

La difficultée est de ne plus penser avec une seule "main loop" comme on l'appelle dans le milieu, mais avec plusieurs, peut être avec des "tick" à fréquence différentes, et chacune de ces loops représentées par des taches.

Le seul hic est qu'a cause de souci de standardisation, OpenGL et DirectX doivent être manipulés par le même thread dans la plupart des action importantes.

Donc ce que j'ai fait c'est que j'ai un thread qui a une sorte de main loop qui fait le rendu a une frequence fixe (autant que possible), et avant le rendu on execute une liste de taches qui peut être modifiée par différents threads sans soucis. Les taches de cette liste sont executée les uns à la suite des autres. Pendant ce temps dans d'autres threads gérés par TBB, d'autres taches sont executées, dont certaines sont leur propres continuité (elles sont ré-executés en boucle) et contiennent des listes sequentielles comme pour le thread graphique.

En fait, pour être plus clair, j'ai des taches paralleles (plus un thread fixe) qui elles même ont des taches non-paralleles, mais qui du coup sont automatiquement syncrhonisées avec le systèmes concerné (graphique, input, audio, IA etc) en evitant les locks de mutex autant que possible (puisqu'ils ne se passent quasimment que lors d'insertions et de suppression des taches dans les listes, de manière optimisées pour ne pas impacter l'execution des taches de la liste).

Ca m'a pris quelque chose comme 2 mois pour étudier, prototyper et mettren en place concretement tout ça (en plsu d'intégrer boost.log parceque c'est thread-safe).

Pour l'instant ça tourne bien mais le je ne fais pas grand chose de violent donc je pourrais peut être en reparler plus tard quand j'aurais beaucoup plus de travail.

Au passage, dans mon cas la modélisation de ce qu'il se passe dans le jeu est dans une serveur (local en solo) ce qui fait qu'il y a toujours 2 process qui tournent pendant qu'on joue: un qui fait "vue" et l'autre qui fait "modele" et qui gère les accès et les règles du jeu. Comme dis auparavant, ça fait que l'OS va équilibrer les deux parties, en plus de TBB qui est utilisé dans les deux process de manière identique mais avec des taches complètement différentes.

Ce que je crains pour l'instant est que le thread graphique, qui déséquilibre le système, devienne un goulot d'étranglement. Mais j'ai l'avantage de faire un jeu qui, je pense, ne devrais pas être gourmand en détails graphiques. Normalement au pire, je vais devoir l'optimiser pour afficher beaucoup de petits objets semblable (via diverses techniques graphiques ) donc ça devrais pas être un souci.


C'est une organisation que j'ai voulu la plus simple possible mais quand même efficace, donc on va voir si je me suis trompé dans quelques mois.

[Emmanuel Deloget]

Je suis en train de faire un jeu qui exploite le multicore en montant son architecture autour de TBB (et std::thread pour le thread graphique parcequ'il doit toujours être le même).

La difficultée est de ne plus penser avec une seule "main loop" comme on l'appelle dans le milieu, mais avec plusieurs, peut être avec des "tick" à fréquence différentes, et chacune de ces loops représentées par des taches.

Le seul hic est qu'a cause de souci de standardisation, OpenGL et DirectX doivent être manipulés par le même thread dans la plupart des action importantes.

Donc ce que j'ai fait c'est que j'ai un thread qui a une sorte de main loop qui fait le rendu a une frequence fixe (autant que possible), et avant le rendu on execute une liste de taches qui peut être modifiée par différents threads sans soucis. Les taches de cette liste sont executée les uns à la suite des autres. Pendant ce temps dans d'autres threads gérés par TBB, d'autres taches sont executées, dont certaines sont leur propres continuité (elles sont ré-executés en boucle) et contiennent des listes sequentielles comme pour le thread graphique.

En fait, pour être plus clair, j'ai des taches paralleles (plus un thread fixe) qui elles même ont des taches non-paralleles, mais qui du coup sont automatiquement syncrhonisées avec le systèmes concerné (graphique, input, audio, IA etc) en evitant les locks de mutex autant que possible (puisqu'ils ne se passent quasimment que lors d'insertions et de suppression des taches dans les listes, de manière optimisées pour ne pas impacter l'execution des taches de la liste).

Ca m'a pris quelque chose comme 2 mois pour étudier, prototyper et mettren en place concretement tout ça (en plsu d'intégrer boost.log parceque c'est thread-safe).

Pour l'instant ça tourne bien mais le je ne fais pas grand chose de violent donc je pourrais peut être en reparler plus tard quand j'aurais beaucoup plus de travail.

Au passage, dans mon cas la modélisation de ce qu'il se passe dans le jeu est dans une serveur (local en solo) ce qui fait qu'il y a toujours 2 process qui tournent pendant qu'on joue: un qui fait "vue" et l'autre qui fait "modele" et qui gère les accès et les règles du jeu. Comme dis auparavant, ça fait que l'OS va équilibrer les deux parties, en plus de TBB qui est utilisé dans les deux process de manière identique mais avec des taches complètement différentes.

Ce que je crains pour l'instant est que le thread graphique, qui déséquilibre le système, devienne un goulot d'étranglement. Mais j'ai l'avantage de faire un jeu qui, je pense, ne devrais pas être gourmand en détails graphiques. Normalement au pire, je vais devoir l'optimiser pour afficher beaucoup de petits objets semblable (via diverses techniques graphiques ) donc ça devrais pas être un souci.


C'est une organisation que j'ai voulu la plus simple possible mais quand même efficace, donc on va voir si je me suis trompé dans quelques mois.

Le problème rsique de se poser si le thread de rendu doit travailler à une fréquence fixe (60 Hz, avec un fallback à 30 Hz si le travail est trop important). Je sens venir deux problèmes :

* D'abord, celui sur lequel tu ne peux pas faire grand chose mais qui, fort heureusement, ne devrait pas se poser. Sur un système non temps réel, tu n'auras pas vraiment de contrôle sur le moment exact où le rendu va se faire - à moins de fortement augmenter sa priorité, mais tu seras quand même en dessous des autres IT ; donc en cas de traffic réseau sévère, tu va probablement avoir une latence appréciable sur le thread de rendu.

* Ensuite, celui qui va probablement se poser, mais sur lequel tu peux agir. Même en supposant que le scheduler de l'OS arrive à ordonnancer le thread de rendu à 60 Hz (ou 30 Hz), il faut que celui-ci ne prenne pas trop de temps (on va supposer que la machine cible a au moins deux thread hardware ; les machines qui en sont dépourvues commencent à se faire rares (Pentium IV première génération), sans quoi tu risque fort de trop limiter le temps nécessaire à l'update (et donc de répéter le rendu de la même frame) ou de ne pas aller assez vite par rapport à l'update (et donc potentiellement de passer sous la barre des 30 Hz, ce qui a un effet désastreux sur le rendu sur une TV HD). Dans les deux cas, dans les faits, tu va te retrouver avec des images qui bougent à une fréquence trop faible pour être agréables à l'oeil.

Enfin, tu dois déjà savoir tout ça

[Klaim]

Le problème rsique de se poser si le thread de rendu doit travailler à une fréquence fixe (60 Hz, avec un fallback à 30 Hz si le travail est trop important). Je sens venir deux problèmes :

* D'abord, celui sur lequel tu ne peux pas faire grand chose mais qui, fort heureusement, ne devrait pas se poser. Sur un système non temps réel, tu n'auras pas vraiment de contrôle sur le moment exact où le rendu va se faire - à moins de fortement augmenter sa priorité, mais tu seras quand même en dessous des autres IT ; donc en cas de traffic réseau sévère, tu va probablement avoir une latence appréciable sur le thread de rendu.

* Ensuite, celui qui va probablement se poser, mais sur lequel tu peux agir. Même en supposant que le scheduler de l'OS arrive à ordonnancer le thread de rendu à 60 Hz (ou 30 Hz), il faut que celui-ci ne prenne pas trop de temps (on va supposer que la machine cible a au moins deux thread hardware ; les machines qui en sont dépourvues commencent à se faire rares (Pentium IV première génération), sans quoi tu risque fort de trop limiter le temps nécessaire à l'update (et donc de répéter le rendu de la même frame) ou de ne pas aller assez vite par rapport à l'update (et donc potentiellement de passer sous la barre des 30 Hz, ce qui a un effet désastreux sur le rendu sur une TV HD). Dans les deux cas, dans les faits, tu va te retrouver avec des images qui bougent à une fréquence trop faible pour être agréables à l'oeil.

Enfin, tu dois déjà savoir tout ça

Oui

En fait c'est un jeu ou il n'y a ni physique, ni impérativité d'avoir un framerate fixe. Autrement dit le rendu peu fluctuer, il doit juste éviter d'être trop lent, comme dans tous jeux. Les règles du jeu modifiant son modèle abstrait sera mis à jour moins de 10 fois par secondes (certainement 8) coté serveur, donc peu de chances de se retrouver avec une forme de lag.
Du coup en réalité le thread graphique ne rends "pas plus" de 60 fps dans mon cas spécifique, et les frames peuvent êtres ignorées si on est en retard sur le rendu - et comme il va y avoir beaucoup d'elements semblables et peu de détails graphique, ça devrais pas poser de problème de vitesse de rendu. (un peu comme si je faisais un jeu d'echec ou toutes les pieces bougent d'une case a l'autre en cycles de secondes, ce qui fait que le rendu peut afficher des animations pendant ce temps qui "illustre" l'état du jeu)

J'ai fait le choix du multicore principalement parceque je pense que l'essentiel des traitements lourds vont se passer dans d'autres fonctionalités spécifique à ce jeu précis et qui sont suffisament isolés les uns des autres pour être mis en concurrence. (mais bon ça reste a confirmer à vrai dire, ça l'était dans mes tests...)

Si c'était un jeu basé sur de la physique et qui serait compétitif au sens ou 60fps pile est très important, j'aurais certainement simplifié les choses pour maintenir l'ensemble du système à la même cadence (sauf l'ia, selon le type de jeu).

D'ailleurs j'avais d'abord tenté cette architecture avec un shoot them up (un bullet-hell pour etre plus spécifique...) et je me suis vite rendu compte qu'a part paralléliser les calculs de collision, il n'y avait aucun interet à utiliser un système de taches. La grande majorité des jeux "simples" sont comme ça, en particulier quand la synchronization modèle-physique->vue est importante pour le jeu, comme n'importe quel jeu d'action a vrai dire.


Par contre ça m'a bien ennuyé (pour rester poli) que je ne puisse pas mettre la tache de rendu en parallèle à cause des accès a OpenGL. Je peux paralléliser les chargements de resources sur la carte graphique (merci Ogre) mais pas moyen de faire des appels de rendu depuis plusieurs threads (comme les taches de tbb ne guarantissent pas le thread sur lequel elles seront executées, ce qui est exactement ce que l'on veut quand on utilise tbb).
Si c'était possible (et visiblement ça le sera d'ici...10 ans...), j'aurais écris le code de manière beaucoup plus uniforme que ce que j'ai actuellement.