Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
Tony_the_D
Total Points:
50
Registered User
October 10, 2008 10:48 AM PDT
Multi-core example with OpenMP slower than single core?

I am testing use of OpenMP to make use of multi-core processors.  An example to compute e and pi found on the web works and runs faster than the single core equivalent.

But the code snippet below (from a routine to do matrix inversion) appears to work and shows 100% cpu usage on dual processors, but in fact takes longer to run than the single core processing equivalent.

!$omp parallel sections shared(a,f)
!$omp section
     do 50 k=ip1,mp
        a(j,k)=a(j,k)+f*a(i,k)
50  continue
!$omp end parallel sections

Question:  Has anyone else experienced cases where the dual core processing runs slower than the single core equivalent?  Any ideas why this is so?

I also tried using OpenMP to speed up a Quicksort algorithm and got the same result (single core is faster than dual core?)

 

Steve Nuchia
Total Points:
2,237
Status Points:
1,737
Brown Belt
October 11, 2008 10:31 PM PDT
Rate
 
#1
There is a lot of overhead in OpenMP.  It will run slower unless the loop takes a significant fraction of a second single-threaded.  Tens of milliseconds, minimum.
Also, if the task if memory bandwidth bound rather than compute or cache bound, it will run no faster parallelized, regardless of the API used.  At least on most single-socket hardware.  You have to know your system architecture here.

 
tim18
Total Points:
66,417
Status Points:
66,417
Black Belt
October 11, 2008 11:42 PM PDT
Rate
 
#2 Reply to #1

In the last example posted in this thread, I can't imagine why parallel sections would be used, rather than parallel do, nor why the inner loop would be designated for OpenMP parallel.  If threaded parallelism is required without any thought given to optimization, /Qparallel would be preferable, even though still not often effective.

As to the minimum problem size for effective OpenMP parallel, I have an example which achieves excellent threaded scaling on Core 2 Duo, when the non-threaded version takes only 1 millisecond.   Of course, this is an ideal case; the cache sharing is effective, as are the persistent threads left from a previous parallel region.  The Intel OpenMP run-time does show a reduced overhead, compared with the Microsoft and gnu libraries.

The basic point, that OpenMP parallelism will not have an advantage for a simple inner loop of length 1000, does apply to the posted case.
Tony_the_D
Total Points:
50
Registered User
October 13, 2008 2:00 PM PDT
Rate
 
#3 Reply to #1
There is a lot of overhead in OpenMP.  It will run slower unless the loop takes a significant fraction of a second single-threaded.  Tens of milliseconds, minimum.
Also, if the task if memory bandwidth bound rather than compute or cache bound, it will run no faster parallelized, regardless of the API used.  At least on most single-socket hardware.  You have to know your system architecture here.

 

Thanks for the feedback.  Your comments provide me something to work on.  I can easily construct a test case where I gradually increase the time of the inner loops so that I can evaluate the effect of the overhead.  Knowing about the overhead will also provide a better base for evaluating other parts of our software which could be parallelized.
Tony_the_D
Total Points:
50
Registered User
October 13, 2008 2:06 PM PDT
Rate
 
#4 Reply to #2
Quoting - tim18

In the last example posted in this thread, I can't imagine why parallel sections would be used, rather than parallel do, nor why the inner loop would be designated for OpenMP parallel.  If threaded parallelism is required without any thought given to optimization, /Qparallel would be preferable, even though still not often effective.

As to the minimum problem size for effective OpenMP parallel, I have an example which achieves excellent threaded scaling on Core 2 Duo, when the non-threaded version takes only 1 millisecond.   Of course, this is an ideal case; the cache sharing is effective, as are the persistent threads left from a previous parallel region.  The Intel OpenMP run-time does show a reduced overhead, compared with the Microsoft and gnu libraries.

The basic point, that OpenMP parallelism will not have an advantage for a simple inner loop of length 1000, does apply to the posted case.

Thanks for the feedback.  I am new to the world of parallelization (obviously), so I will look at parallel do as well.


Intel Software Network Forums Statistics

8292 users have contributed to 31239 threads and 99116 posts to date.
In the past 24 hours, we have 10 new thread(s) 10 new posts(s), and 21 new user(s).

In the past 3 days, the most popular thread for everyone has been huge pages on linux? The most posts were made to Pipeline buffer between stages? The post with the most views is Very amusing...  Escalated as

Please welcome our newest member amirsam7