Why a basic loop isn't accelerated by OpenMP? - c++

Question

I have a basic loop:
int i, n=50000000;
for (i=0 ; i<n ; i++)
{
register float val = rand()/(float)RAND_MAX;
}
That I want to accelerate with OpenMP. I previously set:
omp_set_dynamic(0);
omp_set_num_threads(nths);
with nths=4
And the final loop is:
int i, n=50000000;
#pragma omp parallel for firstprivate(n) default(shared)
for (i=0 ; i<n ; i++)
{
register float val = rand()/(float)RAND_MAX;
}
The non parallelized loop takes 1.12s to execute and the parallel one takes 21.04s (it can varies a lot depending on my linux priority process). I am on a x86 platform with Ubuntu and 4 CPUs with 1 thread each. I compile with g++ (I need it) that I flagged with -fopenmp and I use the library -lgomp
Why OpenMP doesn't accelerate this basic loop ?
EDIT:
Regarding the answers I changed the inside of the loop to be:
for (i=0 ; i<n ; i++)
{
a[i]=i;
b[i]=i;
c[i]=a[i]+b[i];
}
with n=500000 and the pragma:
#pragma omp parallel for firstprivate(n) default(shared) schedule(dynamic) num_threads(4)
I also changed the code to use only gcc and I have the same problem:
With 1 Thread
Test ms = 0.003000
Test Omp ms = 19.695000
With 4 Threads
Test ms = 0.003000
Test Omp ms = 240.990000
EDIT2:
I changed the way I was measuring time when using OpenMP. Instead of the clock() function I used the omp_get_wtime() one, the results are way better.

Answer 1

I ran your code quickly through my system.
First of all, in the array addition case, your 50M is barely enough to show the win, but it does - if OpenMP is set up correctly.
In your case, the schedule(dynamic) is killing you - it tells the compiler to spread the work to the team at runtime. That would make sense if you cannot predetermine your workload - but in this case it's perfectly predictable as the effort per iteration is exactly the same.
I get the following results after editing your example (see below) and running on a hyperthreaded CPU with the cores all fixed on the lowest frequency. I compiled using gcc 4.9.3:
time ./testseq && time ./testpar
real 0m0.576s
user 0m0.504s
sys 0m0.072s
real 0m0.285s
user 0m0.968s
sys 0m0.123s
As you can see, the real value, which is the "wallclock time", roughly halves. The user time increases, because of thread startup and shutdown.
The parallelized results change considerably if i add the schedule(dynamic) clause:
real 0m4.181s
user 0m14.886s
sys 0m1.283s
All of the extra work load is spent on threads that are done doing a small amount of work and looking for the next batch. That requires taking a lock - and that kills your second example. Please only use schedule(dynamic) when you have load balancing issues - where the amount of work per iterator varies wildly.
To give full disclosure, I ran with the following full source code:
CXXFLAGS=-std=c++11 -I. -Wall -Wextra -g -pthread
all: testseq testpar
testpar: test.cpp
${CXX} -o $# $^ -fopenmp ${CXXFLAGS}
testseq: test.cpp
${CXX} -o $# $^ ${CXXFLAGS}
clean:
rm -f *.o *~ test
and test.cpp:
#include <omp.h>
constexpr int n=50*1000*1000;
float a[n];
float b[n];
float c[n];
int main(void) {
#pragma omp parallel for schedule(dynamic)
for (int i=0 ; i<n ; i++) {
a[i]=i;
b[i]=i;
c[i]=a[i]+b[i];
}
}
Note that I also took away the other clauses to your parallel for - you need none of them.

Answer 2

rand() is not at all a thread-safe function. There is a PRNG inside that has a state and therefore cannot be invoked by multiple threads without synchronization. Use different PRNG (C++11 has a bunch of them, Boost as well), use one generator per thread and don't forget to seed them with different seed values (beware of time(NULL)).
UPDATE
n being 500k may be too small to get any speedup due to the overhead of thread creation. Could you test with, e.g., n set to 500M? Moreover, times without OpenMP are suspiciously low (maybe not for such a low n). What are you doing with the a, b, and c arrays after the loop? If nothing, a compiler could optimize the whole loop away in the sequential code. Do something with these arrays, e.g., print out their sum (out of the measured section).