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.