Besoin d'explications et de conseils sur les threads

Version imprimable

26/02/2008, 18h18
matteli

Besoin d'explications et de conseils sur les threads

Salut,

Je programme actuellement un jeu (du type Europa Universalis, pour ceux qui connaisse). J'ai besoin de séparer 2 parties de programme.

Une partie (A) contient : la gestion des events clavier et souris et le rendu. Cette partie est cadencée à 25 i/s et est prioritaire sur B

Une autre (B)contient le reste : IA, évolution des paramètres du jeu ... Cette partie évolue avec l'échelle du temps du jeu. Ca veut dire qu'elle peut ralentir si les calculs le nécessite.

La partie B peut être interrompue pour laisser la partie A se réaliser et se finir après.

J'utilise SDL, opengl, GLUT comme librairies.

J'ai vu la notion de thread dans la SDL. J'imagine que c'est ça qui va résoudre mon problème.

D'où ma question : Est ce que tout peut être résolu avec les threads ? (séparation des programmes, priorité d'un thread sur l'autre, interruption d'un thread puis reprise...)

De façon générale, si vous connaissez des tutos ou des sources qui traitent de mon problème?

Merci

PS : J'imagine que le sujet a déjà été traité et j'ai fait quelques recherches mais rien de bien concluant.
26/02/2008, 18h31
fearyourself

Bonjour,

Comme souvent, on conseille aux gens de ne pas mettre des threads en place avant que cela soit vraiment nécessaire. Il est possible que ton programme puisse tourner sans en avoir recours.

Ensuite, je ne comprends pas vraiment comment tu peux utiliser SDL et Glut... Qui fait quoi dans ce contexte ?

Dernier point, je ne pense pas que les threads te permettront de définir exactement ton système comme cela. La seule chose que tu peux vraiment faire c'est te débrouiller pour que ton code (B) sache s'arrêter rapidement et se reprendre.

Par contre, si tu lances les deux threads sans t'occuper de ces détails, il est possible que tu aurais un bon résultats.

Ma conclusion serait : écrit le programme sans thread mais en préparant pour leur présence si nécessaire. Ensuite, tu peux les ajouter et voir s'il faudra, par la suite, faire des réglages pour obtenir ce que tu cherches.

Jc
26/02/2008, 18h36
matteli

J'utilise GLUT pour l'affichage de caractères.
Je trouve SDL_ttf pas adapté pour la SDL associé à opengl. J'ai utilisé ton code (CTexte) mais pour faire du temps réel, je trouve que ça ralentit.

En tout cas merci pour ta réponse.

Je ne pense pas que mon code sans thread puisse passer. Le code de la partie B peut être assez long.

Mais je vais suivre ton conseil et commencer sans.

Au fait, je me suis trompé de sous-forum, je voulais mettre ça dans le sous-forum SDL.

Je viens de me rendre compte que c'est toi qui a fait les tutos pong et morpion.

Il m'ont beaucoup servi et me serve toujours. :king:

bon apparemment le timer de la SDL me permettra de faire ça.
27/02/2008, 12h55
Emmanuel Deloget

Citation:

Envoyé par fearyourself

Bonjour,

Comme souvent, on conseille aux gens de ne pas mettre des threads en place avant que cela soit vraiment nécessaire. Il est possible que ton programme puisse tourner sans en avoir recours.

Tournons nous vers l'avenir ! Comme l'a dit Herb Sutter, "the free lunch is over" - il est grand temps d'entrer dans l'ère de la gestion concurrentielle des données. D'autant que pour le coup, cela simplifie énormément l'architecture de l'application.

Une application tel que présentée par matteli (basé sur 2 threads dont l'une gère controler+view et l'autre le modèle de l'application) est une bonne idée. En fait, il s'agit d'un modèle de plus en plus utilisé dans le cadre du développement de jeux vidéo.

La première thread effectue la capture des entrées utilisateur et les stocke dans une zone prévue a cet effet (après traitement si besoin est (par exemple, pour transformer une combinaison de touches en un flag "combo")). Une fois cette tâche effectuée, elle effectue le rendu du dernier état connu du modèle de l'application.

Pendant ce temps, la deuxième thread récupère les dernières entrées utilisateur et modifie le modèle en conséquence. Une fois modifié, le modèle est stocké de manière à ce que la thread de rendu puisse le lire sans perturber les calculs subséquents.

On a besoin de 2 points de synchronisation (2 mutex) :
1) lecture (thread 2) et écriture (thread 1) des entrées utilisateur capturée
2) lecture (thread 1) et écriture (thread 2) du modèle de l'application mis à jour et prêt pour le rendu.

A noter que ce découpage impose une architecture logicielle particulière et (selon moi) plus à même de résister au temps qui passe qu'une architecture basée sur l'idée que le programme est mono-thread.

Citation:

Envoyé par fearyourself

Ma conclusion serait : écrit le programme sans thread mais en préparant pour leur présence si nécessaire. Ensuite, tu peux les ajouter et voir s'il faudra, par la suite, faire des réglages pour obtenir ce que tu cherches.
Jc

Pour le coup, ça veut dire que la thread B est transformée en un automate (puisqu'il faut pouvoir reprendre à certaines tâches particulières). On ne gagne pas grand chose à garder un modèle monothread.
28/02/2008, 21h38
fearyourself

Citation:

Envoyé par Emmanuel Deloget

Pour le coup, ça veut dire que la thread B est transformée en un automate (puisqu'il faut pouvoir reprendre à certaines tâches particulières). On ne gagne pas grand chose à garder un modèle monothread.

Si... la simplicité.

Le problème souvent rencontré est de perdre du temps sur des détails d'implémentation au début. Lorsqu'on commence un projet, ce n'est pas forcément bon de s'attaquer directement au problème des threads.

Après, c'est une question de qualité du programmeur et ce qu'il/elle sait faire. Dans le meilleur des mondes, je dirais : oui on fait des threads et en plus on se débrouille pour que chaque thread tourne sur un des coeurs du super dual/quad core...

Jc
29/02/2008, 10h30
Emmanuel Deloget

Citation:

Envoyé par fearyourself

Si... la simplicité.

Le problème souvent rencontré est de perdre du temps sur des détails d'implémentation au début. Lorsqu'on commence un projet, ce n'est pas forcément bon de s'attaquer directement au problème des threads.

Je concède ce point.

Citation:

Envoyé par fearyourself

Après, c'est une question de qualité du programmeur et ce qu'il/elle sait faire. Dans le meilleur des mondes, je dirais : oui on fait des threads et en plus on se débrouille pour que chaque thread tourne sur un des coeurs du super dual/quad core...

Jc

Choisir l'affinity des thread soit même, c'est aussi empêcher l'OS de le faire - et donc modifier le comportement des autres programmes. Dans un système ou un seul process tourne à un moment donné, cela peut valoir le coup. Dans le cas ou plusieurs process tournent, dont un certain nombre en tâche de fond (comme sur Windows, Mac OS X ou Linux), on risque de diminuer les performances du système.

Dans leur présentation "Practical multi-threading for game performance" à la GCDC, Leigh Davis (Intel) et Doug Binks (CryTek) ont tous les deux insisté sur ce point : il peut être utile d'assigner une thread a un coeur, mais cela doit être fait d'une part dans le respect des opérations de l'OS et d'autre part avec une délicatesse infinie (lire: il faut faire très attention, et le faire uniquement si c'est vraiment utile; donc mesurer, comparer, etc).

(PS: cf cet article sur mon blog (extrait d'un article publié sur Gamedev.net)).
29/02/2008, 17h49
fearyourself

Citation:

Envoyé par Emmanuel Deloget

Choisir l'affinity des thread soit même, c'est aussi empêcher l'OS de le faire - et donc modifier le comportement des autres programmes. Dans un système ou un seul process tourne à un moment donné, cela peut valoir le coup. Dans le cas ou plusieurs process tournent, dont un certain nombre en tâche de fond (comme sur Windows, Mac OS X ou Linux), on risque de diminuer les performances du système.

Attention, nous partons dans un troll et ce n'est pas le rôle de ce fil. Je pense qu'on est tous les deux d'accord sur le mérite des threads lorsque c'est maîtrisé. Que cela soit avec l'aide de l'OS ou non pour l'affectation aux coeurs du processeur. Par contre, pour un débutant, cela est rarement le cas puisqu'il se bat avec d'autres concepts en même temps.

C'est pour cela et seulement cela, qu'on déconseille les threads au début.
Jc
01/03/2008, 15h03
matteli

Il semblerait que de mettre la gestion des évènements dans un autre thread que la boucle main ne marche pas.

Du coup, j'ai implanté la gestion des évènements et le rendu dans le main et j'ai crée un thread pour le reste.

On verra bien.
01/03/2008, 15h16
vanacid

L'utilité principale des threads en programmation (et la raison pour laquelle ils ont été inventé justement) C'est pour éviter d'avoir une application qui se gèle pendant un traitement bloquant.

Ça n'a pas été inventé pour accélérer un jeu au départ. Aujourd'hui en tend à faire des threads pour obtenir plus de vitesse et on s'égare.

Mettre la gestion des événements dans un autre thread que la boucle principale d'un jeu me semble très casse gueule.

Voici les choses qui me semblent plus appropriés pour un thread :
- Charger les éléments de la prochaine map en arrière plan
- Effectuer le traitement de l'IA pour les prochains frames pendant le rendu des frames précédents
- Gérer l'arrivée des messages dans un jeu multi-joueur
- Faire une sauvegarde automatique à un checkpoint sans que le jeu ne lag

Donc, si on veut faire des threads, s'assurer qu'on les fait pour quelque chose d'utile et non pas "threader" pour le plaisir de "threader".

Enfin, ça reste mon opinion
01/03/2008, 20h38
LeGreg

Citation:

Envoyé par matteli

Il semblerait que de mettre la gestion des évènements dans un autre thread que la boucle main ne marche pas.

Si si cela marche, mais il faut comprendre que le main thread (le thread qui est automatiquement lancé lors du démarrage de l'appli et qui fait quitter l'application si il sort de la fonction main) n'est pas forcément celle qui gère les evenements que reçoit le thread qui a créé la fenètre (qui là par contre doit être le même).

LeGreg
01/03/2008, 20h43
LeGreg

Citation:

Envoyé par vanacid

Ça n'a pas été inventé pour accélérer un jeu au départ. Aujourd'hui en tend à faire des threads pour obtenir plus de vitesse et on s'égare.

Je crois que tu as raté le coche des CPU multicores, et du Cell.
Aujourd'hui une grande partie des PCs vendus ont plusieurs cores (2, voire quatre, bientot 8, j'ai même vu un PC faisant tourner Windows avec 32 cores AMD). Donc pour exploiter leur puissance à 100% il n'y a pas d'autres solutions que de faire tourner ton application dans plusieurs threads.
Ceci dit le chemin de la parallalélisation (efficace !) est long et ardu pour beaucoup de gens (même pour les pros).

LeGreg
01/03/2008, 23h58
vanacid

Citation:

Envoyé par LeGreg

Je crois que tu as raté le coche des CPU multicores, et du Cell.

Non, j'ai vu le train passer...
J'ai un dual-core sur ma machine. La principale raison pour laquelle j'aime le dual-core c'est pour augmenter la réactivité du système quand plein d'applications roulent en même temps.
Lancer une compilation pendant qu'on écoute de la musique et qu'on chat sur MSN par exemple.

Citation:

Envoyé par LeGreg

Donc pour exploiter leur puissance à 100% il n'y a pas d'autres solutions que de faire tourner ton application dans plusieurs threads.

C'est sur que vu comme ça c'est vrai, par contre, je ne vois pas comment on peut surcharger des processeurs aussi puissant que ceux d'aujourd'hui.

On a déjà assez de puissance en utilisant un minimum de thread :

- Un thread qui gère le jeu en tant que tel
- Un autre qui s'occupe du chargement en arrière-plan pour éviter les fameux "Loading" (Half-Life 2 est particulièrement irritant sur ce point).
- Si possible, un thread qui s'occupe de l'IA.

Citation:

Envoyé par LeGreg

Ceci dit le chemin de la parallalélisation (efficace !) est long et ardu pour beaucoup de gens (même pour les pros).

C'est qu'on essaie de paralléliser des trucs qui se parallélisent mal. J'ai de la difficulté à comprendre pourquoi.

Je ne crois pas que monopoliser tous les cores quand on fait un jeu fasse en sorte que le jeu soit meilleur. On doit penser à paralléliser lorsqu'on sait qu'on va manquer de puissance CPU. Ce qui est loin d'être le cas pour la majorité des jeux. C'est la carte graphique qui manque de puissance avant le processeur la majorité du temps.

Enfin, si on veut se casser la tête à penser comment paralléliser des choses simples au lieu de passer son énergie à affiner le gameplay et améliorer l'algorithme de base, c'est le choix de chacun.

Selon moi, avec des délais de 7 mois à 2 ans, je ne pense pas que tout le monde ait le temps de se couper les cheveux en quatre. On veut un bon jeu, point.

Je ne tiens pas à multiplier les threads (ce sera 2 maxi).

Je fais des tests pour voir comment la priorité des threads est gérés.
Quand je lance 2 thread (hors main thread), il tourne à la même vitesse (logique).

Par contre si je lance un thread et le main thread, j'obtiens une différence de 10% en terme de performance au profit du thread.

Voilà le code que j'utilise :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
 
#include <iostream>
#include <SDL/SDL.h>
#include <SDL/SDL_thread.h>
long i;
long j;
long k=100000000;
long m;
SDL_mutex* myMutex;
int last;
 
int bthread (void* data)
{
    //SDL_mutexP(myMutex);
    while (SDL_GetTicks()-last<1000)
    {
        ++i;
    }
    return (0);
    //SDL_mutexV(myMutex);
 
}
int bthread2 (void* data)
{
    //SDL_mutexP(myMutex);
    m=i;
    while (SDL_GetTicks()-last<1000)
    {
        ++j;
    }
    return (0);
    //SDL_mutexV(myMutex);
 
}
int main ( int argc, char** argv )
{
    myMutex = SDL_CreateMutex();
    atexit(SDL_Quit);
    SDL_Thread *thread= NULL;
    SDL_Thread *thread2= NULL;
    last=SDL_GetTicks();
    thread = SDL_CreateThread( bthread, NULL );
    //thread2 = SDL_CreateThread(bthread2, NULL );
 
    //SDL_WaitThread(thread2, NULL);
    //SDL_WaitThread(thread, NULL);
 
    //SDL_mutexP(myMutex);
 
    m=i;
    while (SDL_GetTicks()-last<1000)
    {
        ++j;
    }
    //SDL_mutexV(myMutex);
 
    std::cout<<"thread : "<<i<<std::endl;
    std::cout<<"boucle : "<<j<<"-"<<m<<"="<<j-m<<std::endl;
    return 0;
}

Vous avez des explications à ça ?