Débat : Que peut apporter le multithread au développement de Jeux ?

Le , par C-E.B, Nouveau membre du Club
Bonjour,

Voyant l'avancée technologique dans ce domaine, pensez-vous qu'il soit possible d'exploiter tous les threads disponibles d'un processeur pour un moteur 3D ?

Vous n'êtes pas s'en savoir qu'Intel va lancer courant de l'année 2009 des nouveaux processeurs comportant 2 et 4 core avec chacun des core pouvant exploiter 2 threads.
D'autre part les jeux n'exploite pas encore ces ressources des processeurs, et cela est bien dommage.

Imaginez un processeur dont chaque thread aurait une(des) tâche(s) particulière(s), ce qui permettrait de monter en puissance au niveau des jeux, augmenter de par ce fait la qualité et la réalité.

Est-ce donc possible ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Fraggy Fraggy - Membre régulier http://www.developpez.com
le 20/03/2009 à 20:25
Citation Envoyé par deadalnix  Voir le message
Vive ma physique quantique : http://www.opensparc.net/opensparc-t2/index.html

nan mais qu'est ce qu'il faut pas lire comme anneries.

Quand au thread, ce n'est pas un topic pub ACCLib, merci. Parceque parler de comment marche un truc mais qu'on peut pas savoir comment il marche merci bien. Les jolis graphiques sans aucune spécification du protocole de test c'est vraiment super fiable aussi !

Je suis impressionné.

C'est sur, ça dérape
En plus y a déjà un thread dédié à acclib...

Vincent, les autres questions posez les sur l'autre thread http://www.developpez.net/forums/d67...deo-parallele/
Avatar de shenron666 shenron666 - Expert confirmé http://www.developpez.com
le 24/03/2009 à 17:18
Citation Envoyé par deadalnix  Voir le message
Vive ma physique quantique : http://www.opensparc.net/opensparc-t2/index.html

nan mais qu'est ce qu'il faut pas lire comme anneries.

quel rapport avec le sujet ?

Citation Envoyé par deadalnix
Quand au thread, ce n'est pas un topic pub ACCLib, merci. Parceque parler de comment marche un truc mais qu'on peut pas savoir comment il marche merci bien. Les jolis graphiques sans aucune spécification du protocole de test c'est vraiment super fiable aussi !

parler de Acclib est tout de même en rapport avec le sujet puisqu'il s'agit d'une bibliothèque pouvant visiblement apporter un partage de taches équitable dans un moteur orienté jeux vidéo

si tu veux parler d'autre chose en rapport avec le sujet tu es le bienvenu

edit : au fait
Citation Envoyé par Fraggy  Voir le message
ps : au fait, le xeon 7400 est un proc 8 coeurs

Intel n'a aucun processeur avec plus de 6 coeurs physiques à l'heure actuelle
le xeon 7400 est un cpu 6 coeurs sans SMT (donc 6 threads)
Avatar de Matthieu Brucher Matthieu Brucher - Rédacteur http://www.developpez.com
le 24/03/2009 à 17:43
Si, ils en ont, mais ils n'arrivent pas à le produire, d'où les 6 coeurs
Avatar de shenron666 shenron666 - Expert confirmé http://www.developpez.com
le 24/03/2009 à 23:10
Citation Envoyé par Matthieu Brucher  Voir le message
Si, ils en ont, mais ils n'arrivent pas à le produire, d'où les 6 coeurs

s'ils n'arrivent pas à le produire, alors ils n'en ont pas
les Xeon série 7000 sont des dual-core peryn mis côte à côte
Intel "fusionne" les dies de 2 coeurs pour créer des quad ou des sextuples coeurs
sauf que cette technique a ses limites tout simplement
Avatar de Matthieu Brucher Matthieu Brucher - Rédacteur http://www.developpez.com
le 24/03/2009 à 23:12
Non. Ils ont en pré-production un vrai 8 coeurs basé sur le Nehalem. Là où les 8 coeurs ne sont pas opérationnels, ils en font un 6 coeurs, faisant donc ce qu'ils avaient critiqué chez AMD il y a un an.
Avatar de shenron666 shenron666 - Expert confirmé http://www.developpez.com
le 24/03/2009 à 23:20
je ne sais pas si on parle de la même chose alors
parceque les Xeon 7000 sont des peryn basés sur l'architecture core, pas des nehalem basés sur l'architecture core i7
Avatar de Rémi Coquet Rémi Coquet - Membre actif http://www.developpez.com
le 16/06/2009 à 12:15
J'ai découvert votre réflexion après un post indépendant sur le même sujet:
http://www.developpez.net/forums/d76...hreads-moteur/

Il me semble (c'est un constat dénué de toute forme d'agressivité) que plusieurs confusions, ou plutôt conséquences des intoxications d'un marketing astucieux, sont à l'œuvre dans de nombreux posts:

Si la théorie permet d'échafauder une "vision" mutithread physique des "nouveaux" µp (je ne parle pas pour le moment des coprocesseurs graphiques) le pragmatisme voudrait que l'on vérifie en situation les gains réels en performances et, s'il y en a, mettre en évidence les lieux réels de ses gains. Pour faire simple, "Un µp tient, vaut mieux que deux threads tu l'auras" .

A lire plusieurs, il semblerait que déterminer sois même les cœurs utilisés, l'affinité des threads et "blinder" les niveaux de priorités avec, par exemple, les API bien connues:
AvSetMmThreadCharacteristics
SetProcessAffinityMask
SetThreadPriority
SetThreadAffinityMask
suffise à augmenter les performances en partageant un travail qui serait sagement parallélisé à notre convenance .

Je suis hélas désolé d'avoir à le dire:
Ce n'est absolument pas vrai, ni vérifié en pratique. Toutes les mesures indiquant le contraire.
En un mot, plus direct: "C'est totalement faux."

Je m'explique:
Les fondeurs savent que les codeurs ne connaissent pas grand chose (rien d'agressif dans leurs constatations) aux mécanismes qu'ils mettent en place et ne souhaitent donc pas voir leurs productions dénigrées simplement parce que le code n'est pas performant.
Leurs technologies sont donc prévues pour être les plus libres possible (indépendantes) de la qualité du code (ne tombons pas dans la caricature, je n'ai pas dis "totalement" indépendant, ce serait me faire un vilain procès ).

Donc, moins le code interfère avec une architecture bien conçue, plus il a de chances de tourner efficacement.
En français courant: Chacun son boulot et les vaches seront bien gardée, "vaches" étant mis pour performances, évidemment.

Pourquoi ne pas pratiquer des benchmarks pragmatiques:
Temps réellement passé dans chaque thread par rapport au temps global d'utilisation du µp.
Cela permet des mesures prenant en compte les changements de contextes et les générations des nouvelles interruptions que vous avez décidé de générer de manière unilatérale (sans laisser faire le µp).
J'ai bien peur (en fait, soyons clair: "Je suis sûr de mes affirmations") que les comparaisons multihread µp VS multithread organisé via code présenteront immanquablement le même constat:

Le µp gère ça bien mieux que mon code…

Le µp sait "démonter" et "remonter" des commandes issues d'un même bloc de code ; la vision par thread étant une vision de codeur et non d'électronicien, le µp n'a de profondeur (d'ensemble) de vue que l'instruction suivante, précédente et leur liens contextuels.

Les diverses informations des constructeurs, qui tiennent plus de la vulgarisation que du transfert de technologie (ne soyons pas irréalistes ) présentent souvent les choses sous une forme graphique qui ne précise pas si la gestion des threads est sous le control du codeur ou de l'exécuteur (l'électronique)…
Le but étant de montrer que le multiplexage se fait au niveau temporel et non plus au niveau des tâches proprement dites et qu'il y a un gain mesuré en échelle de temps (c'est bien là l'astuce marketing ).

Tout ce que nous vivons et ressentons se mesure en échelle de temps constant: Une courbe de fonction, les sens (variations d'intensités dans le temps) etc. Donc, faire varier le temps dynamiquement reviendrait à modifier la courbe de perception.

Tant que le temps reste à granulation constante, nous arrivons à maintenir cohérents nos raisonnements de codeurs.
Avec une granulation temporelle dynamiquement variable, ces raisonnements montrent leurs limites dans le domaine qui n'est plus le leur:
La logique programmée.
Les logiques câblées ou locales étant forcément plus rapides que les logiques programmées ou distantes, les gains seront donc obtenus en favorisant les opérations les plus locales et les moins contextuelles possible.
Cette stratégie est celle de tous les µp depuis maintenant plusieurs décennies et la multiplication des cœurs ne change rien à celle-ci. Ne pas s'y conformer n'apportera que des pertes et en aucun cas des gains.
Le rôle du codeur étant de générer la stratégie la plus proche de celle utilisée par sa cible électronique et non pas de parier sur une forme de vue de l'esprit sans aucun rapport avec le pour "qui" il code.

Pour résumer:
- Vous codez pour une électronique conciliante, certes, mais pas dénuée d'orientation et de performances liées à celle-ci.
Il est donc primordial de favoriser l'orientation par rapport à la conciliation: Ne pas chercher à tirer l'électronique vers le code mais bien plutôt de faire le contraire en appuyant ce dernier pleinement sur elle.

- Les threads sont une vue de l'esprit pour le compilateur et non une réalité pour le µp.

- Vous obtiendrez de bien meilleurs résultats en repensant votre stratégie et votre architecture globales, comme cela à été souligné brièvement par plusieurs dans ce topic, cad en désolidarisant "totalement" les tâches les unes des autres et en les rendant non bloquantes.

- Tous les coprocesseurs (sauf cette stupide FPU) sont fondés sur ce principe. Ils sont les réelles threads physiques de votre plate-forme cible.

- Une vision plus matérielle permet de mieux saisir que la mise en parallèle de sérialisations est la bonne méthode: Lancer des séries process hardware réels en même temps. Le hardware possédant, la plupart du temps, une file d'attente vidangeable (cas des GPU, cartes audio, µp…).

Je vous renvoie à l'autre post cité en entête pour un exemple parmi tant d'autres.
Avatar de Matthieu Brucher Matthieu Brucher - Rédacteur http://www.developpez.com
le 17/06/2009 à 8:56
Citation Envoyé par Rémi Coquet  Voir le message
Pour résumer:
- Vous codez pour une électronique conciliante, certes, mais pas dénuée d'orientation et de performances liées à celle-ci.
Il est donc primordial de favoriser l'orientation par rapport à la conciliation: Ne pas chercher à tirer l'électronique vers le code mais bien plutôt de faire le contraire en appuyant ce dernier pleinement sur elle.

- Les threads sont une vue de l'esprit pour le compilateur et non une réalité pour le µp.

- Vous obtiendrez de bien meilleurs résultats en repensant votre stratégie et votre architecture globales, comme cela à été souligné brièvement par plusieurs dans ce topic, cad en désolidarisant "totalement" les tâches les unes des autres et en les rendant non bloquantes.

- Tous les coprocesseurs (sauf cette stupide FPU) sont fondés sur ce principe. Ils sont les réelles threads physiques de votre plate-forme cible.

- Une vision plus matérielle permet de mieux saisir que la mise en parallèle de sérialisations est la bonne méthode: Lancer des séries process hardware réels en même temps. Le hardware possédant, la plupart du temps, une file d'attente vidangeable (cas des GPU, cartes audio, µp…).

Je vous renvoie à l'autre post cité en entête pour un exemple parmi tant d'autres.

C'est pas que je ne suis pas d'accord avec toi, c'est plus que je nuancerai certains propos.
Dans le cas des coeurs qui se partagent la mémoire, OK, l'affinité n'est pas forcément pertinente; En revanche, avec plusieurs processeurs, fixer la localité du processus ainsi que de sa mémoire AUGMENTE les performances. Je parle bien de processus ici.

Le thread n'est pas qu'une vue de l'esprit du compilateur (d'ailleurs, lui ne sait pas ce que c'est du tout, pour le coup, c'est plus l'OS), c'est une réalité pour plusieurs types de CPUs, tous ceux qui ont du SMT. Les coprocesseurs ne peuvent pas être les threads de la plateforme cible. Mais je pense que tu voulais dire qu'il faut les encapsuler dans des threads (et pourquoi tu considères la FPU comme un cas à part, et pas les ALUs ?)

Comme je l'ai dit au début, pour le reste, je suis d'accord avec toi
Avatar de Rémi Coquet Rémi Coquet - Membre actif http://www.developpez.com
le 17/06/2009 à 14:25
Citation Envoyé par Matthieu Brucher  Voir le message
Dans le cas des coeurs qui se partagent la mémoire, OK, l'affinité n'est pas forcément pertinente; En revanche, avec plusieurs processeurs, fixer la localité du processus ainsi que de sa mémoire AUGMENTE les performances. Je parle bien de processus ici.

Le thread n'est pas qu'une vue de l'esprit du compilateur (d'ailleurs, lui ne sait pas ce que c'est du tout, pour le coup, c'est plus l'OS), c'est une réalité pour plusieurs types de CPUs, tous ceux qui ont du SMT. Les coprocesseurs ne peuvent pas être les threads de la plateforme cible. Mais je pense que tu voulais dire qu'il faut les encapsuler dans des threads (et pourquoi tu considères la FPU comme un cas à part, et pas les ALUs ?)


Si tu as plusieurs µp réellement et TOTALEMENT indépendants, effectivement les goulets d'étranglement se déplacent...

Mais j'ai bien peur qu'il n'y ait que très peu chances que tu ne te retrouves à coder pratiquement dans ce cas de figure et la portabilité d'un tel code serait inférieure à zéro (ce qui n'est intéressant que dans le cadre d'une machine dédiée).

Je comprends tout à fait ce que tu désires préciser avec la "connaissance" de l'OS mais dans le cas très pratique d'un codeur qui utilise un compilateur (ce qui arrive régulièrement souvent) son seul interlocuteur, au niveau de la compréhension avant génération du code réel, est le compilateur
Or c'est bien lui qui va organiser les blocs de codes selon une série d'algos et d'options plus moins performantes.
L'OS, lui, ne fait que proposer la vue de l'esprit et enfin, la seule "connaissance" qui puisse trancher est celle du µp cible. Ci celui-ci n'est pas construit pour fabriquer le découpage du code en segments paralléliseables, toutes les formes d'OS, de compilateur ou de délires via bibliothèques n'y changeront vraiment rien.

Je pense que nous sommes aussi d'accord sur ce point là.

La vieille technologie SMT ne change rien au fond du problème: Aucune accélération ne sera obtenue en fixant, via code, le cœur utilisé par un processus.
Faire tourner le même code sur deux µp différents au niveau de cette technologie, produira des performances positives mais fixer les processus sur des cœurs par différentiation au niveau du code ne produira que des ralentissements dans tous les cas.

Un bonne vieille mesure ne fera que confirmer ce propos évident.

Maintenant, il est clair que les fabricants d'outils de développement ne vont pas se tirer une balle dans le pied mais continuer d'utiliser les phobies et les réflexes de base comme leviers d'intoxication efficaces.

Les coprocesseurs sont tout à fait utilisables comme des threads physiques: Le simple fait d'envoyer du code à deux électroniques indépendantes crée, de facto, deux threads (c'est exactement le principe de n'importe quel µp multi-cœurs). Les encapsuler dans des threads logicielles n'apporte rien, si ce n'est une lenteur supplémentaire et quelques nouveaux conflits.

La FPU souffre de vieux problèmes de synchro qui sont à l'origine de 3D Now! et SSEx.
Avatar de Matthieu Brucher Matthieu Brucher - Rédacteur http://www.developpez.com
le 17/06/2009 à 14:34
Citation Envoyé par Rémi Coquet  Voir le message
Si tu as plusieurs µp réellement et TOTALEMENT indépendants, effectivement les goulets d'étranglement se déplacent...

Mais j'ai bien peur qu'il n'y ait que très peu chances que tu ne te retrouves à coder pratiquement dans ce cas de figure et la portabilité d'un tel code serait inférieure à zéro (ce qui n'est intéressant que dans le cadre d'une machine dédiée).

Pas dans le milieux des jeux, en revanche dans d'autres milieux, ça arrive fréquemment (dotn le mien )

Citation Envoyé par Rémi Coquet  Voir le message
Je comprends tout à fait ce que tu désires préciser avec la "connaissance" de l'OS mais dans le cas très pratique d'un codeur qui utilise un compilateur (ce qui arrive régulièrement souvent) son seul interlocuteur, au niveau de la compréhension avant génération du code réel, est le compilateur
Or c'est bien lui qui va organiser les blocs de codes selon une série d'algos et d'options plus moins performantes.
L'OS, lui, ne fait que proposer la vue de l'esprit et enfin, la seule "connaissance" qui puisse trancher est celle du µp cible. Ci celui-ci n'est pas construit pour fabriquer le découpage du code en segments paralléliseables, toutes les formes d'OS, de compilateur ou de délires via bibliothèques n'y changeront vraiment rien.

Je pense que nous sommes aussi d'accord sur ce point là.

+1
Citation Envoyé par Rémi Coquet  Voir le message
La vieille technologie SMT ne change rien au fond du problème: Aucune accélération ne sera obtenue en fixant, via code, le cœur utilisé par un processus.
Faire tourner le même code sur deux µp différents au niveau de cette technologie, produira des performances positives mais fixer les processus sur des cœurs par différentiation au niveau du code ne produira que des ralentissements dans tous les cas.

Un bonne vieille mesure ne fera que confirmer ce propos évident.

Maintenant, il est clair que les fabricants d'outils de développement ne vont pas se tirer une balle dans le pied mais continuer d'utiliser les phobies et les réflexes de base comme leviers d'intoxication efficaces.

Complètement d'accord.
Pour moi, l'affinité n'a d'intérêt que si on fixe aussi la mémoire, et donc c'est en multi-processus.
Citation Envoyé par Rémi Coquet  Voir le message
Les coprocesseurs sont tout à fait utilisables comme des threads physiques: Le simple fait d'envoyer du code à deux électroniques indépendantes crée, de facto, deux threads (c'est exactement le principe de n'importe quel µp multi-cœurs). Les encapsuler dans des threads logicielles n'apporte rien, si ce n'est une lenteur supplémentaire et quelques nouveaux conflits.

OK, tu pars donc d'un traitement asynchrone (parfois, on a du synchrone, auquel cas, on doit encapsuler).
Citation Envoyé par Rémi Coquet  Voir le message
La FPU souffre de vieux problèmes de synchro qui sont à l'origine de 3D Now! et SSEx.

Des problèmes de synchro ? S'il y avait des problèmes de synchro, on aurait changé le modèle depuis longtemps. Sans compter que la FPU est compatible IEEE, ce qui n'est pas toujours le cas des autres systèmes. Tu veux peut-être plus parler du mécanisme sous-jacent, basé sur une pile et des mots de 80bits ?
Avatar de Rémi Coquet Rémi Coquet - Membre actif http://www.developpez.com
le 17/06/2009 à 19:30
Citation Envoyé par Matthieu Brucher  Voir le message
Pas dans le milieux des jeux, en revanche dans d'autres milieux, ça arrive fréquemment (dotn le mien )

Tout est possible en dehors du cadre de ce topic qui, il me semble, limite le débat à celui, très particulier, du jeu (qui n'est pas directement le mien non-plus).
Pour moi, l'affinité n'a d'intérêt que si on fixe aussi la mémoire, et donc c'est en multi-processus

Le lieu, les moyens de partage de la mémoire, ne jouent pas sur l'électronique mais uniquement, par le biais de lOS, sur des mécanismes de limitations ou de protection de ce dernier. La performance des "threads" réelles est obligatoirement liée aux capacités électroniques de la cible, c'est pour cela que je parle de vues de l'esprit. Les threads logicielles n'étant qu'un argument marketing amusant dans le principe si ce n'est triste dans la vision qu'il engendre dans la tête de nombreux codeurs…
OK, tu pars donc d'un traitement asynchrone (parfois, on a du synchrone, auquel cas, on doit encapsuler).

Deux traitements synchrones ne peuvent en aucun cas être multitâches mais pour le mieux sérialisés et prendront toujours plus de temps en générant un peu plus de conflits. Là encore, le marketing du multitâche a fait ses dégâts non seulement dans le grand publique mais dans la production de concepts fantasmagoriques…
Des problèmes de synchro ? S'il y avait des problèmes de synchro, on aurait changé le modèle depuis longtemps. Sans compter que la FPU est compatible IEEE, ce qui n'est pas toujours le cas des autres systèmes. Tu veux peut-être plus parler du mécanisme sous-jacent, basé sur une pile et des mots de 80bits ?

Le fait que la FPU utilise un LIFO travail en 32 64 et 80 bits ne change pas grand chose (IEEE n'est qu'une forme de représentation qui n'a pas grand chose à voir avec la taille des données).

Le problème de synchronisation de la FPU est tout à fait visible à travers des instructions comme fwait ou finit. Il est impossible de travailler avec la FPU sans la re-synchroniser d'une manière ou d'une autre avec la partie integer du µp.

Multitâches, n'a de sens que si tous les processus sont asynchrones, non-bloquants, et réalisé sur des électroniques indépendantes. Ce que j'appelle vues de l'esprit concerne toute la "partie molle" restante
Offres d'emploi IT
Ingénieur études et développement Java JEE H/F
Conserto - Ile de France - Paris (75000)
Leader technique software télécom H/F
Atos - Provence Alpes Côte d'Azur - 206581
DBA Oracle / Administrateur Oracle H/F
EXPERIS IT - France - Monaco

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique 2D - 3D - Jeux : LittleWhite -