Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
inttel
Total Points:
10
Registered User
July 7, 2009 2:59 PM PDT
openmp slower than single threaded
a program for the sole purpose of trying to demonstrate the advantage of using 4 cores simultaneously is below.

however, it runs for 90 seconds on a 4 core xeon (3ghz) versus 2 seconds on a single core machine.

any hints greatly appreciated.

Tom




#include <stdio.h>
#include <stdlib.h>
#include <omp.h>
#include <time.h>

#define N 1000
#define CHUNKSIZE 25

main () {
time_t sec1;
time_t sec2;
sec1 = time(NULL);
printf("start \n");

int i, chunk;
float a[N];
float b[N];
float c[N];
int j;
float k;


for (i=0; i < N; i++)
a[i] = b[i] = i * 1.0;
chunk = CHUNKSIZE;

#pragma omp parallel for private(i,j,k) schedule(static,chunk)
for (i=0; i < N; i++) {
for (j = 0; j<200000; j++) {
k = rand();
}
// c[i] = a[i] + b[i];
}


sec2 = time(NULL) - sec1;
printf("%ld seconds", sec2);
return 0;

}



compiled using 'gcc -O3 -fopenmp workshare2.c -o workshare2' on gcc 4.3.2 on opensuse64 11.1

Robert Reed (Intel)
Total Points:
9,021
Status Points:
8,521
Brown Belt
July 7, 2009 4:03 PM PDT
Rate
 
#1
Quoting - inttel
a program for the sole purpose of trying to demonstrate the advantage of using 4 cores simultaneously is below.
however, it runs for 90 seconds on a 4 core xeon (3ghz) versus 2 seconds on a single core machine.
any hints greatly appreciated.

[code section excised for sanity]

compiled using 'gcc -O3 -fopenmp workshare2.c -o workshare2' on gcc 4.3.2 on opensuse64 11.1

The core of your problem is probably here:

 

#pragma omp parallel for private(i,j,k) schedule (static,chunk) 
   for (i=0; i < N; i++) {
      for (j = 0; j<200000; j++) {
         k = rand(); 
      } 
      // c[i] = a[i] + b[i]; 
   }

Though rand() not required to be reentrant and therefore not required to be thread safe (see http://www.opengroup.org/onlinepubs/000095399/functions/rand.html), the fact is that some implementations provide thread safety by putting a lock in the function, which probably means that all those parallel invocations of rand() from the various threads are being serialized.  That could go a long way to explaining the slowdown you report.

For future reference, you might consider timing just the code you're testing for parallel performance, rather than including the serial initialization section as part of the timed section as is done in this example.
Dmitriy Vyukov
Total Points:
25,382
Status Points:
25,382
Black Belt
July 9, 2009 6:49 AM PDT
Rate
 
#2 Reply to #1

the fact is that some implementations provide thread safety by putting a lock in the function


Sane implementations (Microsoft Visual C++) provide thread-safety by placing all the data to thread-local storage (TLS). This is a bit sub-optimal, but provides perfect scaling.
You may consider using well-designed self-contained random generator (like the one in boost), so that you will be able to create generator per thread on the stack.
Dmitriy Vyukov
Total Points:
25,382
Status Points:
25,382
Black Belt
July 9, 2009 6:53 AM PDT
Rate
 
#3
There is another possible problem. 25 rand() calls per task can be too small to outweigh parallelization overheads. Work per task must be some 10'000 machine cycles with current tools.
Andrey Karpov
Total Points:
5,573
Status Points:
5,073
Brown Belt
July 10, 2009 4:13 AM PDT
Rate
 
#4 Reply to #1

Additional about rand():
Use of rand() in OpenMP parallel sections
Tudor
Total Points:
945
Status Points:
445
Brown Belt
July 14, 2009 8:38 AM PDT
Rate
 
#5
Ok, I'm a noob at openmp but maybe specifying chunksize = 25 creates too many threads that choke your 4 cores. Try to only create a maximum of 2 * number of cores threads.

--------
'Everything is proceeding as I have foreseen.'
tim18
Total Points:
68,267
Status Points:
68,267
Black Belt
July 14, 2009 9:07 AM PDT
Rate
 
#6 Reply to #5
Quoting - Tudor Serban
Ok, I'm a noob at openmp but maybe specifying chunksize = 25 creates too many threads that choke your 4 cores. Try to only create a maximum of 2 * number of cores threads.
No, setting chunk size doesn't affect the number of threads.  However, you touch on a good point.  Normally, with balanced work among chunks, the largest possible chunk size will be superior, at least when using static scheduling with affinity set.
In this case, it's not at all clear what the original poster was getting at.  It's certainly not a normal usage of openmp.  Maybe he wanted to see whether OpenMP inhibits the compiler from eliminating redundant loops.
jimdempseyatthecove
Total Points:
36,152
Status Points:
36,152
Black Belt
July 14, 2009 12:12 PM PDT
Rate
 
#7 Reply to #6

Normally, with balanced work among chunks, the largest possible chunk size will be superior

Only when all cores/HW threads are dedicated to running your app. When anthing else is running on the system then smaller chunk size may be superior. Similar situation with nested levels and/or when using NOWAIT.

Jim Dempsey

--------

Blog: The Parallel Void


www.quickthreadprogramming.com


Intel Software Network Forums Statistics

8445 users have contributed to 31553 threads and 100400 posts to date.
In the past 24 hours, we have 10 new thread(s) 32 new posts(s), and 42 new user(s).

In the past 3 days, the most popular thread for everyone has been Lost in MKL The most posts were made to TBB on linux segfaulting The post with the most views is Hi,if you were using imsl yo

Please welcome our newest member nonamez