/openmp (Enable OpenMP 2.0 Support)
Causes the compiler to process #pragma omp.
/openmp
Remarks
#pragma omp is used to specify OpenMP Directives and OpenMP Clauses. If /openmp is not specified in a compilation, the compiler ignores OpenMP clauses and directives. OpenMP Function calls are processed by the compiler even if /openmp is not specified.
An application compiled with /openmp and using the OpenMP Libraries can only be run on Windows 2000 or later operating systems.
Applications compiled with /openmp and /clr can only be run in a single application domain process; multiple application domains are not supported. That is, when the module constructor (.cctor) is run, it will detect the process is compiled with /openmp and if the application is being loaded into a non-default runtime. For more information, see appdomain, /clr (Common Language Runtime Compilation), and Initialization of Mixed Assemblies.
If you attempt to load an application compiled with /openmp and /clr into a non-default application domain, a TypeInitializationException exception will be thrown outside the debugger and a OpenMPWithMultipleAppdomainsException exception will be thrown in the debugger.
These exceptions can also be raised in the following situations:
If your application compiled with /clr, but not with /openmp, is loaded into a non-default application domain but where the process includes an application that was compiled with /openmp.
If you pass your /clr application to a utility, such as regasm.exe (Assembly Registration Tool (Regasm.exe)), which loads its target assemblies into a non-default application domain.
The common language runtime's code access security doesn’t work in OpenMP regions. If you apply a CLR code access security attribute outside a parallel region, it won't be in effect in the parallel region.
Microsoft advises that you do not write /openmp applications that allows partially trusted callers, using AllowPartiallyTrustedCallersAttribute, or any CLR code access security attributes.
To set this compiler option in the Visual Studio development environment
Open the project's Property Pages dialog box. For details, see How to: Open Project Property Pages.
Expand the Configuration Properties node.
Expand the C/C++ node.
Select the Language property page.
Modify the OpenMP Support property.
To set this compiler option programmatically
- See OpenMP.
Example
The following sample shows some of the effects of threadpool startup versus using the threadpool after it started up. Assuming an x64, single core, dual processor the threadpool takes about 16ms to startup. After that though there is very little cost for the threadpool.
When you compile with /openmp, the second call to test2 never runs any longer than if you compile with /openmp-, as there is no threadpool startup. At a million iterations the /openmp version is faster than the /openmp- version for the second call to test2, and at 25 iterations both /openmp- and /openmp versions register less than the clock granularity.
So if you have only one loop in your application and it runs in less than 15ms (adjusted for the approximate overhead on your machine), /openmp may not be appropriate, but if it's anything more than that, you may want to consider using /openmp.
// cpp_compiler_options_openmp.cpp
#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("For %d steps, pi = %.15f, %d milliseconds\n", n, d, GetTickCount() - dwStart);
dwStart = GetTickCount();
d = test2(n);
printf("For %d steps, pi = %.15f, %d milliseconds\n", n, d, GetTickCount() - dwStart);
}