Re: quelques points

Mais si tu n'as pas de bol, et qu'un thread gère des « petites » sommes (exposant n, disons les dépenses quotidiennes), et qu'un autre thread gère des sommes plus grosses (exposant n', disons les salaires ou les chiffres du PMU, ou...), tu te retrouves avec des nombres d'ordres de grandeur potentiellement très différents.

Plus « sérieusement » : j'ai donné des formations sur OpenMP. Forcément à un moment donné j'ai parlé des opérations de réduction. Un bête truc du genre produit scalaire :

/* Algorithme non-optimisé pour le produit scalaire */
void
dotproduct_omp(double * const sumref, 
 double const * const A,
 double const * const B,
 const unsigned long N)
{ 
 double sum = 0.0;
#pragma omp parallel shared(A,B) 
 { 
#pragma omp for default(none) reduction(+:sum) 
 for (size_t i = 0; i < N; ++i) {
 sum += A[i] * B[i]; 
 }
 }
 *sumref = sum; 
}
#define N 100UL
int
main(void)
{
 double *A = NULL, 
 *B = NULL;
 unsigned long n = N,
 nbthreads = NUMTHREADS;
 double sum = 0.0;
 A = safe_malloc(sizeof(double) * N);
 B = safe_malloc(sizeof(double) * N);
 for (long i = 0; i < n; ++i) {
 A[i] = i;
 B[i] = n-i;
 }
 dotproduct_omp_atomic(&sum,A,B,n);
 printf("Parallel (OpenMP) dot product = %.2f\n", sum);
 free(A);
 free(B);
 return 0;
}

Bien entendu si toutes les valeurs de tes vecteurs sont peu ou prou du même ordre de grandeur, alors pas de problème. Mais si tu as de grandes disparités, même en double précision, alors la version séquentielle et la version parallèle vont sérieusement diverger pour le résultat final — et pas besoin de beaucoup de threads, je crois qu'au-delà de 4 on voyait déjà poindre les ennuis.