Discussion :

[Lsong]

bonjour à tous et à toutes,

je travaille sur un moteur de physique distribué et j'utilise SDL pour la partie thread et donc synchronisation

l'usage des mutex et des sémaphores ne pause pas de problème en soit, c'est trés simple.

SDL_SemWait(sem);
...
SDL_SemPost(sem);

le problème c'est que parfois le sémaphore reste bloquer 16-60 ms sur le wait, alors qu'il n'y a qu'un seul thread !!! Donc je vois mal comment il peu s'auto-interrompre... j'ai vérifié à coup de "cout" le thread ne lance pas deux fois le wait
mais il reste parfois coincé 60ms (environ 1 fois sur 50 appels c'est très variable)
ça arrive une fois de temps en temps mais ça limite les performance de façon assez forte.
Quand j'augmente le nombre de balles dans ma scène le nombre d'appel augmente et les performance s'effondre

sans la synchro je peu gérer 6000 objets en mouvement sur mon 2Ghz
mais avec ces problèmes de sémaphore je ne dépasse pas les 250 ...

c'est un problème connu des sémaphore et mutex SDL ?
c'est un problème d'utilisation ou d'environnement ?
A savoir parfois ce délais est moins fréquent que d'autre.

si quelqu'un a une idée... elle est la bienvenue

[Mat.M]

Pourquoi utiliser des threads dans un jeu il ya eu maintes fois des discussions là-dessus ?
Les threads c'est bon si tu veux faire un jeu multijoeur pour gérer les échanges réseaux...
un "thread"=processus parallèle en bon français c'est un sous-programme ( au sens exécutable binaire pas code source ) qui s'exécute à coté du programme principal ( ceci grace à l'OS et CPU ) donc est-ce vraiment utile ?

[Lsong]

je bosse sur la parallélisation des calculs, et dans le cas présent des calculs de physique.

Sur un monocore je suis à 100% d'accord ca ne sert à rien
vu que les threads se partage la même puissance de calcul.

Sur un Bi-Core ou un Quad-Core ce n'est plus la même chose car on peu utiliser la puissance des 2 ou 4 cores pour les calculs et la il faut faire des threads.

La parallélisation fonctionelle à ses limites du à la différence de charge de chaque process et de la forte dépendance des differentes étape de calculs dans un jeu, le rendu a besoin des calculs de la physique (enfin en général la physique travaille sur la frame suivante).
La je fait de la parallélisation de donnée ce qui est plus difficile dans le cadre d'un moteur de physique, mais ca marche.

Bref tout ca pour dire "oui" je fais des threads en toute connaissance de cause car nous cherchons à exploiter les processeurs multi-core qui devrait devenir courrant d'ici peu.

[fearyourself]

le problème c'est que parfois le semaphore reste bloquer 16-60 ms sur le wait, alros qu'il n'y a qu'un seul thread !!!

Cela n'a pas grand chose à voir je pense puisque :

- Insérer un test pour savoir si on est en mono-thread est inutile puisqu'utiliser des sémaphores dans un code mono-thread est inutile...

- Du coup, avoir un coût avec un seul thread ne me choque pas.

- Ensuite, il est connu que les sémaphores/mutex sont longs à gérer SDL ou Posix d'ailleurs. Il faut : minimiser les appels vers ces fonctions et/ou se débrouiller pour ne pas en avoir besoin...

c'est un probleme connu des semaphore et mutex SDL ?

Je dirais que c'est un problème des mutex/semaphore qui sont mal utilisés du coup, faudrait que tu montres un bout de code...

Jc

[Lsong]

je precise : j'ai testé en mono thread pour voir si j'avais des problèmes de performance, mais le programme "doit" tourner en multi-thread (4 threads car 4 core) donc l'usage des semaphore ou mutex est obligatoire pour ne pas téléscoper les variables commune aux threads.


je peu vous montrer le code
à la base j'ai commencé par des mutex mais comme ils ont le même probleme de performance je suis passer au semaphore qui semble legerement meilleur
mais c'est probablement qu'une impression

void SDL_PContainer::Lock_Mutex(int Mut)
{
SDL_SemWait(vSem[Mut]);
}

void SDL_PContainer::UnLock_Mutex(int Mut)
{
SDL_SemPost(vSem[Mut]);
}

le code appelant dans le thread

pContainer->Lock_Mutex(pContainer->MUTEX_PCZONE_COMPUTE);

if (index>=mZx*mZy)
{
pContainer->UnLock_Mutex(pContainer->MUTEX_PCZONE_COMPUTE);
return false;
}
int _index = ++index; // cette appel ne doit pas etre interompu
pContainer->UnLock_Mutex(pContainer->MUTEX_PCZONE_COMPUTE);

J'ai oté mes codes de debug qui n'apporte pas grand chose (en gros ca lit le temps avant et apres l'appel pour savoir combien de temps c'est ecouler).
La variable index doit être protegé car les threads ont besoin d'avoir une valeur differente à chaque fois.

En gros j'ai un tableau à 2 ou 3 dimension (ca dépend si la scène est en deux ou trois dimension) et les threads doivent traiter chaque case du tableau qui elle même contien un bloque de donnée.
L'index permet de designer une case du tableau différente à chaque increment
le traitement du tableau se fait en //, c'est évidement util que si on a un processeur multi-core biensur.

Sans le semaphore il arrive que deux threads traitent le meme bloque de donnée et ca fini par planter car a la fin du traitement on nettoie les data, donc le thread qui les traite une deuxieme fois crash, de plus une zone ne sera pas traiter ...

bref les threads sont tout à fait reflechie

[fearyourself]

ok question subsidiaire :

Pourquoi ne pas affecter les blocs à la création des threads ?

Tu me réponderas alors sûrement que cela risquerait de faire qu'un thread ne bosse plus pendant que les autres bossent...

A quoi je dirais que cela dépend si tu peux prouver qu'un thread a des chances de tourner plus vite que les autres avec la même charge de boulot.

Sinon, pourquoi ne pas prendre plusieurs blocs en même temps histoire de limiter le nombre de passage dans ce code, tu aurais donc le meilleur des deux mondes...

Jc

[Lsong]

en gros il s'agit de faire les calculs de physique dans la scene, chaque blocs ont une quantité de donner differente, de plus le nombre de bloc depend du nombre d'objet et du volume de la scene
et le traitement doit se faire a chaque frame(le nombre d'objet pouvant changer biensur)

- donc difficile d'allouer les bloc à la creation des threads
- la charge de travaille n'etant pas lineaire par rapport au nombre de bloc ...

cela dit l'idée d'allouer N bloc est possible mais c'est plus un system pour limiter un probleme sans esseyer de le resoudre
de plus j'utilise les semaphore pour proteger d'autre zone ...

quelqu'un sais si les outil win fonctionne bien ? ou je vais avoir le meme probleme
sinon il me reste plus qu'a implementer mes propres outil ?

[Lsong]

je suis aller voir les implementation des mutex et des semaphore SDL
en gros il font un wait par defaut apres le lock

Code :

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

1
2
3
4
5
6
7
8
9
10
11
int SDL_mutexP(SDL_mutex *mutex)
{
	if ( mutex == NULL ) {
		SDL_SetError("Passed a NULL mutex");
		return -1;
	}
    RMutex rmutex;
    rmutex.SetHandle(mutex->handle);
	rmutex.Wait(); 
	return(0);
}

je ne vois pas c'est quoi un RMutex mais je cherche

[Mat.M]

je crois qu'il ya erreur:

primo dual core ou quad core c'est de la belle tartufferie marketing d'Intel .Pas dit que cela marche à 100%

Segundo basiquement faire de la programmation multiprocessus comment-ça marche ?
Lorsque dans un programme on crée des "threads" le CPU alloue des laps de temps ( appelés quantum ) pour chaque tache.
Tu dis avoir 6000 entités en mouvement donc l'OS va allouer 6000 processus en relation avec le CPU.
Tous les n millionièmes ou 1/1000 de s le CPU est donc obligé de permuter de tache ce qui consomme énormément des cycles.
Sur 6000 cela consomme déjà un certain temps donc la mémoire et les temps d'éxécution se fragmentent ce qui explique les ralentissements dont tu parles ( pas du tout viable pour un jeu vidéo )
Si tu as une carte bi-processeur donc 2 CPU physiquement le temps d'exécution ne sera qu'en théorie divisé par 2...
Même si un thread ce n'est que 10000 octets en mémoire si tu lances 6000 threads en même temps cela revient à lancer 6000 programmes simultanément parce que l'OS alloue de la mémoire disponible + pile de variable.
Moralité ce genre de technique c'est bien pour simuler pas pour faire un jeu ou alors tu prends un seul processus avec un timer qui détermine le laps de temps entre un temps t0 et un t1

ceci dit si tu y tiens vraiment je conseille vivement de laisser tomber SDL et prendre des API de l'OS comme tout simplement _beginthread de win32 et autress mais le code source ne sera plus portable

Sur un Bi-Core ou un Quad-Core ce n'est plus la même chose car on peu utiliser la puissance des 2 ou 4 cores pour les calculs et la il faut faire des threads.

attention y'a pas que ton programme qui tourne . Même si tu as 1,2,4 ,n processeurs sur ta carte mêre y'a aussi les services de l'OS , programmes chargés en mémoire qui tournent

[Laurent Gomila]

Lorsque dans un programme on crée des "threads" le CPU alloue des laps de temps ( appelés quantum ) pour chaque tache.
Tu dis avoir 6000 entités en mouvement donc l'OS va allouer 6000 processus en relation avec le CPU.

Je pense qu'il veut plutôt allouer un thread par processeur, pas un par entité...

Moralité ce genre de technique c'est bien pour simuler pas pour faire un jeu ou alors tu prends un seul processus avec un timer qui détermine le laps de temps entre un temps t0 et un t1

Franchement non, il est courant d'utiliser des threads dans les moteurs physiques. Enfin, au moins un (par exemple PhysX fait systématiquement ses calculs dans un thread à part). Ca permet au minimum de ne pas bloquer la boucle de jeu le temps que la physique soit calculée.

Donc faut arrêter d'être dans l'extrémiste du mono-thread, je suis bien d'accord que beaucoup de débutants veulent les utiliser à tord, mais ici ça me semble justifié.

[Mat.M]

L'index permet de designer une case du tableau différente à chaque increment
le traitement du tableau se fait en //, c'est évidement util que si on a un processeur multi-core biensur.

Sans le semaphore il arrive que deux threads traitent le meme bloque de donnée et ca fini par planter car a la fin du traitement on nettoie les data, donc le thread qui les traite une deuxieme fois crash, de plus une zone ne sera pas traiter ...

les fonctionnalités de SDL ne sont pas adaptées alors ; il faut utiliser, si tu est sous win32 les sections critiques.
Pour verrouiller index il faut prendre EnterCriticalSection et LeaveCriticalSection mais cela ne sera pas portable sous Linux..

[fearyourself]

je suis bien d'accord que beaucoup de débutants veulent les utiliser à tord, mais ici ça me semble justifié.

Clairement, c'est exactement ce qu'il faut faire dans ce cas précis.

les fonctionnalités de SDL ne sont pas adaptées alors ; il faut utiliser, si tu est sous win32 les sections critiques.
Pour verrouiller index il faut prendre EnterCriticalSection et LeaveCriticalSection mais cela ne sera pas portable sous Linux..

Pas forcément, il n'est pas dit que la SDL n'utilise pas ces appels lorsque c'est compilé sous Windows. Il faudrait regarder le code source pour cela.

Jc

[Laurent Gomila]

es fonctionnalités de SDL ne sont pas adaptées alors ; il faut utiliser, si tu est sous win32 les sections critiques.

Les sections critiques sont plus performantes, mais pas dans tous les cas si mes souvenirs sont bons.
A part ça, pour ce qui est mutex et thread, la SDL ne fait que de bêtes appels aux fonctions Win32 correspondantes, on n'y gagnerait rien à tout recoder.

[Lsong]

merci beaucoup pour vous réponse,

si vous voulez savoir je suis plutot extremiste du monothread...
je suis passer en multi car je n'ai pas le choix, à moin que quelqu'un puisse me dire comment utiliser un proc multicore sans thread (ne pas repondre par "du multi-applicatif" )

il n'est bien sur pas question d'allouer un thread par objet, c'est une heresie pur ... entre les ressource et la synchro des resultats arg ...
surtout que quand j'ai dis 6000 c'est encore un nombre petit je suis monté a +9000, le but est de gerer 20000-30000 objets en mouvement


je me suis tappé les sources de SDL et les exemples du MSDN
l'usage des mutex SDL ou win32 revien a faire un WaitForSingleObject !!! ce qui va rendre la main, pas top pour les performance

j'en étais au "critical section" je sens que je vais refaire cette partie avec ces outil
ce n'est plus portable mais je fait ca dans le couche de test donc ce n'est pas trop grave

[Laurent Gomila]

l'usage des mutex SDL ou win32 revien a faire un WaitForSingleObject !!! ce qui va rendre la main, pas top pour les performance

Tu peux développer (notamment pourquoi ça va rendre la main, et pourquoi c'est pas top pour les performances) ? Ca m'intéresse particulièrement en ce moment

[Lsong]

http://msdn2.microsoft.com/en-us/library/ms687032.aspx

WaitForSingleObject
Waits until the specified object is in the signaled state or the time-out interval elapses.

il se mette en attente dans le cas du mutex attente infini qui l'objet sur le quel il est soit appeler

quand tu regarde l'exemple d'utilisation du mutex
http://msdn2.microsoft.com/en-us/library/ms686927.aspx

l'attente se faire sur un
WaitForSingleObject(
hMutex, // handle to mutex
5000L); // five-second time-out interval

il est a craindre que ca fasse l'equivalent d'un yield au minimum, et qu'un autre processe en attente se lance
hors quand j'ai 900 appel a mon lock je ne veux pas faire 900 yield non plus
le temps de traitement d'un block est en général < 1ms (je n'arrive pas a le meusuré) si je fait 900 yield au milieux du traitement des 900 blockj'ai de forte chance de perdre la main et de me retrouver avec 16-60 ms de perdu a un autre process (que je ne connais pas), boum les perfs ...

bon au final je me suis battue un peu avec les sections critiques des & qui se perde
et miracle elles fonctionnent comme je l'esperais, enfin je vais esseyer plus en avant, ne pas vendre la peau de l'ours ...

[Laurent Gomila]

Oui mais si le mutex n'est pas verrouillé, alors WaitForSingleObject va simplement le verrouiller et continuer l'exécution du thread non ? Pourquoi le suspendrait-il ?

Si tu arrives à avoir des retours intéressants avec les sections critiques (par rapport aux mutex) ça m'intéresse aussi

[LeGreg]

primo dual core ou quad core c'est de la belle tartufferie marketing d'Intel .Pas dit que cela marche à 100%

Non non ça marche bien (on ne parle pas d'hyperthreading).

De toute façon c'est facile à vérifier :
application X, monothread monocore 100%.
application X, dual thread dual core 200%.

Après your mileage may vary suivant l'application (facilement parallelisable ou pas) et la façon dont tu programmes bien entendu.

Semaphore/critical section, la façon dont tu les utilises c'est la meme chose. Je doute que ça fasse grand chose pour ta performance sauf à la marge comme ça devrait etre le cas si bien utilisé.

La plaie pour une application multithread c'est d'avoir à se synchroniser à tout bout de champ (si tu vises les perfs et le scaling théorique à 100%). En gros il ne devrait pas y avoir de variable "globale" accedée tout le temps, chaque thread a son propre "contexte" de travail qu'il met à jour de temps à autre.

File circulaire ou double buffer ce qui permet à un thread de travailler sur des données pendant qu'un autre prépare la fournée suivante. Le thread n'a à se synchroniser que lorsqu'il a épuisé sa tache courante.

S'il y a des taches (jobs) à répartir alors un thread chef d'orchestre peut répartir les taches à un pool d'autres threads sans qu'ils aient à se synchroniser entre eux.

C'est à la facilité de cette ségrégation des taches que l'on mesure le potentiel d'accélération apportée par le parallélisme.

--

Pour ton problème de délai, ça me parait douteux, si personne ne détient la section critique et qu'il n'y a pas d'autre threads qui tourne (parfois une application en tache de fond peut voler du temps processeur) alors le wait devrait retourner immédiatement. Verifies que ta mesure de temps est bien précise (utilise les performance counter et bloque l'affinité à un seul core).

LeGreg

[Mat.M]

Ok Le Greg arrêtons la les polémiques nous sommes d'accord .
Sinon LSong tu peux prendre aussi Pthread qui est portable et qui permet de verrouiller les variables ; quelq'un avait posé une question là dessus sur le forum C ou C++

[Lsong]

Laurent Gomila: depuis le passage aux sections critiques je n'ai plus de perte de temps en monothread, parfois en multi (sur un mono core) mais ca c'est normal...
par contre en multi, assez souvant, j'ai un seul thread qui fait tout le boulot, cela n'arrivait pas avec les semaphore SDL, ca renforce mon avis que l'implementation des semaphores SDL provoque un espece de yield();
Bon des que je stresse un peu la machine les deux threads s'active, il faut maintenant que j'aille voir sur le Quad ce que ca donne avec 4 threads(oui c'est genant mais je bosse sur un monocore).

LeGreg :
la je parlais des Semaphore SDL dans la theorie les deux technique doivent revenir à la meme chose je suis d'accord, mais selon l'implementation ... il y a parfois des surprises ...

actuellement je n'ai pas 400% sur le quad car
- tout n'est pas encore // il y a une phase de préparation des zones qui doit être refait en // sous peu(j'ai du boulot), tant que j'étais sous les 5000 objets ce temps etait negligable, maintenant ... ca ne l'est plus
- je sais que le probleme est la synchro et c'est l'algo centrale (dont je ne peu pas parler ici désolé, secret, confidentialité etc...) qui gére ca, mais il faut que le temps de calcul reste dans le temps de la frame ... ben oui il fait pas le café non plus.
Chaque thread a son propre contexte (les fameux blocs de données), seul la distribution de ses données se fait en critique, maintenant avoir un thread qui ordonne tout ca peu etre une solution, mais de toute facon les information génerer par les thread doivent s'inserer dans une structure commune donc il y aura forcement des "section-critiques", mais heureusement chaque thread n'ecrit pas dans la même zone du graphe, ca limite fortement les téléscopage

vu que ca interesse du monde ce que je fabrique je repasserais vous tenir au courrant