Is there any difference between variables in a private clause and variables defined within a parallel region in OpenMP?

Question

I was wondering if there is any reason for preferring the private(var) clause in OpenMP over the local definition of (private) variables, i.e.

i         


        

Answer 1

It's not just syntactic sugar. One of the features of OpenMP strives for is to not change the serial code if the code is not compiled with OpenMP. Any construct you use as part of a pragma is ignored if you don't compile with OpenMP. Doing this you can use things like private, firstprivaate, collapse, and parallel for without changing your code. Changing the code can affect for example how the code is optimized by the compiler.

If you have code like

int i,j;
#pragma omp parallel for private(j)
for(i = 0; i < n; i++) {
      for(j = 0; j < n; j++) {
   }
}

The only way to do this without private in C89 is to change the code by defining j inside the parallel section e.g:

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

Here's a C++ example with firstprivate. Let's say you have a vector which you want to be private. If you use firstprivate you don't have to change your code but if you declare a private copy inside the parallel region you do change your code. If you compile that without OpenMP it makes a unnecessary copy.

vector<int> a;
#pragma omp parallel {
    vector<int> a_private = a;
}

This logic applies to many other constructs. For example collapse. You could manually fuse a loop which changes your code or you can use collapse and only fuse it when compiled with OpenMP.

However, having said all that, in practice I find often that I need to change the code anyway to get the best parallel result so I usually define everything in parallel sections anyway and don't use features such as private, firstprivate, or collapse (not to mention that OpenMP implementations in C++ often struggle with non-POD anyway so it's often better to do it yourself).