Discussion :

[Lsong]

euh ... quelqu'un peu m'aider la ?

je passe ma gestion des threads de SDL vers Win32 (ce post va devenir un post WIN ...)
j'ai donc mis un #include "Windows.h" dans mon header
sauf qu'il semble pas reconnaitre par la suite tout ce qui concerne la gestion que ca soir les Condition et les SectionCritique ...
la difference c'est que dans ce fichier j'ai inclue aussi SDL

#include "Windows.h"

#ifdef WIN32
#pragma comment(lib, "../SDL-1.2.11/lib/SDL.lib")
#pragma comment(lib, "../SDL-1.2.11/lib/SDLmain.lib")
#endif

#include "../SDL-1.2.11/include/SDL.h"
#include "../SDL-1.2.11/include/SDL_endian.h" /* Used for the endian-dependent 24 bpp mode */
//#include "../SDL-1.2.11/include/SDL_image.h"
#include "../SDL-1.2.11/include/SDL_thread.h"

j'ai fait une bourde classique ?

Ls reparti dans la doc

[Lsong]

bon ok les CONDITION VARIABLE c'est que sous vista ...
bon je change de methode

[hegros]

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.

Dans ce cas précis tu poses 1 mutex pour protéger l'incrémentation d'une variable alors que pour cela le plus approprié ce ne serait pas les mutex mais les interlocks. Par contre du coup avec SDL je ne connais pas d'équivalent donc voici un lien MSDN

Peut être que c'était pour l'exemple mais je me base sur cela pour répondre.


D'autant plus avec les mutex (idem sémaphore) il faut faire attention à ce que tu ne généres pas de dead lock. C'est à dire qu'a aucun moment tout tes threads ne se retrouvent bloqués et attendent que quelqu'un les débloque.

Normalement un thread qui lock doit délocker lorsqu'il termine la tâche associée (si possible le plus rapidemment possible )

[Lsong]

je suis passer au "section critique" qui font bien leur job
bon les threads se repartissent pas bien le job mais c'est dut au fait qu'il ne se lance pas tous en même temps je suis parti utiliser les Event pour ca, mais ca ne marche pas vraiment
je bosse encore dessu

[hegros]

je suis passer au "section critique" qui font bien leur job
bon les threads se repartissent pas bien le job mais c'est dut au fait qu'il ne se lance pas tous en même temps je suis parti utiliser les Event pour ca, mais ca ne marche pas vraiment
je bosse encore dessu

Pour synchroniser une variable à l'incrémentation, le plus adapté, au risque de me répéter, ce sont les interlocks. Les Events ca fait un peu usine à gaz pour une variable

[Lsong]

ne t'en fait pas les Event ce n'est pas pour une variable
ca fait un peu marteau pilon pour ecraser ... une bacterie
ce sont les sections critiques qui gerent ca

Les Event c'est pour lancer et arreter les threads (j'ai un system de producteur, consomateur)

pour optimiser j'ai regroupé comme proposer mes zones de données en blocs plus gros pour limiter à 8 passage en zone critique quelque soit le nombre de zone , ca monte a 1500 zone tout de même...

je passe actuellement d'un temps de traitement de
- 19 ms pour 1 thread en moyenne à
- 7 ms pour 4 thread en moyenne

comme la repartition n'est pas homogene le max pour les thread est de 10ms et le min de 5 ms
bref la repartition marche enfin, bon j'ai un peu triché sur les collisions

Il y a quelque chose dans le calcul des collisions qui provoque des pertes de temps. Je vois ca demain, chez moi j'ai pas de multi-core.

petite question :
un new ca peu se paralleliser ? ou le system ca se synchroniser dessus pour ne pas que deux threads fassent un new sur la même zone memoire ??

[Ti-R]

Moi aussi je suis dans les threads et les locks en se moment

J'ai trouvé cela A "synchronized" statement for C++ like in Java

Cela utilise les sections critiques, et cela fonctionne bien, si cela peut aider !

un new ca peu se paralleliser ? ou le system ca se synchroniser dessus pour ne pas que deux threads fassent un new sur la même zone memoire ??

Ton new enverra toujours un espace mémoire non attribué, sinon cela serait vite problématique.

[Lsong]

pour information le New a des performance catastrophique en multi-thread, il faut donc éviter d'en faire le plus possible (du moins sous windows)

sinon voila je système est prêt, la parallélisation des calculs de physique fonctionne

merci a tous pour vos idées

[Laurent Gomila]

sinon voila je système est prêt, la parallélisation des calculs de physique fonctionne

Ca donne des résultats intéressants ? Tu as fait des comparaisons ?

[Lsong]

Oui les résultat

en forçant l'affinité du programme sur un seul des 4 core,
en configurant un thread,
et en jouant sur la surface pour avoir la même densité de calcul

Le programme arrive à gérer 3750 cercles en même temps avant d'avoir des retard, c'est à dire dépasse les 40 ms.

avec 4 threads (sur un quad-core sinon ça ne sert à rien) le programme monte à 11000 cercles sur toute la surface, avec plus les thread prennent plus que les 40 ms de la frame

ça nous fait du 293%

j'ai fais des test en mettant 3 threads,
j'obtiens 10500 cercles, la partie non parrallele : l'affichage et certain traitement de la physique finisse par prendre un core entier, c'est surtout l'affichage car 10000 drawCircle avec SDL ça fini par prendre du temps