OpenMP et Qthread

Citation:

---

Envoy� par uriotcea

Je ne vois pas par quoi remplacer openMP, si quelqu'un � des suggestions pour une librairie plus stable, je suis preneur

---

Y as tbb ou QtConcurrent vue que tu utilise Qt.
SInon, je suis �tonn� pour ton prbl�me. Tu es sur de ne pas avoir oubli� quelquechose lors du build?

as tu essay� de recompiler pthread?
as tu essay� un de ces version de mingw?
http://www.tdragon.net/recentgcc/

Pour dire la verit� je crois que j'ai tout essay�. J'ai essay� la dernier distib de TDM. J'ai effectivement recompil� pthread. J'ai linker ce bout de code avec les lib static de openMP et pthread. J'ai r�essay� avec les DLLs. Gcc4.3.3, gcc4.4.0 et le dernier 4.4.2.
Voila l� je suis sec. J'ai bien essay� de recompiler la lib openMP, histoire d'avoir une version debug. Mais l� c'est trop difficile, je n'y arrive pas.

je suis super etonn� que personne n'est rencontr� ce type de soucie avant moi. openMP semble etre quelquechose de tr�s diffus� et utilis�...

J'avais pas vu tes suggestions de remplacement.J 'utilise deja QConcurrent, mais ca demande de r�ecrire �norm�ment de chose, de plus j'ai une bonne partie des calculs ecrit en fortran. Je ne connaissais pas tbb, mais je ne sais pas si c'est free et si ca supporte le fortran. Malheureusement, j'ai investi pas mal de temps sur openMP sous la version linux, persuoid� que le portage sous windows serait aussi ais� que pour Qt par example.

openmp semble bien marcher sous visual. Mais uniquement les version payante...

Bon, j'essaye de m'en sortir autrement en remplaceant mon pTHread par une section openMP, mais je n'y arrive pas. Je fais cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#pragma omp parallel num_threads(1) { #pragma omp sections nowait { #pragma omp section { // mon gros calcul } } } printf("sortie\n");

---

Ce que je ne comprend pas, c'est que je n'atteind la sortie qu'a la fin de mon gros calcul alors que j'ai mis la directive nowait.
Quelque chose m'�chappe...

j'ai recompil� openMP avec ton projet mais je ne trouve pas ou est le probleme, j'ai une callstack un peu fantaisiste sous windows. j'ai du faire a la main le configure et je ne pense pas que j'aie tout mis correctement.

Peux-tu etre plus explicite. Qu'entends tu pas recompiler le projet. Veux-tu dire que tu as recompil� les source de openMP ?
Dans ce cas mon example initial ne plante plus ?
As-tu un make file pour compiler openMP, comment as-tu fais ?

j'ai pris les sources de OpenMP et un makefile, j'ai bricol� les fichiers que le script configure est cens� cr�er. j'ai �crit un makefile qui compile ton appli et tous les fichiers de OpenMP.
au d�but ca plantait au meme endroit exactement, j'ai r�ussi a aller un poil plus loin mais la je ne sais pas du tout ou ca plante. Ca plante toujours par contre.
D�s fois ca part en boucle infinie (on dirait), des fois ca plante imm�diatement (sans faire le premier printf, on dirait) et d�s fois ca plante au meme endroit que toi. cest tres tres instable quoi.

Pourrais-tu me mettre ton make file histoire d'avoir un point de depart.
Ou as-tu eu les source de openMP

Merci d'avance

Bon j'ai finit pas compiler moi m�me openMP et je vois que ca plante dans la parce que la fonction de pthread , pthread_getspecific(...), renvoie un pointeur null.
Cette fonction appelant simplement la fonction windows api : TlsGetValue(...) qui renvoie donc un pointeur null.

Tout ca pour info, parce je ne vais pas m'amuser � debugger les fonctions API Windows.

tu peux compiler avec le support du mot-cl� __thread (dans config.h, active HAVE_TLS)
active aussi HAVE_SYNC_BUILTINS et ajoute -march=i686 sur la ligne de commande pour la lib.

Je n'ai pas compris ou mettre le __thread
Ensuite si je met HAVE_SYNC_BUILTINS j'ai les erreurs de link suivantes:
Finallement as-tu r�ussi � faire fonctionner mon petit example ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

obj\Debug\gcc-4.4.2\libgomp\config\posix\bar.o||In function `gomp_barrier_wait_end':| D:\temp\gcc-4.4.2\libgomp\config\posix\bar.c|93|undefined reference to `__sync_add_and_fetch_4'| obj\Debug\gcc-4.4.2\libgomp\config\posix\bar.o||In function `gomp_team_barrier_wait_end':| D:\temp\gcc-4.4.2\libgomp\config\posix\bar.c|153|undefined reference to `__sync_add_and_fetch_4'| obj\Debug\gcc-4.4.2\libgomp\critical.o||In function `GOMP_critical_name_start':| D:\temp\gcc-4.4.2\libgomp\critical.c|72|undefined reference to `__sync_val_compare_and_swap_4'| obj\Debug\gcc-4.4.2\libgomp\iter.o||In function `gomp_iter_dynamic_next':| D:\temp\gcc-4.4.2\libgomp\iter.c|192|undefined reference to `__sync_fetch_and_add_4'| D:\temp\gcc-4.4.2\libgomp\iter.c|238|undefined reference to `__sync_val_compare_and_swap_4'| obj\Debug\gcc-4.4.2\libgomp\iter.o||In function `gomp_iter_guided_next':| D:\temp\gcc-4.4.2\libgomp\iter.c|323|undefined reference to `__sync_val_compare_and_swap_4'| obj\Debug\gcc-4.4.2\libgomp\parallel.o||In function `gomp_resolve_num_threads':| D:\temp\gcc-4.4.2\libgomp\parallel.c|88|undefined reference to `__sync_val_compare_and_swap_4'| obj\Debug\gcc-4.4.2\libgomp\single.o||In function `GOMP_single_start':| D:\temp\gcc-4.4.2\libgomp\single.c|46|undefined reference to `__sync_bool_compare_and_swap_4'| obj\Debug\gcc-4.4.2\libgomp\work.o||In function `free_work_share':| D:\temp\gcc-4.4.2\libgomp\work.c|150|undefined reference to `__sync_bool_compare_and_swap_4'| obj\Debug\gcc-4.4.2\libgomp\work.o||In function `gomp_work_share_end_nowait':| D:\temp\gcc-4.4.2\libgomp\work.c|254|undefined reference to `__sync_add_and_fetch_4'| ||=== Build finished: 10 errors, 0 warnings ===|

---

Ok...
Juste avec l'option HAVE_TLS, ca semble fonctionner maintenant, tant que je n'essaye pas de preciser un nombre de thread superieur � 2 (j'ai 2 cores)
Si j'essaye 4 par example avec omp_set_num_threads(4) , j'obtiens 2 message "Hello, world in thread" avant un blocage ou un plantage, cest selon...

Ca progresse tout de m�me avec ton aide

Citation:

---

Envoy� par uriotcea

Ok...
Juste avec l'option HAVE_TLS, ca semble fonctionner maintenant, tant que je n'essaye pas de preciser un nombre de thread superieur � 2 (j'ai 2 cores)
Si j'essaye 4 par example avec omp_set_num_threads(4) , j'obtiens 2 message "Hello, world in thread" avant un blocage ou un plantage, cest selon...

Ca progresse tout de m�me avec ton aide

---

tu as mis aussi -march=i686 sur la ligne de commande ? pour tes erreurs de link.
Pour le TLS, c'est deja bon.
J'ai rep�r� une erreur (enfin, selon moi c'est une erreur) dans une de leurs fonctions, dans team.c, dans gomp_team_start (ligne 250 a peu pres)
a la ligne 391 chez moi, ils cr�ent les parametres de thread sur la pile avec

Code:

---

1 2 3

start_data = gomp_alloca (sizeof (struct gomp_thread_start_data) * (nthreads-i));

---

puis ils lancent les threads
ces parametres sont detruits a la fin de la fonction, puisqu'ils sont sur la pile. Or, rien ne garantit que les threads que l'on vient de cr�er aient fini de faire leur affaire avec ces parametres.
Essaye de remplacer gomp_alloca par gomp_malloc
ca cr�e un leak m�moire, ce n'est pas vraiment le top, mais c'est juste pour voir si l'erreur vient de la

Ok merci, ca ne change rien.
Pourrais me mettre une copie de ton "config.h" parce qu'en fait je ne passe pas par le makefile (quelles commandes mes tu � ton make file).

Pour le moment HAVE_SYNC_BUILTINS g�n�re tj des erreurs au linkage

mon config.h est tout pourri, j'arrive pas aussi loin que toi (je l'ai bidouill� a la paluche aussi)
pour les erreurs de link c'est la ligne de commande de GCC qu'il faut changer pour �viter les erreurs. Dans le Makefile je compile simplement avec

Code:

---

gcc -g -O0 -march=i686

---

Oui, c'est un peu bricolage pour le moment.
Bon je n'ai plus d'erreur de link et ca semble fonctionner avec mon code. Je fais bien des calculs en // Mais � la sortie de mon thread principale j'ai des plantage aleatoire dans la fonction (team.c):

static void gomp_free_thread (void *arg __attribute__((unused)))

Alors parfois c'est au d�but parce que thr vaut n'importe quoi (style "ffeeeffeee")
parfois c'est plus loing dans la fonction. Je vais voir si c'est possible de la blinder un peu mais qunad un pointer n'est pas vraiment NULL, je ne sais pas trop comment le tester

Encore plus etrange, cette fonction ne semble etre appel� que pour la fin de mon thread principale. Si je la vide avec un return tout semble fonctionner sauf qu'a chaque nouveau calcul je vois dans le programmemanger de windows que mon appli s'est incrementer d'un thread. Si j'inclu pas le mode openMP et la lib correspondante dans mon appli tout se passe correctement. Comme si la lib openMP avait remplacer la fonction charger de liberer les thread

feeefeee ca veut dire que la m�moire a �t� lib�r�e par windows, et remplie par ce pattern pour bien montrer que c'est pas tres tres catholique de lire a cette adresse. Apparemment un thread un peu trop z�l� a lib�rer la m�moire en question.