Recherche:

heu j'en sais rien, mais la STL tenait toujours le haut du pavé dans nos tests d'avant.

dual-processor xeon:
C =10000000: 1.094s
OpenMP=10000000: 0.625s
STL =10000000: 0.625s

macosx intel...

je me suis trompé de benchmark,
je vais corriger ce soir.

sinon je trouve les resultats pas si mal que ca,
pour mémoire j'avais obtenu avec le dual-processor xeon:
C =10000000: 1.094s...

hop je ré-ouvre un peu ce débat, je suis sur mon mac avec gcc 4.2
j'ai essayé de regarder un peu si Openmp etait aussi plus lent sur de petites boucles avec le code suivant qui est le meme que celui...

voila:

... attendons les prochains benchs !
si un expert assembleur nous lis alors j'aimerais bien avoir son avis sur le code généré 8-)

Je me méfie énormement .... je pense que le compilateur fait beaucoup de choses derriere et la latence n'est plus mise en evidence ...

Y-aurait-il un expert en assembleur qui pourrait nous...

attends j'avais enlevé le if

donc en mettant

#pragma omp parallel for if(LEN>10000) reduction(+:sum)

j'obtiens:
number of thread max: 4
C =1000: 0.875s
OpenMP=1000: 1.297s

number of thread max: 4
C =1000: 0.89s
OpenMP=1000: 10.735s

et j'ai le code suivant (apres beaucoup de tests/modifs)

Je ne comprends pas le if openmp,
autant faire un if (en dessous d'une...

mais que ton implementation soit si rapide m'etonne vraiment ...
tu ne peux pas etre aussi rapide que le c quand meme .... tu as au minimum une legere penalité d'initialisation des threads ..

Tu...

je n'obtiens pas du tout des resultats coherents...
si on pouvait maintenant changer d'une addition et appliquer une formule telle que cosinus ...

Je suis tres respectueux des licences et j'apprecie ton travail.

;-) j'aime vraiment OpenMP c'est pour ca que je m'interesse beaucoup si il y a des eventuelles faiblesses, et de chercher la raison... Ton benchmark me passionne, la concurrence est un sujet qui me...

je suis d'accord que la reduction avec openmp est limité.
je pense aussi que ta section critique peut etre evitée en gardant les valeurs de chaque thread puis de faire la reduction manuellement (pas...

je pense qu'on peut eviter ta section critique.
Aussi je ne vois pas pourquoi OpenMP aurait une latence, c'est bizarre.
J'aurais bien aimé comparer vraiment en essayant d'autres facons de mon coté...

par exemple


double threadvalues = new double[ omp_get_num_threads_max()]

#pragma omp for
for( i=0 ; i<end-begin ; i++) {
threadvalues[omp_get_thread_num()] = xxx;
}

j'ai un doute sur:


#pragma omp parallel if (nchunks>1) firstprivate(func)
{
#pragma omp for schedule(dynamic,1)
for (int i=0; i<nchunks; ++i)
{
int d=i*grain;
...

voila:

ca me surprend quand meme drolement que OpenMP est plus lent que ta solution ... ca peut pas venir d'autre chose ?

voila...

c'est l'hyperthreading si je ne m'abuse...

je ne pense pas que l'addition soit representatif pour un benchmark. Regarde le mien quand j'ai utilisé un cos ... OpenMP etait plus de 2 fois plus rapide...

... j'adore OpenMP :D

... j'attends tres impatiemment le nouveau bench ....

il faudrait vraiment faire plus qu'une addition dans cette boucle ...
une expression mathematique ? un cos tan etc..

a priori un benchmark comme cela ne montre pas vraiment la superiorité du MT...
il faut charger la mule pour le voir...
juste en mettant: sum+=cos(X[j]/(double)i);
j'obtiens:

C =0: 37.813s...

flute j'avais loupe l'init du t0 :mouarf:

en corrigeant tous ca j'obtiens:

number max of threads:4
C =10000000: 1.094s
OpenMP=10000000: 0.625s
STL =10000000: 0.625s