Can a signed long long be used as an iteratorion variable in OpenMP?

Question

I am trying to test out the performance of this program, before I used to have unsigned long long because I saw this as an example, but now that I am trying to parallelize it, the counter must be signed

But I am not sure if my results are returning a counter of only 1 because the data type of counter is signed long long and not unsigned long long. Or if it has to do with OpenMP with Xeon Phi.

On an OpenMP tutorial website, it says the following: "the iteration variable in for must be a signed integer variable type. In OpenMP 3.0, it may also be an unsigned integer variable type, a pointer type or a constant-time random access iterator type."

[...]
#include <sys/types.h>
#include <omp.h>

    [...]    
    size_t i, j;
    signed long long counter = 0;
    [...]
    if((ch1 ^ ch2) == 0)
    {
        counter = 1;
    }

    #pragma omp parallel for private(counter)
    for(i = 1; i < smallest; i++)
    {
        ch1 = getc(fp1); 
        ch2 = getc(fp2);

        if((ch1 ^ ch2) == 0)
        {
            counter++;
        }
    }
    [...]

Complete code at http://pastebin.com/ESU1yXYT

Do I have to cast some data type in order to find the percentage? Or is it probably just an OpenMP problem?

Answer 1

The iteration variable of your omp parallel for loop isn't counter, it's i, which has a type of size_t, not long long. Your issue is that you declare counter as private in the loop, which according to here means that a new counter object is created for each thread, and all references to the original object are replaced by new ones. I'm not sure exactly what the defined behavior is for counter once you've exited the for loop, but it definitely isn't what you're looking for. You probably want to do something like a reduction

#pragma omp parallel for reduction(+:counter)
for(i = 1; i < smallest; i++)
{
    ch1 = getc(fp1); 
    ch2 = getc(fp2);

    if((ch1 ^ ch2) == 0)
    {
        counter += 1;
    }
}

EDIT

According to Microsoft, the value of counter after the parallel for loop should be the same as it was prior to entering the loop, though I don't know if this is general or implementation-specific behavior.