Parallel Programming in Fortran 95 using OpenMP - People
Parallel Programming in Fortran 95 using OpenMP - People
Parallel Programming in Fortran 95 using OpenMP - People
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
50 3. PRIVATE, SHARED & Co.<br />
DYNAMIC : <strong>in</strong> the previous schedul<strong>in</strong>g method the problem of non homogeneous iterations<br />
has been po<strong>in</strong>ted out. In such a situation it turns out to be difficult to forecast<br />
the optimal distribution of the iterations among the threads. A solution would be<br />
to assign the different blocks of work <strong>in</strong> a dynamic way: as one thread f<strong>in</strong>ishes its<br />
piece of work, it gets a new one. This idea is precisely what lies beh<strong>in</strong>d the present<br />
schedul<strong>in</strong>g method.<br />
When SCHEDULE(DYNAMIC,chunk) is specified, the iteration space is divided <strong>in</strong>to<br />
pieces of work with a size equal to chunk. If this optional parameter is not given,<br />
then a size equal to one iteration is considered. Thereafter, each thread gets one of<br />
these pieces of work. When they have f<strong>in</strong>ished with their task, they get assigned a<br />
new one until no pieces of work are left.<br />
The best way to understand the work<strong>in</strong>g pr<strong>in</strong>ciple of this schedul<strong>in</strong>g method is by<br />
means of an example. In the top part of figure 3.7 12 different pieces of work are<br />
shown. The length of each of these blocks represents the amount of computational<br />
time required to compute them. These pieces of work are go<strong>in</strong>g to be distributed<br />
over a team of three threads. The result<strong>in</strong>g execution schema is shown <strong>in</strong> the bottom<br />
part of figure 3.7. Clearly to see is that each thread gets a new piece or work when<br />
it f<strong>in</strong>ishes the previous one.<br />
GUIDED : the previous dynamic method enhances the capabilities and performance with<br />
respect to the static method, but it adds an overhead <strong>in</strong> computational cost due to<br />
the handl<strong>in</strong>g and distribut<strong>in</strong>g of the different iteration packages. This overhead is<br />
reduced as the size of the pieces of work <strong>in</strong>creases, but then a larger non-equilibrium<br />
between the different threads is to expect.<br />
Another dynamic approach to this problem could be to have pieces of work with<br />
decreas<strong>in</strong>g sizes, so that their associated work is smaller and smaller as they are<br />
assigned to the different threads. The decreas<strong>in</strong>g law is of exponential nature so<br />
that the follow<strong>in</strong>g pieces of work have half the number of iterations as the previous<br />
ones. This is what the present schedul<strong>in</strong>g method does.<br />
The optional parameter chunk specifies the smallest number of iterations grouped<br />
<strong>in</strong>to one piece of work. As before, the last piece of work may have a smaller number<br />
of iterations than specified <strong>in</strong> chunk <strong>in</strong> order to cover completely the iteration space.<br />
The number of pieces of work with equal size and the largest size <strong>in</strong> use are <strong>OpenMP</strong>implementation<br />
dependent.<br />
In figure 3.8 an example of the result<strong>in</strong>g pieces of work is shown. The associated<br />
do-loop has the follow<strong>in</strong>g form:<br />
!$OMP DO SCHEDULE(GUIDED,256)<br />
do i = 1, 10230<br />
...<br />
enddo<br />
!$OMP END DO