26.06.2015 Views

Parallel Programming in Fortran 95 using OpenMP - People

Parallel Programming in Fortran 95 using OpenMP - People

Parallel Programming in Fortran 95 using OpenMP - People

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!