OpenMP code which gives wrong answers when I start using 12 threads - c++

Question

I have this piece of Open MP code here which performs an integeration of the function 4.0/(1+x^2) on the interval [0,1]. The analytical answer to this is pi = 3.14159...
The method of integrating the function is just by a plain approximating Riemann sum. Now the code
gives me the correct answer when I use 1 OpenMP thread, upto 11 OpenMP threads.
However it starts giving increasingly wrong answers once I start using 12 OpenMP threads or more.
Why could this be happening? First here is the C++ code. I am using gcc in an Ubuntu 10.10 environment. The code is compiled with g++ -fopenmp integration_OpenMP.cpp
// f(x) = 4/(1+x^2)
// Domain of integration: [0,1]
// Integral over the domain = pi =(approx) 3.14159
#include <iostream>
#include <omp.h>
#include <vector>
#include <algorithm>
#include <functional>
#include <numeric>
int main (void)
{
//Information common to serial and parallel computation.
int num_steps = 2e8;
double dx = 1.0/num_steps;
//Serial Computation: Method pf integration is just a plain Riemann sum
double start = omp_get_wtime();
double serial_sum = 0;
double x = 0;
for (int i=0;i< num_steps; ++i)
{
serial_sum += 4.0*dx/(1.0+x*x);
x += dx;
}
double end = omp_get_wtime();
std::cout << "Time taken for the serial computation: " << end-start << " seconds";
std::cout << "\t\tPi serial: " << serial_sum << std::endl;
//OpenMP computation. Method of integration, just a plain Riemann sum
std::cout << "How many OpenMP threads do you need for parallel computation? ";
int t;//number of openmp threads
std::cin >> t;
start = omp_get_wtime();
double parallel_sum = 0; //will be modified atomically
#pragma omp parallel num_threads(t)
{
int threadIdx = omp_get_thread_num();
int begin = threadIdx * num_steps/t; //integer index of left end point of subinterval
int end = begin + num_steps/t; // integer index of right-endpoint of sub-interval
double dx_local = dx;
double temp = 0;
double x = begin*dx;
for (int i = begin; i < end; ++i)
{
temp += 4.0*dx_local/(1.0+x*x);
x += dx_local;
}
#pragma omp atomic
parallel_sum += temp;
}
end = omp_get_wtime();
std::cout << "Time taken for the parallel computation: " << end-start << " seconds";
std::cout << "\tPi parallel: " << parallel_sum << std::endl;
return 0;
}
Here is the output for different number of threads starting with 11 threads.
OpenMP: ./a.out
Time taken for the serial computation: 1.27744 seconds Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 11
Time taken for the parallel computation: 0.366467 seconds Pi parallel: 3.14159
OpenMP:
OpenMP:
OpenMP:
OpenMP:
OpenMP:
OpenMP: ./a.out
Time taken for the serial computation: 1.28167 seconds Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 12
Time taken for the parallel computation: 0.351284 seconds Pi parallel: 3.16496
OpenMP:
OpenMP:
OpenMP:
OpenMP:
OpenMP:
OpenMP: ./a.out
Time taken for the serial computation: 1.28178 seconds Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 13
Time taken for the parallel computation: 0.434283 seconds Pi parallel: 3.21112
OpenMP: ./a.out
Time taken for the serial computation: 1.2765 seconds Pi serial: 3.14159
How many OpenMP threads do you need for parallel computation? 14
Time taken for the parallel computation: 0.375078 seconds Pi parallel: 3.27163
OpenMP:

Answer 1

Why not just use a parallel for with static partitioning instead?
#pragma omp parallel shared(dx) num_threads(t)
{
double x = omp_get_thread_num() * 1.0 / t;
#pragma omp for reduction(+ : parallel_Sum)
for (int i = 0; i < num_steps; ++i)
{
parallel_Sum += 4.0*dx/(1.0+x*x);
x += dx;
}
}
Then you won't need to manage all the partitioning and atomic collection of results by yourself.
In order to correctly initialize x, we notice that x = (begin * dx) = (threadIdx * num_steps/t) * (1.0 / num_steps) = (threadIdx * 1.0) / t.
Edit: Just tested this final version on my machine and it seems to work correctly.

Answer 2

The problem is in calculating begin:
while you set num_steps = 2e8, when threadIdx==11, num_steps * threadIdx will lead to 32-bit integer overflow, so your start will be calculated incorrectly.
I advise you use long long int for threadIdx, begin and end.
EDIT:
Also note, that your method of calculating begin and end can lead to steps (and precision ) will be lost. For example, for 313 threads you loose 199 steps.
Right way to calculate begin and end would be:
long long int begin = threadIdx * num_steps/t;
long long int end = (threadIdx + 1) * num_steps/t;
For the same reason, you cannot do the trick with parenthesis, but have to use long long.