Pourquoi la version OpenMP est plus lente?

Je suis expérimenter avec OpenMP. J'ai écrit du code pour vérifier ses performances. Sur un 4-core unique PROCESSEUR Intel avec Kubuntu 11.04, le programme suivant compilé avec OpenMP est environ 20 fois plus lent que le programme est compilé sans OpenMP. Pourquoi?

J'ai compilé par g++ -g -O2 -funroll-loops-fomit-frame-pointer -march=native -fopenmp

#include <math.h>
#include <iostream>

using namespace std;

int main ()
{
  long double i=0;
  long double k=0.7;

  #pragma omp parallel for reduction(+:i)
  for(int t=1; t<300000000; t++){       
    for(int n=1; n<16; n++){
      i=i+pow(k,n);
    }
  }

  cout << i<<"\t";
  return 0;
}

source d'informationauteur Duncan

  1. 15

    Le problème est que la variable k est considéré comme une variable partagée, de sorte qu'il doit être synchronisés entre les threads.
    Une possible solution pour éviter cela est:

    #include <math.h>
#include <iostream>

using namespace std;

int main ()
{
  long double i=0;

#pragma omp parallel for reduction(+:i)
  for(int t=1; t<30000000; t++){       
    long double k=0.7;
    for(int n=1; n<16; n++){
      i=i+pow(k,n);
    }
  }

  cout << i<<"\t";
  return 0;
}

    Suite à la pointe de Martin Beckett dans le commentaire ci-dessous, au lieu de déclarer k à l'intérieur de la boucle, vous pouvez également déclarer const k et à l'extérieur de la boucle.

    Sinon, ejd est correct, le problème ici ne semble pas mauvais parallélisation, mais une mauvaise optimisation lorsque le code est parallélisée. Rappelez-vous que le OpenMP mise en œuvre de gcc est assez jeune et loin d'être optimale.

  2. 3

    Plus rapide code:

    for (int i = 0; i < 100000000; i ++) {;}

    Légèrement plus lente code:

    #pragma omp parallel for num_threads(1)
for (int i = 0; i < 100000000; i ++) {;}

    2 à 3 fois plus lent code:

    #pragma omp parallel for
for (int i = 0; i < 100000000; i ++) {;}

    peu importe ce qu'elle est entre { et }. Un simple ; ou de plus en plus complexes, le calcul, les mêmes résultats. J'ai compilé sous Ubuntu 13.10 64 bits, à l'aide de gcc et g++, en essayant de différents paramètres -ansi -pedantic-erreurs -Wall-Wextra -O3, et en cours d'exécution sur un processeur Intel quad-core 3.5 GHz.

    Je suppose que le thread de gestion des frais généraux est en faute? Il se complique semble pas intelligent pour les OMP de créer un thread à chaque fois que vous en avez besoin et de le détruire après. Je pensais qu'il y aurait quatre (ou huit) de threads qui sont soit en cours d'exécution en cas de besoin ou de sommeil.

  3. 0

    J'observe un comportement similaire sur GCC. Cependant, je me demande si dans mon cas, c'est en quelque sorte lié avec le modèle ou la fonction en ligne. Votre code est aussi au sein du modèle ou de la fonction inline? S'il vous plaît regardez ici.

    Cependant que pour de très courtes pour les boucles, vous pouvez observer quelques petits frais généraux liés avec du fil de commutation comme dans votre cas:

    #pragma omp parallel for
for (int i = 0; i < 100000000; i ++) {;}

    Si votre boucle s'exécute pour certains sérieusement longtemps que quelques ms ou même de quelques secondes, vous devriez observer d'augmentation des performances lors de l'utilisation d'OpenMP. Mais seulement quand vous avez plus d'un PROCESSEUR. Le plus de cœurs que vous avez, plus la performance que vous atteindre avec OpenMP.