CODEWITHSUNDEEP
c++multithreadinggccopenmpgcc4.9
Stratubas
Stratubas

Reputation: 3067

How to make GNU GCC optimize OpenMP threads similarly

This is my first post here. Yay! Back to the problem:

I'm learning how to use OpenMP. My IDE is Code::Blocks. I want to improve some of my older programs. I need to be sure that the results will be exactly the same. It appears that "for" loops are optimized differently in the master thread than in the other threads.

Example: 

#include <iostream>
#include <omp.h>
int main()
{
    std::cout.precision(17);
    #pragma omp parallel for schedule(static, 1) ordered
    for(int i=0; i<4; i++)
    {
        double sum = 0.;
        for(int j=0; j<10; j++)
        {
            sum += 10.1;
        }
        #pragma omp ordered
        std::cout << "thread " << omp_get_thread_num() <<  " says " << sum << "\n";
    }
    return 0;
}

produces

thread 0 says 101
thread 1 says 100.99999999999998579
thread 2 says 100.99999999999998579
thread 3 says 100.99999999999998579

Can I somehow make sure all threads receive the same optimization than my single-threaded programs (that didn't use OpenMP) have received?

EDIT:

The compiler is "compiler and GDB debugger from TDM-GCC (version 4.9.2, 32 bit, SJLJ)", whatever that means. It's the IDE's "default". I'm not familiar with compiler differences.

The output provided comes from the "Release" build, which is adding the "-O2" argument.

None of "-O", "-O1" and "-O3" arguments produces a "101".

You can try my .exe from dropbox (zip file, also contains possibly required dlls).

Upvotes: 3

Views: 441

Answers (2)

Sarthak Singh
Sarthak Singh

Reputation: 191

This i happens because float or double data type can not represent some numbers like 20.2

#include <iostream>
int main()
{
    std::cout.precision(17);
    double a=20.2;
    std::cout << a << std::endl;
    return 0;
}

its output will be

20.199999999999999

for more information on this see Unexpected Output when adding two float numbers

Don't know why this does not happens for the first thread but if you remove openMP then too you will get the same result.

Upvotes: 2

Mohammed Li
Mohammed Li

Reputation: 901

From what I get this is simply numerical accuracy. For a double value type you should expect 16 digits precision.

I.e. the result is 101 +/- 1.e-16*101

This exactly the range you get. And unless you use something like quadruple precision, this is as good as it gets.

Upvotes: 0

Related Questions