Intel compiler (C++) issue with OpenMP reduction on std::vector

Question

Since OpenMP 4.0, user-defined reduction is supported. So I defined the reduction on std::vector in C++ exactly from here. It works fine with GNU/5.4.0 and GNU/6.4.0, but it returns random values for the reduction with intel/2018.1.163.

This is the example:

#include <iostream>
#include <vector>
#include <algorithm>
#include "omp.h"

#pragma omp declare reduction(vec_double_plus : std::vector<double> : \
                              std::transform(omp_out.begin(), omp_out.end(), omp_in.begin(), omp_out.begin(), std::plus<double>())) \
                    initializer(omp_priv = omp_orig)

int main() {

    omp_set_num_threads(4);
    int size = 100;
    std::vector<double> w(size,0);

#pragma omp parallel for reduction(vec_double_plus:w)
    for (int i = 0; i < 4; ++i)
        for (int j = 0; j < w.size(); ++j)
            w[j] += 1;

    for(auto i:w)
        if(i != 4)
            std::cout << i << std::endl;

    return 0;
}

Each thread adds 1 to all w entries (its local w) and at the end all of them are added to together (reduction). The result for all w entries is 4 with GNU, but random with the intel compiler. Does anyone have any idea what is happening here?

score 4 · Accepted Answer · answered May 07 '18 at 22:53

This appears to be a bug in the Intel compiler, I can reliably reproduce it with a C example not involving vectors:

#include <stdio.h>

void my_sum_fun(int* outp, int* inp) {
    printf("%d @ %p += %d @ %p\n", *outp, outp, *inp, inp);
    *outp = *outp + *inp;
}

int my_init(int* orig) {
    printf("orig: %d @ %p\n", *orig, orig);
    return *orig;
}

#pragma omp declare reduction(my_sum : int : my_sum_fun(&omp_out, &omp_in) initializer(omp_priv = my_init(&omp_orig))

int main()
{   
    int s = 0;
    #pragma omp parallel for reduction(my_sum : s)
    for (int i = 0; i < 2; i++)
        s+= 1;

    printf("sum: %d\n", s);
}

Output:

orig: 0 @ 0x7ffee43ccc80
0 @ 0x7ffee43ccc80 += 1 @ 0x7ffee43cc780
orig: 1 @ 0x7ffee43ccc80
1 @ 0x7ffee43ccc80 += 2 @ 0x2b56d095ca80
sum: 3

It applies the reduction operation to the original variable before initializing the private copy from the original value. This leads to the wrong result.

You can manually add a barrier as a workaround:

#pragma omp parallel reduction(vec_double_plus : w)
{
  #pragma omp for
  for (int i = 0; i < 4; ++i)
    for (int j = 0; j < w.size(); ++j)
      w[j] += 1;
  #pragma omp barrier
}

This is a neat way to check it. I actually need performance for my code, so using a barrier may not be the best solution for me. I may use GNU for now, until they fix the bug. — Abaris, May 08 '18 at 18:18
@Abaris Actually you don't even need the barrier, splitting the `parallel` / `for` because the end of a `omp for` has an implicit barrier anyway. In any case this transformation should not have any significant performance impacts. — Zulan, May 08 '18 at 20:05
You are right. It worked fine without the barrier, because of the implicit barrier at the end of the for loop. Now I want to get one step closer to what I want to implement, but I get this [error](https://stackoverflow.com/questions/50244264/issue-with-openmp-reduction-on-stdvector-passed-by-reference). — Abaris, May 09 '18 at 01:30

Intel compiler (C++) issue with OpenMP reduction on std::vector

1 Answers1

Linked