/openmp (Activer la prise en charge d’OpenMP)

Fait en sorte que le compilateur traite #pragma omp les directives en charge d’OpenMP.

Syntaxe

/openmp
/openmp:experimental
/openmp:llvm

Notes

#pragma omp est utilisé pour spécifier des directives et des clauses. S’il /openmp n’est pas spécifié dans une compilation, le compilateur ignore les clauses et directives OpenMP. Les appels de fonction OpenMP sont traités par le compilateur même s’ils /openmp ne sont pas spécifiés.

Le compilateur C++ prend actuellement en charge la norme OpenMP 2.0. Visual Studio 2019 offre également des fonctionnalités SIMD. Pour utiliser SIMD, compilez à l’aide de l’option /openmp:experimental . Cette option active les fonctionnalités OpenMP habituelles et les fonctionnalités SIMD OpenMP non disponibles lors de l’utilisation du /openmp commutateur.

À compter de Visual Studio 2019 version 16.9, vous pouvez utiliser l’option expérimentale /openmp:llvm au lieu de /openmp cibler le runtime LLVM OpenMP. Actuellement, la prise en charge n’est pas disponible pour le code de production, car les DLL libomp requises ne sont pas redistribuables. L’option prend en charge les mêmes directives OpenMP 2.0 que /openmp. Il prend également en charge toutes les directives SIMD prises en charge par l’option /openmp:experimental . Il prend également en charge les index entiers non signés en parallèle pour les boucles en fonction de la norme OpenMP 3.0. Pour plus d’informations, consultez Amélioration de la prise en charge d’OpenMP pour C++ dans Visual Studio.

L’option /openmp:llvm prend en charge l’architecture x64. À compter de Visual Studio 2019 version 16.10, il prend également en charge les architectures x86 et ARM64. Cette option n’est pas compatible avec /clr ou /ZW.

Les applications compilées à l’aide des deux /openmp et /clr peuvent uniquement être exécutées dans un seul processus de domaine d’application. Plusieurs domaines d’application ne sont pas pris en charge. Autrement dit, lorsque le constructeur de module (.cctor) est exécuté, il détecte si le processus est compilé à l’aide /openmp, et si l’application est chargée dans un runtime non par défaut. Pour plus d’informations, consultez appdomain, /clr (Compilation Common Language Runtime) et Initialisation des assemblys mixtes.

Si vous tentez de charger une application compilée à l’aide à la fois /openmp et /clr dans un domaine d’application non par défaut, une TypeInitializationException exception est levée en dehors du débogueur et une OpenMPWithMultipleAppdomainsException exception est levée dans le débogueur.

Ces exceptions peuvent également être levées dans les situations suivantes :

• Si votre application est compilée à l’aide /clr , mais pas /openmp, et est chargée dans un domaine d’application non par défaut, où le processus inclut une application compilée à l’aide /openmp.

• Si vous passez votre /clr application à un utilitaire, tel que regasm.exe, qui charge ses assemblys cibles dans un domaine d’application non par défaut.

La sécurité de l’accès au code du Common Language Runtime ne fonctionne pas dans les régions OpenMP. Si vous appliquez un attribut de sécurité d’accès au code CLR en dehors d’une région parallèle, il ne sera pas en vigueur dans la région parallèle.

Microsoft ne vous recommande pas d’écrire /openmp des applications qui autorisent des appelants partiellement approuvés. N’utilisez AllowPartiallyTrustedCallersAttributepas ou n’importe quel attribut de sécurité d’accès au code CLR.

Pour définir cette option du compilateur dans l'environnement de développement Visual Studio

1. Ouvrez la boîte de dialogue Pages de propriété du projet. Pour plus d’informations, consultez Définir le compilateur C++ et les propriétés de build dans Visual Studio.

2. Développez la >page de propriétés de configuration C/C++>Language.

3. Modifiez la propriété Support OpenMP.

Pour définir cette option du compilateur par programmation

• Consultez OpenMP.

Exemple

L’exemple suivant montre quelques-uns des effets du démarrage du pool de threads par rapport à l’utilisation du pool de threads après son démarrage. En supposant qu’un processeur x64, à cœur unique, double processeur, le pool de threads prend environ 16 ms pour démarrer. Après cela, il y a peu de frais supplémentaires pour le pool de threads.

Lorsque vous compilez l’utilisation /openmp, le deuxième appel à test2 ne s’exécute jamais plus longtemps que si vous compilez à l’aide /openmp-, car il n’y a pas de démarrage de pool de threads. À un million d’itérations, la /openmp version est plus rapide que la /openmp- version du deuxième appel à test2. À 25 itérations, les deux /openmp- versions /openmp s’inscrivent moins que la granularité de l’horloge.

Si vous n’avez qu’une seule boucle dans votre application et qu’elle s’exécute en moins de 15 ms (ajustée pour la surcharge approximative sur votre ordinateur), /openmp peut ne pas être appropriée. Si c’est plus élevé, vous pouvez envisager d’utiliser /openmp.

// cpp_compiler_options_openmp.cpp
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

volatile DWORD dwStart;
volatile int global = 0;

double test2(int num_steps) {
   int i;
   global++;
   double x, pi, sum = 0.0, step;

   step = 1.0 / (double) num_steps;

   #pragma omp parallel for reduction(+:sum) private(x)
   for (i = 1; i <= num_steps; i++) {
      x = (i - 0.5) * step;
      sum = sum + 4.0 / (1.0 + x*x);
   }

   pi = step * sum;
   return pi;
}

int main(int argc, char* argv[]) {
   double   d;
   int n = 1000000;

   if (argc > 1)
      n = atoi(argv[1]);

   dwStart = GetTickCount();
   d = test2(n);
   printf_s("For %d steps, pi = %.15f, %d milliseconds\n", n, d, GetTickCount() - dwStart);

   dwStart = GetTickCount();
   d = test2(n);
   printf_s("For %d steps, pi = %.15f, %d milliseconds\n", n, d, GetTickCount() - dwStart);
}

Voir aussi

Options du compilateur MSVC
Syntaxe de ligne de commande du compilateur MSVC
OpenMP dans MSVC