Programación Paralela en Fortran95 usando OpenMP (Parte II)webserver.dmt.upm.es/.../Clase_3_Programacion_Paralela_OpenMP.pdf · Paralela en Fortran95 usando OpenMP Miguel Hermanns

ProgramacionParalela enFortran95

usando OpenMP

Miguel Hermanns

Descomposicion debucles

Directivas de(de)sincronizacion

Directivas nocolaborativas

Clausulas de datosadicionales

La librerıa runtime

Recomendaciones

Resumen

Programacion Paralela en Fortran95usando OpenMP

(Parte II)

Miguel Hermanns

Universidad Politecnica de Madrid, Espana

3 de mayo de 2007


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Estructura de la clase

1 Resumen de la clase anterior

2 Estrategias de descomposicion de bucles

3 Sincronizacion de tareas

4 Directivas no colaborativas

5 Clausulas de datos adicionales

6 La librerıa runtime de OpenMP

7 Recomendaciones personales


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Resumen de la clase anterior

1 Introduccion y motivacion de OpenMP

2 Caracterısticas fundamentales de OpenMP

3 Regiones paralelas y regiones seriales

4 Conceptos generales y terminologıa habitual

5 Variables compartidas y variables privadas

6 Distribucion de la carga computacional



usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Estrategias de descomposicion de bucles

Razon de ser de las estrategias de descomposicion:

El coste de cada iteracion no tiene porque ser igual:

A = 0d0

do j = 1, 1000

do i = 1, j

A(i,j) = 1d0

enddo

enddo

La distribucion equitativa no siempre es la mejor

Otras estrategias dan un mejor balance de la carga

La estrategia se especifica con la clausula SCHEDULE


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP DO

Caracterısticas de la directiva:

Distribuye la carga de un bucle entre las tareas

La descomposicion se hace en el espacio de iteraciones

La descomposicion es modificable mediante clausulas

El contador es implıcitamente declarado PRIVATE

!$OMP DO clause1 clause2 ...

do i = 1, 1000

...

enddo

!$OMP END DO end_clause


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen


Ejemplo de distribucion de carga de un bucle:

!$OMP PARALLEL NUM_THREADS (10)

!$OMP DO

do i = 1, 1000

...

enddo

!$OMP END DO

!$OMP END PARALLEL

10 2. OpenMP constructs

• Work-sharing constructs must be encountered in the same order by all threads in ateam.

All work-sharing constructs have an implied synchronization in their closing-directives.This is in general necessary to ensure that all the information, required by the codefollowing the work-sharing construct, is uptodate. But such a thread synchronizationis not always necessary and therefore a mechanism of suppressing it exists, since it is aresource wasting affair2. For that purpose a special clause exists which is linked to theclosing-directive: NOWAIT. Further information regarding this clause is given in chapter 3,page 47.

2.1.1 !$OMP DO/!$OMP END DO

This directive-pair makes the immediately following do-loop to be executed in parallel.For example

!$OMP DOdo i = 1, 1000

...enddo

!$OMP END DO

distributes the do-loop over the different threads: each thread computes part of theiterations. For example, if 10 threads are in use, then in general each thread computes100 iterations of the do-loop: thread 0 computes from 1 to 100, thread 1 from 101 to 200and so on. This is shown graphically in figure 2.1.

serial region

parallel region

thread 0

thread 0 thread 1 thread 9...

� � �!$OMP DO

do i = 1, 100 do i = 101, 200 do i = 901, 1000

�

Execution

Figure 2.1: Graphical representation of the example explaining the general working principleof the !$OMP DO/!$OMP END DO directive-pair.

2Threads that reach the implied synchronization are idle until all the other threads reach the samepoint.


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen


Restricciones de la directiva !$OMP DO:

En C, el bucle debe ser de un tipo determinado

En Fortran, el bucle no puede ser del tipo do while

El contador debe ser el mismo para todas las tareas

Solo admite bloques estructurados de codigo

Las variables SHARED solo se actualizan al final


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La clausula SCHEDULE

Caracterısticas de la clausula:

Controla la descomposicion del espacio de iteraciones

Controla la distribucion de la carga

La opcion type especifica la estrategia:

STATIC

DYNAMIC

GUIDED

RUNTIME

!$OMP DO SCHEDULE(type ,chunk)

do i = 1, 600

...

enddo

!$OMP END DO


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La estrategia STATIC

Distribuye las iteraciones en bloques de tamano chunk :

!$OMP DO SCHEDULE(STATIC ,chunk)

do i = 1, 600

...

enddo

!$OMP END DO

3.2. Other clauses 49

The 600 iterations are going to be distributed in different ways by changing thevalue of chunk. The results are shown graphically in figure 3.6, where each blockrepresents a piece of work and the number inside it the thread identification numberprocessing the piece of work.

chunk = 150 chunk = 250 chunk = 300 default600

550

500

450

400

350

300

250

200

150

100

50

0

Iteration

space

0

1

2

0

0

1

2

0

1

0

1

2

Figure 3.6: Graphical representation of the example explaining the general working principleof the SCHEDULE(STATIC,chunk) clause for different values of the optional parameter chunk.

In the first case, chunk = 150, four blocks of work are needed to cover the completeiteration space. Since the total number of iterations is exactly four times the valueof chunk, all blocks are exactly equal in size. To distribute the different blocksamong the existing threads, a round-robin procedure is used leading to the presenteddistribution. The resulting parallel running code is not very efficient, since thread0 is going to work while all the other threads are waiting in an idle state.

In the second case, chunk = 250, the number of blocks equals the number of threads,which is something good. But this time the sizes of the blocks are not equal, sincethe total number of iterations is not an exact multiply of chunk. Even though, thisvalue of the optional parameter leads to a faster code than in the previous case,because the latency times are smaller4.

In the third case, chunk = 300, the number of blocks is smaller than the number ofavailable threads. This means that thread 2 is not going to work for the presentdo-loop. The resulting efficiency is worse than in the previous case and equal to thefirst case.

In the last case, which corresponds to do not specify the optional parameter chunk,OpenMP creates a number of blocks equal to the number of available threads andwith equal block sizes. In general this option leads to the best performance, if alliterations require the same computational time. This remark also applies to theprevious cases and explanations.

4In the first case the fact, that thread 0 needs to compute in total 300 iterations, leads to a slowercode than in the second case, where the maximum number of iterations to compute by one thread is 250.

Por defecto todos los bloques son igual de grandes


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La estrategia DYNAMIC

Distribuye los bloques a medida que terminan las tareas:

Ejemplo de paralelizacion tipo pool of tasks

Tiene en cuenta el coste distinto de cada iteracion:


Pieces of work

1 2 3 4 5 6 7 8 9 10 11 12

parallel region

thread 0 thread 1 thread 2

1 2 3

45

6

78

9

10

1112

�

Execution

Figure 3.7: Graphical representation of the example explaining the working principle of theSCHEDULE(DYNAMIC,chunk) clause.

La opcion chunk controla el tamano de los bloques

Por defecto el tamano es de una iteracion

!$OMP DO SCHEDULE(DYNAMIC ,chunk)

do i = 1, 1000

...

enddo

!$OMP END DO


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La estrategia DYNAMIC


Pieces of work

1 2 3 4 5 6 7 8 9 10 11 12

parallel region


1 2 3

45

6

78

9

10

1112

�

Execution

Figure 3.7: Graphical representation of the example explaining the working principle of theSCHEDULE(DYNAMIC,chunk) clause.


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La estrategia GUIDED

Distribuye los bloques a medida que terminan las tareas:

Funcionamiento analogo a la estrategia DYNAMIC

Los bloques se definen con tamanos decrecientes:

OpenMP version 2.0: decrecimiento exponencial

OpenMP version 2.5: decrecimiento proporcional

La opcion chunk controla el tamano mınimo

Por defecto el tamano mınimo es de una iteracion

!$OMP DO SCHEDULE(GUIDED ,chunk)

do i = 1, 1000

...

enddo

!$OMP END DO


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La estrategia GUIDED

Ejemplo de estrategia GUIDED (OpenMP version 2.0):

!$OMP DO SCHEDULE(GUIDED ,256)

do i = 1, 10230

...

enddo

!$OMP END DO

La opcion 256 da el tamano mınimo de los bloques:52 3. PRIVATE, SHARED & Co.

Pieces of work

1 2

2048 iter.

3 4 5 6

1024 iter.

7 8

512 iter.

9 10 11

256 iter.

12

246 iter.

�

Figure 3.8: Graphical representation of the effect of the SCHEDULE(GUIDED,chunk) clause on ado-loop with 10230 iterations and with chunk = 256.

To see in figure 3.8 is that the last piece of work is smaller than the value specifiedin chunk. This is necessary in order to fulfill the total number of iterations of thedo-loop, namely 10230.

Once the pieces of work have been created, the way in which they are distributedamong the available threads is the same as in the previous scheduling methodDYNAMIC.

RUNTIME : Any of the previous three scheduling methods needs to be fixed at the time ofcompiling the source code. But it may be of interest to be able to modify duringruntime the way in which the work is distributed among the threads. This can beachieved by specifying the RUNTIME scheduling method:

!$OMP DO SCHEDULE(RUNTIME)

If this is done, then the content of the environment variable OMP SCHEDULE speci-fies the scheduling method to be used. More information about the OMP SCHEDULE

environment variable can be found on page 70.

3.2.5 ORDERED

When a do-loop includes statements, which need to be executed sequentially, like in thefollowing example:

do i = 1, 1000A(i) = 2 * A(i-1)

enddo


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La estrategia RUNTIME

Caracterısticas de la estrategia:

Permite especificar la estrategia en tiempo de ejecucion

Lo especifica la variable de entorno OMP SCHEDULE:

hermanns@bender:~$ export OMP SCHEDULE="guided,4"hermanns@bender:~$ export OMP SCHEDULE="dynamic"

Restricciones de la estrategia:

Solo se puede especificar una unica estrategia paratodos los bucles que usen la opcion RUNTIME

!$OMP DO SCHEDULE(RUNTIME)

do i = 1, 1000

...

enddo

!$OMP END DO


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP ORDEREDEspecifica que parte de un bucle se ejecute ordenadamente:

Cada tarea ejecuta su parte cuando le toque

Las demas tareas esperan su turno

Hay que anadir la clausula ORDERED a !$OMP DO

Solo puede haber una region ordenada por bucle

!$OMP DO ORDERED

do i = 1, 100

block1

!$OMP ORDERED

block2

!$OMP END ORDERED

block3

enddo

!$OMP END DO


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP ORDERED

2.3. Synchronization constructs 31

parallel region


� � �!$OMP DO ORDERED

!$OMP END DO

block1 block1 block1

block2

block3 block2

block3 block2

block3

� �

�

�

�

�

��

�

�

�

�

��

� � ��

Execution

Figure 2.7: Graphical representation of the sequence of execution of the example explainingthe working principle of the !$OMP ORDERED/!$OMP END ORDERED directive-pair.

In essence, this directive-pair is similar to the !$OMP CRITICAL/!$OMP END CRITICAL

directive-pair, but without the implied synchronization in the closing-directive and wherethe order of entrance is specified by the sequence condition of the loop iterations.

Despite the typical restrictions, like for example the necessity of the enclosed codeto be a structured block, it is also necessary to take into account, that only one ORDERED

section is allowed to be executed by each iteration inside a parallelized do-loop. Therefore,the following example would not be valid:

!$OMP DO ORDEREDdo i = 1, 1000

...

!$OMP ORDERED...!$OMP END ORDERED

...

!$OMP ORDERED...!$OMP END ORDERED

...enddo


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Directivas de (de)sincronizacion de tareas

Caracterısticas de estas directivas:

Permiten obviar las sincronıas implıcitas

Permiten poner en sincronıa a las diferentes tareas

Tarea 0

Tarea 1

Tarea 2

Tarea 3

tiempo

Trabajando Esperando

Sin

croniz

aci

on


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La clausula NOWAIT

Elimina la sincronizacion de tareas al final de una directiva:

Es aplicable a las siguientes directivas:

!$OMP DO

!$OMP SECTIONS

!$OMP WORKSHARE

!$OMP SINGLE (pendiente de ver)

Evita que las tareas pierdan el tiempo esperando

!$OMP DO

do i = 1, 1000

a = i

enddo

!$OMP END DO NOWAIT

!$OMP DO

do i = 1, 200

b = i

enddo

!$OMP END DO


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP BARRIER

Obliga a las tareas a esperar a las rezagadas:

...

!$OMP BARRIER26 2. OpenMP constructs

parallel region

thread 0 thread 1 thread Np

...

!$OMP BARRIER

�

�

�

�

�

�

�

��

� � ��

Execution

Figure 2.6: Graphical representation of the effect of the !$OMP BARRIER directive on a team ofthreads.

2.3.4 !$OMP ATOMIC

When a variable in use can be modified from all threads in a team, it is necessary toensure that only one thread at a time is writing/updating the memory location of theconsidered variable, otherwise unpredictable results will occur. In the following example

!$OMP DOdo i = 1, 1000

a = a + ienddo

!$OMP END DO

the desired result would be that a contains the sum of all values of the do-loop vari-able i, but this will not be the case. The present directive targets to ensure that aspecific memory location is updated atomically, rather than exposing it to the possibilityof multiple, simultaneously writing threads. Its syntaxis is very simple:

!$OMP ATOMIC

This directive only affects the immediately following statement. Not all possible state-ments are allowed, since most cannot be treated in an atomic way. Only the followingones can be used together with the !$OMP ATOMIC directive:


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP FLUSH

Fuerza la sincronizacion de variables compartidas:

La lista opcional (variable1,...) especifica cuales

Por defecto se sincronizan todas las variables

Existen algunas limitaciones (pag. 58-61)

!$OMP FLUSH (variable1 ,variable2 ,...)

La funcionalidad de !$OMP FLUSH esta implıcita en:

La salida de casi todas las directivas OpenMP

La entrada de !$OMP PARALLEL, CRITICAL y ORDERED

La directiva !$OMP BARRIER


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Directivas no colaborativas

Caracterısticas de estas directivas:

Hacen que solo trabaje una tarea en vez de todas

Evitan la duplicidad de trabajos

Evitan la colision entre tareas

Restricciones de estas directivas:

Deben ser encontradas por todas las tareas

Solo pueden contener bloques estructurados de codigo


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP SINGLE

Trabaja solo una de las tareas, las demas esperan:

!$OMP SINGLE

write (*,*) "Hello"

!$OMP END SINGLE18 2. OpenMP constructs

parallel region


...

!$OMP SINGLE

!$OMP END SINGLE

write(*,*) "Hello"

��

� � �

�

�

�

�

��

�

�

�

�

��

�

Execution

Figure 2.3: Graphical representation of the example explaining the working principle of the!$OMP SINGLE/!$OMP END SINGLE directive-pair.

be parallelized with the aid of the !$OMP WORKSHARE/!$OMP END WORKSHARE directive-pair:matmul, dot product, sum, product, maxval, minval, count, any, all, spread, pack, unpack,reshape, transpose, eoshift, cshift, minloc and maxloc. The syntax to be used is thefollowing one:

!$OMP WORKSHARE

...

!$OMP END WORKSHARE end_clause

where an implied synchronization exists in the closing-directive !$OMP END WORKSHARE,if the NOWAIT clause is not specified on the closing-directive.

In contrast to the previously presented work-sharing constructs, the block of codeenclosed inside the present directive-pair is executed in such a way, that each statementis completed before the next statement is started. The result is that the block of codebehaves exactly in the same way as if it would be executed in serial. For example,the effects of one statement within the enclosed code must appear to occur before theexecution of the following statements, and the evaluation of the right hand side of anassignment must appear to have been completed prior to the effects of assigning to theleft hand side. This means that the following example

real(8) :: A(1000), B(1000)


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP SINGLE


Una sola tarea ejecuta el bloque de codigo

No se especifica cual de las tareas lo hace

Las demas tareas esperan al final de la directiva

Restricciones de la directiva:

Existen algunas limitaciones menores (pag. 42-43)

!$OMP SINGLE clause1 clause2 ...

...

!$OMP END SINGLE end_clause


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP MASTER

Trabaja solo la tarea maestra, las demas no esperan:

!$OMP MASTER

write (*,*) "Hello"

!$OMP END MASTER2.3. Synchronization constructs 23

parallel region


...

!$OMP MASTER

!$OMP END MASTER

write(*,*) "Hello"

��

�

�

�

�

�

�

�

�

��

�

�

�

�

��

�

Execution

Figure 2.4: Graphical representation of the example explaining the working principle of the!$OMP MASTER/!$OMP END MASTER directive-pair.

!$OMP CRITICAL name

...

!$OMP END CRITICAL name

where the optional name argument identifies the critical section. Although it is notmandatory, it is strongly recommended to give a name to each critical section.

When a thread reaches the beginning of a critical section, it waits there until no otherthread is executing the code in the critical section. Different critical sections using thesame name are treated as one common critical section, which means that only one threadat a time is inside them. Moreover, all unnamed critical sections are considered as onecommon critical section. This is the reason why it is recommended to give names to thecritical sections.

A simple example of use of the present directive-pair, which is also represented graph-ically in figure 2.5, would be:

!$OMP CRITICAL write_filewrite(1,*) data

!$OMP END CRITICAL write_file

What is shown in figure 2.5 is that thread 0 has to wait until thread Np has left theCRITICAL region. Before thread Np, thread 1 was inside the CRITICAL region while threadNp was waiting.


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP MASTER


Solo la tarea maestra ejecuta el bloque de codigo

Las demas tareas no esperan al final de la directiva

Diferencias con la directiva !$OMP SINGLE:

Sı se especifica la tarea encargada de trabajar

No hay una sincronizacion al final de la directiva

Pensada sobre todo para ordenadores tipo NUMA

!$OMP MASTER

...

!$OMP END MASTER


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP CRITICAL

Especifica que solo una tarea ejecute el bloque cada vez:

!$OMP CRITICAL

write (1,*) data

!$OMP END CRITICAL24 2. OpenMP constructs

parallel region


...

!$OMP CRITICAL

!$OMP END CRITICAL

write(1,*) data

� �

�

�

�

�

��

�

�

Execution

Figure 2.5: Graphical representation of the example explaining the working principle of the!$OMP CRITICAL/!$OMP END CRITICAL directive-pair.

2.3.3 !$OMP BARRIER

This directive represents an explicit synchronization between the different threads in theteam. When encountered, each thread waits until all the other threads have reached thispoint. Its syntaxis is very simple:

!$OMP BARRIER

Two restrictions need to be taken into account when using this explicit synchroniza-tion:

• The !$OMP BARRIER directive must be encountered by all threads in a team or bynone at all. Several situations may not fulfill this condition. For example:

!$OMP CRITICAL!$OMP BARRIER

!$OMP END CRITICAL

Since only one thread at a time is executing the content of the CRITICAL region, it isimpossible for the other threads to reach the explicit synchronization. The result isthat the program reaches a state without exit. This situation is called a deadlockand it is necessary to avoid it.

Other examples, where also a deadlock happens, could be:


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP CRITICAL


Una sola tarea ejecuta el bloque de codigo cada vez

Las demas tareas esperan al principio de la directiva

La directiva admite un nombre name para identificarla

Zonas crıticas con mismo nombre son como una sola

Restricciones de la directiva:

Al principio y al final debe aparecer el mismo nombre

!$OMP CRITICAL (name)

...

!$OMP END CRITICAL (name)


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP ATOMICEjemplo de paralelizacion erronea de un bucle:

a = 0

!$OMP PARALLEL SHARED(a) PRIVATE(i)

!$OMP DO

do i = 1, 1000

a = a + i

enddo

!$OMP END DO

!$OMP END PARALLEL

Manera correcta de paralelizar el bucle:

a = 0


!$OMP DO

do i = 1, 1000

!$OMP ATOMIC

a = a + i

enddo

!$OMP END DO

!$OMP END PARALLEL


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La directiva !$OMP ATOMIC

Regula la escritura en variables compartidas:

Solo una tarea puede escribir en la variable cada vez

Afecta a la lınea de codigo inmediatamente despues

Solo admite variables escalares

Solo es aplicable a determinadas operaciones:

Los operadores +,*,-,/,.and.,.or.,.eqv. y .neqv.

Las funciones intrınsecas max, min, iand, ior e ieor

x = x operator expr

x = expr operator x

x = intrinsic_procedure(x, expr)

x = intrinsic_procedure(expr , x)


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Clausulas de datos adicionales

Clausulas de datos vistas:

SHARED, PRIVATE, DEFAULT, FIRSTPRIVATE

Clausulas de datos adicionales:

LASTPRIVATE, REDUCTION, COPYPRIVATE, COPYIN

Caracterısticas generales de las clausulas de datos:

Especifican propiedades “paralelas” de las variables

Una variable solo puede aparecer en una clausula, salvoen FIRSTPRIVATE y LASTPRIVATE a la vez

Cada clausula tiene sus limitaciones (pag. 63-79)


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La clausula LASTPRIVATE

Es una extesion de la clausula PRIVATE:

do i = 1, N-1

A(i) = B(i) + B(i+1)

enddo

A(i) = B(i)

El valor de i debe estar definido al final del bucle:

!$OMP PARALLEL

!$OMP DO LASTPRIVATE(i)

do i = 1, N-1

A(i) = B(i) + B(i+1)

enddo

!$OMP END DO

!$OMP END PARALLEL

A(i) = B(i)


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La clausula LASTPRIVATE

Caracterısticas de las variables LASTPRIVATE:

Cada tarea tiene su propia version de la variable

Eso se consigue replicando la variable en memoria

Las otras tareas no pueden ver su contenido

Es para las directivas !$OMP DO y !$OMP SECTIONS

Su valor final es igual al de la version serial del codigo

Peculiaridades de las variables LASTPRIVATE:

Su valor inicial no esta definido

A veces su valor final puede no estar definido



usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La clausula REDUCTION

Es una extesion de la clausula PRIVATE:

max_val = 0

do i = 1, 1000

max_val = max(max_val , abs(A(i)))

enddo

El acceso a max val debe estar regulado:

max_val = 0

!$OMP PARALLEL SHARED(max_val ,A) PRIVATE(i)

...

!$OMP DO REDUCTION(max:max_val)

do i = 1, 1000

max_val = max(max_val , abs(A(i)))

enddo

!$OMP END DO

...

!$OMP END PARALLEL


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen


Caracterısticas de la clausula REDUCTION:

Crea una copia privada de la variable para cada tarea

La copia privada es inicializada apropiadamente

Al final combina las copias con el operador especificado

Solo es aplicable a determinadas operaciones:

Los operadores +,*,-,.and.,.or.,.eqv. y .neqv.

Las funciones intrınsecas max, min, iand, ior e ieor

x = x operator expr

x = expr operator x !excepto para la resta

x = intrinsic_procedure(x, expr)

x = intrinsic_procedure(expr , x)


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen


Ejemplo de paralelizacion erronea de un bucle:

a = 0


!$OMP DO

do i = 1, 1000

a = a + i

enddo

!$OMP END DO

!$OMP END PARALLEL

Manera correcta de paralelizar el bucle:

a = 0

!$OMP PARALLEL REDUCTION (+:a) PRIVATE(i)

!$OMP DO

do i = 1, 1000

a = a + i

enddo

!$OMP END DO

!$OMP END PARALLEL


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La clausula COPYPRIVATE

Propaga el valor de una variable PRIVATE a las demas tareas:

Solo es para la directiva !$OMP SINGLE

La lista especifica las variables PRIVATE a propagar

Es equivalente al uso de una variable compartida


integer :: a

!$OMP PARALLEL PRIVATE(a)

...

!$OMP SINGLE

read (1,*) a

!$OMP END SINGLE COPYPRIVATE(a)

...

!$OMP END PARALLEL


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

La librerıa runtime de OpenMP

Proporciona un conjunto de rutinas de apoyo:

Todo compilador con soporte para OpenMP la incluye

Las rutinas se definen a traves del modulo omp lib:

program Example

use omp_lib

implicit none

...

end program Example

Existen tres tipos de rutinas:

Rutinas de control

Rutinas cerrojo

Rutinas de cronometraje


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Rutinas de control

Permiten controlar el entorno de ejecucion del programa:

Fijar y determinar el numero de tareas:

call OMP_set_num_threads(N)

N = OMP_get_num_threads ()

Determinar el numero de identificacion de una tarea:

ID = OMP_get_thread_num ()

Determinar el numero de tareas maximo:

N = OMP_get_max_threads ()

Determinar el numero de procesadores disponibles:

Np = OMP_get_num_procs ()


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Rutinas de control

Permiten controlar el entorno de ejecucion del programa:

Determinar si se esta en una region paralela o no:

if(OMP_in_parallel ()) then

...

endif

Habilitar y deshabilitar regiones paralelas anidadas:

call OMP_set_nested (.true.)

L = OMP_get_nested ()

Habilitar y deshabilitar el reajuste dinamico de tareas:

call OMP_set_dynamic (. false .)

L = OMP_get_dynamic


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Rutinas cerrojo

Herramienta adicional para la sincronizacion de tareas:

Permite introducir cerrojos (“locks”) en el codigo

Un cerrojo puede estar echado o no echado

Un cerrojo no echado puede ser echado por una tarea

La tarea pasa entonces a poseer el cerrojo

Las tareas no pueden alterar cerrojos que no poseen

Existen dos tipos de cerrojos:

cerrojos simples: solo pueden echarse una vez

cerrojos anidables: pueden echarse mas de una vez


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Rutinas de cronometraje

Permiten medir tiempos de ejecucion de manera portable:

Proporcionan el wall clock time de cada tarea

El origen de tiempos no es el comienzo del programa

El tiempo proporcionado no es consistente entre tareas

Para determinar el tiempo de ejecucion:

Time_Seconds = OMP_get_wtime ()

Para determinar la precision del cronometro:

Seconds_per_Tick = OMP_get_wtick ()


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Recomendaciones personales

1 No usar la estrategia RUNTIME para bucles

2 Usar la clausula NOWAIT con mucho cuidado

3 Usar !$OMP SINGLE en vez de !$OMP MASTER

4 Evitar usar !$OMP ATOMIC y REDUCTION

5 Usar siempre la clausula DEFAULT(NONE)

6 No usar las rutinas cerrojo de la librerıa runtime


usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Resumen

1 Resumen de la clase anterior

2 Estrategias de descomposicion de bucles

3 Sincronizacion de tareas

4 Directivas no colaborativas

5 Clausulas de datos adicionales

6 La librerıa runtime de OpenMP



usando OpenMP

Miguel Hermanns






Recomendaciones

Resumen

Agradecimientos

Oscar FloresUniversidad Politecnica de Madrid

Documents

Programación Paralela en Fortran95 usando OpenMP (Parte II)webserver.dmt.upm.es/.../Clase_3_Programacion_Paralela_OpenMP.pdf · Paralela en Fortran95 usando OpenMP Miguel Hermanns