Mpi Spanish PDF

Procesamiento Paralelo en Redes Linux Utilizando MPI
Alumno: Vicente F. Reyes Puerta

Director: Jose Antonio Jimnez Milln
Julio 2003
2
Resumen
El presente documento realiza un estudio de investigacin que aborda el procesamiento pa-

ralelo en redes de ordenadores. De esta manera se analiza la utilizacin de los clusters (grupos
de ordenadores conectados en red) a modo de computador virtual paralelo como plataforma
para la ejecucin de aplicaciones paralelas.
El entorno utilizado para realizar dicho estudio es el sistema operativo Linux, el cual ofrece
todas las facilidades de acceso a dispositivos y comunicacin necesarias para la ejecucin de
los algoritmos paralelos. Para la implementacin de los algoritmos paralelos desarrollados
hemos utilizado la interfaz MPI (Message Passing Interface, Interfaz de Paso de Mensajes).
Dicha interfaz es un estndar que define la sintaxis y la semntica de las funciones contenidas
en una librera de paso de mensajes diseada para ser usada en programas que exploten la
existencia de mltiples procesadores. De este modo no slo conseguimos que el desarrollo de
los algoritmos sea ms claro y sencillo, si no que adems logramos que sean portables.
El estudio realizado queda dividido en tres partes diferenciadas que coinciden con la es-
tructura del documento. En un principio hacemos un estudio general sobre el procesamiento
paralelo, y establecemos una clasificacin detallada sobre los distintos tipos de paralelismo
existentes en la actualidad. En la segunda parte realizamos un anlisis detallado de la interfaz
de paso de mensajes MPI, ejemplificando la informacin ofrecida con diversos algoritmos es-
critos en C que realizan cmputos paralelos utilizando dicha interfaz. Por ltimo generamos
un estudio de los resultados obtenidos en las ejecuciones explicando paso a paso la manera en
la que han sido cosechados.
3
4
ndice general
Objetivos I
Desarrollo III
I Sistemas de Procesamiento Paralelo 1
1. Introduccin 3
1.1. Utilidades del Procesamiento Paralelo . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definiciones Bsicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Caractersticas Fsicas de la Comunicacin . . . . . . . . . . . . . . 4
1.2.2. Estndares Relacionados . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Clasificacin Sistemas Paralelos . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Paralelismo Implcito o de Bajo Nivel . . . . . . . . . . . . . . . . . 6
1.3.2. Paralelismo Explcito o de Alto Nivel . . . . . . . . . . . . . . . . . 7
1.4. Arquitecturas Basadas en Paralelismo Implcito . . . . . . . . . . . . . . . . 9
1.4.1. Segmentacin o pipeline . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2. Tecnologa SWAR . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.3. Procesadores Auxiliares . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5. Arquitecturas Basadas en Paralelismo Explcito . . . . . . . . . . . . . . . . 19
1.5.1. Multiprocesadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5.2. Multicomputadores . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.5.3. Procesadores Matriciales . . . . . . . . . . . . . . . . . . . . . . . 37
1.5.4. Procesadores Vectoriales . . . . . . . . . . . . . . . . . . . . . . . . 38
2. Herramientas Desarrollo Software Paralelo 43

2.1. Modelos de Interaccin entre Procesadores . . . . . . . . . . . . . . . . . . 43
2.1.1. Paso de Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.1.2. Memoria Compartida . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.2. Utilidades de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.1. PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.2. MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.2.3. P4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.2.4. Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.2.5. Linda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5
6 NDICE GENERAL
II Gua MPI 55
3. El Estndar MPI 57
3.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4. Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5. Plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6. Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6.1. MPI-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.6.2. MPI-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.7. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4. Conceptos Bsicos 67
4.1. Algoritmo Hola Mundo! . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2. Programas MPI en General . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3. Informndonos del Resto del Mundo . . . . . . . . . . . . . . . . . . . . . . 69
4.4. El Problema de la Entrada/Salida . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5. Ubicacin de los Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6. Informacin Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.7. Implementacin Algoritmo Hola Mundo! . . . . . . . . . . . . . . . . . . . 71
5. Paso de Mensajes 73
5.1. Algoritmo Clculo de reas mediante Montecarlo . . . . . . . . . . . . . . . 73
5.2. El Entorno del Mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3. Funciones de Paso de Mensajes Bloqueantes . . . . . . . . . . . . . . . . . . 76
5.4. Funciones de Paso de Mensajes No Bloqueantes . . . . . . . . . . . . . . . . 77
5.5. Agrupaciones de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.5.1. Tipos Derivados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.5.2. Vectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.6. Implementacin Clculo de reas mediante Montecarlo . . . . . . . . . . . . 80
5.6.1. Implementacin con Mensajes Bloqueantes . . . . . . . . . . . . . . 80
5.6.2. Implementacin con Mensajes No Bloqueantes . . . . . . . . . . . . 86
6. Comunicacin Colectiva 93
6.1. Algoritmo Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.2. Distribucin y Recoleccin de los Datos . . . . . . . . . . . . . . . . . . . . 94
6.3. Operaciones de Comunicacin Colectiva . . . . . . . . . . . . . . . . . . . . 96
6.4. Operaciones de Reduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.5. Implementacin Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . 98
7. Comunicadores y Topologas 105

7.1. Algoritmo Multiplicacin de Matrices de Fox . . . . . . . . . . . . . . . . . 105
7.2. Comunicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3. Trabajando con Grupos, Contextos y Comunicadores . . . . . . . . . . . . . 107
7.4. Particionamiento de los Comunicadores . . . . . . . . . . . . . . . . . . . . 110
NDICE GENERAL 7
7.5. Topologas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.6. Divisin de Rejillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.7. Implementacin Multiplicacin de Matrices de Fox . . . . . . . . . . . . . . 114
III Anlisis del Rendimiento 125
8. Evaluacin del Sistema 127

8.1. Utilidad mpptest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.1.1. Compilacin y Ejecucin . . . . . . . . . . . . . . . . . . . . . . . . 128
8.1.2. Formatos de Salida . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.1.3. Visualizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
8.1.4. Grficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
8.1.5. Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.2. Pruebas Realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.2.1. Comunicacin Bloqueante . . . . . . . . . . . . . . . . . . . . . . . 131
8.2.2. Comunicacin No Bloqueante . . . . . . . . . . . . . . . . . . . . . 132
8.2.3. Participacin Total de los Procesos . . . . . . . . . . . . . . . . . . . 133
8.2.4. Solapamiento entre Comunicacin y Procesamiento . . . . . . . . . . 135
8.2.5. Comunicacin Colectiva . . . . . . . . . . . . . . . . . . . . . . . . 136
8.2.6. Fiabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9. Evaluacin de los Algoritmos 143

9.1. Herramientas de Monitorizacin . . . . . . . . . . . . . . . . . . . . . . . . 143
9.1.1. Ficheros de Recorrido . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.1.2. Trazado de la Ejecucin . . . . . . . . . . . . . . . . . . . . . . . . 146
9.1.3. Animacin en Tiempo Real . . . . . . . . . . . . . . . . . . . . . . 147
9.2. Criterios de Evaluacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
9.2.1. Tiempo de Ejecucin . . . . . . . . . . . . . . . . . . . . . . . . . . 148
9.2.2. Nmero de Procesadores . . . . . . . . . . . . . . . . . . . . . . . . 149
9.2.3. Coste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
9.3. Resultados Obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
9.3.1. Algoritmo Clculo de reas mediante Montecarlo Bloqueante . . . . 149
9.3.2. Algoritmo Clculo de reas mediante Montecarlo No Bloqueante . . 151
9.3.3. Algoritmo Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . 154
9.3.4. Algoritmo Multiplicacin de Matrices de Fox . . . . . . . . . . . . . 159
A. Instalacin, Configuracin y Manejo de MPICH 163

A.1. Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.2. Obtencin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.3. Compilacin e Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.4. Configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
A.4.1. El Fichero de Mquinas . . . . . . . . . . . . . . . . . . . . . . . . 166
A.4.2. RSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
A.4.3. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
A.4.4. Secure Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
8 NDICE GENERAL
A.5. Compilacin y Enlace de Programas . . . . . . . . . . . . . . . . . . . . . . 171

A.6. Ejecucin de Programas con mpirun . . . . . . . . . . . . . . . . . . . . . . 172
A.7. Extensin MPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
B. Manual de Referencia 175

B.1. MPI_Bcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
B.2. MPI_Cart_coords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
B.3. MPI_Cart_create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
B.4. MPI_Cart_rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
B.5. MPI_Cart_sub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
B.6. MPI_Comm_create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
B.7. MPI_Comm_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
B.8. MPI_Comm_rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
B.9. MPI_Comm_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
B.10. MPI_Comm_split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
B.11. MPI_Finalize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
B.12. MPI_Get_processor_name . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
B.13. MPI_Group_incl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
B.14. MPI_Init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
B.15. MPI_Irecv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.16. MPI_Isend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
B.17. MPI_Recv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
B.18. MPI_Reduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
B.19. MPI_Send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
B.20. MPI_Sendrecv_replace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
B.21. MPI_Type_commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
B.22. MPI_Type_struct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
B.23. MPI_Type_vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
B.24. MPI_Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
B.25. MPI_Waitall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
B.26. MPI_Waitany . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
B.27. MPI_Wtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Conclusiones 203
Bibliografa 208
Direcciones URL 209

ndice de figuras
1.1. Clasificacin Paralelismo Implcito . . . . . . . . . . . . . . . . . . . . . . . 6

1.2. Clasificacin Paralelismo Explcito . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Ciclo de Instruccin de 2 etapas (A) . . . . . . . . . . . . . . . . . . . . . . 9
1.4. Ciclo de Instruccin de 10 etapas . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5. Ciclo de Instruccin de 2 etapas (B) . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Cauce de 6 etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7. Procesamiento Digital de Seales . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8. Esquema Multiprocesador . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.9. Organizacin Bsica Bus de Tiempo Compartido . . . . . . . . . . . . . . . 20
1.10. Organizacin Bus de Tiempo Compartido con Cach . . . . . . . . . . . . . 21
1.11. Organizacin Memorias Multipuerto . . . . . . . . . . . . . . . . . . . . . . 22
1.12. Topologa Anillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.13. Topologa Malla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.14. Topologa rbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.15. Topologa Hipercubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.16. Objetivo Procesamiento Paralelo en Clusters . . . . . . . . . . . . . . . . . . 30
1.17. Esquema Procesador Matricial . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.18. Esquema Procesador Vectorial . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.19. Cray SX-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1. Modelo Bsico para Paso de Mensajes . . . . . . . . . . . . . . . . . . . . . 44

2.2. Modelo Bsico para Memoria Compartida . . . . . . . . . . . . . . . . . . . 47
2.3. Esquema Bsico Utilizacin MPI . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1. Logo MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1. Generacin Puntos Aleatorios . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2. Clculo Hipotenusa Punto Aleatorio . . . . . . . . . . . . . . . . . . . . . . 75
6.1. Procesos estructurados en rbol . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.1. Grfico Comunicacin Bloqueante . . . . . . . . . . . . . . . . . . . . . . . 132

8.2. Comparacin Com.Bloqueante - No Bloqueante . . . . . . . . . . . . . . . . 134
8.3. Comparacin Com. Participativa - No Participativa . . . . . . . . . . . . . . 135
8.4. Comparacin Com. Solapada - No Solapada . . . . . . . . . . . . . . . . . . 137
8.5. Grfico Comunicacin Colectiva . . . . . . . . . . . . . . . . . . . . . . . . 139
9
10 NDICE DE FIGURAS
9.1. Animacin en Tiempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

9.2. Modelo Ejecucin Clculo de reas Bloqueante 8 Procesos . . . . . . . . . . 150
9.3. Grfico Tiempo Ejecucin Clculo de reas Bloqueante . . . . . . . . . . . 152
9.4. Grfico Coste Clculo de reas Bloqueante . . . . . . . . . . . . . . . . . . 152
9.5. Modelo Ejecucin Clculo de reas No Bloqueante 8 Procesos . . . . . . . . 153
9.6. Grfico Tiempo Ejecucin Clculo de reas No Bloqueante . . . . . . . . . 155
9.7. Grfico Coste Clculo de reas No Bloqueante . . . . . . . . . . . . . . . . 155
9.8. Modelo Ejecucin Regla del Trapecio 8 Procesos . . . . . . . . . . . . . . . 156
9.9. Grfico Tiempo Ejecucin Regla del Trapecio . . . . . . . . . . . . . . . . . 158
9.10. Grfico Coste Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . 158
9.11. Comparacin Tiempos de distintas Cantidades de Procesos . . . . . . . . . . 160
9.12. Comparacin Costes de distintas Cantidades de Procesos . . . . . . . . . . . 160
9.13. Modelo Ejecucin Algoritmo de Fox 9 Procesos . . . . . . . . . . . . . . . . 161
ndice de cuadros
1.1. Dimetros Topologas Hipercubo y Malla . . . . . . . . . . . . . . . . . . . 28

1.2. Ejemplos Computadores Vectoriales . . . . . . . . . . . . . . . . . . . . . . 42
5.1. Tipos de Datos MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1. Operaciones de Reduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.1. Particin Matriz 6*6 en 9 Procesos . . . . . . . . . . . . . . . . . . . . . . . 106

7.2. Topologa Fsica 3*3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.1. Evaluacin Clculo de reas Bloqueante . . . . . . . . . . . . . . . . . . . . 151

9.2. Evaluacin Clculo de reas No Bloqueante . . . . . . . . . . . . . . . . . . 154
9.3. Evaluacin Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . . 157
9.4. Evaluacin Multiplicacin de Matrices de Fox . . . . . . . . . . . . . . . . . 159
11
12 NDICE DE CUADROS
ndice de algoritmos
4.1. Hola Mundo! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1. Clculo de reas mediante Montecarlo (Bloqueante) . . . . . . . . . . . . . 81
5.2. Clculo de reas mediante Montecarlo (No Bloqueante) . . . . . . . . . . . 86
6.1. Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.1. Multiplicacin de Matrices de Fox . . . . . . . . . . . . . . . . . . . . . . . 114
13
14 NDICE DE ALGORITMOS
Objetivos
El objetivo principal del presente proyecto de investigacin consiste en demostrar la utili-

dad y potencialidad del procesamiento paralelo, concretamente en lo relativo a su aplicacin
en clusters (redes de computadores). Debemos probar con resultados reales y anlisis grficos
la mejora en el rendimiento que produce la ejecucin paralela de determinados algoritmos.
Figura 1: Objetivo Procesamiento Paralelo en Clusters
Con el objeto de delimitar el campo de estudio lo primero que debemos hacer es situar
el paralelismo basado en redes dentro de la amplia variedad de sistemas dedicados al proce-
samiento paralelo. Propondremos una clasificacin para los distintos tipos de paralelismo ex-
istentes en la actualidad, y explicaremos las caractersticas principales de cada uno de ellos.
Un aspecto bsico para el desarrollo de la investigacin consiste en disear e implemetar
un conjunto de algoritmos paralelos que pongan en prctica los tipos de comunicacin ms
importantes que se dan en el procesamiento paralelo basado en redes. Para lograr este objetivo
estudiaremos las caracterticas ms importantes de MPI (Message Passing Interface, Interfaz
de Paso de Mensajes) y emplearemos dicha interfaz en el desarrollo de diversos algoritmos
paralelos.
Por ltimo haremos un estudio detallado de los resultados obtenidos en las ejecuciones de
los algoritmos desarrollados, explicando paso a paso la manera en la que han sido realizados.
I
II OBJETIVOS
Dichos resultados sern utilizados para la generacin de grficos que nos ayuden a entender
las importantes ventajas que nos aporta el procesamiento paralelo.
Desarrollo
A continuacin explicaremos detenidamente el desarrollo de la investigacin llevada a

cabo para la realizacin del presente proyecto. Dicho desarrollo coincide en la prctica con la
estructura del documento realizado.
Sistemas de Procesamiento Paralelo

En primer lugar debemos llevar a cabo una visin general del procesamiento paralelo, para
as poder valorar la importancia de este amplio campo de estudio.
En el captulo 1 se estudian los conceptos bsicos relacionados con este modelo de proce-
samiento, y proponemos una clasificacin para los distintos tipos de paralelismo existentes en
la actualidad, explicando las caractersticas principales de cada uno de ellos.
Nuestra clasificacin divide el paralelismo de los computadores en dos grandes ramas:
Paralelismo implcito o de bajo nivel
Paralelismo explcito o de alto nivel
La tcnicas de paralelismo implcito estn dirigidas al reforzamiento del nivel de concurrencia

dentro de la CPU, de manera que queda oculta a la arquitectura del ordenador. Por lo tanto
pueden ser vistos como sistemas de un slo procesador.
Paralelismo Implcito
Procesadores
Segmentacin Mltiples ALUs Auxiliares
Figura 1: Clasificacin Paralelismo Implcito
El paralelismo explcito o de alto nivel hace referencia a aquellos sistemas en los cuales
se interconectan varios procesadores para cooperar en la ejecucin de los programas de apli-
cacin. Se trata de sistemas que ofrecen una infraestructura explcita para el desarrollo del soft-
ware del sistema y aplicaciones que exploten el paralelismo. A este tipo de paralelismo dedi-
caremos el resto de la investigacin, centrndonos concretamente en las arquitecturas MIMD
con memoria distribuida.
III
IV DESARROLLO
Paralelismo Explcito
MISD SIMD
(Procesadores Vectoriales) (Procesadores Matriciales) MIMD
Memoria Compartida Memoria Distribuida

Multiprocesadores Multicomputadores
(SMP) (Cluster)
Figura 2: Clasificacin Paralelismo Explcito
Una vez resuelto el sistema de intercomunicacin fsica de los equipos, deben abordarse
los mecanismos para lograr la coordinacin entre los procesadores. En el captulo 2 analizamos
las caractersticas bsicas de los dos modelos de interaccin entre procesadores (paso de men-
sajes y memoria compartida), para luego centrarnos en las utilidades de desarrollo de software
paralelo ms populares que existen en la actualidad: PVM, MPI, p4, Express y Lynda.
Gua MPI
La segunda parte de nuestro estudio se centra en la utilizacin de la interfaz MPI (Mes-
sage Passing Interface, Interfaz de Paso de Mensajes) para el desarrollo de aplicaciones par-
alelas.
El estudio de la interfaz MPI comienza en el captulo 3 con una explicacin sobre el origen
y la motivacin que promovieron la creacin del estndar. Por otro lado analizamos los con-
tenidos del estndar, sus objetivos, su funcionamiento bsico y sus distintas versiones. Como
vemos en la figura 3, MPI es implementado normalmente como interfaz de comunicaciones,
utilizando las facilidades ofrecidas por el sistema que vayamos a usar (comunicacin va sock-
ets, operaciones de memoria compartida, etc).
MPI_Send() MPI_Recv()
MPI MPI
SO SO
Figura 3: Esquema Funcionamiento MPI
A continuacin en el captulo 4 vemos los conceptos bsicos sobre la utilizacin de MPI

para el desarrollo de programas escritos en C. Todos los programas MPI comparten una serie
de caractersticas. La inicializacin y finalizacin del entorno de ejecucin se llevan a cabo
mediante funciones que explicaremos en este captulo. Tambin analizamos los mtodos para
V
identificar los procesos en ejecucin. Para ejemplificarlo escribiremos un sencillo programa

en C que hace uso de funciones MPI para ejecutar una versin paralela del conocido algoritmo
Hola Mundo!.
El captulo 5 aborda la funcin ms importante y caracterstica del estndar MPI: el paso de
mensajes. Se utiliza bsicamente para el intercambio de datos entre los procesos en ejecucin.
En este captulo estudiamos las caractersticas ms importantes de los mensajes bloqueantes
y no bloqueantes, aplicando dicha teora a la implementacin de un algoritmo diseado para
el clculo de reas circulares. El algoritmo Clculo de reas mediante Montecarlo realiza una
aproximacin del rea de una circunferencia con un radio determinado mediante la simulacin
de variables aleatorias, empleando un mtodo estadstico (figura 4).
Figura 4: Algoritmo Clculo de reas mediante Montecarlo
Las operaciones de comunicacin colectiva son aquellas que se aplican al mismo tiempo
a todos los procesos pertenecientes a un comunicador. Tienen una gran importancia en el
estndar MPI, debido a la claridad de su sintaxis y a su eficiencia. En el captulo 6 analizamos
su utilidad y conveniencia implementando el algoritmo Regla del Trapecio de manera que haga
un uso inteligente de dichas operaciones.
El captulo 7 aborda el uso de comunicadores y topologas. Esta caracterstica hace a MPI
diferente de la mayora de los dems sistemas de paso de mensajes. En pocas palabras, un
comunicador es una coleccin de procesos que pueden mandarse mensajes entre ellos. Una
topologa es una estructura impuesta en los procesos de un comunicador que permite a los
procesos ser direccionados de diferentes maneras. Para ilustrar estas ideas desarrollaremos el
cdigo que implementa el algoritmo de Fox para multiplicar dos matrices cuadradas mediante
su subdivisin en una serie de procesos (cuadro 1).
Anlisis del Rendimiento

Todo el trabajo anteriormente realizado no tendra ningn sentido si no viniera avalado por
unos resultados satisfactorios en la ejecucin de algoritmos paralelos.
Para conseguir una cierta objetividad en el anlisis de los algoritmos ejecutados en un
VI DESARROLLO
0

Proceso 1

Proceso 2
Proceso

3

Proceso 4
Proceso
5
Proceso

6

Proceso 7

Proceso 8
Proceso

Cuadro 1: Subdivisin de Matrices Algoritmo de Fox
determinado sistema paralelo, lo primero que debemos hacer es medir el rendimiento de dicho
sistema. Dicha medicin se realiza a travs de herramientas especializadas en el anlisis, de
modo que podemos saber fcilmente y con seguridad cunto de apropiado es el sistema para la
ejecucin de determinados algoritmos paralelos. En las figuras 6 y 7 mostramos el rendimiento
del sistema en la ejecucin de paso de mensajes bloqueantes y operaciones de comunicacin
colectiva, respectivamente.
Comunicacion Bloqueante
1200
Com.Bloqueante
1000
800
Tiempo (micro-seg)
600
400
200
0
0 200 400 600 800 1000 1200
Tamano (bytes)
Figura 6: Grfico Comunicacin Bloqueante

VII
Comunicacion Colectiva Op.Reduccion-Entero

160000
32
256
512
140000 1024
120000
Tiempo (micro-seg)
100000
80000
60000
40000
20000
0
0 2 4 6 8 10 12 14 16
Num.Procesos
Figura 7: Grfico Comunicacin Colectiva
El captulo 9 aborda el estudio de los resultados obtenidos en las ejecuciones explicando

paso a paso la manera en la que han sido cosechados. Dichos resultados los analizaremos ms
detenidamente en el apartado de conclusiones, ya que nos ayudan a demostrar el xito del
presente proyecto de investigacin.
VIII DESARROLLO
Parte I
Sistemas de Procesamiento Paralelo
1
Captulo 1
Introduccin
Definimos como procesamiento paralelo al concepto de agilizar la ejecucin de un pro-

grama mediante su divisin en fragmentos que pueden ser ejecutados simultneamente, cada
uno en un procesador. De este modo un programa que se ejecute en procesadores podra
ejecutarse veces ms rpido que usando un solo procesador, al menos en teora...
1.1. Utilidades del Procesamiento Paralelo

Aunque el uso de mltiples procesadores puede agilizar muchas operaciones, la mayora de
las aplicaciones no estn diseadas para aprovechar los beneficios del procesamiento paralelo.
Bsicamente el procesamiento paralelo es apropiado para:
Aplicaciones con suficiente paralelismo como para hacer bueno el uso de mltiples
procesadores. El problema radica en identificar las porciones de programa que puedan
ser ejecutadas independiente y simultneamente en procesadores separados; sto en re-
alidad es complejo, ya que encontraremos aplicaciones que podran ser ejecutadas en
paralelo y sin embargo se ralentizan al ser paralelizadas en un sistema particular. Por
ejemplo, un programa que tarda 4 segundos en ser ejecutado en una sola mquina podra
tardar 1 segundo de procesamiento en cada uno de los cuatro procesadores disponibles
en una red, pero no lograramos nada si la coordinacin entre dichos procesadores tar-
dase ms de 3 segundos.
Implementaciones de algoritmos que o bien ya son paralelos (escritos para obtener las
ventajas del procesamiento paralelo) o bien esperamos paralelizar nosotros mismos,
codificando de nuevo al menos alguna de sus partes.
Si nos encontramos en alguno de estos casos veremos que el procesamiento paralelo puede
proporcionarnos el rendimiento de un supercomputador, aplicado a algunos programas que
realizan complejas operaciones u operan en grandes bloques de datos. Y lo que es ms, ello se
puede lograr con hardware relativamente barato. Adems es posible utilizar dichos sistemas
paralelos para la realizacin de otros trabajos cuando no estn ocupados con una tarea en
paralelo.
3
4 CAPTULO 1. INTRODUCCIN
Si no es el procesamiento paralelo lo que se busca, pero queremos mejorar el rendimiento

de nuestra aplicacin, se pueden hacer multitud de cosas. En aplicaciones secuenciales pode-
mos usar un procesador ms rpido, aadir memoria al sistema, etc.
1.2. Definiciones Bsicas

Aunque el procesamiento paralelo haya sido utilizado durante muchos aos en una gran
variedad de sistemas, todava no es familiar para la mayora de los usuarios. Antes de comenzar
la discusin de las varias alternativas existentes para implementar el procesamiento paralelo,
es importante precisar el significado de algunos conceptos fundamentales.
1.2.1. Caractersticas Fsicas de la Comunicacin

Velocidad de Transferencia de Datos
En el campo de las redes de comunicacin el intercambio de informacin entre orde-
nadores se realiza generalmente mediante transmisiones analgicas. En una transmisin analg-
ica el ancho de banda se define como la diferencia mxima entre la frecuencia ms alta y ms
baja de la seal sobre la que se transporta la informacin. Existe una relacin directa entre
el ancho de banda y la velocidad de transmisin: cuanto mayor es el ancho de banda de un
sistema de transmisin, mayor es la velocidad a la que se pueden transmitir los datos en el
medio.
Podemos definir la velocidad de modulacin de una seal analgica como el nmero de
veces por segundo que la seal cambia su valor en la lnea o medio de transmisin. Esta
velocidad se mide en baudios. El nmero de baudios determina la cantidad de cambios de
estado por segundo que se producen en una transmisin. Cuantos ms estados, ms cantidad
de bits por segundo se podrn transmitir.
Definimos la velocidad de transmisin como el nmero de bits transmitidos por segundo.

Su unidad es el bps (bits por segundo). En general si el nmero de estados posibles de la lnea
de comunicacin es , a cada estado le correspondern "! bits de informacin.
Imaginemos que en una red telefnica que funciona a 2400 baudios podemos transmitir
4 bits en cada baudio. En ese caso la velocidad de transmisin sera de 2400 baudios x 4
(bits/baudio) = 9600 bits por segundo.
En la transmisin de informacin digital entre computadores es fundamental que asegure-
mos intercambios de datos libres de errores. El coste de sto estriba en que a la propia informa-
cin a transmitir se le deben aadir otras informaciones adicionales para deteccin/correccin
de errores, para establecer y controlar la comunicacin, etc. Aparece aqu un nuevo concepto
de velocidad que llamaremos velocidad de transferencia de datos, y que representa la cantidad
de informacin til que puede transmitirse por unidad de tiempo.
Latencia
En un sistema de comunicacin llamamos latencia al mnimo tiempo empleado en transmi-
tir un dato, incluyendo la informacin de control necesaria para enviarlo o recibirlo. La latencia
es muy importante en procesamiento paralelo porque determina el tamao granular, es decir,
1.2. DEFINICIONES BSICAS 5
lo mnimo que debe tardar la ejecucin de un segmento de cdigo para que su ejecucin en
paralelo sea rentable, hablando en trminos de rendimiento computacional.
Bsicamente si un segmento de cdigo se ejecuta en menos tiempo del que se emplea en
transmitir su resultado (latencia), entonces ser ms rpido ejecutar dicho segmento de cdigo
de manera secuencial en el procesador que necesita dicho resultado; de este modo la ejecucin
secuencial evitara la sobrecarga en la comunicacin.
1.2.2. Estndares Relacionados

IA32
El modelo IA32 (Intel Architecture, 32-bit) es una especificacin para microproce-
sadores que define su arquitectura y funcionalidad, o lo que es lo mismo, su comportamiento
desde el punto de vista del software. Dicha especificacin define entre otros elementos las
siguientes caractersticas de los microprocesadores:
Los modos de operacin
La organizacin de la memoria
La estructura de los registros
El direccionamiento de los operandos
Los tipos de datos
El conjunto de instrucciones
Interrupciones y excepciones
Todos los microprocesadores Intel x86 (a partir del 80386) siguen el modelo IA32, inclui-
dos los ms recientes: Pentium, P6, Pentium 4, Pentium M y Xeon. AMD y Cyrix tambin
desarrollan multitud de procesadores compatibles con la arquitectura IA32.
Dado que Linux se desarroll en principio en procesadores IA32, y dado que sta fue la
manera en que se centr en el mercado, es conveniente usar dicha denominacin IA32 para
distinguir este tipo de procesadores de los PowerPC, Alpha, PA-RISC, MIPS, SPARC, etc.
RAID
Como en otras reas de rendimiento en los computadores, los diseadores de memorias de
disco reconocen que si uno de los componentes slo puede alcanzar un determinado lmite, se
puede conseguir una ganancia en prestaciones adicional usando varios de esos componentes
en paralelo. En el caso de las memorias de disco, esto conduce al desarrollo de conjuntos de
discos que operen independientemente y en paralelo.
Siguiendo este principio, el esquema RAID (Redundant Array of Independent Disks,
Conjunto Redundante de Discos Independientes) es una tecnologa sencilla para mejorar tanto
el ancho de banda como la fiabilidad de la E/S a disco. Consta de 6 niveles independientes,
desde 0 hasta 5. Estos niveles no implican una relacin jerrquica, pero designan diseos de
arquitecturas diferentes que poseen tres caractersticas comunes:
Paralelismo Implcito
Procesadores
Segmentacin Mltiples ALUs Auxiliares
Figura 1.1: Clasificacin Paralelismo Implcito
1. RAID es un conjunto de unidades fsicas de disco vistas por el sistema operativo como
una nica unidad lgica.
2. Los datos se distribuyen a travs de las unidades fsicas de un conjunto.
3. La capacidad de los discos redundantes se usa para almacenar informacin de paridad,

que garantice la recuperacin de los datos en caso de fallo de disco.
Los detalles de la caracterstica segunda y tercera cambian segn los distintos niveles de RAID.
RAID 0 no soporta la tercera caracterstica. Linux soporta los estndares RAID 0, 1, 4 y 5
adems de hardware RAID especializado.
1.3. Clasificacin Sistemas Paralelos

En general, se puede dividir el paralelismo de los computadores en dos grandes ramas:
Paralelismo implcito o de bajo nivel
Paralelismo explcito o de alto nivel
1.3.1. Paralelismo Implcito o de Bajo Nivel

La tcnicas de paralelismo implcito estn dirigidas al reforzamiento del nivel de concur-
rencia dentro de la CPU, de manera que queda oculta a la arquitectura del ordenador. Por lo
tanto pueden ser vistos como sistemas de un slo procesador. Como ejemplos de paralelismo
de bajo nivel estn:
Segmentacin o pipeline: La ejecucin de cada instruccin se divide en una secuencia

de etapas, de forma que varias instrucciones pueden ejecutarse en paralelo, cada una en
una etapa distinta de su ejecucin.
Mltiples Unidades Funcionales en el Procesador: La repeticin de ALUs permite una

aproximacin superescalar, con la ejecucin paralela de varias instrucciones, todas en
la misma etapa de su ejecucin. Un procesador superescalar es aquel en el que las in-
strucciones comunes (aritmtica entera y en punto flotante, cargas, almacenamientos y
bifurcaciones condicionales) pueden iniciar su ejecucin simultneamente y ejecutarse
de manera independiente. Estas implementaciones plantean problemas complejos de
1.3. CLASIFICACIN SISTEMAS PARALELOS 7
Paralelismo Explcito
MISD SIMD
(Procesadores Vectoriales) (Procesadores Matriciales) MIMD
Memoria Compartida Memoria Distribuida

Multiprocesadores Multicomputadores
(SMP) (Cluster)
Figura 1.2: Clasificacin Paralelismo Explcito
diseo relacionados con el cauce de instrucciones.

En esta lnea, la tecnologa SWAR consiste en agilizar las operaciones en registros de en-
teros mediante la divisin de dichos registros en una serie de campos de igual longitud,
asignando una ALU a cada uno de los campos y realizando la ejecucin paralelamente.
En este caso se ejecuta la misma instruccin sobre distintos datos en paralelo.
Procesadores Auxiliares (Attached Processors): Los procesadores auxiliares son es-

encialmente computadores de propsito especfico que se conectan a un sistema host o
servidor para acelerar determinados tipos de cmputo. El ejemplo ms comn es el uso
de procesadores de E/S, que liberan a la CPU de la responsabilidad del control detallado
de las operaciones de E/S.
1.3.2. Paralelismo Explcito o de Alto Nivel

El paralelismo explcito o de alto nivel hace referencia a aquellos sistemas en los cuales
se interconectan varios procesadores para cooperar en la ejecucin de los programas de apli-
cacin. Se trata de sistemas que ofrecen una infraestructura explcita para el desarrollo del
software del sistema y aplicaciones que exploten el paralelismo.
La forma ms comn de clasificar los sistemas de procesadores paralelos fue la introducida
por Flynn, la cual establece las siguientes categoras de computadores:
SISD (Single Instruction Single Data, Flujo de instrucciones nico y flujo de datos
nico): Un procesador interpreta una secuencia de instrucciones para operar con los
datos almacenados en una memoria. De este modo en cualquier momento slo se es-
t ejecutando una nica instruccin. Esta categora responde a la arquitectura de Von
Neumann, tambin llamados computadores serie escalares.
SIMD (Single Instruction Multiple Data, Flujo de instrucciones nico y flujo de datos
mltiple): Una nica instruccin es aplicada sobre diferentes datos al mismo tiempo. En
las mquinas de este tipo un cierto nmero de elementos procesadores son controlados
y sincronizados mediante una unidad de control. Cada elemento procesador tiene una
memoria asociada, de manera que cada instruccin es ejecutada simultneamente por
todos los elementos procesadores pero sobre un conjunto de datos diferentes. Debido
a su utilidad en el procesamiento de matrices, a este tipo de mquinas se les llama
procesadores matriciales.
MISD (Multiple Instruction Single Data, Flujo de instrucciones mltiple y flujo de

datos nico): Varias instrucciones actan simultneamente sobre un nico trozo de datos.
Este tipo de mquinas se pueden interpretar de dos maneras. En principio, podemos con-
siderarlas como mquinas formadas por varias unidades de procesamiento, las cuales
reciben instrucciones distintas que operan sobre los mismos datos. Esta clase de arqui-
tectura ha sido clasificada por numerosos arquitectos de computadores como impracti-
cable o imposible, y en estos momentos no existen ejemplos que funcionen siguiendo
este modelo. Otra forma de interpretar el modelo MISD es considerarlo como una clase
de mquinas donde un mismo flujo de datos fluye a travs de numerosas unidades de
procesamiento. Arquitecturas altamente segmentadas, como la que poseen los arrays
sistlicos o los procesadores vectoriales, son clasificadas a menudo bajo esta categora.
Estas arquitecturas realizan el procesamiento vectorial a travs de una serie de etapas,
cada una ejecutando una funcin particular produciendo un resultado intermedio. La
razn por la cual dichas arquitecturas son clasificadas como MISD es que los elementos
de un vector pueden ser considerados como pertenecientes al mismo dato, y todas las
etapas del cauce representan mltiples instrucciones que son aplicadas sobre ese vector.
MIMD (Multiple Instruction Multiple Data, Flujo de instrucciones mltiple y flujo

de datos mltiple): Un conjunto de unidades de procesamiento ejecuta simultneamente
diferentes secuencias de instrucciones sobre conjuntos de datos diferentes. Es la organi-
zacin que poseen los sistemas multiprocesadores y multicomputadores en general.
SPMD es una versin restringida de MIMD en la cual todos los procesadores ejecutan
el mismo programa. Al contrario que SIMD, cada procesador ejecuta una secuencia de
instrucciones diferente.
En la organizacin MIMD, los procesadores son de uso general, puesto que deben ser capaces
de procesar todas las instrucciones necesarias para realizar las transformaciones apropiadas de
los datos. Las arquitecturas MIMD se pueden subdividir adems segn la forma que tienen
los procesadores para comunicarse (figura 1.2). Si los procesadores comparten una memoria
comn, entonces cada procesador accede a los programas y datos almacenados en la memoria
compartida, y los procesadores se comunican unos con otros a travs de esa memoria. Este
tipo de sistemas se conocen como multiprocesadores fuertemente acoplados o simplemente
multiprocesadores.
Si cada procesador tiene una memoria dedicada, entonces cada elemento de proceso es
en s mismo un computador. La comunicacin entre los computadores se realiza a travs de
caminos fijos o mediante algn mecanismo de conmutacin de mensajes. Este tipo de sistemas
se conocen como multiprocesadores dbilmente acoplados o multicomputadores.
1.4. ARQUITECTURAS BASADAS EN PARALELISMO IMPLCITO 9
Istruccin Istruccin Resultado

Captacin Ejecucin
Figura 1.3: Ciclo de Instruccin de 2 etapas (A)
1.4. Arquitecturas Basadas en Paralelismo Implcito

1.4.1. Segmentacin o pipeline
Desde 1960 esta arquitectura ha recibido una gran atencin debido a la considerable mejora
que ha producido en la velocidad de proceso sin que ello aumente, en la misma medida, el coste
del sistema.
La segmentacin de instrucciones es similar al uso de una cadena de montaje en una fbri-
ca. Una cadena de montaje saca partido al hecho de que el producto pasa a travs de varias
etapas de produccin. De esta manera se puede trabajar sobre los productos en varias etapas
simultneamente. A este proceso se le llama segmentacin (pipelining) porque, como en una
tubera o cauce (pipeline), en un extremo se aceptan nuevas entradas antes de que algunas
entradas aceptadas anteriormente aparezcan como salidas en el otro extremo.
Para aplicar este concepto a la ejecucin de instrucciones debemos darnos cuenta de que en
realidad una instruccin tiene varias etapas. La figura 1.4 muestra, por ejemplo, una particin
del ciclo de instruccin en 10 etapas que tienen lugar secuencialmente. Claramente puede
pensarse en la utilizacin de la segmentacin.
Como una aproximacin sencilla consideremos la subdivisin del procesamiento de una
instruccin en dos etapas: captacin de instruccin y ejecucin de instruccin. Hay perodos
en la ejecucin de una instruccin en los que no se accede a memoria principal. Este tiempo
podra utilizarse para captar la siguiente instruccin en paralelo con la ejecucin de la actual.
La figura 1.3 representa esta aproximacin.
El cauce tiene dos etapas independientes. La primera etapa capta una instruccin y la
almacena en un buffer. Cuando la segunda etapa est libre la primera le pasa la instruccin
almacenada. Mientras que la segunda etapa ejecuta la instruccin, la primera etapa utiliza
algn ciclo de memoria no usado para captar y almacenar la siguiente instruccin. A sto se
le llama prebsqueda o precaptacin de la instruccin (instruction prefetch) o solapamiento
de la captacin (fetch overlap). Debera estar claro que ese proceso acelerar la ejecucin de
instrucciones.
10
Indireccin Indireccin
Captacin de Captacin del Almacenamiento

instruccin operando del operando
Solicitud de Solicitud de
instruccin operando Ms de Ms de
un operando un resultado
Clculo de Decodificacin Clculo de Operacin Clculo de

la direccin de la operacin la direccin la direccin Chequeo de Interrupcin
con los interrupciones
de la instruccin de la instruccin del operando datos del operando
CAPTULO 1. INTRODUCCIN
Siguiente Cadena No
instruccin o vector interrupcin
Figura 1.4: Ciclo de Instruccin de 10 etapas

Esperar Esperar
Nueva direccin
Istruccin Istruccin Resultado

Captacin Ejecucin
Descartar
Figura 1.5: Ciclo de Instruccin de 2 etapas (B)
Si las etapas de captacin y ejecucin fueran de igual duracin, el tiempo de ciclo de

instruccin se reducira a la mitad. Sin embargo si miramos ms atentamente el cauce de la
figura 1.5 veremos que la duplicacin de la velocidad de ejecucin es poco probable por dos
razones:
1. El tiempo de ejecucin ser generalmente ms largo que el tiempo de captacin. La

ejecucin implicar la lectura y almacenamiento de los operandos y la realizacin de
alguna operacin. De este modo la etapa de captacin puede tener que esperar algn
tiempo antes de que pueda vaciar su buffer.
2. Una instruccin de bifurcacin condicional hace que la direccin de la siguiente instruc-

cin a captar sea desconocida. De este modo, la etapa de captacin debe esperar hasta
que reciba la direccin de la siguiente instruccin desde la etapa de ejecucin. La etapa
de ejecucin puede entonces tener que esperar mientras se capta la siguiente instruccin.
La prdida de tiempo debida a la segunda razn puede reducirse haciendo una estimacin.
Una regla simple es la siguiente: cuando una instruccin de bifurcacin condicional pasa de
la etapa de captacin a la de ejecucin, la etapa de captacin capta la instruccin de memoria
que sigue a la instruccin de salto. Entonces si el salto no se produce no se pierde tiempo. Si
el salto se produce debe desecharse la instruccin captada y captar una nueva instruccin.
Aunque estos factores reduzcan la efectividad potencial del cauce de dos etapas, se produce
alguna aceleracin. Para conseguir una mayor aceleracin, el cauce debe tener ms etapas.
Consideremos la siguiente descomposicin del procesamiento de una instruccin:
Captar Instruccin (Fetch Instruction, FI): Leer la supuesta siguiente instruccin en

un buffer.
Decodificar Instruccin (Decode Instruction, DI): Determinar el cdigo de operacin

y los campos del operando.
Calcular Operandos (Calculate Operands, CO): Calcular la direccin efectiva de ca-

da operando fuente. Esto puede involucrar varios modos de direccionamiento: mediante
desplazamiento, indirecto a travs de registro, indirecto u otros.
Captar Operandos (Fetch Operands, FO): Captar cada operando de memoria. Los
operandos en registros no tienen que ser captados.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
FI DI CO FO EO WO
Instruccin 1
FI DI CO FO EO WO
Instruccin 2
FI DI CO FO EO WO
Instruccin 3
FI DI CO FO EO WO
Instruccin 4
FI DI CO FO EO WO
Instruccin 5
FI DI CO FO EO WO
Instruccin 6
FI DI CO FO EO WO
Instruccin 7
FI DI CO FO EO WO
Instruccin 8
FI DI CO FO EO WO
Instruccin 9
Figura 1.6: Cauce de 6 etapas
Ejecutar Instruccin (Execute Instruction, EI): Realizar la operacin indicada y al-

macenar el resultado, si lo hay, en la posicin de operando destino especificada.
Escribir Operando (Write Operand, WO): Almacenar el resultado en memoria.
Con esta descomposicin las diversas etapas tienen casi igual duracin. Por motivos de clar-
idad asumamos que tienen igual duracin. La figura 1.6 muestra cmo un cauce de 6 etapas
puede reducir el tiempo de ejecucin de 9 instrucciones de 54 a 14 unidades de tiempo.
En realidad dicha simulacin es demasiado idealista. Para empezar no todas las instruc-
ciones recorren las 6 etapas del cauce; por ejemplo, una instruccin de carga no necesita la
etapa WO. Ello complica el hardware del cauce. Adems la mayora de los sistemas no per-
miten varios accesos a memoria simultneos, por lo que las etapas FI, FO y WO no podran
ejecutarse al mismo tiempo.
Otros factores como la dificultad en la ejecucin de la bifurcacin condicional ya comenta-
da, o la espera que se produce en ciertas etapas cuando no todas las etapas son de igual duracin
(lo cual es lo ms comn), complican el diseo y limitan la mejora de las prestaciones.
Segn toda esta discusin precedente, puede parecer que cuanto mayor sea el nmero de
etapas en el cauce, ms rpida ser la velocidad de ejecucin. Algunos diseadores del IBM
S/360 observaron dos factores que frustran este aparente sencillo patrn de diseo de altas
prestaciones, y que siguen siendo ciertos hoy da:
1. En cada etapa, hay algn gasto extra debido a la transferencia de datos de buffer a buffer
y a la realizacin de varias funciones de preparacin y distribucin.
2. La cantidad de control lgico necesario para manejar dependencias de memoria y reg-

istros y para optimizar el uso del cauce aumenta enormemente con el nmero de etapas.
En definitiva, la segmentacin de instrucciones es una poderosa tcnica para aumentar las

prestaciones pero requiere un diseo cuidadoso si se quieren obtener resultados ptimos con
una complejidad razonable.
La emergencia de la segmentacin y su temprana evolucin se produjo en la primera lnea
de supercomputadores IBM. El modelo IBM 7030 (llamado computador a toda mecha) su-
per en 100 veces la velocidad del computador ms rpido en produccin de aquella poca,
el IBM 704. Dicho logro slo se pudo alcanzar mediante la segmentacin de instrucciones.
Luego vinieron otros xitos como el IBM 360/91, el procesador 6502, y un largo etc. Hoy da
todas las compaas implementan es sus procesadores este tipo de arquitectura.
1.4.2. Tecnologa SWAR

SWAR (SIMD Within A Register, Paralelismo SIMD Dentro de un Registro) es el tr-
mino genrico aplicado a un tipo de paralelismo interno al procesador. La idea consiste en
agilizar las operaciones en registros de enteros mediante la divisin de dichos registros en
una serie de campos de igual longitud, asignando una unidad de procesamiento (una ALU en
definitiva) a cada uno de los campos y realizando la ejecucin paralelamente.
Dada una mquina con registros de # bits y ALUs, se puede lograr que sus operaciones
sobre registros funcionen como operaciones paralelas SIMD en campos de #%$& bits. De
todas formas slo con el empuje de las tecnologas multimedia, que han conseguido acelerar
las operaciones en un rango de 2x hasta 8x, se ha llegado a la popularidad e importancia de
dicha tecnologa. Ya en 1997 la mayora de los microprocesadores incorporaban soporte de
hardware para SWAR:
Intel Pentium II & Pentium with MMX (MultiMedia eXtensions, Extensiones Multi-
media)
AMD K6 MMX (MultiMedia eXtensions, Extensiones Multimedia)
Cyrix M2 MMX (MultiMedia eXtensions, Extensiones Multimedia)
Digital Alpha MAX (MultimediA eXtensions, Extensiones Multimedia)
HewlettPackard PARISC MAX (Multimedia Acceleration eXtensions, Extensiones

de Aceleracin Multimedia)
Microunity Mediaprocessor SIGD (Single Instruction on Groups of Data, Instruc-

ciones nicas en Grupos de Datos)
MDMX, pronunciado Mad Max (MIPS Digital Media eXtension, Extensiones Media
Digital MIPS)
Sun SPARC V9 VIS (Visual Instruction Set, Juego de Instrucciones Visuales)

A diferencia de lo que sucede con las tres firmas que aceptaron las primitivas MMX (In-
tel/AMD/Cyrix), todos los los dems conjuntos de instrucciones son difcilmente compara-
bles, y mutuamente incompatibles. Con el paso del tiempo las MMX tambin evolucionaron,
generandose nuevas extensiones como las EMMX de Cyrix, las 3DNow! de AMD o las SSE
y SSE2 de Intel, entre otras.
1.4.2.1. Utilidades de SWAR

Aunque todos los procesadores actuales son capaces de ejecutar al menos algn tipo de
paralelismo basado en la tecnologa SWAR, la realidad es que ni siquiera los juegos de instruc-
ciones SWAR ms desarrollados soportan paralelismo de carcter general. De hecho, muchos
piensan que la diferencia de rendimiento entre un procesador Pentium y un Pentium MMX se
debe ms a factores como el mayor tamao de la cach que a la aparicin de las MMX. As
pues... para qu es realmente buena la tecnologa SWAR?
Operaciones sobre datos de tipo entero, cuanto ms pequeos mejor. Dos valores de 32
bits caben en un registro MMX de 64 bits, pero tambin lo hacen ocho caracteres de un
byte o incluso un tablero de ajedrez con valores de un bit. Cuando un dato ocupa varios
campos de un registro, determinadas operaciones (llamadas operaciones particionadas)
se ven afectadas por interacciones entre los campos debido al acarreo/resto, etc. Por ello,
cuanto menor sea el tamao de dichos enteros, ms limpias sern las operaciones y por
lo tanto mejor aprovecharemos el parelismo generado por la repeticin de ALUs.
Nota: En los juegos de instrucciones ms actuales, como lal EMMX, las 3DNow! o las
SSE2, tambin se admiten operaciones sobre datos de tipo flotante.
Paralelismo SIMD o de vectores, en el cual la misma operacin es aplicada a todos los

campos simultneamente. Hay maneras de anular la operacin en algunos campos selec-
cionados (enmascaramiento), pero ello complica el cdigo y disminuye el rendimiento.
Referencias a memoria localizadas y regulares. SWAR en general y MMX en particular

no obtienen buenos resultados utilizando accesos aleatorios. Reunir con dichos accesos
un vector x[y] (donde y es un ndice de dicho vector) resulta demasiado costoso.
Es cierto que todas stas son restricciones muy duras, pero tambin es cierto que dicho tipo
de paralelismo se da en muchos algoritmos paralelos (no slo en aplicaciones multimedia).
Enfocada al tipo de paralelismo adecuado, la tecnologa SWAR puede ser ms eficiente que
utilizar SMPs o Clusters... y no cuesta nada utilizarla.
1.4.2.2. Soporte MMX Bajo Linux

Bajo Linux los procesadores IA32 son nuestro principal inters. Lo bueno es que tanto
los AMD, como los Cyrix y los Intel tienen una base comn, las instrucciones MMX. Sin
embargo el rendimiento de dichas instrucciones vara, y adems, actualmente cada firma tiene
sus propias extensiones; por lo tanto programar un soporte para dichas instrucciones puede
resultar algo engorroso.
Existen tres mtodos para utilizar MMX en SWAR:
1. Utilizar una librera de funciones MMX ya desarrollada. En la Universidad de Purdue

existe un grupo de trabajo (URL [15]) que ha desarrollado libreras adaptadas a varios
juegos de instrucciones determinados. As, tenemos la librera libmmx diseada para
las instrucciones MMX en general, la librera libxmmx para las Cyrix EMMX y la
librera libsse para las Intel SSE. Tambin existe una librera un tanto curiosa, MMX
Emulator (URL [7]), diseada para ejecutar programas que usen instrucciones MMX
en procesadores que no tengan soporte para ellas. As, afirman tener un 386 MMX...
como sus realizadores apuntan, es lento pero funciona.
2. Usar las instrucciones MMX directamente. Esto es algo complicado por dos razones. El
primer problema es la portabilidad: no podremos ejecutar un programa as implementa-
do en procesadores que no tengan soporte para MMX. El segundo problema es que el
ensamblador para IA32 que utilicemos en Linux podra no soportar dichas instrucciones
MMX.
3. Utilizar un lenguage de alto nivel o un compilador que genere directamente las instruc-
ciones MMX apropiadas. En este sentido, en la Universidad de Purdue (URL [15]) se
ha desarrollado un lenguaje llamado SWARC y su compilador, el Scc, el cual est en
permanente fase experimental, aunque disponible. Como sus autores sealan, Scc no
pretende ser un producto de alta calidad en trminos de eficiencia; en cambio propor-
ciona una implementacin bsica del modelo SWAR.
Por otro lado tenemos los compiladores de Intel (URL [4]) de C++ y Fortran para Linux,
los cuales generan las instrucciones MMX deseadas de manera optimizada.
1.4.3. Procesadores Auxiliares

Los procesadores auxiliares son esencialmente computadores de propsito especfico que
se conectan a un sistema host o servidor para acelerar determinados tipos de cmputo. Por
ejemplo, muchas tarjetas de vdeo y audio para PCs contienen procesadores auxiliares disea-
dos, respectivamente, para acelerar operaciones sobre grficos y audio.
Aunque esta tcnica ya no est en auge, es muy difcil que otros mtodos de procesamiento
paralelo alcancen su bajo coste y alto rendimiento. Una buena manera de sacarle partido a estos
procesadores es utilizar un PC bajo Linux como servidor. El problema es que no existe mucho
software de soporte disponible, por lo que en ocasiones tendremos que trabajar por nuestra
cuenta desarrollndolo nosotros mismos.
1.4.3.1. Beneficios de los PCs bajo Linux como Servidor

Antes de que nos desanime el hecho de trabajar por nuestra cuenta, es til entender que,
aunque pueda ser dificultoso hacer que un PC bajo Linux acte como servidor de un determi-
nado sistema, es una de las pocas plataformas adecuadas para este tipo de uso.
Los PCs son buenos servidores por dos razones principalmente. La primera es su capaci-
dad de ampliacin, de manera fcil y barata. Recursos como la memoria, discos, redes, etc.
son aadidos a un PC de manera trivial. La segunda es su facilidad de interconexin a otros
dispositivos a travs de sus interfaces estndar. No slo estn ampliamente disponibles los
prototipos de los buses ISA y PCI si no que adems disponemos del puerto paralelo, el cual
Figura 1.7: Procesamiento Digital de Seales
ofrece un rendimiento razonable en un iterfaz independiente. Adems la separacin del es-

pacio de E/S en los microprocesadores IA32 facilita la interconexin, proporcionando una
proteccin hardware de las direcciones de E/S.
Por otra parte Linux es un buen sistema operativo para crear un servidor. La disponibili-
dad de todo el cdigo fuente y la extensa documentacin existente son una ayuda tremenda,
obviamente. Adems Linux proporciona una planificacin cercana al tiempo real, e incluso
existe una versin de Linux en tiempo real desarrollada por FSMLabs (URL [3]). Pero lo que
quizs es ms importante es el hecho de que a la vez que proporciona un entorno UNIX com-
pleto, Linux soporta herramientas de desarrollo que estn diseadas para ser ejecutadas bajo
Microsoft DOS o Windows. Los programas MSDOS pueden ser ejecutados en Linux usando
dosemu, el cual proporciona una mquina virtual protegida que ejecuta MSDOS. El soporte
de Linux para los programas diseados para Windows 3.xx es an ms directo: software li-
bre como wine. Este software (URL [21]) simula Windows 3.xx y Win32 lo suficientemente
bien como para que la mayora de los programas se ejecuten correcta y eficientemente en un
entorno UNIX/X.
Las siguientes dos secciones arrojan ejemplos de sistemas paralelos que utilizan esta ar-
quitectura que podran ser soportados bajo Linux.
1.4.3.2. Procesadores DSP

Un DSP (Digital Signal Processor, Procesador de Seales Digitales) es un tipo de mi-
croprocesador muy rpido y potente. Un DSP procesa los datos en tiempo real. Esta capacidad
de tiempo real hace de los DSPs perfectos para aplicaciones que no pueden tolerar demoras.
As, suelen emplearse en el Procesamiento Digital de Seales, un mtodo de procesamiento
de seales del mundo real que utiliza tcnicas matemticas para realizar transformaciones o
extraer informacin, como se muestra en la figura 1.7.
Aqu tenemos algunas de las ventajas de dichos procesadores:
Operaciones de multiplicacin y suma en un slo ciclo
Funcionamiento en tiempo real, simulacin y emulacin
Flexibilidad
Fiabilidad
Aumenta rendimiento del sistema

Disminuye costes
Existe un prspero mercado para estos procesadores. Aunque estos chips fueron generalmente
diseados para ser utilizados en sistemas de aplicacin especfica, tambin pueden ser utiliza-
dos como magnficos computadores paralelos auxiliares. Estos son los beneficios de utilizar
dichos procesadores como computadores paralelos auxiliares:
Muchos de ellos, como los Texas Instruments TMS320 y los Analog Devices SHARC
DSP, estn diseados para construir mquinas paralelas con poca o ninguna lgica de
enlace.
Son econmicos, especialmente por MIP o MFLOP. Incluyendo el coste de la lgica
de soporte bsica, suele decirse que su coste es una dcima parte de lo que cuesta un
procesador para PC con un rendimiento comparable.
No utilizan mucha energa ni desprenden demasiado calor. Esto significa que es posible
tener un grupo de estos chips alimentados por una fuente de alimentacin convencional
para PCs, y encerrarlos dentro del chasis del PC sin que se convierta en un horno.
Existen algunos elementos en los juegos de instrucciones de los DSP que los compi-
ladores de alto nivel no suelen usar de manera apropiada, como por ejemplo la operacin
Bit Reverse Addressing. Usando un sistema paralelo auxiliar, es posible compilar y
ejecutar la mayora del cdigo en el servidor, ejecutando aquellos algoritmos que hacen
un mayor consumo de tiempo en los DSPs. Dichos algoritmos pueden ser implementa-
dos mediante un cdigo cuidadosamente adaptado.
Los procesadores DSP no estn diseados para ejecutar un sistema operativo UNIX, y
generalmente no son muy buenos como procesadores de propsito general. Por ejemplo,
muchos de ellos no tienen hardware de manejo de memoria. En otras palabras, funcionan
mejor como clientes de un servidor de propsito ms general... como un PC bajo Linux.
Muchas tarjetas de sonido y modems incluyen procesadores DSP que pueden ser accedidos
mediante controladores de Linux sin ninguna dificultad. Lo difcil llega cuando utilizamos un
sistema paralelo auxiliar que contenga cuatro o ms procesadores DSP... y eso es exactamente
lo que nos interesa. Existen dos familias de procesadores DSP utilizados ampliamente para
procesamiento paralelo:
Texas Instruments TMS320 Muy populares durante mucho tiempo, resulta muy sencillo
construir un procesador paralelo basado en el TMS320. Existen versiones del TMS320
slo para enteros y tambin para punto flotante; los diseos ms antiguos usaban algn
tipo inusual del formato punto flotante de precisin simple, pero los nuevos modelos so-
portan los formatos IEEE. El antiguo TMS320C4x consigue hasta 80 Mflops usando el
formato punto flotante simple precisin especfico de Texas Instruments; en constraste,
el TMS320C67x proporciona hasta 1Gflop simple precisin o 420 Mflops doble pre-
cisin para los clculos en formato punto flotante IEEE. No slo es fcil configurar un
grupo de estos chips como un multiprocesador, si no que adems existen chips multi-
procesadores, como el TMS320C8x que combina en paralelo un procesador RISC mae-
stro con unidad de punto flotante IEEE a 100 Mflops con dos o cuatro DSPs esclavos
con unidad de entero.
Analog Devices SHARC Estos chips pueden ser utilizados como un multiprocesador de 6
procesadores con memoria compartida y sin lgica de conexionado externa. Sistemas
mayores pueden ser construidos usando 6 enlaces de 4 bits por chip. Muchos de los
sistemas ms grandes son empleados en aplicaciones militares, y resultan econmicos.
En esta lnea la compaa Integrated Computing Engines, llamada en la actualidad Me-
dia100, ofrece una gama de tarjetas PCI llamadas GreeICE y BlueICE, sta ltima ms
actual. La primera versin (GreenICE) contiene una matriz de 16 procesadores SHARC
y es capaz de proporcionar picos de velocidad de hasta 1,9 Gflops usando el formato
IEEE simple precisin. BlueICE triplica dicha velocidad, y su coste no es elevado.
1.4.3.3. FPGAs y Computadores de Lgica Reprogramable
Si el paralelismo consiste en conseguir la mxima velocidad, por qu no construimos

nuestro propio hardware? El problema es que cuesta mucho, lleva mucho tiempo su desarrollo,
se vuelve inservible cuando cambiamos el algoritmo aunque sea slo un poco, etc. Sin embargo
recientes avances en los FPGAs (Field Programmable Gate Array, Matriz de Compuertas
Lgicas Programable) elctricamente reprogramables han anulado dichas objeciones. Ahora
la densidad de compuertas es lo suficientemente alta como para un procesador simple pueda
ser construido en un nico FPGA. Adems el tiempo de reconfiguracin (reprogramacin) de
los FPGAs ha bajado a un nivel en el que es razonable incluso reconfigurar el FPGA cuando
pasamos de una fase de un algoritmo a otra.
Normalmente debemos trabajar con lenguajes de descripcin de hardware como VHDL
para la reconfiguracin del FPGA, as como escribir cdigo de bajo nivel que haga de interfaz
con los programas del sistema host Linux. Pero el esfuerzo merece la pena, ya que el coste de
los FPGAs es bajo, especialmente para algoritmos que operen con enteros de baja precisin
(en realidad un subconjunto de aquellas operaciones para las que fu diseado SWAR). Los
FPGAs pueden realizar complejas operaciones tan rpido como podamos introducir los datos.
Por ejemplo, sistemas basados en un nico FPGA han alcanzado tiempos mejores que los
supercomputadores en la bsqueda de bases de datos genticas.
Las siguientes dos compaas desarrollan hardware basado en FPGA:
Virtual Computer Company Esta compaa ofrece una variedad de productos que usan FP-
GAs Xilinx dinmicamente reconfigurables basados en SDRAM. Destaca su tarjeta
Virtual ISA Proto Board de 8/16 bit para el puerto ISA.
Altera El ARC-PCI (Altera Reconfigurable Computer PCI bus, Computador Reconfig-

urable Altera para bus PCI) es una tarjeta del mismo tipo que la Virtual ISA Proto
Board de Virtual Computer Company, pero utiliza FPGAs Altera y el interfaz PCI en
vez del ISA.
Muchas de las herramientas de diseo, lenguajes de descripcin de hardware, compiladores,

etc. funcionan slo bajo Windows o DOS, por lo que podramos utilizar dosemu o wine para
ejecutarlos bajo Linux.
1.5. ARQUITECTURAS BASADAS EN PARALELISMO EXPLCITO 19
CPU CPU CPU
E/S
E/S
Interconexin
E/S
Memoria Principal
Figura 1.8: Esquema Multiprocesador
1.5. Arquitecturas Basadas en Paralelismo Explcito

1.5.1. Multiprocesadores
Un sistema multiprocesador es aquel que est formado por un conjunto de procesadores
que comparten una memoria principal comn y estn bajo el control de un mismo sistema
operativo. Las principales caractersticas de un procesador de este estilo son:
1. Posee dos o ms procesadores de propsito general similares y de capacidades compa-

rables.
2. Todos los procesadores comparten el acceso a una memoria global (comn). Tambin
pueden utilizarse memorias locales (privadas).
3. Todos los procesadores comparten el acceso a los dispositivos de E/S, bien a travs de
los mismos canales o bien a travs de canales distintos que proporcionan caminos de
acceso a los mismos dispositivos.
4. El sistema est controlado por un sistema operativo integrado que permite la interaccin
entre los procesadores y los programas.
La figura 1.8 describe en trminos generales la organizacin de un sistema multiproce-

sador. Hay dos o ms CPUs. Cada CPU es autnoma, incluyendo una unidad de control, una
CPU CPU E/S E/S Memoria Memoria
Bus del Sistema
Figura 1.9: Organizacin Bsica Bus de Tiempo Compartido
ALU, registros y posiblemente una cach. Cada CPU tiene acceso a una memoria principal
compartida y a los dispositivos de E/S a travs de algn mecanismo de interconexin. Los
procesadores pueden comunicarse entre s a travs de la memoria (mensajes de informacin
de control almacenada en reas comunes de datos). Tambin es posible que las CPUs inter-
cambien seales directamente, como indican las lneas discontinuas. La memoria a menudo
se organiza de forma que sean posibles los accesos simultneos a bloques de memoria separa-
dos. En algunas configuraciones cada CPU puede tener tambin su propia memoria principal
privada y sus canales de E/S adems de los recursos compartidos.
1.5.1.1. Organizacin
La organizacin de un sistema multiprocesador puede clasificarse como sigue:
Bus de Tiempo Compartido o Comn
Memoria Multipuerto
Unidad de Control Central
Bus de Tiempo Compartido
El Bus de Tiempo Compartido es el mecanismo ms simple para construir un sistema mul-

tiprocesador (figura 1.9). La estructura y las interfaces son bsicamente las mismas que las de
un sistema monoprocesador que utilice un bus para la interconexin. El bus consta de lneas
de control, direccin y datos. Para facilitar las transferencias DMA (Direct Memory Access,
Acceso Directo a Memoria) con los procesadores de E/S se proporcionan los siguientes ele-
mentos:
Direccionamiento: Debe ser posible distinguir los mdulos del bus para determinar la
fuente y el destino del mensaje.
Arbitraje: Cualquier mdulo de E/S puede funcionar temporalmente como maestro. Se

proporciona un mecanismo para arbitrar entre las peticiones que compiten por el control
del bus, utilizando algn tipo de esquema de prioridad.
CPU CPU E/S E/S Memoria Memoria

Cach Cach
Bus del Sistema
Figura 1.10: Organizacin Bus de Tiempo Compartido con Cach
Tiempo Compartido: Cuando un mdulo est controlando el bus, los dems mdulos no
tienen acceso al mismo y deben, si es necesario, suspender su funcionamiento hasta que
dispongan del bus.
Estos elementos son utilizables directamente en una configuracin de multiprocesador. En este

caso hay varias CPUs adems de varios procesadores de E/S que intentan acceder a uno o ms
mdulos de memoria a travs del bus.
La organizacin de Bus de Tiempo Compartido presenta diversas ventajas en comparacin
con otras aproximaciones:
Simplicidad: Es la aproximacin ms sencilla para organizar el multiprocesador. La

interfaz fsica y la lgica de cada procesador para el direccionamiento, el arbitraje, y para
compartir el tiempo del bus es la misma que la de un sistema con un solo procesador.
Flexibilidad: Es generalmente sencillo expandir el sistema conectando ms CPUs al bus.
Fiabilidad: El bus es esencialmente un medio pasivo, y el fallo de cualquiera de los

dispositivos conectados no provocara el fallo de todo el sistema.
La principal desventaja de la organizacin de bus compartido son las prestaciones. Todas las
referencias a memoria pasan por el bus. En consecuencia, la velocidad del sistema est limitada
por el tiempo de ciclo. Para mejorar las prestaciones es deseable equipar a cada CPU con una
memoria cach (figura 1.10). sta reducira considerablemente el nmero de accesos.
El uso de cachs introduce algunas consideraciones de diseo nuevas. Puesto que cada
cach local contiene una imagen de una parte de la memoria, si se altera una palabra en una
cach es posible que quede invalidada una palabra en otra cach. Para evitarlo debe avisarse a
las otras CPUs de que se ha producido una actualizacin de la memoria. Esto por lo general
complica el diseo del sistema.
Memorias Multipuerto
La organizacin de memorias multipuerto permite el acceso directo e independiente a
los mdulos de memoria desde cada una de las CPUs y los mdulos de E/S (figura 1.11).
Se necesitar un sistema de arbitraje para resolver los conflictos. El mtodo que se utiliza a
menudo para ello consiste en asignar prioridades fijas a cada puerto de memoria. Normalmente
M1 M2 Mk
CPU1
E/S 1
CPUn
E/S m
Figura 1.11: Organizacin Memorias Multipuerto
la interfaz fsica y elctrica en cada puerto es idntica a la que aparece en un mdulo de

memoria de un slo puerto. As, se necesitan pocas o ninguna modificacin en las CPUs o en
los mdulos de E/S para adaptarlas a este modelo de organizacin.
La organizacin de memorias multipuerto es ms compleja que la organizacin de bus
compartido, precisndose aadir al sistema una buena cantidad de lgica. No obstante se con-
siguen mejores prestaciones puesto que cada procesador tiene un camino especfico a cada m-
dulo de memoria. Otra ventaja del multipuerto es que permite configurar partes de la memoria
como privadas para una o ms CPUs y/o mdulos de E/S. Estas caractersticas permiten
incrementar la seguridad frente a accesos no autorizados y para el almacenamiento de ruti-
nas de restablecimiento en zonas de memoria no susceptibles de ser modificadas por otros
procesadores.
Unidad de Control Central
La unidad de control central encauza las distintas secuencias de datos entre los distintos
mdulos independientes: CPU, memoria, E/S. El controlador puede almacenar temporalmente
peticiones y realizar las funciones de arbitraje y temporizacin. Adems puede transmitir men-
sajes de estado y control entre las CPUs y alertar sobre cambios en las cachs.
Puesto que toda la lgica de coordinacin de la configuracin de multiprocesador se con-
centra en la unidad de control central, las interfaces de E/S, memoria, y CPU no sufren cambios
esenciales. Esto proporciona la flexibilidad y simplicidad de conexin propias de la aproxi-
macin del bus compartido. Las desventajas clave de esta aproximacin son que la unidad de
control es bastante compleja y que representa un cuello de botella potencial para las presta-
ciones.
1.5.1.2. Multiprocesadores Simtricos (SMP)
SMP (Symmetric Multi-Processor, Multiprocesadores Simtricos) se refiere, en trmi-

nos de sistemas operativos, al concepto de grupo de procesadores trabajando juntos como
pares, de manera que cualquier parte del trabajo puede ser realizada por cualquiera de los
procesadores sin diferencia alguna. Este tipo de sistemas son multiprocesadores, es decir,
pertenecen al modelo MIMD con memoria compartida. En el mundo IA32, SMP significa
cumplir con la norma MPS (Intel MultiProcessor Specification, Especificacin Multiproce-
sador de Intel).
En un SMP todos los procesadores pueden acceder a la misma memoria, generalmente
mediante un bus compartido de alta velocidad. La comunicacin entre los procesadores es
fcil en principio. Cualquier procesador puede dejar datos o mensajes en una posicin deter-
minada y luego indicar a otro procesador la direccin en la que puede encontrar los datos.
Esto es tpico del multiprocesamiento; as, un computador ejecuta una o ms aplicaciones que
se componen de una serie de procesos secuenciales que cooperan entre s. Este esquema se
puede implementar en un sistema monoprocesador, pero tambin se puede implementar fcil-
mente en un sistema multiprocesador SMP: en cualquier momento cada uno de los mltiples
procesadores est ejecutando un proceso distinto. La comunicacin entre procesos se realiza
mediante mensajes y seales de estado que pueden intercambiarse los procesadores a travs
de la memoria.
En la prctica el nivel de prestaciones deseado complica la comunicacin entre los proce-
sadores. Cuando se tienen muchos procesadores rpidos compitiendo por acceder a la misma
memoria a travs del mismo bus, los conflictos pueden degradar seriamente el rendimiento
del conjunto del sistema. La solucin, como hemos visto, es aadir una cach local a cada
procesador. Esta solucin ocasiona el problema adicional de la coherencia de cach. La coor-
dinacin entre los procesadores que se requiere para resolver el problema origina un cuello de
botella en el bus compartido. El resultado es que los multiprocesadores tpicos estn limitados
a unas pocas decenas de procesadores. Un multiprocesador SMP con miles de procesadores
no parece que sea muy prctico.
1.5.1.3. Soporte SMP Bajo Linux
Antes de entrar a discutir aspectos ms tcnicos, debemos hacernos primero un par de cues-
tiones acerca de esta arquitectura que, si bien es una de las ms extendidas en procesamiento
paralelo, tiene un soporte relativamente reciente en Linux.
Funciona realmente SMP en Linux? Funciona. Adems es una opcin con una buena
relacin coste/rendimiento para paralelizar nuestro sistema, ya que una placa base con soporte
para varios procesadores y sus correspondientes micros normalmente elevar poco el precio
del sistema con respecto a un sistema uniprocesador.
En la mayora de las ocasiones para hacer que Linux se ejecute en dicho hardware slo
necesitamos realizar una instalacin de Linux con soporte para un solo procesador, y luego
recompilar el ncleo con la fila SMP=1 del fichero Makefile activa. Entonces informaremos
a lilo o nuestro gestor de arranque acerca del nuevo ncleo compilado, y a disfrutar. En cuanto
a rendimiento y estabilidad podemos decir son sistemas bastante firmes. En resumen, SMP
Linux realmente funciona.
La siguiente cuestin es cunto soporte de alto nivel est disponible para escribir y ejecutar
programas paralelos con memoria compartida en SMP Linux. Actualmente existe bastante
software dedicado a este propsito. Por ejemplo, ahora podemos contar con una librera muy
completa para el manejo de hilos POSIX.
Aunque el rendimiento puede ser menor que utilizando mecanismos especialmente creados
para trabajar con memoria compartida, un sistema SMP Linux tambin puede usar la mayora
del software de procesamiento paralelo desarrollado originalmente para clusters de estaciones
de trabajo. Dicho tipo de software utiliza comunicacin va sockets, y puede funcionar en un
sistema SMP Linux e incluso en mltiples SMP conectados en red formando un cluster. De
todas formas la comunicacin va sockets implica mucha sobrecarga innecesaria en un sistema
SMP. Gran parte de esta sobrecarga se produce dentro del ncleo y en el manejo de interrup-
ciones; sto empeora el problema ya que SMP Linux generalmente slo admite un procesador
en el ncleo al mismo tiempo y el manejador de interrupciones est implementado de manera
que slo el procesador de arranque (boot processor) puede procesar interrupciones. A pesar
de ello el hardware de comunicacin de un SMP tpico es tan superior a la mayora de las
redes de comunicacin de los clusters, que el software diseado para dichos clusters a menudo
funcionar mejor en los sistemas SMP que en los clusters para los que fu creado.
En el resto de esta seccin estudiaremos qu tipo de sistemas SMP soporta Linux,
aclararemos qu es la Especificacin Multiprocesador de Intel, y haremos algunas observa-
ciones acerca del uso de la memoria cach y la configuracin del bus a utilizar.
Especificacin Multiprocesador de Intel
Aunque los sistemas SMP han existido desde hace muchos aos, hasta hace poco cada
mquina tenda a implementar sus funciones bsicas de manera distinta al resto, de forma que
el soporte del sistema operativo no era portable. Lo que ha cambiado esta situacin es la MPS
(Intel MultiProcessor Specification, Especificacin Multiprocesador de Intel).
Los nicos sistemas que no cumplen la norma MPS ni la IA32 y tienen soporte bajo Linux
son las mquinas multiprocesador Sun4m de SPARC. Linux tiene soporte para la mayora de
las mquinas que cumplen la norma MPS 1.1 y MPS 1.4 con hasta 16 procesadores 486DX,
Pentium, Pentium Pro o superiores. Los procesadores IA32 que no tienen soporte son los
procesadores Intel 386, Intel 486SX/SLC (la falta de unidad de punto flotante interfiere en los
mecanismos SMP) y los procesadores AMD y Cyrix (requieren chips de soporte SMP que no
parecen estar disponibles por el momento).
Es importante entender que el rendimiento de los sistemas que cumplen la norma MPS
puede variar ampliamente. Como era previsto, una causa de las diferencias de rendimiento es
la velocidad del procesador: mayores frecuencias de reloj tienden a proporcionar sistemas ms
potentes, teniendo en cuenta que un procesador Pentium Pro es ms rpido que un Pentium. De
todas formas la norma MPS no especifica realmente cmo implementa el hardware la memoria
compartida; lo que s especifica es la manera en la que esta implementacin debe funcionar
desde el punto de vista del software. Esto significa que el rendimiento est tambin en funcin
de cmo interacta la implementacin de la memoria compartida con las caractersticas SMP
Linux y nuestro sistema particular.
La principal diferencia entre los sistemas que cumplen la norma MPS es la manera en la
que implementan fsicamente el acceso a la memoria compartida.
Aspectos sobre la Memoria Cach

Algunos sistemas MPS con procesadores Pentium y todos los que llevan procesadores
Pentium Pro y superiores tienen cachs L2 (Level 2, De Nivel 2) independientes (la memoria
cach L2 va dentro del mdulo que contiene el procesador). El hecho de tener cachs L2
separadas es considerado generalmente como una optimizacin del rendimiento; sin embargo
sto no es tan obvio bajo Linux. La principal complicacin est en que el planificador de SMP
Linux no intenta mantener cada proceso en el mismo procesador, siendo ste un concepto
denominado afinidad con el procesador. sto podra cambiar pronto; recientemente se han
generado discusiones sobre el tema en la comunidad SMP Linux bajo el ttulo Enlace con
el procesador. Sin afinidad con el procesador, el hecho de tener cachs L2 separadas podra
introducir una sobrecarga importante cuando le demos ciclos de reloj a un proceso en un
procesador distinto al que estaba ejecutando dicho proceso anteriormente.
Muchos sistemas relativamente econmicos estn organizados de manera que dos proce-
sadores Pentium comparten una memoria cach L2. Lo malo es que sto provoca competencia
entre los procesadores por el uso de la cach, degradando seriamente el rendimiento cuando
se ejecutan mltiples programas secuenciales independientes. Sin embargo la mayora de los
programas paralelos se benefician de la memoria cach compartida en situaciones en las que
ambos procesadores intentan acceder a la misma lnea de la memoria compartida; en dichas
situaciones slo uno de los procesadores debe acceder a la cach y la competencia entre los
procesadores es evitada. De este modo se crea el efecto bsqueda compartida. Adems la
falta de afinidad con el procesador provoca menos dao con una cach L2 compartida. As, en
programas paralelos no est realmente claro que la comparticin de cach L2 sea tan daina
como cabe esperar.
La experiencia demuestra que la cach de los sistemas SMP Linux muestran grandes difer-
encias en su rendimiento dependiendo del nivel de actividad del ncleo requerida. En el peor
de los casos el aumento es 1.2 veces la velocidad del procesador. De todas maneras tambin se
han observado picos de aumento de hasta 2.1 veces la velocidad del procesador, lo cual sugiere
que el cmputo intensivo de cdigo con el modelo SPMD saca provecho del efecto bsqueda
compartida.
Configuracin del Bus

Lo primero que hay que decir es que la mayora de los sistemas modernos conectan los
procesadores (en turnos) a uno o ms buses PCI que hacen de puente hacia uno o ms buses
ISA/EISA. Estos puentes aaden latencia, y adems los buses EISA e ISA ofrecen general-
mente una menor velocidad de transferencia de datos que los PCI (ISA es el de menor ve-
locidad), de manera que las unidades de disco, tarjetas de vdeo y otros componentes de alto
rendimiento deben ser conectados al bus PCI.
Aunque un sistema MPS puede alcanzar una buena velocidad en la ejecucin de muchos
programas paralelos de cmputo intensivo (incluso si slo hay un bus PCI de tiempo com-
partido), las operaciones de E/S no se ejecutan mejor que en los sistemas uniprocesador... de
hecho irn probablemente peor debido a la competencia por el bus entre los procesadores.
As, si lo que buscamos es mejorar el rendimiento de las operaciones E/S debemos emplear
un sistema MPS con mltiples buses PCI independientes y controladoras E/S (por ejemplo,
mltiples controladoras SCSI). Antes que nada necesitaremos estar seguros de que SMP Lin-
ux soporta el sistema que se desea emplear. Adems debemos tener en cuenta que actualmente
Linux permite slo un procesador en el ncleo al mismo tiempo, de manera que elegiremos
aquellas controladoras E/S que minimicen el tiempo requerido en el ncleo para realizar cada
operacin E/S. Para conseguir un alto nivel de rendimiento tendremos que considerar la posi-
bilidad de manejar la E/S de los dispositivos directamente, sin hacer llamadas al sistema... esto
no es tan difcil como parece, y tampoco debera comprometer la seguridad.
Es importante hacer notar que la relacin entre la velocidad del bus y la frecuencia de reloj
del procesador se ha vuelto ms difusa durante los ltimos aos. Actualmente no es extrao
encontrar sistemas con mayor frecuencia de reloj en el procesador y a la vez menor frecuencia
en el bus, en comparacin con otros sistemas. El ejemplo clsico de sto es el Pentium 133,
el cual usa generalmente un bus ms rpido que el Pentium 150, debido a la bsqueda de un
mayor rendimiento en varios bancos de prueba. Estos efectos se amplifican en los sistemas
SMP. De todos modos, en la mayora de los casos es ms importante tener un bus rpido.
1.5.2. Multicomputadores
Un sistema multicomputador es aquel que est formado por un conjunto de sistemas rel-
ativamente autnomos, en los que cada CPU dispone de su propia memoria principal y sus
canales de E/S.
En este tipo de sistemas, cada procesador tiene su propio espacio de memoria privado, que
no resulta visible para los otros procesadores. Segn sto los resultados y la informacin de
coordinacin debe pasarse entre los nodos a travs de una red de interconexin, usualmente en
forma de mensajes con un formato determinado.
Una de las motivaciones principales para el desarrollo de organizaciones de multicom-
putador es la de superar las limitaciones de escala de los multiprocesadores; de ste modo
los multicomputadores poseen una mayor escalabilidad. Se define como escalabilidad de un
sistema a su capacidad para responder a cargas de trabajo crecientes. En un sistema de proce-
samiento paralelo, se mide mediante el nmero de mquinas que pueden conectarse al sistema
sin que el rendimiento del sistema caiga. El objetivo es desarrollar una organizacin escalable
que pueda dar cabida a un amplio rango de nmero de procesadores.
Puesto que los procesadores en un multicomputador deben comunicarse mediante el in-
tercambio de mensajes, un elemento clave en el diseo es la red de interconexin, que debe
realizarse para operar lo ms eficientemente posible. En general existe un compromiso entre
la distancia mxima entre dos nodos y el nmero de conexiones fsicas que se desea en cada
nodo. Se han explorado varias tecnologas de interconexin para proporcionar escalabilidad y
hacer posible un comportamiento eficiente. A continuacin describiremos las topologas ms
extendidas:
Anillo: Si la comunicacin es bidireccional a lo largo del anillo, entonces la distancia

mxima entre dos nodos cualesquiera para un anillo de nodos es '$)( . Usualmente
se utilizan paquetes de mensajes de tamao fijo que contienen la direccin del destino
deseado. Esta topologa es apropiada para un nmero relativamente pequeo de proce-
sadores con una comunicacin de datos mnima. La figura 1.12 ilustra un anillo con
cuatro nodos.
Figura 1.12: Topologa Anillo
Figura 1.13: Topologa Malla
Malla: La forma ms simple de una malla es una matriz bidimensional en la que cada
nodo se conecta a cuatro vecinos. En una malla simple de +* nodos, la distancia
mxima entre dos nodos es (-,.0/2143 . Si hay conexiones cclicas utilizando los nodos
de los bordes, la distancia mxima se reduce a (-,.'$)(53 . La organizacin en malla es
adecuada para ejecutar algoritmos orientados a matrices. La figura 1.13 ilustra una malla
de 3*3 nodos.
rbol: Las redes con topologa de rbol se han investigado para ejecutar algoritmos de
tipo divide-y-vencers, tales como los de bsqueda y ordenacin. La figura 1.14 ilustra
Figura 1.14: Topologa rbol

Figura 1.15: Topologa Hipercubo
Nmero de nodos Malla Hipercubo

16 6 saltos 4 saltos
Cuadro 1.1: Dimetros Topologas Hipercubo y Malla
un rbol binario sencillo.
Hipercubos: Una topologa hipercubo utiliza 6

(87 procesadores distribuidos en un
hipercubo de dimensin . Cada enlace tiene enlaces bidireccionales a nodos adya-
centes. Tambin representa la distacia mxima entre dos nodos de dicho hipercubo. En
la figura 1.15 mostramos un hipercubo de dimensin 4, con 6
( 1:9 procesadores.
Desde la perspectiva de la implementacin hardware de una topologa, la topologa hiper-
cubo es la ms atractiva. En el cuadro 1.1 comparamos la comunicacin en el peor caso en
las topologas hipercubo y malla. El hipercubo se escala bien: el dimetro del sistema crece
lentamente con el nmero de nodos, en comparacin con la malla.
Recientemente ha surgido un inters creciente por pasar de topologas fijas a topologas
seleccionables por el usuario y controladas por una red de enrutamiento. En lugar de conectar
todos los procesadores juntos mediante enlaces directos, se conectan a una red de enrutamien-
to rpida que utiliza conmutadores para establecer e interrumpir las conexiones virtuales, de
una forma similar a la conmutacin de paquetes. Si los conmutadores se disean para que
ocasionen retardos mnimos en los mensajes, el retardo de comunicacin se incrementar lig-
eramente al aadir ms nodos al sistema. Otra propiedad atractiva es que cada procesador
necesita slo una conexin bidireccional a la red de conmutadores.
Los sistemas multicomputador pueden dividirse bsicamente en dos categoras:
Clusters (o agrupamientos de nodos). Estos sistemas son grupos de nodos que se comu-
nican a travs de una interfaz de red. Deben tener un buena relacin coste/rendimiento,
por lo que en principio slo debemos utilizar para su montaje componentes hardware
relativamente comunes.
MPPs (Massively Parallel Processors, Procesadores Masivamente Paralelos). Estos
sistemas pueden distinguirse de los anteriores por las propiedades que los hacen Masi-
vamente Paralelos:
; Utilizacin de interconexiones de muy alto rendimiento
; Capacidad de E/S inmensa
; Tolerancia a fallos
Seguramente quedemos sorprendidos al comprobar que estos sistemas no necesitan

CPUs de gama alta. La mayora de los mejores sistemas MPPs tienen miles de CPUs,
siendo ms importante para el rendimiento del sistema la calidad de las interconexiones
y su topologa.
1.5.2.1. Clusters o Agrupamientos de Nodos

Una de las posibilidades de mejor relacin coste/rendimiento es la proporcionada por los
clusters, grupos de nodos conectados a travs de una interfaz de red. Dicha organizacin crea
un sistema multicomputador, es decir, un sistema de procesamiento paralelo perteneciente al
modelo MIMD con memoria distribuida. Por supuesto su tipologa puede ser muy variada, as
como el soporte tanto hardware como software. Afortunadamente existe mucho y variado so-
porte software para el procesamiento paralelo usando PCs bajo Linux, gracias a la popularidad
de esta tecnologa.
La utilizacin de clusters en procesamiento paralelo supone muchas ventajas, como son:
Cada una de las mquinas de un cluster puede ser un sistema completo, que puede
ser utilizado para ejecutar una amplia gama de aplicaciones. sto lleva a pensar que el
procesamiento paralelo bajo clusters no es ms que una manera de aprovechar los ciclos
desperdiciados por los usuarios de PCs. Sin embargo no es tan sencillo aprovechar
estos ciclos sin ralentizar el trabajo primario para el que se utilizan dichas estaciones de
trabajo, pero puede hacerse.
La creciente popularidad de los sistemas en red hace que la mayora del hardware que
necesitamos para construir un cluster se fabrique a gran escala, con la correspondiente
bajada de precios como resultado. Tambin reduce el coste del sistema el hecho de que
slo necesitamos una consola (es decir, una tarjeta de vdeo, un monitor y un teclado)
para todo el cluster, aunque necesitemos conectar dicha consola a cada mquina al prin-
cipio para hacer una instalacin inicial; una vez hecha la instalacin, un PC bajo Linux
no necesita una consola para funcionar. En comparacin, los SMP y los Procesadores
Auxiliares pertenecen a mercados mucho ms restringidos, con lo que suelen tener pre-
cios ms elevados.
Figura 1.16: Objetivo Procesamiento Paralelo en Clusters
Los clusters pueden llegar a formar sistemas verdaderamente amplios, no teniendo las
limitaciones de escala de los SMP. Mientras que es complicado encontrar sistemas SMP
compatibles con Linux con ms de 4 procesadores, podemos construir un cluster de
hasta 16 sistemas con casi cualquier hardware de red comn. Con no mucho trabajo,
cientos e incluso miles de mquinas pueden ser interconectadas. De hecho, Internet
entero puede ser vista como un cluster verdaderamente gigantesco.
El hecho de que sustituir un computador estropeado en un cluster sea trivial compara-

do con arreglar un SMP parcialmente estropeado hace que la disponibilidad sea mucho
mayor en los clusters cuidadosamente diseados. sto es importante no slo en aplica-
ciones particulares que no toleren interrupciones en el servicio, si no que tambin en
sistemas de uso general que contengan suficientes procesadores como para que sean
muy comunes los fallos aislados. Por ejemplo, incluso cuando la media de fallo de un
PC sea de dos aos, en un cluster con 32 mquinas la probabilidad de que una falle en
los primeros 6 meses es muy alta.
La conclusin es que los clusters son econmicos, que los dispositivos necesarios para con-
struirlo estn disponibles, y que se pueden construir sistemas verdaderamente amplios; pero
por supuesto no todo son ventajas. Tambin existen una serie de problemas:
Excepto muy pocas excepciones, el hardware de red no est diseado para el proce-
samiento paralelo. Normalmente la latencia es muy alta y la velocidad de transferencia
de datos relativamente baja comparada con la proporcionada por los SMPs y los proce-
sadores auxiliares. Por ejemplo, la latencia casi nunca supera unos pocos microsegundos
en los SMPs, pero casi siempre es igual o mayor a cientos o miles de microsegun-
dos en un cluster. La velocidad de transferencia de datos en los SMP es mayor de 100
Mbytes/seg; aunque el hardware de red ms rpido (Gigabyte Ethernet) ofrece una ve-
locidad comparable, la mayora de las redes comunes son entre 10 y 1000 veces ms
lentas.
El rendimiento del hardware de red puede ser suficiente si es una red aislada para cluster.
Si la red no est aislada de otro trfico, el rendimiento puede ser sustancialmente peor.
Existe poco soporte de software para manejar un cluster como si se tratara de un slo
sistema. Por ejemplo, el comando ps nos informa de los procesos que concurren en un
sistema Linux, pero no nos informa de todos los procesos que concurren en el cluster de
sistemas Linux.
Con todo sto, podemos decir que los clusters ofrecen una gran potencia, pero dicha potencia
puede ser difcil de alcanzar en la mayora de las aplicaciones. Lo bueno es que existe una gran
cantidad de software que nos puede ayudar a conseguir un alto rendimiento en programas bien
adaptados a este entorno, y que existen redes diseadas especficamente para ampliar el rango
de programas que pueden alcanzar un buen rendimiento.
1.5.2.2. Sistemas Beowulf

Un sistema Beowulf es bsicamente un cluster dedicado al procesamiento paralelo. Es un
sistema que usualmente consta de un nodo servidor y uno o ms nodos clientes conectados
va Ethernet o algn otro tipo de red. Es un tipo de sistema que se construye empleando
hardware comn, como por ejemplo PCs bajo Linux, adaptadores Ethernet estndar y hubs
convencionales. No contiene ningn hardware especializado y es trivialmente reproducible.
Adems Beowulf usa software comn como Linux, PVM y MPI.
El nodo servidor controla todo el cluster y ofrece ficheros a los nodos clientes. Tambin
es la consola del cluster y su conexin al exterior. Los sistemas Beowulf ms grandes pueden
tener ms de un nodo servidor, y posiblemente otros nodos dedicados a tareas particulares, por
ejemplo consolas o estaciones de monitorizacin. En la mayora de los casos los nodos clientes
no tienen dispositivos directos de E/S; son controlados y configurados por el nodo servidor.
En una configuracin de clientes sin disco, los clientes no conocen su IP ni su nombre hasta
que el nodo servidor se lo enva. Una de las principales diferencias entre un Beowulf y un
COW(Cluster Of Workstations, Cluster de Estaciones de Trabajo) es que el comportamiento
de un Beowulf es ms parecido al de una nica mquina que al de un grupo de estaciones de
trabajo. En la mayora de los casos los clientes no tienen teclado ni monitor, y son accedidos
slo a travs de login remoto o posiblemente mediante un terminal serie. Podemos pensar en
los nodos de un sistema Beowulf como en paquetes CPU+Memoria que pueden ser agregados
al cluster, de la misma manera que una CPU o un mdulo de memoria puede ser agregado a
una placa base.
Beowulf no es un paquete especial de software, ni una nueva topologa de red, ni la ltima
modificacin del ncleo de Linux. Beowulf es una manera de crear clusters de PCs bajo Linux
para formar un supercomputador virtual paralelo. Existen muchos paquetes software como
modificaciones del ncleo de Linux, libreras PVM y MPI, y herramientas de configuracin
que hacen la arquitectura Beowulf ms rpida, fcil de configurar y til. Sin embargo podemos
construir una mquina de tipo Beowulf usando una distribucin estndar Linux sin software
adicional. Si tenemos dos ordenadores con Linux en red que comparten un sistema de ficheros
/home va NFS (Network File System, Sistema de Ficheros en Red) y podemos ejecutar
shell remoto (rsh) desde una mquina a otra, entonces podemos argumentar que tenemos un
sistema Beowulf simple de dos nodos.
Clasificacin Sistemas Beowulf

En la prctica los sistemas Beowulf han sido construidos de distintas maneras. Debido a
la bsqueda de un mayor rendimiento a veces han sido empleados componentes no comunes,
como por ejemplo aquellos que son comercializados por slo un fabricante. Para tener en
cuenta los diferentes tipos de sistemas existe la siguiente clasificacin.
BEOWULF CLASE I:
Este tipo de mquinas son construidas a base de componentes sacados del mercado comn.
La definicin estricta es que un Beowuf CLASE I debe se ensamblado a partir de componentes
que se puedan encontrar en al menos tres catlogos de publicidad nacionales o internacionales.
Las ventajas de los sistemas de CLASE I son:
El hardware est disponible en mltiples fuentes (bajo precio, fcil mantenimiento).
Ausencia de dependencia con respecto a un nico fabricante.
Soporte bajo Linux garantizado en sus distribuciones ms comunes.
Usualmente basado en estndares (SCSI, Ethernet, etc.).
Las desventajas de los sistemas de CLASE I son:
Mayor rendimiento puede requerir hardware de la CLASE II.
BEOWULF CLASE II:

Un Beowulf de CLASE II es simplemente cualquier mquina que no pueda ser ensamblada
utilizando nicamente hardware comn. sto no es un impedimento. De hecho sto es slo una
clasificacin.
Las ventajas de los sistemas de CLASE II son:
El rendimiento puede llegar a ser realmente alto
Las desventajas de los sistemas de CLASE II son:
El soporte bajo Linux puede variar de una distribucin a otra.
Existencia de dependencia con respecto a un nico fabricante.
Suelen ser sistemas ms caros que los de CLASE I.
Una clase no tiene porqu ser necesariamente mejor que la otra. Todo depende de nuestras
necesidades y nuestro presupuesto. sta clasificacin slo pretende que las discusiones sobre
los sistemas Beowulf sean coherentes y detalladas.
1.5.2.3. Hardware de Red
Las redes de ordenadores pertenecen a un campo en pleno auge. El desarrollo de las tec-
nologas y la aparicin de nuevos productos hacen que cada vez est ms al alcance de todos
generar procesamiento paralelo a travs de un cluster. Sin embargo no existe una tecnologa
de red que resuelva todos los problemas de la mejor manera; de hecho, la variedad de posibil-
idades, costes y rendimientos es tremenda.
A continuacin definiremos las caractersticas de algunos de los tipos de red ms popu-
lares:
ATM
Soporte bajo Linux: controladores del ncleo, librera AAL
Velocidad de Transferencia de Datos: 155 Mb/seg
Latencia: 120 <>=@?A
Disponibilidad: varios fabricantes
Interfaz: PCI
Estructura de Red: conexin mediante hub dedicado
Al menos en parte podra decirse que la tecnologa ATM (Asynchronous Transfer Mode,
Modo de Transferencia Asncrona) es el futuro. ATM no tiene un coste elevado y es ms rpida
que Fast Ethernet; adems puede ser usada a travs de las largas distancias que las compaas
de telfono pueden cubrir. El protocolo de red ATM est diseado para proporcionar una in-
terfaz software con poca sobrecarga y un manejo ms eficiente de los mensajes pequeos y de
las comunicaciones en tiempo real (p.ej. vdeo y audio digital). Adems es una de las redes
con mayor velocidad de transferencia de datos que Linux soporta actualmente. Lo malo es que
no es una tecnologa barata y que an existen algunos problemas de compatibilidad entre los
distintos fabricantes.
Ethernet
Soporte bajo Linux: controladores del ncleo
Disponibilidad: hardware comn
Interfaz: PCI
Estructura de Red: hub dedicado o compartido, o bus multipuerto sin hub

Durante algunos aos, la Ethernet de 10 Mb/seg ha sido la tecnologa estndar de red. De

hecho un gran nmero de PCs tienen su controladora Ethernet integrada en la placa base. En
redes con poca carga podemos organizar las conexiones Ethernet como un bus multipuerto
sin hub; esta configuracin puede servirnos para conectar hasta 200 ordenadores con un coste
mnimo, pero no es apropiado para procesamiento paralelo. Aadir un hub compartido no va a
mejorar el rendimiento en realidad. Sin embargo los hubs dedicados proporcionan la mxima
velocidad de transferencia de datos a conexiones simultneas y no tienen un alto coste por
ordenador. Linux soporta un amplio rango de interfaces Ethernet, pero es importante recordar
que las variaciones en el hardware de la interfaz pueden suponer importantes diferencias en el
rendimiento.
Fast Ethernet
Latencia: 80 <>=&?BA
Interfaz: PCI
Estructura de Red: hub dedicado o compartido
Aunque existen varias tecnologas que se llaman a s mismas Fast Ethernet este trmino se
usa principalmente para referirnos a las Ethernet de 100 Mb/seg basadas en hub que son com-
patibles con los dispositivos y cables utilizados para las Ethernet 10 BaseT de 10 Mb/seg.
Como podamos esperar esta tecnologa posee un enorme mercado, con lo cual su relacin
prestaciones/precio es bastante mejor que en otras configuraciones. Sin embargo la trampa
est en que al dividir el ancho de banda de un nico bus de 100 Mb/seg entre un grupo de
ordenadores mediante un hub compartido, el rendimiento puede quedar por debajo del que
obtendramos al utilizar una Ethernet de 10 Mb/seg con un hub dedicado, la cual proporciona
a cada ordenador una conexin completa de 10 Mb/seg. Los hubs dedicados que proporcionan
100 Mb/seg a cada computador simultneamente son caros, aunque sus precios bajan a diario y
proporcionan un rendimiento muy superior al que obtenemos utilizando los hubs compartidos.
Gigabit Ethernet
Interfaz: PCI
Estructura de Red: hub dedicado o FDRs

En principio Gigabit Ethernet no tiene buenas razones tecnolgicas para ser llamada Ethernet.
Sin embargo dicho nombre refleja la intencin de que en un futuro sea una tecnologa barata
y destinada a un amplio mercado, con soporte nativo para IP. Sin embargo su precio actual
hace que no resulte econmica su utilizacin. Al contrario que en otras tecnologas Ethernet,
Gigabit Ethernet ofrece un control a bajo nivel que aporta fiabilidad a dicho tipo de red. Los
FDRs (Full Duplex Repeaters, Repetidores Full Duplex) multiplexan las lneas utilizando
buffers y control de flujo localizado para mejorar el rendimiento. La mayora de los hubs
dedicados estn siendo construidos con nuevos mdulos interfaces para que sean compatibles
con los dispositivos Gigabit. Existe un driver bajo Linux para la interfaz Yellowfin G-NIC de
Packet Engines (URL [13]). Los primeros test bajo Linux arrojaron un ancho de banda unas
2,5 veces superior a la 100 Mb/seg Fast Ethernet; en las redes Gigabit la configuracin del bus
PCI es un factor crtico.
FireWire (IEEE 1394)

Soporte bajo Linux: no
Interfaz: PCI
Estructura de Red: aleatorio sin ciclos (configuracin automtica)
FireWire (URL [2]), el estndar IEEE 1394-1995, est destinado a ser la red digital de bajo
coste y alta velocidad para consumidores en general. Aunque suela promocionarse como la
interfaz a la cual conectar cmaras de vdeo digitales a nuestro ordenador, FireWire est pen-
sada para ser utilizada en aplicaciones que van desde ser el sustituto de SCSI hasta conectar
los componentes de reproduccin de vdeo y audio. Permite conectar hasta 64k dispositivos
utilizando cualquier topologa que haga uso de buses y puentes sin ciclos, y automticamente
detecta los componentes cuando son conectados o desconectados (conexin en caliente). So-
porta mensajes cortos con baja latencia as como trasmisiones asncronas al estilo ATM (usadas
para mantener sincronizados los mensajes multimedia). Adaptec tiene productos FireWire que
permiten la conexin de hasta 63 dispositivos a una tarjeta PCI. Aunque FireWire no ser la
red de mayor ancho de banda disponible dentro de un tiempo, el mercado de consumo (que
puede abaratar bastante los precios) y el soporte para mensajes con baja latencia hacen de sta
una de las mejores tecnologas para construir clusters de PCs bajo Linux utilizando redes de
paso de mensajes, al menos durante los prximos aos.
PLIP
Velocidad de Transferencia de Datos: 1,2 Mb/seg

Interfaz: SPP
Estructura de Red: cable entre dos ordenadores
Slo por el coste de un cable LapLink, PLIP (Parallel Line Interface Protocol, Protocolo de
Interfaz de Lnea Paralela) permite comunicar dos mquinas Linux a travs del puerto paralelo
estndar utilizando software basado en sockets. En trminos de velocidad de transferencia de
datos, latencia y escalabilidad, no es una tecnologa de redes seria; sin embargo, su bajsimo
coste y alta compatibilidad lo hacen til. El controlador forma parte de las distribuciones
estndar del ncleo de Linux.
SLIP
Velocidad de Transferencia de Datos: 0,1 Mb/seg
Interfaz: RS232C
Estructura de Red: cable entre dos ordenadores
Aunque SLIP (Serial Line Interface Protocol, Protocolo de Interfaz de Lnea Serie) est
situado al final del espectro de rendimiento, SLIP (o CSLIP o PPP) permite establecer comu-
nicacin mediante sockets entre dos ordenadores a travs del puerto serie RS232 ordinario.
Los puertos RS232 pueden ser conectados mediante un cable serie null-modem RS232 o
incluso a travs de un mdem. En cualquier caso la latencia es alta y la velocidad de transfer-
encia de datos baja, de manera que SLIP slo debe ser usado cuando no exista otra alternativa
disponible. Sin embargo es mejor que nada; adems la mayora de los PCs tienen dos puertos
RS232, de manera que podemos crear una red conectando un grupo de ordenadores de manera
linear o en topologa de anillo. Tambin existe un software de comparticin llamado EQL.
USB
Interfaz: USB
Estructura de Red: bus

UNIDAD DE
CONTROL
DISTRIBUIDOR DE LA RED
PE PE PE PE
PE PE PE PE
PE PE PE PE
ELEMENTOS PROCESADORES
Figura 1.17: Esquema Procesador Matricial
USB (Universal Serial Bus, Bus Serie Universal) (URL [20]) es un bus serie que propor-
ciona la velocidad de una interfaz ethernet convencional. Soporta conexin en caliente (pode-
mos enchufar cualquier dispositivo USB con el ordenador encendido) y puede manejar si-
multneamente hasta 127 perifricos que van desde teclados hasta cmaras de videoconferen-
cia.
En realidad no existe una especificacin clara sobre la metodologa a seguir para conectar
varios PCs mediante este puerto; sin embargo la importancia del estndar y su comodidad
hacen de esta interfaz una alternativa a tener en cuenta. Se puede decir que USB es la versin
barata y de bajo rendimiento de FireWire que podemos utilizar en casi cualquier PC.
1.5.3. Procesadores Matriciales

Esta arquitectura es representativa del modelo SIMD, es decir, una sola instruccin opera
simultneamente sobre mltiples datos. Un procesador matricial est formado por un conjun-
to de elementos procesadores (EPs) sincronizados que funcionan bajo la supervisin de una
unidad de control (UC).
Normalmente dicha UC es un procesador escalar que cuenta con su propia memoria para
almacenar programas y datos. Adems, cada EP tendr tambin su propia memoria. En la
figura 1.17 se muestra el esquema general de este tipo de arquitectura.
El funcionamiento de este sistema es el siguiente: la UC busca y decodifica las instruc-
ciones de la memoria central y, dependiendo del tipo de instruccin, son ejecutadas direc-
tamente en la unidad de control o bien son transmitidas a los EPs para su ejecucin. Las
instrucciones escalares y de control de flujo como saltos, etc. se ejecutan en la UC, mientras
que las instrucciones aritmtico-lgicas, las de enrutado de datos y otras operaciones locales
son transmitidas a los EPs y ejecutadas por stos sobre su memoria local. Respecto a los datos,
los EPs tienen sus propios canales de E/S.
De esta manera, la instruccin que ejecutan simultneamente los EPs es la misma, mientras
que los datos sern los de la memoria de cada EP, y por tanto sern diferentes. Por todo ello
un procesador slo requiere un nico programa para controlar todos los EPs.
La idea de utilizacin de los procesadores matriciales es la de explotar el parlalelismo en
los datos de un problema ms que la de paralelizar la secuencia de ejecucin de las instruc-
ciones. El problema se paraleliza dividiendo los datos en particiones sobre las que se pueden
realizar las mismas operaciones. Un tipo de datos altamente particionable es el formado por
vectores y matrices, siendo ste ltimo el tipo de datos hacia el cual estn ms orientadas este
tipo de arquitecturas. Por ello a estos procesadores se les llama matriciales.
Aparte del propio paralelismo obtenido por el clculo en paralelo sobre los elementos de
un vector o matriz, la propia red de interconexin entre los EPs reduce el tiempo de ejecucin
en determinadas tareas. Dicha red se encarga de conectar a los EPs con sus propios vecinos.
De esta manera la topologa de la red de interconexin determinar qu tipo de clculos sacan
el mximo partido a determinado procesador matricial. Por ejemplo, en el tratamiento de im-
genes, donde muchas operaciones son clculos entre pxels vecinos, una arquitectura matricial
con una topologa adecuada paralelizara con facilidad dichos clculos.
Un caso particular de los procesadores matriciales son los Procesadores Asociativos o As-
sociative Processors cuya principal caracterstica es la utilizacin de memorias asociativas.
La ejecucin de la misma operacin sobre distintas informaciones se usa en la simulacin
de condiciones climatolgicas, control de trfico areo, operaciones con matrices, etc. Ejem-
plos de computadores con esta organizacin son el ILLIAC IV, PEPE, BSP STARAN y ICL-
DAP.
1.5.4. Procesadores Vectoriales

En esencia los procesadores vectoriales son mquinas con unidades funcionales vectoriales
segmentadas (en definitiva ALUs segmentadas) diseadas para optimizar las operaciones con
estructuras de tipo vectorial. Este tipo de paralelismo es considerado MISD por la mayora de
los cientficos debido a la utilizacin de ALUs segmentadas. La segmentacin hace posible que
varias instrucciones pueden ser ejecutadas simultneamente sobre un mismo dato (el vector).
Al igual que en los procesadores matriciales el paralelismo viene de que al operar con
vectores o matrices normalmente sus elementos son independientes entre s, es decir, en gen-
eral no existen dependencias entre los datos dentro de los propios vectores o matrices. Esto
permite que muchas de las operaciones aplicadas a un determinado vector y todas las que se
hacen entre elementos de unos vectores con otros puedan realizarse en paralelo, o al menos en
distintas etapas del mismo cauce de instrucciones sin que haya un conflicto entre los datos.
Un computador vectorial estar formado normalmente por un procesador escalar y un
procesador vectorial diseado especficamente para operar con vectores. Dicho procesador
vectorial contendr a su vez varias ALUs, cada una de las cuales opera sobre un vector com-
pleto. Adems dichas ALUs se encuentran completamente segmentadas y pueden comenzar
una nueva operacin cada ciclo de reloj. De esta manera el paralelismo proviene de la repeti-
cin de ALUs y de su segmentacin. Sin embargo es la segmentacin la que hace que varias
instrucciones puedan ser ejecutadas al mismo tiempo sobre un determinado vector.
Dependiendo del tipo de procesador vectorial cada ALU ser totalmente funcional o bien
se encargar de realizar una funcin especfica, como suma/resta, multiplicacin, divisin, etc.
Adems debe existir una unidad de Carga/Almacenamiento encargada de leer los vectores
desde la memoria y almacenarlos en ella.
La diferencia entre este tipo de procesadores y los matriciales es que mientras los ma-
triciales son comandados por las instrucciones, los vectoriales son comandados por flujos de
datos continuos. As mientras en los procesadores matriciales slo existe un flujo de instruc-
ciones entre la unidad de control y los elementos procesadores, en los computadores vectori-
ales tenemos dos flujos separados: el de instrucciones y el de datos. En este caso, el procesador
escalar enva un flujo de datos continuo hacia el procesador vectorial, indicndole la operacin
que debe realizar mediante el flujo de instrucciones. En la figura 1.18 mostramos el diseo tpi-
co de un procesador vectorial con registros.
40
Procesador escalar
Cauces funcionales
escalares
Instrucciones escalares Procesador vectorial
Unidad de control Instrucciones vectoriales Unidad de control

escalar vectorial
Control
Instrucciones
Memoria principal Cauce func. vectorial

(Programa y datos)
Datos Datos
escalares vectoriales
Registros
CAPTULO 1. INTRODUCCIN
Almacenamiento Computador vectoriales
masivo anfitrin
E/S Usuario Cauce func. vectorial
Figura 1.18: Esquema Procesador Vectorial

Figura 1.19: Cray SX-6
Los procesadores vectoriales, segn el mtodo de almacenamiento de los operandos, se

clasifican en:
Mquinas vectoriales con registros :

En una mquina de este tipo todas las operaciones vectoriales excepto las de carga y al-
macenamiento operan con vectores almacenados en registros. La mayora de mquinas
vectoriales modernas utilizan este tipo de arquitectura. Ejemplos: Cray Research (CRAY-
1, CRAY-2, X-MP, Y-MP y C90), supercomputadores japoneses (NEC SX Series, las
Fujitsu VP200 y VP400 y la Hitachi S820).
Mquinas vectoriales memoria-memoria :

En este tipo de mquinas, todas las operaciones vectoriales son de memoria a memoria.
Como la complejidad interna as como el coste son menores, es la primera arquitectura
vectorial que se emple. Ejemplo: el CDC.
Los supercomputadores vectoriales empezaron con modelos monoprocesadores como el

Cray 1 en 1976. Los supercomputadores vectoriales recientes ofrecen ambos modelos, el
monoprocesador y el multiprocesador. La mayora de supercomputadores de altas prestaciones
modernos ofrecen multiprocesadores con hardware vectorial como una caracterstica ms de
los equipos. En el cuadro 1.2 vemos algunos ejemplos de procesadores vectoriales con sus
caractersticas principales.
Computadora Ao Ciclo Reloj Ciclo Reloj mx Pico CPU Pico Total

(ns) (Mhz) CPUs (Mflop/s) (Mflop/s)
Hitachi S820 1983 4.0 71 1 2000 2000
Cray 2 1985 4.1 166 4 488 1952
Cray Y-MP 1988 6.0 166 8 333 2667
NEC SX-3 1989 2.9 400 4 5500 22000
Cray C90 1991 4.0 240 16 1000 16000
Cray 3 1995 2.0 500 16 2000 32000
Cuadro 1.2: Ejemplos Computadores Vectoriales

Captulo 2
Herramientas para el Desarrollo de

Software Paralelo
Una vez resuelto el sistema de intercomunicacin fsica de los equipos, deben abordarse
los mecanismos para lograr la coordinacin entre los procesadores.
Bsicamente existen dos modelos de interaccin entre procesadores: paso de mensajes y
memoria compartida. Dichos modelos se pueden utilizar de varias formas. Como en todas las
reas de la programacin, existen varios mtodos para alcanzar el objetivo:
Por un lado podemos implementar dichos modelos a bajo nivel, utilizando cdigo mquina,
ensamblador o compiladores de lenguajes no especializados. Dicha alternativa nos per-
mite desarrollar un cdigo ms adaptado y optimizado para el hardware que vayamos a
usar.
Por otro lado podemos emplear utilidades de desarrollo de software paralelo, que son
bsicamente facilidades para la programacin a alto nivel de aplicaciones distribuidas
(compiladores, libreras, etc.) y herramientas para su ejecucin y monitorizacin. Dichas
utilidades de programacin permiten al programador generar de manera automtica co-
municacin mediante paso de mensajes y memoria compartida sin que deba preocuparse
de los detalles. Las ventajas de emplear dichas utilidades son su facilidad de manejo y
la portabilidad de los algoritmos desarrollados.
A continuacin estudiaremos las caractersticas bsicas de los dos modelos de interaccin

antes mencionados, para luego centrarnos en las utilidades de desarrollo ms populares que
existen en la actualidad.
2.1. Modelos de Interaccin entre Procesadores

2.1.1. Paso de Mensajes
El paso de mensajes es un modelo de interaccin entre los procesadores que forman un
sistema paralelo. A grandes rasgos un mensaje es un conjunto de datos definido mediante soft-
ware por un procesador y enviado a travs de una red de comunicaciones hacia otro procesador,
el cual debe aceptar el mensaje y actuar segn su contenido.
43
44 CAPTULO 2. HERRAMIENTAS DESARROLLO SOFTWARE PARALELO
MEMORIA MEMORIA MEMORIA MEMORIA MEMORIA

CPU CPU CPU CPU CPU
Figura 2.1: Modelo Bsico para Paso de Mensajes
Todas las unidades de proceso pueden ser origen o destino de mensajes en cualquier mo-
mento y todas pueden intercambiar datos entre s. El enrutamiento de mensajes se le deja al
sistema operativo y el nmero de saltos o puntos de intercomunicacin por los que el mensaje
debe pasar dependern de la topologa de la mquina en uso. Este sistema puede utilizarse al-
canzando un rendimiento ptimo en multicomputadores y en multiprocesadores con memoria
distribuida.
Aunque la sobrecarga en la comunicacin (latencia) en cada paso de mensaje puede ser
alta normalmente hay pocas restricciones sobre la cantidad de informacin que pueden con-
tener dichos mensajes. De este modo si contamos con un ancho de banda amplio el paso de
mensajes puede ser un mtodo muy efectivo para transmitir grandes bloques de datos de entre
los procesadores.
Sin embargo para minimizar la necesidad de costosas operaciones de paso de mensajes los
datos deben estar distribuidos entre los procesadores, de modo que el conjunto de datos refer-
enciados por cada procesador est en su memoria local. A sto se le conoce como distribucin
de datos (data layout).
Una gran ventaja del paso de mensajes reside en su elevada portabilidad, puesto que por
lo general consiste en el protocolo de comunicaciones estndar de la red ms las rutinas de
sincronizacin y comunicacin de procesos, que se ejecutan sobre dicho protocolo. Adems
dicho modelo puede usarse en una red de computadores heterognea.
2.1.1.1. Comunicacin mediante Sockets
En un sistema multitarea como Linux los sockets son la base para la comunicacin me-
diante paso de mensajes. Un socket es un punto de comunicacin que se comunica con otro
socket para enviarle mensajes. Son bidireccionales, los hay de varios tipos y nos permiten
comunicarnos con un proceso que est en otro ordenador o en el mismo.
Cuando queremos recibir datos por un socket creamos uno y escuchamos por l hasta
que nos lleguen datos. En caso de querer enviar datos lo que hacemos es crear un socket,
cumplimentar los datos de la direccin de destino y enviar los datos al otro socket a travs del
nuestro. Por consiguiente para que dos procesos se comuniquen mediante sockets cada uno
debe crear el suyo.
Para transmitir datos entre nodos bajo Linux usaremos normalmente la familia de sock-
ets AF_INET. Este tipo de sockets se usan principalmente en redes IP, como por ejemplo la
extensa Internet. En estas redes los ordenadores se identifican mediante una direccin IP que
es propia de cada nodo, o sea, no existen dos nodos con la misma direccin IP en una misma
red. De esta manera los sockets pueden ser identificados unvocamente en toda la red. Ello es
2.1. MODELOS DE INTERACCIN ENTRE PROCESADORES 45
importante ya que, conociendo todos los datos necesarios, podemos ponernos en contacto con
cualquier punto de comunicacin de cualquier nodo de nuestra red.
Los datos que identifican unvocamente a estos puntos de transmisin son:
La direccin IP del nodo en donde reside el proceso que est usando ese punto de conex-
in.
El nmero del puerto. El puerto es un nmero entero sin signo de 16 bits cuyo propsito
es el de permitir que en un ordenador puedan existir 65536 puntos posibles de comu-
nicacin para cada tipo de socket AF_INET. Esto es suficiente para que no suponga un
lmite (en la prctica) para el nmero de puntos de comunicacin diferentes que puede
haber al mismo tiempo en un ordenador.
Y el tipo de socket, dato que no reside en la informacin de direccionamiento, ya que

es algo implcito al socket. Si usamos un socket de un tipo, ste slo se comunicar con
sockets del mismo tipo.
Para referirnos a un socket usaremos la direccin de socket. Las direcciones de socket son
diferentes segn la familia. Llevan todos un primer parmetro que identifica la familia de
socket y luego, segn sta, los datos correspondientes.
En el caso de la familia de sockets para redes IP estos datos son la direccin del ordenador
y el nmero de puerto. Los tipos de sockets de esta familia son dos, que se corresponden
con los dos tipos transmisin de datos en una red de paquetes, y son los que definiremos a
continuacin.
Datagramas (UDP)
Es el modelo ms sencillo y tambin el menos robusto. Consiste en enviar paquetes de
datos a un destino determinado. Cada paquete que enviamos ha de llevar la direccin de desti-
no y es guiado por la red de manera independiente. Estos paquetes con la direccin de destino
incluida se llaman datagramas. Los datagramas tienen una longitud limitada, por lo que los
datos que enviamos no pueden exceder de esa longitud. Adems hay ciertos problemas deriva-
dos del hecho de que los paquetes transiten por una red, que se agravan cuanto ms extensa
sea sta:
Prdida de paquetes. En el nivel de red y en los nodos de enrutamiento se pueden perder

paquetes debido a congestin, problemas en la transmisin, etc.
Orden de los paquetes. En una red de rea extensa los paquetes atraviesan varios nodos
para llegar a su destino. En estos nodos los algoritmos de enrutamiento no suelen ser
estticos. De este modo para llegar al mismo destino un paquete puede seguir diferentes
rutas, debido a que en un momento dado un nodo puede decidir encaminar el paquete
por un sitio y luego por otro. Esto obedece sobre todo a causas derivadas del control de
la congestin (el congestionamiento de las lneas influye a la hora de determinar por cual
de ellas se enva el paquete) y de la robustez del sistema (si un nodo se cae se encaminan
los paquetes por otro sitio). La consecuencia es que dos paquetes que fueron enviados
pueden llegar desordenados por haber seguido distintas rutas.
Estos problemas no suceden si las transmisiones se realizan dentro de una red de rea local, ya
que no es necesario encaminar los paquetes. El protocolo de soporte sobre IP que sigue este
esquema se llama UDP (User Datagram Protocol, Protocolo de Datagramas de Usuario) y
por consiguiente hablaremos de UDP/IP.
Comunicaciones Orientadas a Conexin (TCP)
Consiste en realizar una conexin entre las dos partes. Tiene la desventaja de que se pierde
tiempo en establecer la conexin, pero despus la comunicacin es fiable, ordenada y utiliza
cabeceras ms pequeas.
El protocolo de soporte sobre IP que sigue este esquema se denomina TCP (Transfer Data
Protocol, Protocolo de Transferencia de Datos); hablaremos de flujos TCP/IP debido a que se
establece un canal por donde los datos fluyen de manera continua y ordenada.
El protocolo TCP es bastante ms complejo que UDP e implementa segmentacin, lo
cual nos permite pasar datos de gran longitud. Dichos datos sern segmentados en partes ms
pequeas, enviados conservando el orden y ensamblados en el destino.
2.1.2. Memoria Compartida

La memoria compartida es otro modelo de interaccin entre los procesadores que forman
un sistema paralelo. Muchos sistemas con MultiProcesadores Simtricos (SMP) comparten
fsicamente una sola memoria entre sus procesadores, de manera que un dato escrito por un
procesador en la memoria compartida puede ser accedido directamente por cualquier otro.
En los sistemas en los que cada procesador tiene su propia memoria, la memoria compartida
puede implementarse lgicamente convirtiendo cada referencia a memoria no local en una
comunicacin apropiada entre procesadores.
Fsicamente la memoria compartida puede tener una velocidad de transferencia de datos
amplia y una latencia baja, pero slo cuando los mltiples procesadores no intentan acceder al
bus simultneamente; as, la distribucin de datos influye seriamente en el rendimiento, la uti-
lizacin de la cach, etc. de manera que puede resultar complicado determinar qu distribucin
de datos es la mejor para un determinado sistema.
Normalmente la idea esencial de este modelo consiste en identificar las regiones paralela y
secuencial de un programa. La regin secuencial se ejecuta en un solo procesador y la paralela
en mltiples procesadores. La regin paralela consistir normalmente en mltiples hilos, cada
uno ejecutndose de forma concurrente como se ilustra en la figura 2.2. Los hilos son esencial-
mente procesos poco pesados que son planificados de distinta manera a los procesos UNIX
y, lo que es ms importante, tienen acceso compartido a un mismo mapa de memoria.
En muchos programas la identificacin de las regiones paralela y secuencial puede ser sen-
cillo, pero en otros es necesario indicar al compilador que realice la paralelizacin automtica,
lo cual hasta el momento es un mtodo poco refinado y requiere intervencin del programador
para la mejora final del cdigo. An as los sistemas de memoria compartida suelen ser ms
sencillos que los de paso de mensajes, y pueden desarrollarse ms rpidamente. En todo caso
el rendimiento depender del compilador que utilicemos.
Un compilador para memoria compartida deber generar cdigo para creacin de hilos,
sincronizacin y acceso a los datos en memoria compartida. En comparacin un compilador
2.1. MODELOS DE INTERACCIN ENTRE PROCESADORES 47
Hilo 1
Hilo 2
Hilo sencillo Hilo sencillo
Hilo 3
Hilo 4
Regin Regin Regin

secuencial paralela secuencial
Figura 2.2: Modelo Bsico para Memoria Compartida
para paso de mensajes es considerablemente ms simple, pues consistir slo en un compilador

base y las libreras para comunicaciones.
La sincronizacin es un concepto altamente importante en este tipo de sistemas. La com-
particin de recursos globales est llena de riesgos. Por ejemplo, si dos procesos hacen uso al
mismo tiempo de la misma variable global y ambos llevan a cabo tanto lecturas como escrit-
uras sobre la variable, el orden en el que se ejecuten las lecturas y escrituras es crtico.
As surge el concepto de exclusin mutua. Dos o ms procesos no pueden acceder a de-
terminados recursos al mismo tiempo. As, existen varias maneras de conseguir la exclusin
mutua. Por un lado podemos hacerlo a nivel hardware, a travs de instrucciones mquina es-
peciales o de inhabilitacin por interrupciones. Tambin a nivel de sistema operativo, con la
utilizacin de semforos u otros mecanismos. A nivel de compilador contamos con la ayuda
de los monitores. Como vemos existen varios mecanismos para conseguir la sincronizacin de
los procesos en este tipo de sistemas.
2.1.2.1. Todo Compartido Vs. Algo Compartido
Hay dos modelos fundamentales usados comnmente en programacin con memoria com-
partida: Todo Compartido y Algo Compartido. Ambos modelos permiten la comunicacin
entre procesadores mediante lecturas y escrituras de/en la memoria compartida; la diferencia
consiste en que el modelo Todo Compartido ubica todos los datos en memoria compartida,
mientras que el modelo Algo Compartido requiere que el usuario indique explcitamente qu
datos pueden ser compartidos y cules son privados para un nico procesador.
Qu modelo de datos debemos usar? Lgicamente debemos usar el modelo que mejor se
adapte a nuestras necesidades, aunque muchas veces sto es slo cuestin de gustos. Mucha
gente prefiere el modelo Todo Compartido porque no hay necesidad de identificar qu datos
deben ser compartidos en el momento de su declaracin... simplemente bloqueamos los acce-
sos potencialmente conflictivos a objetos compartidos para asegurarnos de que slo un proce-
sador tenga acceso en un momento dado. De nuevo, sto no es tan simple... por ello mucha
gente prefiere la relativa seguridad del modelo Algo Compartido.
Modelo Todo Compartido

Lo mejor de este modelo es que fcilmente podemos analizar un programa secuencial
existente y convertirlo incrementalmente en un programa paralelo bajo el modelo Todo Com-
partido. No hay necesidad de determinar qu datos deben ser accesibles por cada uno de los
procesadores.
En principio el principal problema de este modelo es que cualquier accin ejecutada por
un procesador podra afectar a otros procesadores. El problema sale a la luz de dos maneras:
Muchas libreras contienen estructuras de datos que simplemente no se pueden compar-

tir. Por ejemplo, una convencin UNIX es que la mayora de las funciones retornan su
cdigo de error en una variable llamada errno; si dos procesos bajo el modelo Todo
Compartido ejecutan varias llamadas, tendran conflictos entre ellas porque en realidad
comparten la misma variable errno. Aunque ahora existe una versin de la librera que
corrige sto, todava existen otros muchos problemas similares en la mayora de las li-
breras. Por ejemplo, a menos que sean tomadas precauciones especiales la librera X
no funcionar si las llamadas son hechas por mltiples procesos bajo el modelo Todo
Compartido.
Normalmente en cualquier otro modelo de programacin el peor caso para un programa

con un puntero defectuoso o un error de segmentacin es que el proceso que contiene el
cdigo errneo muera. Incluso en este caso el ncleo podra generar un fichero que nos
d una pista de lo sucedido. En procesamiento paralelo bajo el modelo Todo Compartido
es comn que los accesos perdidos provoquen el fallecimiento de un proceso distinto al
que contiene el error, haciendo casi imposible localizar y corregir el error.
Ninguno de estos dos tipos de problemas son usuales cuando se emplea el modelo Algo Com-
partido, debido a que slo los datos explcitamente marcados son compartidos. Adems resulta
obvio que el modelo Todo Compartido slo funciona si todos los procesos tienen exctamente
la misma imagen de la memoria; de este modo no es posible usar el modelo Todo Compartido
con diferentes imgenes del cdigo (slo se puede usar SPMD, no MIMD en general).
El soporte ms comn en programacin bajo el modelo Todo Compartido son las libreras
de hilos. Los hilos son esencialmente procesos poco pesados que podran no ser planificados
de la misma manera que los procesos UNIX y, lo que es ms importante, pueden tener acceso
compartido a un mismo mapa de memoria.
La primera librera que soport paralelismo en SMP Linux es la ahora algo obsoleta
bb_threads, una librera muy pequea que utiliza la llamada clone() para crear nuevos pro-
cesos planificados independientemente que comparten un mismo espacio de direcciones. Los
computadores SMP Linux pueden ejecutar mltiples hilos de este tipo en paralelo, ya que en
este caso cada hilo es en realidad un proceso Linux completo; la desventaja es que no obten-
emos la misma planificacin optimizada que realizan otras libreras de hilos.
Ms recientemente ha sido desarrollada una versin de la librera de hilos POSIX. Esta
librera, LinuxThreads, es claramente la librera preferida para ser usada bajo el modelo Todo
Compartido bajo SMP Linux. Dicha librera de hilos POSIX est bien documentada. Ahora
el principal problema es que la librera tiene muchos detalles por definir y acabar, de modo
que LinuxThreads est todava en proceso de desarrollo. Adems tenemos el problema de
2.2. UTILIDADES DE DESARROLLO 49
que la librera POSIX se ha visto involucrada en el proceso de estandarizacin, de manera que

tenemos que ser cuidadosos para no programar utilizando versiones obsoletas del estndar.
Modelo Algo Compartido

El modelo Algo Compartido en realidad significa compartir slo lo necesario. Este
planteamiento puede funcionar en MIMD de manera general (no slo en SPMD) teniendo
en cuenta que debemos ubicar los objetos compartidos en la misma posicin de memoria para
cada uno de los mapas de memoria de cada procesador. Y lo que es ms importante, el modelo
Algo Compartido hace ms fcil la prediccin y puesta a punto del rendimiento, el filtrado de
errores, etc. Los nicos problemas son:
Puede ser difcil saber de antemano qu necesita realmente ser compartido.
La verdadera posicin de los objetos en memoria compartida puede ser difcil de estable-
cer, especialmente para los objetos ubicados en una pila. Por ejemplo, puede ser nece-
sario ubicar explcitamente objetos compartidos en un segmento de memoria separado,
requiriendo de este modo rutinas de ubicacin en memoria separada e introduciendo
punteros indirectos extra en cada referencia.
Hoy da existen dos mecanismos muy parecidos para permitir a grupos de procesos de Lin-
ux tener espacios de memoria independientes, compartiendo slo un pequeo segmento de
memoria. Asumiendo que no hemos excluido el System V IPC en el momento de la con-
figuracin de nuestro sistema Linux, tendremos un mecanismo muy portable que ha venido
a denominarse System V Shared Memory. La otra alternativa es una utilidad de mapeo de
memoria cuya implementacin vara ampliamente entre distintos sistemas UNIX: la llamada
al sistema mmap().
2.2. Utilidades de Desarrollo

2.2.1. PVM
PVM (Parallel Virtual Machine, Mquina Virtual Paralela) es una librera de paso de
mensajes libre y portable, generalmente implementada por encima de los sockets. Est clara-
mente establecida como el estndar de paso de mensajes para el procesamiento paralelo en
clusters.
PVM puede ser utilizado en monoprocesadores, mquinas SMP, as como clusters conec-
tados por una red que soporte sockets (por ejemplo SLIP, PLIP, Ethernet, ATM, etc). De hecho,
PVM funciona incluso en grupos de mquinas con diferentes tipos de procesadores, configura-
ciones, o diferentes tipos de red (clusters heterogneos). Puede incluso tratar un grupo bastante
amplio de mquinas conectadas a Internet como una sla mquina paralela (una mquina vir-
tual paralela, de ah su nombre).
Lo mejor de todo, PVM es desde hace tiempo una distribucin libre (URL [14]), lo que
ha llevado a muchos lenguajes de programacin, libreras de aplicaciones, herramientas de
programacin y depuracin de errores, etc. a utilizar PVM como su librera portable de paso
de mensajes.
El modelo de funcionamiento de PVM es simple pero muy general, y se acomoda a una

amplia variedad de estructuras de programas de aplicacin. La interfaz de programacin es
muy sencilla, permitiendo que las estructuras de los programas sencillos sean implementadas
de manera intuitiva.
El usuario escribe su aplicacin como un conjunto de tareas que cooperan. Dichas tareas
acceden a los recursos de PVM a travs de una librera de funciones con una interfaz estndar.
Estas funciones permiten la inicializacin y finalizacin de las tareas a travs de la red, as co-
mo la comunicacin y la sincronizacin entre dichas tareas. Las operaciones de comunicacin
utilizan estructuras predefinidas, tanto las encargadas del envo y recepcin de datos como
aquellas ms complejas (sincronizacin en barrera, suma global, broadcast, etc.).
Debido a su portabilidad, su disponibilidad y su simple pero completa interfaz de pro-
gramacin, el sistema PVM ha ganado una amplia aceptacin en la comunicad de clculo
cientfico de alto rendimiento.
2.2.2. MPI
MPI (Message Passing Interface, Interfaz de Paso de Mensajes) es un estndar que define
la sintaxis y la semntica de las funciones contenidas en una librera de paso de mensajes,
diseada para ser usada en programas que exploten la existencia de mltiples procesadores.
Aunque la interfaz no cambie, puede implementarse tanto en sistemas que utilicen paso de
mensajes, como sistemas de memoria compartida.
La primera versin de MPI fu desarrollada en 1993-1994 por un grupo de investigadores
al servicio de la industria, el gobierno y el sector acadmico. Debido al apoyo recibido MPI es
relativamente el nuevo estndar para la programacin de procesadores paralelos basado en el
paso de mensajes, tomando el testigo de PVM.
Sin embargo existen frecuentes dudas y discusiones por parte de los usuarios acerca de cul
es el estndar a utilizar. As pues haremos un resumen de las diferencias ms caractersticas
entre los sistemas ms utilizados, PVM y MPI:
Entorno de Ejecucin:
Simplemente PVM tiene uno definido, mientras que MPI no especifica cmo debe ser
implementado. As el inicio de la ejecucin de un programa PVM ser realizado de
manera idntica en cualquier plataforma, mientras que para MPI depende de la imple-
mentacin que estemos utilizando.
Soporte para Clusters Heterogneos:

PVM fu desarrollado para aprovechar ciclos de CPU de estaciones de trabajo ociosas,
por lo que maneja de manera directa mezclas heterogneas de mquinas y sistemas op-
erativos. En contraste MPI asume que su principal objetivo son los MPPs y los clusters
dedicados de estaciones de trabajo casi idnticas. Sin embargo, dependiendo de la im-
plementacin que utilicemos, tendremos un soporte ms o menos adecuado.
Amplitud del Campo de Estudio:

PVM evidencia una unidad de propsito que MPI no tiene. Como veremos en el captulo
3 la especificacin MPI-1 centra su atencin en el modelo de paso de mensajes, al igual
que PVM. Sin embargo la especificacin MPI-2 incluye muchas caractersticas que van
MPI_Send() MPI_Recv()
MPI MPI
SO SO
Figura 2.3: Esquema Bsico Utilizacin MPI
ms all del modelo de paso de mensajes, como el acceso paralelo a ficheros de E/S o el
acceso a memoria remota, entre otros muchos ejemplos.
Diseo de Interfaz de Usuario:

MPI fu diseado despus de PVM, y claramente aprendi de l. MPI ofrece una interfaz
ms clara y eficiente, con manejo de buffers y abstracciones de alto nivel que permiten
definir las estructuras de datos a ser transmitidas por los mensajes.
Importancia del Estndar:

El hecho de que MPI sea respaldado por un estndar formal ampliamente apoyado sig-
nifica que el uso de MPI es, en muchas instituciones, cuestin de poltica.
MPI no est concebido para ser una infraestructura software aislada y autosuficiente para ser
usada en procesamiento distribuido. MPI no necesita planificacin de procesos, herramientas
de configuracin de la plataforma a usar, ni soporte para E/S. Como resultado MPI es imple-
mentado normalmente como interfaz de comunicaciones, utilizando las facilidades ofrecidas
por el sistema que vayamos a usar, tal como se indica en la figura 2.3 (comunicacin va sock-
ets, operaciones de memoria compartida, etc). ste escenario es ideal para que los programas
PVM sean portados a MPI, de manera que se aproveche el alto rendimiento de comunicacin
que ofrecen algunas compaas en sus arquitecturas.
Dado que ste es el estndar en el que nos basaremos para el desarrollo del presente doc-
umento, en el captulo 3 haremos una descripcin ms elaborada de sus caractersticas.
2.2.3. P4
El sistema p4 es una librera de macros y funciones desarrollada por el Argonne National
Laboratory 1 destinadas a la programacin de una gran variedad de mquinas paralelas. El
sistema p4 soporta tanto el modelo de memoria compartida (basado en monitores) como el
modelo de memoria distribuida (basado en paso de mensajes).
Para el modelo de memoria compartida, p4 proporciona un conjunto de monitores as
como funciones desarrolladas para crearlos y manipularlos; un monitor es un mecanismo de
sincronizacin de procesos en sistemas con memoria compartida. Para el modelo de memoria
distribuida, p4 proporciona operaciones de envo y recepcin, y un mtodo de administracin
1
Desarrollador de la implementacin MPICH, apndice A
de procesos basado en un fichero de configuracin que describe la estructura de los grupos y

procesos.
Dicho fichero especifica el nombre del servidor, el fichero que ser ejecutado en cada
mquina, el nmero de procesos que sern iniciados en cada servidor (principalmente para
sistemas multiprocesador) e informacin auxiliar. Un ejemplo de fichero de configuracin es:
# start one eslave on each of sun2 and sun3

local 0
sun2 1 /home/mylogin/pupgms/sr_test
sun3 1 /home/mylogin/pupgms/sr_test
Dos cosas son notables en lo que se refiere al mecanismo de administracin de los procesos
en p4. Primero, existe la nocin de procesos maestros y procesos esclavos, y pueden formarse
jerarquas multinivel para implementar el denominado modelo de cluster de procesamiento.
Segundo, el principal modo de creacin de procesos es esttico, a travs del fichero de con-
figuracin; la creacin dinmica de procesos es posible slo mediante procesos creados es-
tticamente que deben invocar una funcin p4 que expande un nuevo proceso en la mquina
local. A pesar de estas restricciones una gran variedad de paradigmas de aplicacin pueden ser
implementados en el sistema p4 de una manera bastante sencilla.
El paso de mensajes es conseguido en el sistema p4 a travs del uso de primitivas send
y receive tradicionales, con casi los mismos parmetros que los dems sistemas de paso de
mensajes. Algunas variantes han sido proporcionadas por cuestiones semnticas, como el in-
tercambio heterogneo y las transferencias bloqueantes o no bloqueantes. Sin embargo una
proporcin significativa de la administracin del buffer y su carga se le deja al usuario. Aparte
del paso de mensajes bsico, p4 ofrece tambin una variedad de operaciones globales incluyen-
do broadcast, mximo y mnimo globales, y sincronizacin por barrera.
2.2.4. Express
En contraste con lo que sucede con otros sistemas de procesamiento paralelo descritos
en esta seccin, Express es una coleccin de herramientas que individualmente dirigen varios
aspectos del procesamiento concurrente. Dicho paquete software es desarrollado y comercial-
izado por Parasoft Corporation, una compaa creada por algunos miembros del proyecto de
procesamiento concurrente de Caltech.
La filosofa de Express se basa en comenzar con la versin secuencial de un algoritmo
y aplicarle un ciclo de desarrollo recomendado, para as llegar a la versin paralela de dicho
algoritmo de manera ptima. Los ciclos de desarrollo tpicos comienzan con el uso de la her-
ramienta VTOOL, una aplicacin grfica que permite mostrar por pantalla el progreso de los
algoritmos secuenciales dinmicamente. Puede mostrar actualizaciones y referencias a estruc-
turas de datos individuales, con la intencin de demostrar la estructura de los algoritmos y
proporcionar la informacin necesaria para su paralelizacin.
En relacin con este programa tenemos la herramienta FTOOL, que proporciona un anli-
sis en profundidad de los programas. Dicho anlisis incluye informacin acerca del uso de
variables, la estructura de flujo de control, etc. FTOOL opera tanto en las versiones secuen-
ciales de los algoritmos como en las paralelas. Una tercera herramienta llamada ASPAR es
usada entonces; esta herramienta es un paralelizador automtico que convierte programas se-
cuenciales escritos en C o Fortran en sus versiones paralelas o distribuidas, usando los modelos
de programacin Express.
El ncleo del sistema Express es un conjunto de libreras de comunicacin, E/S y grficos
paralelos. Las primitivas de comunicacin son parecidas a las encontradas en otros sistemas de
paso de mensajes e incluyen una variedad de primitivas para realizar operaciones globales y de
distribucin de datos. Las funciones de E/S extendida permiten la E/S paralela. Un conjunto de
funciones similar es proporcionado para mostrar grficos de mltiples procesos concurrentes.
Express contiene adems la herramienta NDB, un depurador paralelo que utiliza comandos
basados en la popular interfaz dbx.
2.2.5. Linda
Linda es un modelo concurrente de programacin fruto de la evolucin de un proyecto de
investigacin de la Universidad de Yale. El concepto principal en Linda es el espacio de tuplas,
una abstracin a travs de la cual se comunican los procesos. Este tema central de Linda ha
sido propuesto como paradigma alternativo a los dos mtodos tradicionales de procesamiento
paralelo: el basado en memoria compartida, y el basado en paso de mensajes. El espacio de
tuplas es esencialmente una abstraccin de la memoria compartida/distribuida, con una difer-
encia importante: los espacios de tuplas son asociativos. Tambin existen otras distinciones
menores. Las aplicaciones utilizan el modelo Linda introduciendo en los programas secuen-
ciales estructuras que manipulan el espacio de tuplas.
Desde el punto de vista de las aplicaciones, Linda es un conjunto de extensiones para
lenguajes de programacin que facilitan la programacin paralela. Proporciona una abstrac-
cin de la memoria compartida que no requiere la existencia de hardware especfico que com-
parta memoria fsicamente.
El trmino Linda se refiere a menudo a implementaciones especficas software que sopor-
tan el modelo de programacin Linda. Este tipo de software establece y mantiene espacios de
tuplas, siendo utilizado en conjuncin con libreras que interpretan y ejecutan primitivas Lin-
da. Dependiendo del entorno (mutiprocesadores con memoria compartida, sistemas de paso
de mensajes, etc.) el macanismo de espacio de tuplas ser implementado utilizando diferentes
tcnicas con varios grados de eficiencia.
Recientemente ha sido propuesto un nuevo esquema relacionado con el proyecto Linda.
Este esquema, denominado Pirhana, propone un planteamiento revolucionario en el proce-
samiento concurrente: los recursos computacionales (vistos como agentes activos) eligen a los
procesos basndose en su disponibilidad y conveniencia. Este esquema puede ser implemen-
tado en mltiples plataformas y es conocido como Sistema Pirhana o Sistema Linda-Pirhana.
Parte II
Gua MPI
55
Captulo 3
El Estndar MPI
MPI (Message Passing Interface, Interfaz de Paso de Mensajes) es un estndar que de-
fine la sintaxis y la semntica de las funciones contenidas en una librera de paso de mensajes
diseada para ser usada en programas que exploten la existencia de mltiples procesadores.
Dicha librera puede ser utilizada por una amplia variedad de usuarios para implementar pro-
gramas que utilicen paso de mensajes.
Desde la finalizacin de su primera versin en Junio de 1994, MPI ha sido ampliamente
aceptado y usado. Existen implementaciones muy estables y eficientes, incluyendo algunas de
dominio pblico. Adems dichas implementaciones estn disponibles para un amplia variedad
de mquinas. Gracias a ello MPI ha alcanzado uno de sus principales objetivos: darle credibil-
idad al procesamiento paralelo. Ahora las companas y los investigadores tienen una manera
sencilla y segura para desarrollar programas paralelos portables de paso de mensajes.
3.1. Origen
El paso de mensajes es un paradigma de programacin ampliamente utilizado en computa-
dores paralelos, especialmente en aquellas con memoria distribuida. Aunque existen muchas
variantes, el concepto bsico de procesos comunicndose mediante mensajes est muy consol-
idado.
Durante los aos anteriores a la aparicin del estndar MPI se perciba un progreso sustan-
cial en proyectar aplicaciones importantes en este paradigma. De hecho, cada compaa haba
implementado ya su propia variante. Ms recientemente algunos sistemas de dominio pblico
haban demostrado que el paso de mensajes poda implementarse eficientemente de manera
portable.
Figura 3.1: Logo MPI
57
58 CAPTULO 3. EL ESTNDAR MPI
Por todo ello comprendemos que ste era el momento apropiado para definir tanto la sin-
taxis como la semntica de una librera estndar de funciones que fuera til a una amplia
variedad de usuarios y que pudiera implementarse eficientemente en una amplia gama de com-
putadores. Y de esa idea naci el estndar MPI.
Los diseadores de MPI pretendieron incorporar la mayora de las caractersticas ms
atractivas de los sistemas existentes de paso de mensajes, antes que seleccionar uno de ellos
y adoptarlo como el estndar. As, en su origen MPI estuvo muy influenciado por el trabajo
del Centro de Investigacin T.J.Watson de IBM, el sistema NX/2 de Intel, Express, Vertex de
nCUBE y PARMACS. Otras contribuciones importantes fueron las realizadas por Zipcode,
Chimp, PVM, Chameleon y PICL. Los diseadores de MPI identificaron algunos defectos
crticos de los sistemas de paso de mensajes existentes en reas como la composicin de datos
complejos, la modularidad y las comunicaciones seguras. sto permiti la introduccin de
nuevas caractersticas en MPI.
3.2. Historia
El esfuerzo de estandarizacin de MPI involucr a unas 60 personas procedentes de 40
organizaciones, principalmente de EEUU y Europa. La mayora de las principales compaas
de computadores paralelos del momento estuvieron involucradas en MPI, as como investi-
gadores provenientes de universidades, laboratorios de gobierno y la industria. El proceso de
estandarizacin comenz con el Seminario sobre Estndares de Paso de Mensajes en Entornos
de Memoria Distribuida, patrocinado por el Centro de Investigaciones sobre Procesamien-
to Paralelo, mantenido durante los das 29-30 de Abril de 1992 en Williansburg, Virginia
(EEUU). En este seminario se discutieron las caractersticas esenciales que deba tener una
interfaz estndar de paso de mensajes y se estableci un grupo de trabajo para continuar con
el proceso de estandarizacin.
Un borrador preliminar, conocido como MPI1, fu propuesto por Dongarra, Hempel, Hey
y Walker en Noviembre de 1992 y una versin revisada fu completada en Febrero de 1993.
MPI1 abarcaba las caractersticas principales que fueron identificadas en el seminario de
Williansburg como necesarias en un estndar de paso de mensajes. Dado que fu generado
para promover la discusin, este primer borrador se centr principalmente en las comuni-
caciones punto-a-punto. Aunque tocaba muchos asuntos referentes a la estandarizacin, no
inclua operaciones colectivas ni tena en cuenta la utilizacin de hilos.
En Noviembre de 1992 una reunin del grupo de trabajo de MPI tuvo lugar en Minneapo-
lis, en la cual se decidi hacer el proceso de estandarizacin de una manera ms formal, adop-
tando la organizacin y los procedimientos del High Performance Fortran Forum (Foro For-
tran de Alto Rendimiento). Fueron formados subcomits para cada una de las principales reas
que componen el estndar, y se estableci un foro de discusin va e-mail para cada una de
ellas. De esta manera qued conformado el Foro MPI (URL [8]), a cuyo cargo quedara el
proceso de estandarizacin de MPI.
En dicha reunin se propuso el objetivo de presentar un borrador del estndar MPI en
el otoo de 1993. Para conseguirlo el Foro MPI mantuvo reuniones cada 6 semanas durante
los primeros 9 meses de 1993, presentando el borrador del estndar MPI en la conferencia
Supercomputing 93 en Noviembre de 1993. Despus de un perodo de comentarios pblicos,
3.3. OBJETIVOS 59
que resultaron en algunos cambios en MPI, la versin 1.0 de MPI fu presentada en Junio de
1994.
A principios de Marzo de 1995 el Foro MPI empez a reunirse de nuevo para considerar
correcciones y extensiones al documento original del estndar MPI. El primer producto fruto
de estas deliberaciones fu la versin 1.1 de MPI, presentada en Junio de 1995.
En Julio de 1997 aparecen al mismo tiempo la versin 1.2 de MPI y la especificacin MPI-
2. La versin 1.2 de MPI contiene correcciones y clarificaciones referentes a la versin 1.1.
Sin embargo MPI-2 aade nuevos elementos al estndar MPI-1, definiendo la versin 2.0 de
MPI.
Todava hoy continan las discusiones acerca de las reas hacia las cuales podra ser til
expandir el estndar MPI; sin embargo en muchas de ellas es necesario obtener ms expe-
riencia y realizar ms discusiones. De todo ello se encarga un documento separado, el MPI
Journal Of Development (Peridico de Desarrollo), que no forma parte de la especificacin
MPI-2. Y por supuesto el Foro MPI sigue abierto a las aportaciones que puedan realizar los
usuarios del estndar, con el objetivo de mantenerlo y desarrollarlo.
3.3. Objetivos
La finalidad de MPI, de manera concisa, es desarrollar un estndar para escribir programas
de paso de mensajes que sea ampliamente utilizado. Para ello la interfaz debe establecer un
estndar prctico, portable, eficiente, escalable, formal y flexible.
Objetivos Principales
Portabilidad
El principal objetivo de MPI, como ocurre en la mayora de los estndares, es conseguir
un alto grado de portabilidad entre diferentes mquinas. Esta portabilidad sera parecida a
la que se consigue con lenguajes de programacin como Fortran. De esta manera el mismo
cdigo fuente de paso de mensajes debera poder ser ejecutado en una variedad de mquinas
tan grande como la soportada por las distintas implementaciones de MPI, aunque pueda ser
necesaria una puesta a punto para obtener la mxima ventaja de las caractersticas de cada
sistema. A pesar de que el paso de mensajes muchas veces es considerado algo propio de los
sistemas paralelos de memoria distribuida, el mismo cdigo podra ser ejecutado en un sistema
paralelo de memoria compartida. Puede ejecutarse en clusters o incluso en un conjunto de pro-
cesos ejecutndose en una misma mquina. El hecho de saber que existen implementaciones
de MPI eficientes para una amplia variedad de sistemas nos da cierto grado de flexibilidad en
el desarrollo del cdigo, la bsqueda de errores y la eleccin de la plataforma que finalmente
utilizaremos.
Heterogeneidad
Otro tipo de compatibilidad ofrecido por MPI es su capacidad para ejecutarse en sistemas
heterogneos de manera transparente. As pues, una implementacin MPI debe ser capaz de
extender una coleccin de procesos sobre un conjunto de sistemas con arquitecturas diferentes,
de manera que proporcione un modelo de computador virtual que oculte las diferencias en
las arquitecturas. De este modo el usuario no se tiene que preocupar de si el cdigo est
enviando mensajes entre procesadores de la misma o distinta arquitectura. La implementacin
MPI har automticamente cualquier conversin que sea necesaria y utilizar el protocolo
de comunicacin adecuado. Sin embargo MPI no prohibe implementaciones destinadas a un
nico y homogneo sistema, as como tampoco ordena que distintas implementaciones MPI
deban tener la capacidad de interoperar. En definitiva, los usuarios que quieran ejecutar sus
programas en sistemas heterogneos debern utilizar implementaciones MPI diseadas para
soportar heterogeneidad.
Rendimiento
La portabilidad es un factor importante, pero el estndar no conseguira una amplia uti-

lizacin si se consiguiera dicha portabilidad a expensas del rendimiento. Por ejemplo, el
lenguaje Fortran es comnmente usado por encima de los lenguajes ensambladores porque
los compiladores casi siempre ofrecen un rendimiento aceptable comparado con la alternativa
no portable que representa el lenguaje ensamblador. Un punto crucial es que MPI fu cuida-
dosamente diseado de manera que permite implementaciones eficientes. Las elecciones en el
diseo parecen haber sido hechas correctamente, dado que las implementaciones MPI estn al-
canzando un alto rendimiento en una amplia variedad de plataformas; de hecho el rendimiento
alcanzado en dichas implementaciones es comparable al de los sistemas presentados por las
compaas, los cuales estn diseados para arquitecturas especficas y tienen menor capacidad
de portabilidad.
Un objetivo importante de diseo en MPI fu el de permitir implementaciones eficientes
para mquinas de diferentes caractersticas. Por ejemplo, MPI evita cuidadosamente especi-
ficar la manera en que las operaciones tienen lugar. Slo especifica qu hace una operacin
lgicamente. Como resultado MPI puede ser fcilmente implementado en sistemas que tienen
buffer de mensajes en el proceso emisor, en el receptor, o que no tienen buffers para nada.
Las implementaciones pueden beneficiarse de las ventajas que ofrecen los subsistemas de co-
municacin de varias mquinas a travs de sus caractersticas especficas. En mquinas con
coprocesadores de comunicacin inteligentes podemos cargar sobre dichos coprocesadores la
mayora del procesamiento relativo al protocolo de paso de mensajes. En otros sistemas la
mayora del cdigo de comunicacin ser ejecutada por el procesador principal.
Otro ejemplo es el uso de objetos opacos en MPI; por ejemplo los elementos grupo y co-
municador son objetos opacos. Desde un punto de vista prctico sto significa que los detalles
de su representacin interna dependen de la implementacin MPI particular, y como conse-
cuencia el usuario no puede acceder directamente a ellos. En vez de ello el usuario accede a un
manejador que referencia al objeto opaco, de manera que dichos objetos opacos son manipu-
lados por funciones MPI especiales. De esta manera cada implementacin es libre de hacer lo
mejor en determinadas circunstancias.
Otra eleccin de diseo importante para la eficiencia es la manera de evitar el trabajo in-
necesario. MPI ha sido cuidadosamente diseado de modo que no sea necesaria demasiada
informacin extra con cada mensaje, ni complejas codificaciones o decodificaciones sobre las
cabeceras de dichos mensajes. MPI tambin evita computaciones extra o tests en funciones
crticas que degraden el rendimiento. Otra manera de minimizar el trabajo es reducir la repeti-
cin de computaciones previas. MPI proporciona esta capacidad a travs de construcciones
3.3. OBJETIVOS 61
como peticiones de comunicacin persistente o los atributos de los comunicadores. El diseo

de MPI evita la necesidad de operaciones extra de copia o almacenamiento sobre los datos: en
la mayora de los casos los datos son llevados directamente de la memoria de usuario a la red,
y son recibidos directamente de la red a la memoria receptora.
MPI ha sido diseado para reducir la sobrecarga en la comunicacin producida por el
procesamiento, utilizando agentes de comunicacin inteligentes y ocultando latencias en la
comunicacin. sto se ha logrado usando llamadas no bloqueantes, que separan el inicio de la
comunicacin de su final.
Escalabilidad
La escalabilidad es otro objetivo importante del procesamiento paralelo. La escalabilidad
de un sistema es su capacidad para responder a cargas de trabajo crecientes. De este modo los
programas MPI deben mantener su nivel de rendimiento aunque incrementemos el nmero de
procesos a ejecutar.
MPI permite o soporta la escalabilidad a travs de algunas de sus caractersticas de diseo.
Por ejemplo, una aplicacin puede crear subgrupos de procesos que, en turnos, puedan ejecutar
operaciones de comunicacin colectiva para limitar el nmero de procesos involucrados.
Formalidad
MPI, como todos los buenos estndares, es valioso debido a que define el comportamiento
de las implementaciones de manera concisa. Esta caracterstica libera al programador de tener
que preocuparse de aquellos problemas que puedan aparecer. Un ejemplo de ello es la garanta
de seguridad en la transmisin de mensajes que ofrece MPI. Gracias a esta caracterstica el
usuario no necesita comprobar si los mensajes son recibidos correctamente.
Resumen de Objetivos
Disear una interfaz para la programacin de aplicaciones.
La interfaz debe ser diseada para que pueda ser implementada en la mayora de las
plataformas, sin necesidad de cambios importantes en la comunicacin o el software del
sistema.
Permitir implementaciones que puedan ser utilizadas en entornos heterogneos.
Permitir una comunicacin eficiente.
Asumir una interfaz de comunicacin fiable: el usuario no debe preocuparse por los
fallos en la comunicacin.
La semntica de la interfaz debe ser independiente del lenguaje.
La interfaz debe permitir la utilizacin de hilos.
Proporcionar extensiones que aadan ms flexibilidad.

3.4. Usuarios
El estndar MPI est pensado para ser utilizado por todo aquel que pretenda desarrollar
programas de paso de mensajes codificados en Fortran 77 y C. sto incluye programadores
de aplicaciones individuales, desarrolladores de software para mquinas paralelas y creadores
de entornos y herramientas. Para que esta amplia audiencia lo considere atractivo, el estndar
debe proporcionar al usuario bsico una interfaz simple y fcil de manejar, que no impida el
uso de las operaciones de alto rendimiento disponibles en mquinas avanzadas.
3.5. Plataformas
El atractivo del paradigma de paso de mensajes proviene al menos en parte de su portabil-
idad. Los programas expresados de esta manera podran ser ejecutados en multicomputadores,
multiprocesadores o combinaciones de ambos. Adems es posible realizar implementaciones
basadas en memoria compartida. El paradigma no queda obsoleto al combinar arquitecturas de
memoria distribuida con arquitecturas de memoria compartida, o al incrementar la velocidad
de la red. Debe ser a la vez posible y til implementar dicho estndar en una gran variedad de
mquinas, incluyendo dichas mquinas que se componen de colecciones de otras mquinas,
paralelas o no, conectadas por una red de comunicaciones.
La interfaz es apropiada para su uso en programas MIMD y SPMD. Aunque no propor-
ciona un soporte explcito para la ejecucin de hilos la interfaz ha sido diseada de manera
que no perjudique su uso.
MPI proporciona muchas caractersticas encaminadas a mejorar el rendimiento en com-
putadores paralelos con hardware de comunicacin especializado entre procesadores. De este
modo es posible realizar implementaciones nativas MPI de alto rendimiento para este tipo de
mquinas. Al mismo tiempo existen implementaciones MPI que utilizan los protocolos estn-
dares de comunicacin entre procesadores de Unix, las cuales proporcionan portabilidad a los
clusters y redes heterogneas.
3.6. Versiones
El estndar MPI se divide bsicamente en dos especificaciones, MPI-1 y MPI-2. La sigu-
iente clasificacin muestra el nivel de compatibilidad con MPI que posee una implementacin
dada:
Mantener compatibilidad con la especificacin MPI-1 significa ser compatible con la

versin 1.2 de MPI.
Mantener compatibilidad con la especificacin MPI-2 significa proporcionar toda la fun-

cionalidad definida por la especificacin MPI-2.
En todo caso la compatibilidad hacia atrs est preservada. De esta manera un programa MPI-
1.1 vlido ser un programa MPI-1.2 vlido y un programa MPI-2 vlido; un programa MPI-
1.2 vlido ser un programa MPI-2 vlido.
3.6. VERSIONES 63
3.6.1. MPI-1
Las versiones 1.0, 1.1 y 1.2 del estndar MPI se engloban en la especificacin MPI-1.
Dicha especificacin centra su atencin en el modelo de paso de mensajes. A continuacin
mostramos una lista con los elementos contenidos en dicha especificacin, y aquellos que
quedan fuera de ella.
Elementos Incluidos
Comunicaciones punto a punto
Operaciones colectivas
Grupos de procesos
Contextos de comunicacin
Topologas de procesos
Administracin del entorno
Enlaces con Fortran 77 y C
Interfaz para la creacin de perfiles de ejecucin
Elementos No Incluidos
Operaciones de memoria compartida
Operaciones ya soportadas por el sistema operativo de manera estandarizada durante la

adopcin de MPI; por ejemplo, manejadores de interrupcin o ejecucin remota
Herramientas para la construccin de programas
Facilidades para la depuracin de errores
Soporte especfico para hilos
Soporte para planificacin y creacin de procesos
Funciones de E/S paralela
Como vemos MPI-1 est diseado para aprovechar todas las facilidades ofrecidas por el sis-
tema que vayamos a usar, tanto aquellas pertenecientes al sistema de comunicacin (opera-
ciones de memoria compartida, comunicacin va sockets, etc.) como las relativas al entorno
de programacin (herramientas para la construccin de programas, facilidades para la depu-
racin de errores, etc). Como resultado MPI es implementado normalmente como interfaz de
comunicaciones, utilizando dichas facilidades ofrecidas por el sistema.
Existen muchas caractersticas que fueron consideradas y no se incluyeron en MPI-1. s-
to ocurri por algunas razones: las restricciones de tiempo que se propuso el Foro MPI en
acabar la especificacin; el sentimiento de no tener suficiente experiencia en algunos de los
campos; y la preocupacin de que el aadir ms caractersticas podra retrasar la aparicin

de implementaciones. De todas maneras las caractersticas no incluidas siempre pueden ser
aadidas como extensiones en implementaciones especficas, como es el caso de la extensin
MPE dentro de la implementacin MPICH (seccin A.7).
3.6.2. MPI-2
La especificacin MPI-2 es bsicamente una extensin a MPI-1 que aade nuevos elemen-
tos al estndar. La versin 2.0 de MPI pertenece a la especificacin MPI-2. Entre las nuevas
funcionalidades que se aaden destacan las siguientes:
Administracin y Creacin de Procesos
Comunicaciones Unilaterales
E/S Paralela
Operaciones Colectivas Extendidas
Enlaces con Fortran 90 y C++
La razn por la cual se cre la especificacin MPI-2 fu la demanda por parte de los usuarios
y desarrolladores de nuevas caractersticas en el estndar. De todos modos MPI-2 slo aade
nuevos elementos a MPI-1, pero no lo modifica.
3.7. Implementaciones
Desde que se complet la primera versin del estndar en 1994 un gran nmero de imple-
mentaciones MPI han sido puestas a disposicin de los usuarios. Esto incluye tanto algunas
implementaciones portables e independientes como aquellas que han sido desarrolladas y op-
timizadas por las principales compaas de computadores paralelos. La alta calidad de dichas
implementaciones ha sido un punto clave en el xito de MPI.
A continuacin destacamos las tres implementaciones de dominio pblico ms importantes
que pueden ser utilizadas en clusters de sistemas Linux:
MPICH (URL [9]) es sin duda la implementacin ms importante de MPI. Muchas im-
plementaciones comerciales desarrolladas por las grandes compaas de computadores
paralelos se basan en ella. La primera versin de MPICH fu escrita durante el proceso
de estandarizacin de MPI, siendo finalmente presentada al mismo tiempo que la versin
1.0 de MPI. De hecho las experiencias de los autores de MPICH se convirtieron en una
gran ayuda para el Foro MPI en el proceso de desarrollo del estndar. Su portabilidad es
enorme y su rendimiento elevado. Posee compatibilidad total con MPI-1 e implemen-
ta muchos elementos de MPI-2. En el apndice A se analizan de manera detenida sus
caractersticas y se informa sobre su instalacin, configuracin y manejo.
LAM (URL [6]) fu desarrollada originalmente en el Centro de Supercmputo de Ohio

antes de que el estndar MPI fuera presentado. Cuando MPI apareci, LAM adopt
3.7. IMPLEMENTACIONES 65
el estndar. LAM no slo consiste en la librera MPI, si no que adems contiene her-
ramientas de depuracin y monitorizacin. Ha sido optimizada para funcionar con clus-
ters heterogneos de sistemas Unix; sin embargo es muy portable, siendo utilizada en
una amplia variedad de plataformas Unix, desde estaciones de trabajo a supercomputa-
dores. LAM posee compatibilidad total con MPI-1 e implementa muchos elementos de
MPI-2.
CHIMP (URL [1]) fu desarrollada en el Centro de Cmputo Paralelo de Edimburgo.

Como LAM, CHIMP comenz como una infraestructura independiente de paso de men-
sajes que luego evolucion hacia una implementacin MPI. CHIMP es conocida princi-
palmente por haber sido utilizada como versin optimizada de MPI para los CRAY T3D
y T3E. CHIMP es portable, pudiendo ser utilizada en estaciones de trabajo de Sun, SGI,
DEC, IBM y HP, en plataformas Meiko y en el Fujitsu AP 1000.
Captulo 4
Conceptos Bsicos
Todos los programas MPI comparten una serie de caractersticas. La inicializacin y final-
izacin del entorno de ejecucin se llevan a cabo mediante funciones que explicaremos en este
captulo. Tambin analizaremos los mtodos para identificar los procesos en ejecucin.
Por otro lado estudiaremos funciones para informarnos de dnde est ubicado cada proceso
y el momento temporal en que nos encontramos, y explicaremos el problema de la E/S en
procesadores paralelos. Para ejemplificar todo sto implementaremos un sencillo programa
que enva un mensaje de saludo e indica el nmero de procesos en ejecucin.
4.1. Algoritmo Hola Mundo!

Basndonos en el primer programa que muchos de nosotros vimos en C expondremos una
variante que har uso de mltiples procesos.
En MPI los procesos implicados en la ejecucin de un programa paralelo se identifican
por una secuencia de enteros no negativos. Si hay C procesos ejecutando un programa, stos
tendrn los identificadores DFE:1)EBGBGBG@EHC/I1 . El siguiente programa hace que el proceso 0 (encar-
gado de la E/S, seccin 4.4) imprima un mensaje de saludo e informe del nmero de procesos
en ejecucin, as como del tiempo empleado en el procesamiento.
Los detalles sobre la compilacin y ejecucin de este programa dependen del sistema que
estemos usando. De este modo debemos conocer cmo compilar y ejecutar programas par-
alelos que usen MPI. En la seccin A.5 explicamos cmo compilarlo bajo la implementacin
MPICH, y en la seccin A.6 se habla sobre la ejecucin de programas MPI.
Cuando el programa es compilado y ejecutado con dos procesos, la salida debera ser de
la siguiente manera:
Proceso 0 en linux.local Encargado de la E/S

Hola Mundo!
Numero Procesos: 2
Tiempo Procesamiento: 0.000065
Si lo ejecutamos con cuatro procesos la salida sera:
67
68 CAPTULO 4. CONCEPTOS BSICOS
Hola Mundo!
Numero Procesos: 4
Aunque los detalles de qu ocurre cuando el programa es ejecutado varan de una mquina a
otra, lo esencial es lo mismo en todos los sistemas, a condicin de que ejecutemos un proceso
en cada procesador.
1. El usuario manda una directiva al sistema operativo que crea una copia del programa
ejecutable en cada procesador.
2. Cada procesador comienza la ejecucin de su copia del ejecutable.
3. Diferentes procesos pueden ejecutar diferentes instrucciones bifurcando el programa a
travs de condicionantes. Dichos condicionantes suelen basarse, como veremos, en el
identificador del proceso.
4.2. Programas MPI en General

Todos los programas escritos en MPI deben contener la directiva de preprocesador
#include mpi.h
El fichero mpi.h contiene las definiciones, macros y prototipos de funcin necesarios para
compilar los programas MPI.
Antes de que podamos llamar a cualquier otra funcin MPI debemos hacer una llamada a
MPI_Init(); esta funcin slo debe ser llamada una vez. Sus argumentos son punteros a los
parmetros de la funcin main(), argc y argv. Dicha funcin permite al sistema hacer todas
la configuraciones necesarias para que la librera MPI pueda ser usada. Despus de que el pro-
grama haya acabado de utilizar la librera MPI debemos hacer una llamada a MPI_Finalize().
Esta funcin limpia todos los trabajos no finalizados dejados por MPI (por ejemplo, envos
pendientes que no hayan sido completados, etc.). As, un programa MPI tpico tiene la sigu-
iente composicin:
.
.
.
#include mpi.h
.
.
.
main(int argc, char** argv){
.
.
.
/*Ninguna llamada a funcin MPI anterior a esta*/
MPI_Init(&argc, &argv);
.
.
.
MPI_Finalize();
/*Ninguna llamada a funcin MPI posterior a esta*/
.
.
.
}/*main*/
4.3. INFORMNDONOS DEL RESTO DEL MUNDO 69
4.3. Informndonos del Resto del Mundo

MPI ofrece la funcin MPI_Comm_rank(), la cual retorna el identificador de un proceso
en su segundo argumento. Su sintaxis es:
int MPI_Comm_rank(MPI_Comm comunicador, int* identificador)
El primer argumento es el comunicador. Esencialmente un comunicador es una coleccin de

procesos que pueden enviarse mensajes entre s. Normalmente para disear programas bsicos
el nico comunicador que necesitaremos ser MPI_COMM_WORLD. Est predefinido en
MPI y consiste en todos los procesos que se ejecutan cuando el programa comienza.
Muchas de las construcciones que empleamos en nuestros programas dependen tambin
del nmero de procesos que se ejecutan. MPI ofrece la funcin MPI_Comm_size() para de-
terminar dicho nmero de procesos. Su primer argumento es el comunicador. En el segundo
argumento retorna el nmero de procesos pertenecientes a dicho comunicador. Su sintaxis es:
int MPI_Comm_size(MPI_Comm comunicador, int* numprocs)
4.4. El Problema de la Entrada/Salida

En nuestros algoritmos asumimos que el proceso 0 puede escribir en la salida estndar (la
ventana del terminal). Prcticamente todos los procesadores paralelos proporcionan este mto-
do de E/S. De hecho la mayora de ellos permiten a todos los procesos tanto leer de la entrada
estndar como escribir en la salida estndar. Sin embargo la dificultad aparece cuando varios
procesos estn intentando ejecutar operaciones de E/S simultneamente. Para comprender sto
expondremos un ejemplo.

Supongamos que diseamos un programa de manera que cada proceso intente leer los
valores , J y K aadiendo la siguiente instruccin:
scanf( %d %d %d, &a, &b, &c);
Adems supongamos que ejecutamos el programa con dos procesos y que el usuario introduce:
10 20 30
Qu ocurre? Obtienen ambos procesos los datos? Lo hace uno slo? O lo que es peor,
obtiene el proceso 0 el nmero 10 y el 20 mientras que el proceso 1 obtiene el 30? Si todos los
procesos obtienen los datos, qu ocurre cuando escribimos un programa en el que queremos
que el proceso 0 obtenga el primer valor de entrada, el proceso 1 el segundo, etc.? Y si slo
un proceso obtiene los datos, qu le ocurre a los dems? Es razonable hacer que mltiples
procesos lean de una sola terminal?
Por otra parte, qu ocurre si varios procesos intentan escribir datos en la terminal si-
multneamente? Se imprimirn antes los datos del proceso 0, despus los del proceso 1,
y as sucesivamente? O se imprimirn dichos datos aleatoriamente? O, lo que es peor, se
mostrarn los datos de los distintos procesos todos mezclados (una lnea del proceso 0, dos
caracteres del proceso 1, 3 caracteres del 0, 2 lneas del 2, etc.)?
Las operaciones estndar de E/S en C no proporcionan soluciones simples a dicho proble-
ma; as, la E/S sigue siendo objeto de investigacin por parte de la comunidad de procesamien-
to paralelo.
Por todo ello asumiremos que el proceso 0 puede al menos escribir en la salida estndar.
Tambin asumiremos que puede leer de la entrada estndar. En todos los casos asumiremos que
slo el proceso 0 puede interactuar con la E/S. sto podra parecer una debilidad, ya que como
mencionamos antes la mayora de las mquinas paralelas permiten que mltiples procesos
interactuen con la E/S. Sin embargo es un mtodo muy slido que nos permitir realizar un
manejo limpio de la E/S en nuestros programas.
4.5. Ubicacin de los Procesos

La funcin MPI_Get_processor_name() nos permite conocer el nombre del procesador
donde est ubicado cada proceso. sto puede ser til para monitorizar nuestros programas en
redes heterogneas. Conocer en qu mquina concreta se est ejecutando un proceso especfico
puede ser determinante para explicar su comportamiento, para lo cual podemos ayudarnos con
las herramientas de monitorizacin (seccin 9.1).
La sintaxis de dicha funcin es la siguiente:
int MPI_Get_processor_name(char* nombre, int* longnombre)
El parmetro nombre es una cadena (vector de caracteres) cuyo tamao debe ser al menos
igual a la constante MPI_MAX_PROCESSOR_NAME. En dicho vector quedar almacena-
do el nombre del procesador. El parmetro longnombre es otro parmetro de salida que nos
informa de la longitud de la cadena obtenida.
4.6. Informacin Temporal

Con el objeto de facilitar el control y la monitorizacin, MPI nos ofrece funciones en-
caminadas a proporcionar informacin temporal sobre la ejecucin de nuestros programas. La
funcin MPI_Wtime() nos informa sobre el tiempo transcurrido en un determinado proceso.
Dicha funcin no tiene parmetros; su valor de retorno es de tipo double y representa el
tiempo transcurrido en segundos desde el comienzo de la ejecucin del proceso. Si el atributo
MPI_WTIME_IS_GLOBAL est definido y su valor es true (por defecto es as) el valor de-
vuelto por la funcin estar sincronizado con todos los procesos pertenecientes al comunicador
MPI_COMM_WORLD.
Nosotros utilizaremos esta funcin para ofrecer cierta informacin al usuario sobre el tiem-
po de ejecucin de nuestro programa por la salida estndar. Nos permitir en estos casos difer-
enciar entre el tiempo de ejecucin de un programa y el tiempo de procesamiento.
Definimos el tiempo de ejecucin de un programa como el tiempo que emplea para re-
solver un problema en un computador paralelo, desde el momento en que es generado el
primer proceso hasta que acaba el ltimo. Este tiempo no debe ser calculado con la funcin
4.7. IMPLEMENTACIN ALGORITMO HOLA MUNDO! 71
MPI_Wtime() debido a que dicha funcin forma parte del entorno MPI, el cual debe ser fi-
nalizado antes de que el programa termine. Por lo tanto el tiempo que arrojara es incorrecto,
siempre menor al que debera; en su lugar usaremos las herramientas de monitorizacin para
determinar el tiempo de ejecucin.
Por otro lado llamamos tiempo de procesamiento al tiempo que emplea el computador en
calcular el resultado, eliminando el tiempo de inicializacin y finalizacin de los procesos, y
la comunicacin con el usuario. De esta manera si el usuario tarda diez segundos en introducir
los datos para un problema, ese tiempo no ser aadido al tiempo de procesamiento pero
s al tiempo de ejecucin. La funcin MPI_Wtime() nos ayudar a calcular el tiempo de
procesamiento de un programa para despus mostrarlo al usuario por la salida estndar.
En el caso del algoritmo Hola Mundo! el tiempo de procesamiento no es indicativo. Sin
embargo es muy til en programas donde un proceso (normalmente el proceso 0) desencadena
la ejecucin de los dems (normalmente al distribuir entre todos los procesos los datos que el
usuario introduce por la entrada estndar). ste ser el caso ms comn entre los algoritmos
expuestos en el presente documento.
4.7. Implementacin Algoritmo Hola Mundo!

A continuacin exponemos el cdigo del algoritmo Hola Mundo!. Como vemos dicho
programa utiliza el paradigma SPMD (Same Program Multiple Data, Programa nico y Flu-
jo de Datos Mltiple). Obtenemos el efecto de diferentes programas ejecutndose en distintos
procesadores bifurcando la ejecucin del programa. Para ello nos basamos en el identificador
del proceso: las instrucciones ejecutadas por el proceso 0 son distintas de las ejecutadas por
otros procesos, aunque todos los procesos estn ejecutando el mismo programa. ste es el
mtodo ms comn para escribir programas MIMD.
Algoritmo 4.1: Hola Mundo!
1
2 /********************************************************/
3 /*Hola Mundo: CODIGO PROGRAMA QUE SALUDA */
4 /********************************************************/
5
6 # define TAMCADENA 100
7 # include " mpi . h "
8 # include < s t d i o . h>
9
10 /**************/
11 /*FUNCION MAIN*/
/**************/
LML
12
13 i n t main ( i n t argc , char argv ) {
14 int id ; /*IDENTIFICADOR DEL PROCESO*/
15 i n t numprocs ; /*NUMERO DE PROCESOS*/
16 char nombreproc [MPI_MAX_PROCESSOR_NAME] ;
17 /*NOMBRE PROCESADOR*/
18 i n t lnombreproc ; /*LONGITUD NOMBRE PROCESADOR*/
19 double t m p i n i c = 0 . 0 ; /*TIEMPO INICIO DE LA EJECUCION*/
20 double t m p f i n ; /*TIEMPO FINAL DE LA EJECUCION*/
21
22
23 /*INICIALIZAMOS EL ENTRORNO DE EJECUCION MPI*/
24 M P I _ I n i t (& argc ,& argv ) ;
25
26 /*ALMACENAMOS EL IDENTIFICADOR DEL PROCESO*/
27 MPI_Comm_rank (MPI_COMM_WORLD,& i d ) ;
28
29 /*ALMACENAMOS EL NUMERO DE PROCESOS*/
30 MPI_Comm_size (MPI_COMM_WORLD, & numprocs ) ;
31
32 /*E/S:NOMBRE DEL PROCESADOR,PROCESO 0*/
33 MPI_Get_processor_name ( nombreproc,& lnombreproc ) ;
34 i f ( i d ==0){
35 f p r i n t f ( s t d o u t , " \ n P r o c e s o %d en %s E n c a r g a d o de l a E / S \ n \ n " ,
36 i d , nombreproc ) ;
37 }
38
39 /*TIEMPO INICIAL DE LA EJECUCION */
40 t m p i n i c=MPI_Wtime ( ) ;
41
42 /*E/S:PROCESAMIENTO*/
43 i f ( i d ==0){
44 f p r i n t f ( s t d o u t , " H o l a Mundo ! \ n \ n " ) ;
45 }
46
47 /*TIEMPO FINAL DE LA EJECUCION*/
48 t m p f i n =MPI_Wtime ( ) ;
49
50 /*E/S:INFORMACION SOBRE LA EJECUCION*/
51 i f ( i d ==0){
f p r i n t f ( s t d o u t , " Numero P r o c e s o s : %d \ n " , numprocs ) ;
N
52
53 f p r i n t f ( s t d o u t , " Tiempo P r o c e s a m i e n t o : % f \ n \ n " , t m p f i n t m p i n i c ) ;
54 }
55
56 /*FINALIZAMOS EL ENTRORNO DE EJECUCION MPI*/
57 MPI_Finalize ( ) ;
58 return 0 ;
59 }
Captulo 5
Paso de Mensajes
El paso de mensajes es quizs la funcin ms importante y caracterstica del estndar MPI.

Se utiliza bsicamente para el intercambio de datos entre los procesos en ejecucin. En este
captulo estudiaremos las caractersticas ms importantes de los mensajes bloqueantes y no
bloqueantes, aplicando dicha teora a la implementacin de un algoritmo diseado para el
clculo de reas circulares.
5.1. Algoritmo Clculo de reas mediante Montecarlo

El mtodo de Montecarlo es un mtodo numrico que permite resolver problemas matemti-
cos mediante la simulacin de variables aleatorias. Utilizaremos dicho mtodo para aproximar
el rea de un crculo con un radio determinado.
Supongamos que queremos calcular el rea de un crculo de radio O . Para hacerlo tomare-
mos un cuadrado de lado (@O y lo pondremos alrededor del crculo de radio O , de manera que
quede circunscrito. A continuacin generaremos un nmero de puntos aleatorios dentro del
rea del cuadrado. Algunos caern dentro del rea del crculo y otros no, como se expone en
la figura 5.1.
Tomaremos 6 como el nmero de puntos aleatorios generados dentro del cuadrado y

P O y elquenmero
como del crculo. Si sabemos que el rea del crculo es
de puntos que caen dentro
el rea del cuadrado es ,Q(@OM3 , tendremos la siguiente igualdad:
P O Q, (@OM3
6
Con lo cual llegamos fcilmente a que:
P SR *
6
P
P
Utilizando dicha aproximacin de y sabiendo el radio del crculo aproximaremos f-
cilmente su rea mediante O . Lgicamente cuantas ms muestras tomemos, o lo que es lo
P
mismo, cuantos ms puntos generemos, mejor ser la aproximacin de . Tambin interviene
mucho la aleatoriedad de las muestras; cuanto ms aleatorias sean, mejor.
La cuestin ahora es determinar los puntos que caen dentro del crculo y los que caen
fuera. Para explicarlo observemos la figura 5.2. Dado un punto ,.T'EU-3 podremos saber si ha
cado dentro del crculo mediante la regla de Pitgoras:
73
74 CAPTULO 5. PASO DE MENSAJES
Figura 5.1: Generacin Puntos Aleatorios
V T XW U
Si la hipotenusa es mayor que el radio del crculo querr decir que el punto est fuera de
dicho crculo. Si la hipotenusa es menor que el radio, consideraremos que est dentro. Como
podemos observar en la figura, tambin podemos generar puntos en slo una cuarta parte del
cuadrado y el crculo, de manera que la proporcin no queda alterada. As lo hacemos en la
implementacin del algoritmo Clculo de reas mediante Montecarlo (seccin 5.6).
5.2. El Entorno del Mensaje

El paso de mensajes bloqueantes se lleva a cabo en nuestros programas por las funciones
MPI_Send() y MPI_Recv() principalmente. La primera funcin enva un mensaje a un pro-
ceso determinado. La segunda recibe un mensaje de un proceso. stas son las funciones ms
bsicas de paso de mensajes en MPI. Para que el mensaje sea comunicado con xito, el sistema
debe adjuntar alguna informacin a los datos que el programa intenta transmitir. Esta infor-
macin adicional conforma el entorno del mensaje. En MPI el entorno contiene la siguiente
informacin:
1. El identificador del proceso receptor del mensaje.
2. El identificador del proceso emisor del mensaje.
3. Una etiqueta.
4. Un comunicador.
Estos datos pueden ser usados por el proceso receptor para distinguir entre los mensajes en-
trantes. El origen puede ser usado para distinguir mensajes recibidos por distintos procesos.
5.2. EL ENTORNO DEL MENSAJE 75
(x,y)
Figura 5.2: Clculo Hipotenusa Punto Aleatorio

La etiqueta es un int especificado por el usuario que puede ser usado para distinguir mensajes
recibidos por un nico proceso. Por ejemplo, supongamos que el proceso est enviando dos
mensajes al proceso Y ; ambos mensajes contienen un nmero flotante. Uno de los flotantes

se emplea en un clculo, mientras que otro debe ser impreso. Para determinar cul es cul,
puede usar etiquetas diferentes para cada mensaje. Si Y usa las mismas etiquetas que en
las recepciones correspondientes, sabr qu hacer con ellas. MPI garantiza que los enteros
dentro del intervalo 0-32767 pueden ser usados como etiquetas. La mayora de las imple-
mentaciones permiten valores mucho mayores.
Como dijimos antes un comunicador es bsicamente una coleccin de procesos que pueden
mandarse mensajes entre s. La importancia de los comunicadores se acenta cuando los
mdulos de un programa han sido escritos independientemente de los dems. Por ejemplo,
supongamos que queremos resolver un sistema de ecuaciones diferenciales y, en el transcurso
de resolverlo, tenemos que resolver un sistema de ecuaciones lineales. Mejor que escribir la
resolucin del sistema de ecuaciones lineales desde el principio, podramos usar una librera
de funciones escrita por otra persona y optimizada para el sistema que estamos usando. C-
mo evitamos que se confundan los mensajes que nosotros enviamos entre los procesos y

Y con los mensajes enviados en la librera de funciones? Sin la ventaja de los comunicadores
probablemente haramos una particin del rango de las posibles etiquetas, haciendo que parte
de ellas slo puedan ser usadas por la librera de funciones. sto es tedioso y puede causarnos
problemas si ejecutamos el programa en otro sistema: puede que la librera del otro sistema
no haga uso del mismo rango de etiquetas. Con la ventaja de los comunicadores, simple-
mente creamos un comunicador para uso exclusivo en la resolucin del sistema de ecuaciones
lineales, y se lo pasamos a la librera encargada de hacerlo como argumento en la llamada.
Comentaremos los detalles ms adelante. Por ahora continuaremos utilizando el comunicador
MPI_COMM_WORLD, el cual consiste en todos los procesos que se ejecutan cuando el
programa comienza.
Tipo de Datos MPI Tipo de Datos C

MPI_CHAR signed char
MPI_SHORT signed short int
MPI_INT signed int
MPI_LONG signed long int
MPI_UNSIGNED_CHAR unsigned char
MPI_UNSIGNED_SHORT unsigned short int
MPI_UNSIGNED unsigned int
MPI_UNSIGNED_LONG unsigned long int
MPI_FLOAT float
MPI_DOUBLE double
MPI_LONG_DOUBLE long double
MPI_BYTE
MPI_PACKED
Cuadro 5.1: Tipos de Datos MPI
5.3. Funciones de Paso de Mensajes Bloqueantes

Para resumir detallamos la sintaxis de las dos funciones ms importantes de paso de men-
sajes bloqueantes:
int MPI_Send(void* mensaje, int contador,

MPI_Datatype tipo_datos, int destino,
int etiqueta, MPI_Comm comunicador)
int MPI_Recv(void* mensaje, int contador,

MPI_Datatype tipo_datos, int origen,
int etiqueta, MPI_Comm comunicador,
MPI_Status* status)
Al igual que la mayora de las funciones de la biblioteca estndar de C, la mayora de las

funciones MPI retornan un entero como cdigo de error. Sin embargo, como la mayora de los
programadores de C, ignoraremos esos valores de retorno en casi todos los casos.
Los contenidos del mensaje son almacenados en un bloque de memoria referenciado por
el argumento mensaje. Los siguientes dos argumentos, contador y tipo_datos, permiten al
sistema identificar el final del mensaje: ste contiene una secuencia de contador valores, cada
uno del tipo MPI datatype. Este tipo no es un tipo de C, aunque la mayora de los tipos
predefinidos corresponden a tipos de C. En el cuadro 5.1 se listan los tipos predefinidos de
MPI con sus correspondientes tipos de C, si stos existen.
Los ltimos dos tipos, MPI_BYTE y MPI_PACKED, no corresponden con tipos estn-
dar de C. El tipo MPI_BYTE puede ser usado si queremos forzar que el sistema no realice
conversin alguna entre las distintas representaciones de los datos (por ejemplo, en una red
heterognea de estaciones de trabajo que utilicen una representacin de datos distinta).
5.4. FUNCIONES DE PASO DE MENSAJES NO BLOQUEANTES 77
Notar que la cantidad de espacio reservado para el buffer de entrada no tiene porqu co-
incidir con la cantidad exacta de espacio que ocupa el mensaje que estemos recibiendo. Por
ejemplo, podra darse el caso de que el tamao del mensaje que el proceso 1 enva al proceso 0
sea de 28 caracteres (strlen(mensaje)+1), aunque el proceso 0 reciba el mensaje en un buffer
que tiene capacidad para 100 caracteres. sto tiene sentido. En general el proceso receptor no
conoce el tamao exacto del mensaje que se le est enviando. MPI permite recibir mensajes
tan largos como capacidad reservada tengamos. Si no tenemos suficiente capacidad, tendremos
un error de desbordamiento.
Los argumentos destino y origen son los identificadores del proceso receptor y del proceso
emisor, respectivamente. MPI permite que el argumento origen sea un comodn. Existe una
constante predefinida llamada MPI_ANY_SOURCE que puede ser usada si un proceso est
preparado para recibir un mensaje procedente de cualquier proceso. No existe comodn para
destino.
Como dijimos anteriormente MPI contiene dos mecanismos diseados especficamente
para particionar el espacio de los mensajes: las etiquetas y los comunicadores. Los argumen-
tos etiqueta y comunicador son, respectivamente, la etiqueta y el comunicador. El argumento
etiqueta es un int y, por ahora, nuestro nico comunicador es MPI_COMM_WORLD, el
cual, como comentamos antes, est predefinido en todos los sistemas MPI y consiste en todos
los procesos que se ejecutan cuando el programa comienza. Existe un comodn,

MPI_ANY_TAG, que puede ser usado en MPI_Recv() para la etiqueta. No existe un comod-

n para el comunicador. En otras palabras, para que el proceso mande un mensaje al proceso
Y el argumento comunicador que usa en MPI_Send() debe ser idntico al argumento que
Y usa en MPI_Recv().
El ltimo argumento de MPI_Recv(), status, retorna informacin acerca de los datos que
hemos recibido. Referencia a un registro con dos campos, uno para el origen y otro para la
etiqueta. Por ejemplo, si el origen era MPI_ANY_SOURCE en la llamada a MPI_Recv(), el
argumento status contendr el identificador del proceso que envi el mensaje.
5.4. Funciones de Paso de Mensajes No Bloqueantes

El rendimiento de los sistemas de paso de mensajes puede ser mejorado mediante el so-
lapamiento entre comunicacin y procesamiento en los algoritmos. Un mtodo para realizar
sto es mediante la comunicacin no bloqueante. Las funciones de envo de mensajes no blo-
queantes inician el envo del mensaje, pero no lo completan; para ello se necesita una llamada
a la funcin de finalizacin de envos no bloqueantes. De la misma manera una llamada a una
funcin de recepcin de mensajes no bloqueantes no detiene la ejecucin del algoritmo hasta
que dicho mensaje sea realmente recibido, como ocurre con las versiones bloqueantes. De este
modo podemos solapar comunicacin y procesamiento en nuestros algoritmos.
Las versiones no bloqueantes de las funciones de paso de mensajes son:
int MPI_Isend(void* mensaje, int contador,

MPI_Request* peticion)
int MPI_Irecv(void* mensaje, int contador,

A simple vista la diferencia entre estas funciones y sus versiones bloqueantes es la existencia
del argumento peticion en sus llamadas. Este argumento es utilizado por las funciones de
finalizacin de transmisiones bloqueantes para su ejecucin.
Las funciones de finalizacin de transmisiones bloqueantes son:
int MPI_Wait(MPI_Request* peticion,

MPI_Status* status)
int MPI_Waitany(int contador,
MPI_Request* vector_peticiones,
int* indice,
MPI_Status* status)
int MPI_Waitall(int contador,
MPI_Status* status)
La funcin MPI_Wait() espera a que se complete un envo o una recepcin de un mensaje.

Para ello le pasamos como argumento de entrada el argumento de salida que nos proporciona
la funcin de paso de mensajes no bloqueantes en el momento de la llamada. El argumento de
salida status nos proporciona informacin acerca de los datos que hemos recibido.
Por su parte MPI_Waitany() espera a que se complete cualquiera de las peticiones que le
pasamos en vector_peticiones, devolviendo en el argumento indice la posicin de la peticin
satisfecha.
MPI_Waitall() espera a que se completen todas las peticiones que le pasamos en vec-
tor_peticiones.
5.5. Agrupaciones de Datos

Con la generacin de mquinas actual el envo de mensajes es una operacin costosa.
Segn esta regla, cuantos menos mensajes enviemos mejor ser el rendimiento general del
algoritmo. As pues en el algoritmo Clculo de reas mediante Montecarlo podramos mejorar
el rendimiento si distribuimos los datos de entrada en un solo mensaje entre los procesadores.
Recordemos que las funciones de paso de mensajes tienen dos argumentos llamados con-
tador y tipo_datos. Estos dos parmetros permiten al usuario agrupar datos que tengan el
mismo tipo bsico en un nico mensaje. Para usarlo dichos datos deben estar almacenados en
direcciones de memoria contiguas. Debido a que el lenguaje C garantiza que los elementos
de un vector estn almacenados en direcciones de memoria contiguas, si queremos enviar los
elementos de un vector, o un subconjunto de ellos, podremos hacerlo en un solo mensaje.
Desafortunadamente esto no nos ayuda en el algoritmo Clculo de reas mediante Mon-
tecarlo si queremos enviar los datos de entrada a cada proceso en un solo mensaje. Ello es
5.5. AGRUPACIONES DE DATOS 79
debido a que las variables que contienen el radio y el nmero de muestras no tienen porqu es-
tar alojadas en direcciones de memoria contiguas. Tampoco debemos almacenar estos datos en
un vector debido a que ello restara claridad y elegancia al cdigo. Para lograr nuestro objetivo
utilizaremos una facilidad de MPI para la agrupacin de los datos.
5.5.1. Tipos Derivados

Una opcin razonable para conseguir nuestro objetivo podra ser almacenar el radio y el
nmero de muestras en una estructura con dos miembros (un flotante largo y un entero largo)
como se muestra a continuacin:
typedef struct{
long double radio;
long nmuestras_local;
} Tipo_Datos_Entrada;
e intentar utilizar el tipo de datos de la estructura como argumento tipo_datos en las funciones
de paso de mensajes. El problema aqu es que el tipo de datos de la estructura no es un tipo
de datos MPI; necesitamos construir un tipo de datos MPI a partir del tipo de datos de C. MPI
propone una solucin a sto permitiendo al usuario construir tipos de datos MPI en tiempo de
ejecucin. Para construir un tipo de datos MPI bsicamente se especifica la distribucin de los
datos en el tipo (los tipos de los miembros y sus direcciones relativas de memoria). Un tipo
de datos MPI construido de este modo se denomina tipo de datos derivado. Para ver cmo
funciona sto expondremos la funcin que construye dicho tipo de datos.
void construir_tipo_derivado(Tipo_Datos_Entrada* pdatos,

MPI_Datatype* pMPI_Tipo_Datos){
MPI_Datatype tipos[2];
int longitudes[2];
MPI_Aint direcc[3];
MPI_Aint desplaz[2];
/*PRIMERO ESPECIFICAMOS LOS TIPOS*/

tipos[0]=MPI_LONG_DOUBLE;
tipos[1]=MPI_LONG;
/*ESPECIFICAMOS EL NUMERO DE ELEMENTOS DE CADA TIPO*/

longitudes[0]=1;
longitudes[1]=1;
/*CALCULAMOS LOS DESPLAZAMIENTOS DE LOS MIEMBROS DE LA ESTRUCTURA

RELATIVOS AL COMIENZO DE DICHA ESTRUCTURA*/
MPI_Address(pdatos,&direcc[0]);
MPI_Address(&(pdatos->radio),&direcc[1]);
MPI_Address(&(pdatos->nmuestras_local),&direcc[2]);
desplaz[0]=direcc[1]-direcc[0];
desplaz[1]=direcc[2]-direcc[0];
/*CREACION TIPO DATOS DERIVADO*/

MPI_Type_struct(2,longitudes,desplaz,tipos,pMPI_Tipo_Datos);
/*CERTIFICARLO DE MANERA QUE PUEDA SER USADO*/

MPI_Type_commit(pMPI_Tipo_Datos);
}/*construir_tipo_derivado*/
Las primeras dos sentencias especifican los tipos de los miembros del tipo de datos deriva-
do, y las dos siguientes especifican el nmero de elementos de cada tipo. La funcin
MPI_Address() nos ayuda a calcular los desplazamientos de cada uno de los miembros con
respecto a la direccin inicial del primero. Con esta informacin ya sabemos los tipos, los
tamaos y las direcciones relativas de memoria de cada uno de los miembros del tipo de datos
de C, y por lo tanto ya podemos definir el tipo de datos MPI derivado del tipo de datos de C.
sto se hace llamando a las funciones MPI_Type_struct() y MPI_Type_Commit().
El tipo de datos MPI creado puede ser usado en cualquiera de las funciones de comuni-
cacin de MPI. Para usarlo simplemente usaremos como primer argumento de las funciones
la direccin inicial de la estructura a enviar, y el tipo de datos MPI creado en el argumento
tipo_datos.
5.5.2. Vectores
La funcin MPI_Type_vector() crea un tipo derivado consistente en contador elementos.
int MPI_Type_vector(int contador, int longitud_bloque,

int salto, MPI_Datatype tipo_datos_elem,
MPI_Datatype* nuevo_tipo)
Cada elemento contiene longitud_bloque elementos de tipo tipo_datos_elem. El argumento

salto es el nmero de elementos de tipo tipo_datos_elem que hay entre los sucesivos elemen-
tos de nuevo_tipo.
5.6. Implementacin Clculo de reas mediante Montecarlo

A continuacin exponemos las versiones bloqueante y no bloqueante del algoritmo Clcu-
los de reas mediante Montecarlo.
5.6.1. Implementacin con Mensajes Bloqueantes

5.6. IMPLEMENTACIN CLCULO DE REAS MEDIANTE MONTECARLO 81
Algoritmo 5.1: Clculo de reas mediante Montecarlo (Bloqueante)

1
2 /***************************************************/
3 /*Calculo de Areas: CODIGO APROXIMACION DE AREAS */
4 /*CIRCULARES MEDIANTE MONTECARLO (BLOQUEANTE) */
5 /***************************************************/
6
8 # include < s t d l i b . h>
9 # include < math . h>
11
12 /*DECLARACION ESTRUCTURA DATOS ENTRADA*/
13 typedef s t r u c t {
14 long double r a d i o ;
15 long n m u e s t r a s _ l o c a l ;
16 } Tipo_Datos_Entrada ;
17
18 /*DECLARACION DE LA FUNCIONES QUE VAMOS A UTILIZAR*/
long double MonteCarlo ( i n t i d , long double r a d i o , long l o c a l _ n ) ;
L L
19
void o b t e n e r _dat os ( long double p r a d i o , long pnmuestras_global ) ;
L
20
void d i s t r i b u i r _ d a t o s ( i n t i d , i n t numprocs , long double p r a d i o ,
L
21
long p n m u e s t r a s _ l oc a l ) ;
L
22
void r e c o l e c t a r _ d a t o s ( i n t i d , i n t numprocs , long double p a p r o x _ l o c a l ,
L
23
long double p a p r o x _ g l o b a l ) ;
L
24
void c o n s t r u i r _ t i p o _ d e r i v a d o ( Tipo_Datos_Entrada pdatos ,
L
25
26 MPI_Datatype pMPI_Tipo_Datos ) ;
27
28 /**************/
29 /*FUNCION MAIN*/
/**************/
LML
30
32
33 long double PI25DIGITOS=3.141592653589793238462643;
34 /*VALOR PI PARA CALCULAR EL ERROR*/
40 long double r a d i o ; /*RADIO CIRCUNFERENCIA*/
41 long n m u e s t r a s _global ; /*NUMERO DE MUESTRAS*/
42 long n m u e s t r a s _ l o c a l ; /*NUMERO DE MUESTRAS DE CADA PROCESO*/
43 long double a p r o x _ l o c a l ; /*APROX LOCAL DE CADA PROCESO*/
44 long double a p r o x _ g l o b a l ; /*APROX GENERAL (MEDIA DE TODAS LAS LOCALES)*/
45 int raiz =0; /*PROCESO QUE RECIBE LAS LOCALES Y LAS SUMA*/
47 double t m p f i n ; /*TIEMPO FINAL DE LA EJECUCION */
48
49 int etiqueta =50; /*ETIQUETA MENSAJES DE PRUEBA*/
50 MPI_Status s t a t u s ; /*STATUS RECEPCION MENSAJES DE PRUEBA*/
51 int origen ; /*PROCESO ORIGEN MENSAJES DE PRUEBA*/
52
53

56
59
61 MPI_Comm_size (MPI_COMM_WORLD,& numprocs ) ;
62
63 /*E/S:NOMBRE DEL PROCESADOR,PROCESADOR 0*/
65 i f ( i d ==0){
66 f p r i n t f ( s t d o u t , " \ n P r o c e s o %d en %s E n c a r g a d o de l a E / S \ n " ,
68 }
69 /*E/S:NOMBRE DEL PROCESADOR,TODOS LOS PROCESOS (PRUEBAS)*/
70 /*if(id==0){
71 * for (origen=1;origen<numprocs;origen++){
72 * MPI_Recv(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,origen,
73 * etiqueta,MPI_COMM_WORLD,&status);
74 * fprintf(stdout,"Proceso %d en %s\n",origen,nombreproc);
75 * }
76 *}
77 *else{
78 * MPI_Send(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,0,
79 * etiqueta,MPI_COMM_WORLD);
80 *}
81 */
82
83 /*OBTENEMOS DATOS INTRODUCIDOS POR EL USUARIO*/
84 i f ( i d ==0){
85 o b t e n e r _datos(& r a d i o ,& n m u e s t r a s _ global ) ;
86 /*NUMERO DE MUESTRAS PARA CADA PROCESO*/
87 n m u e s t r a s _ l o c a l=n m u e s t r a s _ global / numprocs ;
/*TRUNCAMOS NUMERO DE MUESTRAS GLOBAL*/
L
88
89 n m u e s t r a s _gl obal= n m u e s t r a s _ l o c a l numprocs ;
90 }
91
92 /*TIEMPO INICIAL DE PROCESAMIENTO*/
93 i f ( i d ==0){ f p r i n t f ( stdout , " Procesando . . . \ n \ n " ) ; }
95
96 /*DISTRIBUIMOS DATOS INTRODUCIDOS POR EL USUARIO*/
97 d i s t r i b u i r _ d a t o s ( i d , numprocs ,& r a d i o ,& n m u e s t r a s _ l o c a l ) ;
98
99 /*CALCULAMOS LA INTEGRAL PARCIAL DEL PROCESO*/
100 a p r o x _ l o c a l = MonteCarlo ( i d , r a d i o , n m u e s t r a s _ l o c a l ) ;
101
102 /*RECOLECTAMOS AREAS CALCULADAS POR LOS PROCESOS Y HACEMOS LA MEDIA*/
103 r e c o l e c t a r _ d a t o s ( i d , numprocs ,& a p r o x _ l o c a l ,& a p r o x _ g l o b a l ) ;
104
105 /*TIEMPO FINAL DE PROCESAMIENTO*/
107
108 /*E/S:IMPRIMIMOS RESULTADO Y TIEMPO DE PROCESAMIENTO*/
109 i f ( i d ==0){
110 f p r i n t f ( s t d o u t , " Con n= %d m u e s t r a s , l a e s t i m a c i o n d e l a r e a de l a \ n " ,

111 n m u e s t r a s _global ) ;
112 f p r i n t f ( s t d o u t , " de l a c i r c u n f e r e n c i a con r a d i o %Lf e s \ n " , r a d i o ) ;
113 f p r i n t f ( s t d o u t , " %.60 Lf \ n " , a p r o x _ g l o b a l ) ;
f p r i n t f ( s t d o u t , " E r r o r < %f \ n \ n " ,
L L N
114
115 f a b s ( PI25DIGITOS r a d i o r a d i o a p r o x _ g l o b a l ) ) ;
N
116
118 }
119
122
123 } /*main*/
124
125
126 /***************************************************************/
127 /*FUNCION obtener_datos:PROCESO 0 CONSULTA AL USUARIO EL RADIO */
128 /*DE LA CIRCUNFERENCIA Y EL NUMERO DE MUESTRAS GLOBAL */
/***************************************************************/
L L
129
130 void o b t e n e r _dat os ( long double p r a d i o , long pnmuestras_global ) {
131
132 /*E/S:PETICION DE DATOS*/
133
134 f p r i n t f ( s t d o u t , " I n t r o d u z c a r a d i o de l a c i r c u n f e r e n c i a \ n " ) ;
135 s c a n f ( " %Lf " , p r a d i o ) ;
136 f p r i n t f ( s t d o u t , " I n t r o d u z c a numero de m u e s t r a s \ n " ) ;
137 s c a n f ( " %l d " , pnmuestras_global ) ;
138
139
140 /*E/S SIN PETICION:UTILIZAR EN CASO DE PRUEBAS*/
141 /**pradio=1.0;*pnmuestras_global=200000000;*/
142
143 } /*obtener_datos*/
144
145
146 /**********************************************************************/
147 /*FUNCION distribuir_datos:PROCESO 0 DISTIBUYE RADIO DE LA */
148 /*CIRCUNFERENCIA Y EL NUMERO DE MUESTRAS (n) ENTRE LOS DEMAS PROCESOS */
/**********************************************************************/
L
149
L
150
151 long p n m u e s t r a s _ l oc a l ) {
152
153 MPI_Datatype MPI_Tipo_Datos_Entrada ;
154 Tipo_Datos_Entrada d a t o s _ e n tr ada ;
155 int origen =0; /*PROCESO ORIGEN MENSAJES*/
156 int destino ; /*PROCESO DESTINO DATOS*/
157 int etiqueta ; /*ETIQUETA MENSAJES*/
158 MPI_Status s t a t u s ; /*STATUS RECEPCION MENSAJES*/
159
160
161 c o n s t r u i r _ t i p o _ d e r i v a d o (& d a t o s _ e n tr ada,& MPI_Tipo_Datos_Entrada ) ;
162
163 i f ( i d ==0){
164 /*ENVIO DE LOS DATOS*/
L
d a t o s _ e nt rada . r a d i o = p r a d i o ;
L
165
166 d a t o s _ e nt rada . n m u e s t r a s _ l o c a l = p n m u e s t r a s _ l o c al ;
167 f o r ( d e s t i n o =1; d e s t i n o <numprocs ; d e s t i n o + + ) {
168 e t i q u e t a =30;
169 MPI_Send(& d a t o s _ e nt rada , 1 , MPI_Tipo_Datos_Entrada , d e s t i n o ,
170 e t i q u e t a ,MPI_COMM_WORLD ) ;
171 }
172 }
173 else {
174 /*RECEPCION DE LOS DATOS*/
175 e t i q u e t a =30;
176 MPI_Recv(& d a t o s _ e n tra da , 1 , MPI_Tipo_Datos_Entrada , o r i g e n ,
e t i q u e t a ,MPI_COMM_WORLD,& s t a t u s ) ;
L
177
p r a d i o= d a t o s _ e ntr ada . r a d i o ;
L
178
179 p n m u e s t r a s _ l o c al= d a t o s _ e nt rada . n m u e s t r a s _ l o c a l ;
180 }
181 } /*distribuir_datos*/
182
183
184 /************************************************************************/
185 /*FUNCION MonteCarlo: RETORNA EL AREA DE LA CIRCUNFERENCIA CON RADIO */
186 /*radio UTILIZANDO EL NUM.MUESTRAS nummuestras MEDIANTE MONTECARLO */
187 /************************************************************************/
188 long double MonteCarlo ( i n t i d , long double r a d i o , long nummuestras ) {
189
190 long double p i ; /*VBLE QUE ALMACENA NUMERO PI*/
191 long double area ; /*AREA CIRCUNFERENCIA*/
192 long double x ; /*EJE ORDENADAS MUESTRA ACTUAL*/
193 long double y ; /*EJE COORDENADAS MUESTRA ACTUAL*/
194 long double h i p ; /*HIPOTENUSA MUESTRA ACTUAL*/
195 long aciertos =0; /*NUM.MUESTRAS QUE CAEN DENTRO DE LA CIRCUNFERENCIA*/
196 long fallos =1; /*NUM.MUESTRAS QUE CAEN FUERA DE LA CIRCUNFERENCIA*/
197 long i ; /*CONTADOR*/
198
199
200 /*UTILIZAMOS COMO SEMILLA EL IDENTIFICADOR DEL PROCESO*/
201 srand ( i d ) ;
202
203 /*ESTIMACION DE PI*/
204 f o r ( i =0; i ! = nummuestras ; i + + ) {
205 x =( long double ) rand ( ) / RAND_MAX;
206 y =( long double ) rand ( ) / RAND_MAX;
207 h i p = s q r t ( pow ( x , 2 ) +pow ( y , 2 ) ) ;
208 i f ( hip >1){ f a l l o s ++;}
209 else { a c i e r t o s + + ; }
}
L
210
211 p i = 4 . 0 ( ( long double ) a c i e r t o s / nummuestras ) ;
212
/*CALCULAMOS AREA*/
L
213
214 area=pow ( r a d i o , 2 ) p i ;
215
216 r e t u r n area ;
217
218 } /*MonteCarlo*/
219
220
221 /*********************************************************************/
222 /*FUNCION recolectar_datos:PROCESO 0 HACE LA MEDIA DE LAS */
223 /*APROXIMACIONES LOCALES */
/*********************************************************************/
L
224
L
225
226 long double p a p r o x _ g l o b a l ) {
227
228 int origen ; /*PROCESO ORIGEN MENSAJES*/
229 int destino =0; /*PROCESO DESTINO DATOS*/
231 MPI_Status s t a t u s ; /*STATUS RECEPCION MENSAJES*/
232 long double b u f f e r ; /*BUFFER RECEPCION APROXIMACIONES LOCALES*/
233
234 i f ( i d ==0){
/*RECOLECTAMOS LOS CALCULOS LOCALES Y HACEMOS LA MEDIA*/
L L
235
236 p a p r o x _ g l o b a l= p a p r o x _ l o c a l ;
237 f o r ( o r i g e n =1; o r i g e n<numprocs ; o r i g e n + + ) {
238 e t i q u e t a =30+ o r i g e n ;
239 MPI_Recv(& b u f f e r , 1 , MPI_LONG_DOUBLE, o r i g e n , e t i q u e t a ,
MPI_COMM_WORLD,& s t a t u s ) ;
L L
240
241 p a p r o x _ g l o b a l =( p a p r o x _ g l o b a l+ b u f f e r ) / 2 . 0 ;
242 }
243 }
244 else {
246 e t i q u e t a =30+ i d ;
247 MPI_Send ( p a p r o x _ l o c a l , 1 , MPI_LONG_DOUBLE, d e s t i n o , e t i q u e t a ,
248 MPI_COMM_WORLD ) ;
249 }
251
252
253 /*********************************************************************/
254 /*FUNCION construir_tipo_derivado: CONSTRUYE EL TIPO DE DATOS MPI */
255 /*NECESARIO PARA DISTRIBUIR LOS DATOS DE ENTRADA EMPAQUETADOS */
/*********************************************************************/
L
256
L
257
258 MPI_Datatype pMPI_Tipo_Datos ) {
259
260 MPI_Datatype t i p o s [ 2 ] ;
261 int longitudes [ 2 ] ;
262 MPI_Aint d i r e c c [ 3 ] ;
263 MPI_Aint desplaz [ 2 ] ;
264
265
266 /*PRIMERO ESPECIFICAMOS LOS TIPOS*/
267 t i p o s [ 0 ] =MPI_LONG_DOUBLE;
268 t i p o s [ 1 ] =MPI_LONG;
269
270 /*ESPECIFICAMOS EL NUMERO DE ELEMENTOS DE CADA TIPO*/
271 longitudes [0]=1;
273
274 /*CALCULAMOS LOS DESPLAZAMIENTOS DE LOS MIEMBROS DE LA ESTRUCTURA
275 RELATIVOS AL COMIENZO DE DICHA ESTRUCTURA*/

MPI_Address ( pdatos ,& d i r e c c [ 0 ] ) ;
N
276
MPI_Address ( & ( pdatos >r a d i o ) , & d i r e c c [ 1 ] ) ;
N
277
MPI_Address ( & ( pdatos >n m u e s t r a s _ l o c a l ) , & d i r e c c [ 2 ] ) ;
N
278
desplaz [ 0 ] = d i r e c c [1] d i r e c c [ 0 ] ;
N
279
280 desplaz [ 1 ] = d i r e c c [2] d i r e c c [ 0 ] ;
281
282 /*CREACION TIPO DATOS DERIVADO*/
283 MPI_Type_struct ( 2 , l o n g i t u d e s , desplaz , t i p o s , pMPI_Tipo_Datos ) ;
284
285 /*CERTIFICARLO DE MANERA QUE PUEDA SER USADO*/
286 MPI_Type_commit ( pMPI_Tipo_Datos ) ;
287
288 } /*construir_tipo_derivado*/
5.6.2. Implementacin con Mensajes No Bloqueantes
Algoritmo 5.2: Clculo de reas mediante Montecarlo (No Bloqueante)
1
2 /***************************************************/
3 /*Calculo de Areas: CODIGO APROXIMACION DE AREAS */
4 /*CIRCULARES MEDIANTE MONTECARLO (NO BLOQUEANTE) */
5 /***************************************************/
6
7 /*NUMERO MAXIMO DE PROCESOS EN EJECUCION */
8 # define MAX_NUM_PROCS 128
9
14
17 long double r a d i o ;
18 long n m u e s t r a s _ l o c a l ;
20
long double MonteCarlo ( i n t i d , long double r a d i o , long l o c a l _ n ) ;
L L
22
void o b t e n e r _dat os ( long double p r a d i o , long pnmuestras_global ) ;
L
23
L
24
long p n m u e s t r a s _ l oc a l ) ;
L
25
L
26
long double p a p r o x _ g l o b a l ) ;
L
27
L
28
30
31 /**************/
32 /*FUNCION MAIN*/
/**************/
L8L
33
35
36 long double PI25DIGITOS=3.141592653589793238462643;
37 /*VALOR PI PARA CALCULAR EL ERROR*/
43 long double r a d i o ; /*RADIO CIRCUNFERENCIA*/
44 long n m u e s t r a s _global ; /*NUMERO DE MUESTRAS*/
45 long n m u e s t r a s _ l o c a l ; /*NUMERO DE MUESTRAS DE CADA PROCESO*/
46 long double a p r o x _ l o c a l ; /*APROX LOCAL DE CADA PROCESO*/
47 long double a p r o x _ g l o b a l ; /*APROX GENERAL (MEDIA DE TODAS LAS LOCALES)*/
48 int raiz =0; /*PROCESO QUE RECIBE LAS LOCALES Y LAS SUMA*/
51
53 MPI_Status s t a t u s ; /*STATUS RECEPCION MENSAJES DE PRUEBA*/
54 int origen ; /*PROCESO ORIGEN MENSAJES DE PRUEBA*/
55
56
59
62
65
68 i f ( i d ==0){
71 }
73 /*if(id==0){
78 * }
79 *}
80 *else{
83 *}
84 */
85
87 i f ( i d ==0){
88 o b t e n e r _dato s(& r a d i o ,& n m u e s t r a s _ global ) ;
89 /*NUMERO DE MUESTRAS PARA CADA PROCESO*/
90 n m u e s t r a s _ l o c a l=n m u e s t r a s _ global / numprocs ;

/*TRUNCAMOS NUMERO DE MUESTRAS GLOBAL*/
L
91
92 n m u e s t r a s _gl obal= n m u e s t r a s _ l o c a l numprocs ;
93 }
94
96 i f ( i d ==0){ f p r i n t f ( stdout , " \ nProcesando . . . \ n \ n " ) ; }
98
100 d i s t r i b u i r _ d a t o s ( i d , numprocs ,& r a d i o ,& n m u e s t r a s _ l o c a l ) ;
101
103 a p r o x _ l o c a l = MonteCarlo ( i d , r a d i o , n m u e s t r a s _ l o c a l ) ;
104
105 /*RECOLECTAMOS AREAS CALCULADAS POR LOS PROCESOS Y HACEMOS LA MEDIA*/
106 r e c o l e c t a r _ d a t o s ( i d , numprocs ,& a p r o x _ l o c a l ,& a p r o x _ g l o b a l ) ;
107
110
112 i f ( i d ==0){
113 f p r i n t f ( s t d o u t , " Con n= %d m u e s t r a s , l a e s t i m a c i o n d e l a r e a de l a \ n " ,
114 n m u e s t r a s _global ) ;
115 f p r i n t f ( s t d o u t , " de l a c i r c u n f e r e n c i a con r a d i o %Lf e s \ n " , r a d i o ) ;
116 f p r i n t f ( s t d o u t , " %.60 Lf \ n " , a p r o x _ g l o b a l ) ;
f p r i n t f ( s t d o u t , " E r r o r < %f \ n \ n " ,
L L N
117
118 f a b s ( PI25DIGITOS r a d i o r a d i o a p r o x _ g l o b a l ) ) ;
N
119
121 }
122
125
126 } /*main*/
127
128
129 /***************************************************************/
130 /*FUNCION obtener_datos:PROCESO 0 CONSULTA AL USUARIO EL RADIO */
131 /*DE LA CIRCUNFERENCIA Y EL NUMERO DE MUESTRAS GLOBAL */
/***************************************************************/
L L
132
133 void o b t e n e r _dat os ( long double p r a d i o , long pnmuestras_global ) {
134
136
137 f p r i n t f ( s t d o u t , " I n t r o d u z c a r a d i o de l a c i r c u n f e r e n c i a \ n " ) ;
138 s c a n f ( " %Lf " , p r a d i o ) ;
139 f p r i n t f ( s t d o u t , " I n t r o d u z c a numero de m u e s t r a s \ n " ) ;
140 s c a n f ( " %l d " , pnmuestras_global ) ;
141
142
144 /**pradio=1.0;*pnmuestras_global=200000000;*/
145
147
148
149 /**********************************************************************/
150 /*FUNCION distribuir_datos:PROCESO 0 DISTIBUYE RADIO DE LA */
151 /*CIRCUNFERENCIA Y EL NUMERO DE MUESTRAS (n) ENTRE LOS DEMAS PROCESOS */
/**********************************************************************/
L
152
L
153
154 long p n m u e s t r a s _ l oc a l ) {
155
158 int origen =0; /*PROCESO ORIGEN MENSAJES*/
159 int destino ; /*PROCESO DESTINO DATOS*/
161 MPI_Request r e q u e s t ; /*PETICION MENSAJES NO BLOQUEANTES*/
162 MPI_Status s t a t u s ; /*STATUS RECEPCION*/
163
165
166 i f ( i d ==0){
/*ENVIO DE LOS DATOS*/
L
167
d a t o s _ e n trada . r a d i o = p r a d i o ;
L
168
169 d a t o s _ e n trada . n m u e s t r a s _ l o c a l = p n m u e s t r a s _ l o c al ;
170 f o r ( d e s t i n o =1; d e s t i n o <numprocs ; d e s t i n o + + ) {
171 e t i q u e t a =30;
172 MPI_Isend(& d a t o s _ e ntr ada , 1 , MPI_Tipo_Datos_Entrada , d e s t i n o , e t i q u e t a ,
173 MPI_COMM_WORLD,& r e q u e s t ) ;
174 }
175 }
176 else {
177 /*RECEPCION DE LOS DATOS*/
178 e t i q u e t a =30;
179 MPI_Irecv (& d a t o s _ e n trada , 1 , MPI_Tipo_Datos_Entrada , o r i g e n , e t i q u e t a ,
MPI_Wait(& r e q u e s t ,& s t a t u s ) ;
L
181
p r a d i o= d a t o s _ e ntr ada . r a d i o ;
L
182
183 p n m u e s t r a s _ l o c al= d a t o s _ e n trada . n m u e s t r a s _ l o c a l ;
184 }
186
187
188 /************************************************************************/
189 /*FUNCION MonteCarlo: RETORNA EL AREA DE LA CIRCUNFERENCIA CON RADIO */
190 /*radio UTILIZANDO EL NUM.MUESTRAS nummuestras MEDIANTE MONTECARLO */
191 /************************************************************************/
192 long double MonteCarlo ( i n t i d , long double r a d i o , long nummuestras ) {
193
194 long double p i ; /*VBLE QUE ALMACENA NUMERO PI*/
195 long double area ; /*AREA CIRCUNFERENCIA*/
196 long double x ; /*EJE ORDENADAS MUESTRA ACTUAL*/
197 long double y ; /*EJE COORDENADAS MUESTRA ACTUAL*/
198 long double h i p ; /*HIPOTENUSA MUESTRA ACTUAL*/
199 long aciertos =0; /*NUM.MUESTRAS QUE CAEN DENTRO DE LA CIRCUNFERENCIA*/
200 long f a l l o s = 1 ; /*NUM.MUESTRAS QUE CAEN FUERA DE LA CIRCUNFERENCIA*/

201 long i ; /*CONTADOR*/
202
203
205 srand ( i d ) ;
206
207 /*ESTIMACION DE PI*/
208 f o r ( i =0; i ! = nummuestras ; i + + ) {
209 x =( long double ) rand ( ) / RAND_MAX;
210 y =( long double ) rand ( ) / RAND_MAX;
211 h i p = s q r t ( pow ( x , 2 ) +pow ( y , 2 ) ) ;
212 i f ( hip >1){ f a l l o s ++;}
213 else { a c i e r t o s + + ; }
}
L
214
215 p i = 4 . 0 ( ( long double ) a c i e r t o s / nummuestras ) ;
216
/*CALCULAMOS AREA*/
L
217
218 area=pow ( r a d i o , 2 ) p i ;
219
220 r e t u r n area ;
221
222 } /*MonteCarlo*/
223
224
225 /*********************************************************************/
226 /*FUNCION recolectar_datos:PROCESO 0 HACE LA MEDIA DE LAS */
227 /*APROXIMACIONES LOCALES */
/*********************************************************************/
L
228
L
229
230 long double p a p r o x _ g l o b a l ) {
231
232 int origen ; /*PROCESO ORIGEN MENSAJES*/
233 int destino =0; /*PROCESO DESTINO DATOS*/
235 long double b u f f e r ; /*BUFFER RECEPCION APROXIMACIONES LOCALES*/
236 int i ; /*CONTADOR*/
237 MPI_Request r e q u e s t ;
238 MPI_Request r e q u e s t s [MAX_NUM_PROCS ] ;
239 MPI_Status s t a t u s ;
240
241
i f ( i d ==0){
L L
242
243 paprox_global= paprox_local ;
244 /*MANDAMOS LAS PETICIONES DE DATOS*/
246 e t i q u e t a =30+ o r i g e n ;
247 MPI_Irecv (& b u f f e r , 1 , MPI_LONG_DOUBLE, o r i g e n , e t i q u e t a ,
248 MPI_COMM_WORLD,& r e q u e s t s [ o r i g e n ] ) ;
249 }
250 /*RECOLECTAMOS LOS CALCULOS LOCALES Y HACEMOS LA MEDIA*/
251 f o r ( i =1; i <numprocs ; i + + ) {
MPI_Waitany ( numprocs , r e q u e s t s ,& o r i g e n ,& s t a t u s ) ;
L L
252
253 p a p r o x _ g l o b a l =( p a p r o x _ g l o b a l+ b u f f e r ) / 2 . 0 ;
254 }
255 }
256 else {
258 e t i q u e t a =30+ i d ;
259 MPI_Isend ( p a p r o x _ l o c a l , 1 , MPI_LONG_DOUBLE , d e s t i n o , e t i q u e t a ,
261 }
263
264
265 /*********************************************************************/
/*********************************************************************/
L
268
L
269
271
276
277
280 t i p o s [ 1 ] =MPI_LONG;
281
285
N
288
MPI_Address ( & ( pdatos >r a d i o ) , & d i r e c c [ 1 ] ) ;
N
289
MPI_Address ( & ( pdatos >n m u e s t r a s _ l o c a l ) , & d i r e c c [ 2 ] ) ;
N
290
N
291
293
296
299
Captulo 6
Comunicacin Colectiva
Las operaciones de comunicacin colectiva son aquellas que se aplican al mismo tiempo
a todos los procesos pertenecientes a un comunicador. Tienen una gran importancia en el
estndar MPI, debido a la claridad de su sintaxis y a su eficiencia. Para analizar su utilidad y
conveniencia implementaremos el algoritmo Regla del Trapecio de manera que haga un uso
inteligente de dichas operaciones.
6.1. Algoritmo Regla del Trapecio

La regla del trapecio estima Z\ [] ^ ,.T_3a`5T mediante la divisin del intervalo b cE Jcd en seg-
mentos iguales, calculando la siguiente suma:

V b ^ ,.T 3 $)( W ^ ,.T 3$)( W 7Mf e ^ ,.T g 3d

7 gih
V g Wlk V k
Donde ,QJj/ 3 $& , y T , FD EBGBGBG4E .
Una manera de realizar este clculo mediante un algoritmo paralelo es dividir el interva-
lo b EcJcd entre los procesos haciendo que cada proceso calcule la integral de ^ ,.T\3 sobre su
subintervalo. Para estimar la integral completa se suman los clculos locales de cada proceso.
Supongamos que tenemos C procesos y segmentos, y, para simplificar, supongamos que
es divisible entre C . En este caso es natural que el primer proceso calcule la integral de los
primeros '$cC segmentos, el segundo proceso calcular el rea de los siguientes '$cC segmentos,
etc. Siguiendo esta regla el proceso m estimar la integral del subintervalo:
b
W m V E W ,Hm W 41 3 V d
C C
Cada proceso necesita la siguiente informacin:
El nmero de procesos C
Su identificador

El intervalo de integracin completo b cE Jcd
93
94 CAPTULO 6. COMUNICACIN COLECTIVA
El nmero de segmentos
La funcin ^ ,.T\3 a integrar
Los dos primeros datos se pueden conseguir llamando a las funciones MPI_Comm_size() y
MPI_Comm_rank(). Sin embargo tanto el intervalo b EcJcd como el nmero de segmentos
deben ser introducidos por el usuario. Por otro lado sera positivo que el usuario pudiera elegir
la funcin ^ ,.T_3 a integrar (dentro de un conjunto predefinido de funciones). Como explicamos
en la seccin 4.4 slo un proceso (normalmente el proceso 0) debe encargarse de obtener
los datos de la entrada estndar y distribuirlos entre los dems procesos. sto puede hacerse
mediante paso de mensajes o mediante comunicacin colectiva, siendo la segunda opcin ms
eficiente. En la seccin 6.2 se explica el uso de las operaciones de comunicacin colectiva con
dicho propsito.
Por otro lado una buena forma de sumar los clculos individuales de los procesos es hacer
que cada proceso enve su clculo local al proceso 0, y que el proceso 0 haga la suma final. De
nuevo podemos emplear al menos dos tcnicas: paso de mensajes y operaciones de reduccin.
Dado que las operaciones de reduccin son ms eficientes, utilizaremos la segunda opcin.
Las funciones que ofreceremos al usuario estarn codificadas en funciones de cdigo C,
por lo que tendremos que modificar el cdigo y compilarlo de nuevo para introducir nuevas
funciones. Entre las funciones ofrecidas incluiremos al menos las siguientes:
^ ,.T_3 (@T

^ ,.T_3 T
^ ,.T_3 n
^ ,.T_3 o
qp n4rs

P

Esta ltima
P
funcin nos permite realizar la bsqueda del nmero . El rea bajo la curva
U
qp n r nos proporciona un mtodo para computar :
t
WR v
R )
u y
w
x
z "
u {

SR P P
M
` T b .
, \
T
3 d , R 0
/ M
D 3
,1 T 3
Por lo tanto tenemos que para computar
P mediante la regla del trapecio utilizaremos
q

p
^ ,.T\3 o n r s , D y J 1 .
6.2. Distribucin y Recoleccin de los Datos

La distribucin y recoleccin de los datos se puede realizar mediante dos tcnicas: paso de
mensajes (como hicimos en el algoritmo Clculo de reas mediante Montecarlo) y comuni-
cacin colectiva. Las operaciones de comunicacin colectiva son ms eficientes debido a que
reducen el tiempo empleado en dichas operaciones, reduciendo el nmero de pasos necesarios
para su ejecucin.
En la tcnica de paso de mensajes el problema radica en que cargamos a un proceso con
demasiado trabajo. Al utilizar esta tcnica para distribuir los datos damos bsicamente los
siguientes pasos:
6.2. DISTRIBUCIN Y RECOLECCIN DE LOS DATOS 95
0 4
0 2 4 6
0 1 2 3 4 5 6 7
Figura 6.1: Procesos estructurados en rbol
1. Proceso 0 recoge los datos de la entrada estndar

2. Proceso 0 enva un mensaje a cada uno de los restantes procesos comunicndole los
datos de entrada
Si utilizamos un bucle para realizar el segundo paso, los procesos con identificador mayor
deben continuar esperando mientras el proceso 0 enva los datos de entrada a los procesos con
identificador menor. ste no es slo un asunto de E/S y por supuesto no es un comportamiento
deseable: el punto principal del procesamiento paralelo es conseguir que mltiples procesos
colaboren para resolver un problema. Si uno de los procesos est haciendo la mayora del
trabajo, podramos usar mejor una mquina convencional de un solo procesador.
Por otro lado observamos que existe una ineficiencia similar en el final del algoritmo al
utilizar paso de mensajes en el proceso de recoleccin, donde el proceso 0 hace todo el trabajo
de recolectar y sumar las integrales locales.
La pregunta que surge es... cmo podemos dividir el trabajo ms equitativamente entre los
procesos? Una solucin natural es imaginar que tenemos un rbol de procesos, con el proceso
0 como raz.
Durante la primera etapa de la distribucin de los datos pongamos que el proceso 0 enva
los datos al 4. Durante la siguiente etapa el 0 enva los datos al 2, mientras que el 4 los enva
al 6. Durante la ltima etapa el 0 se los enva al 1, mientras el 2 los enva al 3, el 4 al 5 y el
6 al 7 (mirar la figura 6.1). As reducimos el bucle de distribucin de la entrada de 7 etapas a
3 etapas. De manera ms general, si tenemos C procesos este procedimiento permite distribuir

los datos de entrada en "! ,|C\3 etapas, mientras que de la anterior manera lo haciamos en
,|C}/~143 etapas. Si C es grande esta mejora es una gran ventaja.

Si queremos utilizar un esquema de distribucin estructurado en rbol en nuestro algorit-
mo, necesitamos introducir un bucle con i"! ,|C\3 etapas. En la implementacin de dicho bucle
cada proceso necesita calcular en cada etapa:
Si recibe, y en caso de hacerlo, el origen; y
Si enva, y en caso de hacerlo, el destino
Como puede suponerse estos clculos pueden ser algo complicados, especialmente porque no
hay un ordenamiento fijo. En nuestro ejemplo elegimos:
1. 0 enva al 4
2. 0 enva al 2, 4 al 6
3. 0 enva al 1, 2 al 3, 4 al 5, 6 al 7
Aunque podramos haber elegido tambin:
1. 0 enva al 1
2. 0 enva al 2, 1 al 3
3. 0 enva al 4, 1 al 5, 2 al 6, 3 al 7
De hecho, a menos que sepamos algo acerca de la topologa subyacente de nuestra mquina
no podremos decidir realmente qu esquema es mejor.
Lo ideal sera usar una funcin diseada especficamente para la mquina que estemos
usando de manera que no nos tengamos que preocupar acerca de todos los detalles, y que no
tengamos que modificar el cdigo cada vez que cambiamos de mquina. Y como habr podido
adivinar MPI proporciona dicha funcin.
6.3. Operaciones de Comunicacin Colectiva

Un patrn de comunicacin que engloba a todos los procesos de un comunicador es una
comunicacin colectiva. Como consecuencia una comunicacin colectiva implica a ms de dos
procesos. Un broadcast es una operacin de comunicacin colectiva en donde un proceso enva
un mismo mensaje a todos los procesos. En MPI la funcin para hacer sto es MPI_Bcast():
int MPI_Bcast(void* mensaje, int contador,

MPI_Datatype tipo_datos, int raiz,
MPI_Comm com);
La funcin enva una copia de los datos contenidos en mensaje por el proceso raiz a cada pro-
ceso perteneciente al comunicador com. Debe ser llamada por todos los procesos pertenecientes
al comunicador con los mismos argumentos para raiz y com. Por lo tanto un mensaje broad-
cast no puede ser recibido con la funcin MPI_Recv(). Los parmetros contador y tipo_datos
tienen la misma finalidad que en MPI_Send() y MPI_Recv(): especifican la extensin del
mensaje. Sin embargo, al contrario que en las funciones punto a punto, MPI insiste en que en
las operaciones de comunicacin colectiva contador y tipo_datos deben ser iguales en todos
los procesos pertenecientes al comunicador. La razn de sto es que en algunas operaciones
colectivas un nico proceso recibe datos de otros muchos procesos, y para que el programa
determine qu cantidad de datos han sido recibidos necesitara un vector de status de retorno.
6.4. OPERACIONES DE REDUCCIN 97
6.4. Operaciones de Reduccin

En el algoritmo Regla del Trapecio, tras la fase de introduccin de datos, todos los proce-
sadores ejecutan esencialmente las mismas instrucciones hasta el final de la fase de suma. De
este modo, a menos que la funcin ^ ,.T_3 sea muy complicada (p.ej. que requiera ms trabajo
ser evaluada en ciertas zonas del intervalo b EcJcd ), esta parte del programa distribuye el trabajo
equitativamente entre los procesos. Como hemos dicho antes, ste no es el caso en la fase de
suma final en donde si utilizamos paso de mensajes el proceso 0 realiza una cantidad de tra-
bajo desproporcionada. Sin embargo probablemente se haya dado cuenta que invirtiendo las
flechas de la figura 6.1 podemos usar la comunicacin estructurada en rbol. De esta manera
podemos distribuir el trabajo de calcular la suma entre los procesos como sigue:
1. (a) 1 enva al 0, 3 al 2, 5 al 4, 7 al 6
(b) 0 suma su integral a la recibida de 1, 2 suma su integral a la recibida de 3, etc.
2. (a) 2 enva al 0, 6 al 4
(b) 0 suma, 4 suma
3. (a) 4 enva al 0
(b) 0 suma
Por supuesto caemos en la misma cuestin que cuando discutiamos la implementacin de nue-
stro propio broadcast: Hace un uso ptimo de la topologa de nuestra mquina esta estructura
en rbol? Una vez ms debemos responder que ello depende de la mquina. As que, como
antes, debemos dejar a MPI hacer dicho trabajo utilizando una funcin optimizada.
La suma global que queremos calcular es un ejemplo de una clase general de operaciones
de comunicacin colectiva llamadas operationes de reduccin. Las operaciones de reduccin
forman un subconjunto de las operaciones de comunicacin colectiva. En una operacin de re-
duccin global todos los procesos (pertenecientes a un comunicador) aportan datos, los cuales
se combinan usando una operacin binaria. Las operaciones binarias tpicas son la suma, el
mximo, el mnimo, AND lgico, etc. La funcin MPI que implementa una operacin de re-
duccin es:
int MPI_Reduce(void* operando, void* resultado,

int contador, MPI_Datatype tipo_datos,
MPI_Op operacion, int raiz,
MPI_Comm comunicador);
La funcin MPI_Reduce combina los operandos referenciados por operando usando la op-
eracin sealada por operacion y almacena el resultado en la variable resultado perteneciente
al proceso raiz. Tanto operando como resultado referencian contador posiciones de memo-
ria del tipo tipo_datos. MPI_Reduce() debe ser llamado por todos los procesos pertenecientes
a comunicador; adems contador, tipo_datos y operacion deben ser iguales para todos los
procesos.
El argumento operacion puede adquirir uno de los valores predefinidos mostrados en el
cuadro 6.1. Tambin es posible definir operaciones adicionales.
Nombre de Operacin Significado

MPI_MAX Mximo
MPI_MIN Mnimo
MPI_SUM Suma
MPI_PROD Producto
MPI_LAND AND Lgico
MPI_BAND AND Bit a Bit
MPI_LOR OR Lgico
MPI_BOR OR Bit a Bit
MPI_LXOR OR Exclusivo Lgico
MPI_BXOR OR Exclusivo Bit a Bit
MPI_MAXLOC Mximo y su Localizacin
MPI_MINLOC Mnimo y su Localizacin
Cuadro 6.1: Operaciones de Reduccin
6.5. Implementacin Regla del Trapecio

A continuacin exponemos la implementacin del algoritmo Regla del Trapecio. Notar que
cada proceso llama a MPI_Reduce() con los mismos argumentos; de hecho, aunque la variable
que almacena la suma global slo tiene significado para el proceso 0, todos los procesos deben
suministrar un argumento.
Algoritmo 6.1: Regla del Trapecio
1
2 /********************************************************/
3 /*Regla del Trapecio: CODIGO APROXIMACION DE INTEGRALES */
4 /*MEDIANTE LA REGLA DEL TRAPECIO */
5 /********************************************************/
6
9
12 long double a ;
13 long double b ;
14 long nsegmentos ;
15 i n t nfuncion ;
17
19 long double T r a p e c i o ( long double l o c a l _ a , long double l o c a l _ b , long l o c a l _ n ,
20 long double h , i n t numfuncion ) ;
21 long double F1 ( long double x ) ;
6.5. IMPLEMENTACIN REGLA DEL TRAPECIO 99
long double F4 ( long double x ) ;

L L
24
void o b t e n e r _dat os ( i n t i d , long double pa , long double pb ,
L L
25
long pn , i n t pnumfuncion ) ;
L L
26
void d i s t r i b u i r _ d a t o s ( i n t i d , long double pa , long double pb ,
L L
27
long pn , i n t pnumfuncion ) ;
L
28
void r e c o l e c t a r _ d a t o s ( i n t i d , i n t numprocs , long double p p a r c i a l ,
L
29
long double pcompleta ) ;
L
30
L
31
33
34 /**************/
35 /*FUNCION MAIN*/
/**************/
LML
36
38
39 long double a ; /*COMIENZO DEL INTERVALO GENERAL*/
40 long double b ; /*FINAL DEL INTERVALO GENERAL*/
41 long n ; /*NUMERO DE SEGMENTOS EN TOTAL*/
42
48 long double h ; /*ANCHO DE CADA SEGMENTO*/
49 long double l o c a l _ a ; /*COMIENZO DEL SUBINTERVALO DE CADA PROCESO*/
50 long double l o c a l _ b ; /*FINAL DEL SUBINTERVALO DE CADA PROCESO*/
51 long l o c a l _ n ; /*NUMERO DE SEGMENTOS PARA CADA PROCESO*/
52 long double p a r c i a l ; /*INTEGRAL PARCIAL DE CADA PROCESO*/
53 long double completa ; /*INTEGRAL COMPLETA (SUMA DE TODAS LAS PARCIALES)*/
55 double t m p f i n ; /*TIEMPO FINAL DE LA EJECUCION*/
56 i n t numfuncion ; /*NUMERO DE FUNCION A UTILIZAR*/
57 i n t e t i q u e t a =50;
58 MPI_Status s t a t u s ;
59 int origen ;
60
61
62 /*INICIALIZAMOS EL ENTORNO DE EJECUCION MPI*/
64
67
70
73 i f ( i d ==0){
76 }
77 /*E/S:NOMBRE DEL PROCESADOR,TODOS LOS PROCESOS (PARA PRUEBAS)*/
78 /*if(id==0){
83 * }
84 *}
85 *else{
88 *}
89 */
90
92 o b t e n e r _d atos ( i d ,& a,& b ,& n,& numfuncion ) ;
93
95 i f ( i d ==0){ f p r i n t f ( stdout , " \ nProcesando . . . \ n \ n " ) ; }
97
99 d i s t r i b u i r _ d a t o s ( i d ,& a ,& b,& n ,& numfuncion ) ;
100
101 /*SI NUMSEGMENTOS/NUMPROCS NO ES DIVISION ENTERA NUMSEGMENTOS SE TRUNCA*/
l o c a l _ n=n / numprocs ; /*NUMERO DE SEGMENTOS PARA CADA PROCESO*/
L
102
n= l o c a l _ n numprocs ; /*NUMERO DE SEGMENTOS EN TOTAL (TRUNCADO)*/
N
103
104 h =( b a ) / n ; /*ANCHO DE SEGMENTO.SIMILAR PARA TODOS LOS PROCESOS*/
105
106 /*EL SUBINTERVALO DEL PROCESO TENDRA UN ANCHO DE local_n*h Y ESTARA
COMPRENDIDO ENTRE local_a Y local_b*/
L L
107
local_a = a + id local_n h ;
L
108
109 local_b = local_a + local_n h ;
110
112 p a r c i a l = T r a p e c i o ( l o c a l _ a , l o c a l _ b , l o c a l _ n , h , numfuncion ) ;
113
114 /*RECOLECTAMOS INTEGRALES CALCULADAS POR LOS PROCESOS Y LAS SUMAMOS*/
115 r e c o l e c t a r _ d a t o s ( i d , numprocs ,& p a r c i a l ,& completa ) ;
116
119
121 i f ( i d ==0){
122 f p r i n t f ( s t d o u t , " Con n= %d t r a p e c i o s , l a e s t i m a c i o n de l a i n t e g r a l \ n " , n ) ;
123 f p r i n t f ( s t d o u t , " de l a f u n c i o n s e l e c c i o n a d a d e s d e " ) ;
124 f p r i n t f ( s t d o u t , " %Lf h a s t a %Lf e s \ n %.60 Lf \ n \ n " , a , b , completa ) ;
N
125
127 }
128
131
132 } /*main*/
133
134
135 /***********************************************************************/
136 /*FUNCION obtener_datos:PROCESO 0 CONSULTA AL USUARIO COMIENZO Y FINAL */
137 /*DEL INTERVALO [a,b] Y EL NUMERO DE SEGMENTOS (n) */
/***********************************************************************/
L L
138
void o b t e n e r _dat os ( i n t i d , long double pa , long double pb ,
L L
139
140 long pn , i n t pnumfuncion ) {
141
143
144 i f ( i d ==0){
145 f p r i n t f ( s t d o u t , " \ n I n t r o d u z c a num . de l a f u n c i o n a i n t e g r a r \ n " ) ;
146 f p r i n t f ( s t d o u t , " \ nF1 =2 x F2=x^2 F3 = 1 / x F4 = 4 / ( 1 + x ^ 2 ) \ nF " ) ;
s c a n f ( " %d " , pnumfuncion ) ;
L L
147
148 i f ( pnumfuncion < 1 | | pnumfuncion > 4 ) {
f p r i n t f ( s t d o u t , " E r r o r en l a e n t r a d a , u t i l i z a n d o f u n c i o n F1=2 x \ n " ) ;
L
149
150 pnumfuncion =1;
151 }
152 f p r i n t f ( s t d o u t , " I n t r o d u z c a un v a l o r p a r a a ( i n i c i o d e l i n t e r v a l o ) \ n " ) ;
153 s c a n f ( " %Lf " , pa ) ;
154 f p r i n t f ( s t d o u t , " I n t r o d u z c a un v a l o r p a r a b ( f i n a l d e l i n t e r v a l o ) \ n " ) ;
155 s c a n f ( " %Lf " , pb ) ;
156 f p r i n t f ( s t d o u t , " I n t r o d u z c a numero de s e g m e n t o s \ n " ) ;
157 s c a n f ( " %l d " , pn ) ;
158 }
159
160
162 /*if(id==0){*pa=0;*pb=1;*pn=1000000000;*pnumfuncion=4;}*/
163
165
166
167 /**************************************************************************/
168 /*FUNCION distribuir_datos:PROCESO 0 DISTIBUYE COMIENZO Y FINAL DEL */
169 /*INTERVALO [a,b] Y EL NUMERO DE SEGMENTOS (n) ENTRE LOS DEMAS PROCESOS */
/**************************************************************************/
L L
170
void d i s t r i b u i r _ d a t o s ( i n t i d , long double pa , long double pb ,
L L
171
172 long pn , i n t pnumfuncion ) {
173
176 int raiz =0; /*PROCESO QUE ENVIA LOS DATOS A LOS DEMAS PROCESOS*/
177
178
179 /*CONSTRUIMOS EL TIPO MPI PARA EMPAQUETAR LOS DATOS DE ENTRADA*/
181
182 i f ( i d ==0){
/*EMPAQUETADO DE DATOS*/
L
183
d a t o s _ e n trada . a= pa ;
L
184
d a t o s _ e n trada . b= pb ;
L
185
d a t o s _ e n trada . nsegmentos= pn ;
L
186
187 d a t o s _ e n trada . n f u n c i o n = pnumfuncion ;
188 }
189
190 MPI_Bcast (& d a t o s _ e ntr ada , 1 , MPI_Tipo_Datos_Entrada , r a i z ,MPI_COMM_WORLD ) ;
191
192 if ( id !=0){
/*RECOGIDA DE DATOS*/
L
193
pa=d a t o s _ e n tra da . a ;
L
194
pb=d a t o s _ e n tra da . b ;
L
195
pn=d a t o s _ e n tra da . nsegmentos ;
L
196
197 pnumfuncion= d a t o s _ e nt rada . n f u n c i o n ;
198 }
199
201
202
203 /************************************************************************/
204 /*FUNCION Trapecio:FUNCION QUE APLICA LA REGLA DEL TRAPECIO AL */
205 /*SUBINTERVALO COMPRENDIDO ENTRE local_a Y local_b, CON UN NUMERO DE */
206 /*SEGMENTOS local_n Y UN TAMAO DE SEGMENTO h */
207 /************************************************************************/
208 long double T r a p e c i o ( long double l o c a l _ a , long double l o c a l _ b , long l o c a l _ n ,
209 long double h , i n t numfuncion ) {
L
210
211 long double ( f ) ( long double ) ; /*VBLE QUE ALMACENA FUNCION A INTEGRAR*/
212 long double i n t e g r a l ; /*VBLE QUE ALMACENA EL RESULTADO*/
213 long double x ; /*POSICION EN EL EJE X*/
215
216 switch ( numfuncion ) {
217 case 1 : f =F1 ; break ;
218 case 2 : f =F2 ; break ;
219 case 3 : f =F3 ; break ;
220 case 4 : f =F4 ; break ;
221 }
222 i n t e g r a l =( f ( l o c a l _ a )+ f ( l o c a l _ b ) ) / 2 . 0 ;
x= l o c a l _ a ;
N
223
224 f o r ( i =1; i <= l o c a l _ n 1; i + + ) {
225 x+=h ;
226 i n t e g r a l += f ( x ) ;
}
L
227
228 i n t e g r a l =h ;
229 return i n t e g r a l ;
230
231 } /*Trapecio*/
232
233
234 /*******************************************************************/
235 /*FUNCION recolectar_datos:PROCESO 0 SUMA LAS INTEGRALES PARCIALES */
236 /*CALCULADAS POR LOS DEMAS PROCESOS. */
/*******************************************************************/
L
237
void r e c o l e c t a r _ d a t o s ( i n t i d , i n t numprocs , long double p p a r c i a l ,
L
238
239 long double pcompleta ) {
240
241 int raiz =0; /*PROCESO QUE RECIBE LAS PARCIALES Y LAS SUMA*/
242
243 /*SUMAMOS LAS INTEGRALES PARCIALES CALCULADAS POR CADA PROCESO*/
244 MPI_Reduce ( p p a r c i a l , pcompleta , 1 , MPI_LONG_DOUBLE, MPI_SUM, 0 ,MPI_COMM_WORLD ) ;

245
246 } /*recolectar_datos*/
247
248
249 /********************************/
250 /*FUNCION F1(x):FUNCION f(x)=2x */
251 /********************************/
252 long double F1 ( long double x ) {
253 long double v a l o r _ r e t o r n o ;
L
254
255 v a l o r _ r e t o r n o =2 x ;
256 return valor_retorno ;
257 }
258
259
260 /*********************************/
261 /*FUNCION F2(x):FUNCION f(x)=x^2 */
262 /*********************************/
L
265
266 v a l o r _ r e t o r n o =x x ;
268 }
269
270 /*********************************/
271 /*FUNCION F3(x):FUNCION f(x)=1/x */
272 /*********************************/
275
276 v a l o r _ r e t o r n o =1/ x ;
278 }
279
280 /***************************************/
281 /*FUNCION F4(x):FUNCION f(x)=4/(1+x^2) */
282 /***************************************/
L
285
286 valor_retorno =4/(1+x x ) ;
288 }
289
290
291 /*********************************************************************/
/*********************************************************************/
L
294
L
295
297

302
303
307 t i p o s [ 2 ] =MPI_LONG ;
308 t i p o s [ 3 ] = MPI_INT ;
309
315
N
318
MPI_Address ( & ( pdatos >a ) , & d i r e c c [ 1 ] ) ;
N
319
MPI_Address ( & ( pdatos >b ) , & d i r e c c [ 2 ] ) ;
N
320
MPI_Address ( & ( pdatos >nsegmentos ) , & d i r e c c [ 3 ] ) ;
N
321
MPI_Address ( & ( pdatos >n f u n c i o n ) , & d i r e c c [ 4 ] ) ;
N
322
N
323
N
324
N
325
327
330
333
Captulo 7
Comunicadores y Topologas
El uso de comunicadores y topologas hace a MPI diferente de la mayora de los dems

sistemas de paso de mensajes. En pocas palabras, un comunicador es una coleccin de proce-
sos que pueden mandarse mensajes entre ellos. Una topologa es una estructura impuesta en
los procesos de un comunicador que permite a los procesos ser direccionados de diferentes
maneras. Para ilustrar estas ideas desarrollaremos el cdigo que implementa el algoritmo de
Fox para multiplicar dos matrices cuadradas.
7.1. Algoritmo Multiplicacin de Matrices de Fox

Asumimos que las matrices principales , g 3 y Y ,QJ g 3 tienen orden . Tambin
asumimos que el nmero de procesos C es un cuadrado perfecto, cuya raiz m es tal que el
resultado de '$@m es un entero. Digamos que C
m , y que '$@m . En el algoritmo de
Fox las matrices principales son particionadas en bloques y repartidas entre los procesos. As
vemos nuestros procesos como una tabla virtual de mIm elementos, donde a cada proceso se
le asigna una submatriz de cada una de las matrices principales. De manera ms formal,
-
tenemos la siguiente correspondencia:
DFE:1)EBG G G EHC/1@/ ,Q=ME3 D~=ME~m/~1@
k
La siguiente afirmacink define nuestra tabla de procesos: el proceso pertenece

a la fila
y la columna dadas por , 3 . Adems diremos que el proceso con direccin e ,Q=5E3 tiene
asignadas las submatrices:
q o qp'

7. 7 BB s 78e 7
.
a o p'..

o ap'

.. o p'

c
7 s 7e B B s 7e s 7Fe
J q 7 7 B
B
J o qp'
s 7e
7

Y .. ..

J o p'
s
a oJ ap'
s
o p'
s
c
. .
7 7e B B 7 e 7e
105
106 CAPTULO 7. COMUNICADORES Y TOPOLOGAS
0

Proceso 1
Proceso
2

Proceso

3

Proceso 4
Proceso
5

Proceso

6

Proceso 7
Proceso
8

Proceso

7.1: Particin Matriz 6*6 en 9 Procesos

Cuadro
Por ejemplo, si C

, ,.T_3

,.T_$)ET5 53 y 9 entonces la matriz estara
particionada como se indica en el cuadro 7.1.
En el algoritmo de Fox las
submatrices
y Y , = DFE:1)EBGBGBG4Em/+1 son multiplicadas y
acumuladas por el proceso e ,.O@E3 .
Algoritmo bsico
Desde paso=0 hasta paso=q-1(aumentar paso en cada iteracin):
1. Elegir una submatriz de A de cada una de las filas de procesos. La submatriz elegida

en la fila ser q
, donde
8":&
2. En cada una de las filas de procesos hacer un broadcast de la submatriz elegida hacia
los dems procesos en dicha fila.
3. En cada proceso multiplicar la submatriz recibida de A por la matriz de B que reside

en dicho proceso, sin modificar ninguna de estas matrices. Sumar el resultado de la
multiplicacin al valor que contiene el proceso en la matriz resultado C.
4. En cada proceso enviar la submatriz de B al proceso que est encima de l (los proce-
sos de la primera fila enviarn la submatriz a la ltima fila).
7.2. Comunicadores
Si intentamos implementar el algoritmo de Fox, parece claro que nuestro trabajo se facil-
itara si pudiramos tratar ciertos subconjuntos de procesos como el universo de la comuni-
cacin, al menos temporalmente. Por ejemplo, en el pseudocdigo
2. En cada una de las filas de procesos hacer un broadcast de la submatriz elegida hacia
los dems procesos en dicha fila.
7.3. TRABAJANDO CON GRUPOS, CONTEXTOS Y COMUNICADORES 107
sera til tratar cada fila como el universo de la comunicacin, as como en la sentencia
4. En cada proceso enviar la submatriz de B al proceso que est encima de l (los proce-
sos de la primera fila enviarn la submatriz a la ltima fila).
sera til tratar cada columna de procesos como el universo de la comunicacin.

El mecanismo que MPI proporciona para tratar a un subconjunto de procesos como el uni-
verso de la comunicacin son los comunicadores. Hasta ahora hemos definido al comunicador
como una coleccin de procesos que pueden mandarse mensajes entre ellos. Ahora que quer-
emos construir nuestros propios comunicadores necesitaremos una discusin ms profunda.
En MPI existen dos tipos de comunicadores: intracomunicadores e intercomunicadores.
Los intracomunicadores son esencialmente una coleccin de procesos que pueden mandarse
mensajes entre ellos y utilizar operaciones de comunicacin colectivas. Por ejemplo,
MPI_COMM_WORLD es un intracomunicador, y queremos formar para cada fila y cada
columna del algoritmo de Fox otro intracomunicador. Los intercomunicadores, como su pro-
pio nombre indica, son utilizados para mandar mensajes entre los procesos pertenecientes a
intracomunicadores disjuntos. Por ejemplo, un intercomunicador podra ser til en un entorno
que nos permitiera crear procesos dinmicamente: un nuevo conjunto de procesos que for-
men un intracomunicador podra ser enlazado al conjunto de procesos original (por ejemplo
MPI_COMM_WORLD) mediante un intercomunicador. Nosotros slo utilizaremos intraco-
municadores.
Un intracomunicador mnimo est compuesto de:
Un Grupo, y
Un Contexto.
Un grupo es una coleccin ordenada de procesos. Si un grupo consiste en C procesos, a cada

proceso en el grupo se le asigna un nico identificador, que no es ms que un entero no negativo
en el rango DFE:1)EBGBGBG@EHC/1 . Un contexto puede ser entendido como una etiqueta definida por
el sistema que es atribuida al grupo. De este modo dos procesos que pertenecen al mismo
grupo y usan el mismo contexto pueden comunicarse. Esta paridad grupo-contexto es la forma
ms bsica de comunicador. Otros datos pueden ser asociados al comunicador. En particular,
se le puede asociar una estructura o topologa al comunicador, permitiendo un esquema de
direccionamiento de los procesos ms natural. Abordaremos las topologas en la seccin 7.5.
7.3. Trabajando con Grupos, Contextos y Comunicadores

Para ilustrar las bases del uso de los comunicadores, vamos a crear un comunicador cuyo

C . Supongamos tambin que ,.T\3
grupo consiste en los procesos de la primera fila de nuestra tabla virtual. Supongamos que
MPI_COMM_WORLD contiene C procesos, donde m
,.T_$@m8ET5 m53 . As la primera fila de procesos consistir en los procesos cuyo identificador
es DFE:1)EBGBGBG&Em/1 (aqu los identificadores pertenecen a MPI_COMM_WORLD). Para crear
el grupo de nuestro nuevo comunicador podemos ejecutar el siguiente cdigo:
MPI_Group MPI_GROUP_WORLD;
MPI_Group grupo_primera_fila;
MPI_Comm com_primera_fila;
int tam_fila;
int* ids_procesos;
/* CREA LISTA CON LOS PROCESOS DEL NUEVO COMUNICADOR */

ids_procesos=(int*) malloc(q*sizeof(int));
for (proc=0; proc<q ; proc++)
ids_procesos[proc]=proc;
/* OBTIENE GRUPOS DEL COMUNICADOR MPI_COMM_WORLD */

MPI_Comm_group(MPI_COMM_WORLD,&MPI_GROUP_WORLD);
/* CREA EL NUEVO GRUPO */

MPI_Group_incl(MPI_GROUP_WORLD,q,ids_procesos,
&grupo_primera_fila);
/* CREA EL NUEVO COMUNICADOR */
MPI_Comm_create(MPI_COMM_WORLD,grupo_primera_fila,
&com_primera_fila)
Este cdigo construye de una manera muy estricta el nuevo comunicador. Primero crea una
lista de los procesos que debern ser asignados al nuevo comunicador. Luego crea un grupo
con dichos procesos. sto requiere dos llamadas; primero se obtiene el grupo asociado a
MPI_COMM_WORLD, dado que ste es el grupo del cual se extraen los procesos para
el nuevo grupo; luego se crea el grupo con MPI_Group_incl(). Finalmente el nuevo comuni-
cador es creado con una llamada a MPI_Comm_create(). La llamada a MPI_Comm_create()
asocia implcitamente un contexto al nuevo grupo. El resultado es el comunicador
com_primera_fila. Ahora los procesos pertenecientes a com_primera_fila pueden ejecutar
a los otros procesos del grupo grupo_primera_fila:
operaciones de comunicacin colectivas. Por ejemplo, el proceso 0 (en grupo_primera_fila)
puede hacer un broadcast de su matriz
int mi_id_en_primera_fila;
float* A_00;
/* mi_id ES EL IDENT. DEL PROCESO EN MPI_GROUP_WORLD */

if(mi_id<q){
MPI_Comm_rank(com_primera_fila,&mi_id_en_primera_fila);
/* ASIGNAMOS ESPACIO A A_00, ORDEN=n */
A_00=(float*) malloc(n*n*sizeof(float));
if(mi_id_en_primera_fila==0){
/*INICIALIZAMOS A_00 */
.
.
.
}
7.3. TRABAJANDO CON GRUPOS, CONTEXTOS Y COMUNICADORES 109
MPI_Bcast(A_00,n*n,MPI_FLOAT,0,com_primera_fila);
}
Los grupos y los comunicadores son objetos opacos. Desde un punto de vista prctico sto
significa que los detalles de su representacin interna dependen de la implementacin MPI
particular, y como consecuencia el usuario no puede acceder directamente a ellos. En vez
de esto el usuario accede a un manejador que referencia al objeto opaco, de manera que
dichos objetos opacos son manipulados por funciones MPI especiales, como por ejemplo
MPI_Comm_create(), MPI_Group_incl() y MPI_Comm_group().
Los contextos no son explcitamente usados en ninguna funcin MPI. En vez de ello, son
implcitamente asociados a los grupos cuando los comunicadores son creados.
La sintaxis de los comandos que hemos usado para crear com_primera_fila es bastante
sencilla. El primer comando
int MPI_Comm_group(MPI_Comm com, MPI_Group* grupo)
simplemente retorna el grupo perteneciente al comunicador com.

El segundo comando
int MPI_Group_incl(MPI_Group antiguo_grupo,

int tamano_nuevo_grupo,
int* ids_antiguo_grupo,
MPI_Group* nuevo_grupo)
crea un nuevo grupo a partir de una lista de procesos pertenecientes al grupo existente an-
tiguo_grupo. El nmero de procesos en el nuevo grupo es tamano_nuevo_grupo, y los pro-
cesos que sern incluidos son listados en ids_antiguo_grupo. El proceso 0 en nuevo_grupo
tiene el identificador ids_antiguo_grupo[0] en antiguo_grupo, el proceso 1 en nuevo_grupo
es el ids_antiguo_grupo[1] en antiguo_grupo, y as sucesivamente.
El comando final
int MPI_Comm_create(MPI_Comm antiguo_com,

MPI_Group nuevo_grupo,
MPI_Comm* nuevo_com)
asocia el contexto al grupo nuevo_grupo, y crea el comunicador nuevo_com. Todos los pro-
cesos en nuevo_grupo pertenecen al grupo subyacente antiguo_com.
Existe una diferencia extremadamente importante entre las primeras dos funciones y la ter-
cera. MPI_Comm_group() y MPI_Group_incl() son ambas operaciones locales. Ello quiere
decir que no hay comunicacin entre los procesos implicados en dicha ejecucin. Sin embar-
go MPI_Comm_create() es una operacin colectiva. Todos los procesos en antiguo_grupo
deben llamar a MPI_Comm_create() con los mismos argumentos. El estndar MPI da tres
razones para ello:
Permite a la implementacin colocar a MPI_Comm_create() como la primera de las

comunicaciones colectivas regulares.
Proporciona mayor seguridad.
Permite que las implementaciones eviten comunicaciones relativas a la creacin del

contexto.
Notemos que como MPI_Comm_create() es colectiva tendr un comportamiento sincronizador.

En particular, si varios comunicadores estn siendo creados, todos deben ser creados en el mis-
mo orden en todos los procesos.
7.4. Particionamiento de los Comunicadores

En nuestro programa de multiplicacin de matrices necesitamos crear mltiples comuni-
cadores (uno para cada fila de procesos y uno para cada columna). ste podra ser un proceso
extremadamente tedioso si C fuera grande y tuviramos que crear cada comunicador usando
las tres funciones comentadas en la seccin anterior. Afortunadamente MPI proporciona una
funcin, MPI_Comm_split(), que puede crear varios comunicadores simultneamente. Para
ejemplificar su uso crearemos un comunicador para cada fila de procesos:
MPI_Comm com_fila;
int fila;
/* id ES EL IDENTIFICADOR EN MPI_COMM_WORLD.
* q*q = p */
fila = id / q;
MPI_Comm_split(MPI_COMM_WORLD, fila, id, &com_fila);
Una nica llamada a MPI_Comm_split() crea m nuevos comunicadores, todos ellos con el
mismo nombre com_fila. Por ejemplo, si C
el grupo com_fila consistir en los procesos
0, 1 y 2 para los procesos 0, 1 y 2. En los procesos 3, 4 y 5 el grupo subyacente a nuevo_com
ser el formado por los procesos 3, 4 y 5; y lo mismo ocurrir con los procesos 6, 7 y 8.
La sintaxis de MPI_Comm_split() es:
int MPI_Comm_split(MPI_Comm antiguo_com,

int clave_particion,
int clave_id, MPI_Comm* nuevo_com)
La llamada crea un comunicador para cada valor de clave_particion. Los procesos con el

mismo valor en clave_particion forman un nuevo grupo. El identificador de los procesos en
el nuevo grupo estar determinado por su valor en clave_id. Si los procesos y Y llaman

ambos a la funcin MPI_Comm_split() con el mismo valor en clave_particion, y el argu-
mento clave_id pasado por el proceso es menor que el pasado por el proceso Y , entonces el

identificador de en el grupo nuevo_com ser menor que el identificador del proceso Y . Si
llaman a la funcin con el mismo valor en clave_id el sistema asignar arbitrariamente a uno
de los procesos un identificador menor.
7.5. TOPOLOGAS 111
MPI_Comm_split() es una operacin colectiva y debe ser llamada por todos los procesos
pertenecientes a antiguo_com. La funcin puede ser utilizada incluso si no deseamos asig-
narle un comunicador a todos los procesos. sto puede ser realizado pasando la constante
predefinida MPI_UNDEFINED en el argumento clave_particion. Los procesos que hagan
sto obtendrn como valor de retorno en nuevo_com el valor MPI_COMM_NULL.
7.5. Topologas
Recordemos que es posible asociar informacin adicional (ms all del grupo y del con-
texto) a un comunicador. Una de las piezas de informacin ms importantes que se pueden
adjuntar al comunicador es la topologa. En MPI una topologa no es ms que un mecanis-
mo para asociar diferentes esquemas de direccionamiento a los procesos pertenecientes a un
grupo. Notar que las topologas en MPI son topologas virtuales, lo que quiere decir que po-
dra no haber una relacin simple entre la estructura de procesos de una topologa virtual y la
estructura fsica real de la mquina paralela.
Esencialmente existen dos tipos de topologas virtuales que se pueden crear en MPI: la
topologa cartesiana o rejilla, y la topologa grfica. Conceptualmente sta ltima engloba a
la primera. De todos modos, y debido a la importancia de las rejillas en las aplicaciones, existe
una coleccin separada de funciones en MPI cuyo propsito es la manipulacin de rejillas
virtuales.
En el algoritmo de Fox queremos identificar los procesos en MPI_COMM_WORLD
mediante las coordenadas de una rejilla, y cada fila y cada columna de la rejilla necesita formar
su propio comunicador. Observemos un mtodo para construir dicha estructura.
Comenzamos asociando una estructura de rejilla a MPI_COMM_WORLD. Para hacer
esto necesitamos especificar la siguiente informacin:
1. El nmero de dimensiones de la rejilla. Tenemos 2.
2. El tamao de cada dimensin. En nuestro caso, no es ms que el nmero de filas y el

nmero de columnas. Tenemos m filas y m columnas.
3. La periodicidad de cada dimensin. En nuestro caso esta informacin especifica si la

primera entrada de cada fila o columna es adyacente a la ltima entrada de dicha
fila o columna, respectivamente. Dado que nosotros queremos un paso circular de las
matrices en cada columna, sera provechoso que la segunda dimensin fuera peridica.
No es importante si la primera dimensin es peridica o no.
4. Finalmente MPI ofrece al usuario la posibilidad de permitir al sistema optimizar el di-

reccionamiento de la rejilla, posiblemente reordenando los procesos pertenecientes al
comunicador asociado, para as aprovechar mejor la estructura fsica de dichos procesos.
Dado que no necesitamos preservar el orden de los procesos en MPI_COMM_WORLD,
deberamos permitir al sistema el reordenamiento.
Para implementar estas decisiones simplemente ejecutaremos el siguiente cdigo:
MPI_Comm com_rejilla;
int dimensiones[2];
int periodicidad[2];
int reordenamiento = 1;
dimensiones[0] = dimensiones[1] = q;
periodicidad[0] = periodicidad[1] = 1;
MPI_Cart_create(MPI_COMM_WORLD, 2, dimensiones,
periodicidad, reordenamiento,
&com_rejilla);
Tras ejecutar este cdigo el comunicador com_rejilla contendr los procesos pertenecientes
a MPI_COMM_WORLD (posiblemente reordenados) y tendr asociado un sistema de co-
ordenadas cartesianas de dos dimensiones. Para determinar las coordenadas de un proceso
simplemente llamaremos a la funcin MPI_Cart_coords():
int coordenadas[2];
int id_rejilla;
MPI_Comm_rank(com_rejilla, &id_rejilla);
MPI_Cart_coords(com_rejilla, id_rejilla, 2, coordenadas);
Observemos que necesitamos llamar a MPI_Comm_rank() para obtener el identificador del

proceso en com_rejilla. Esto es necesario porque en nuestra llamada a MPI_Cart_create()
establecimos la variable reordenamiento a 1, y por lo tanto el identificador original de un
proceso en MPI_COMM_WORLD puede cambiar en com_rejilla.
La inversa a MPI_Cart_coords() es MPI_Cart_rank():
int MPI_Cart_rank(com_rejilla, coordenadas, &id_rejilla)
Dadas las coordenadas de un proceso, MPI_Cart_rank() retorna el identificador del proceso

en su tercer parmetro id_proceso.
La sintaxis de MPI_Cart_create() es:
int MPI_Cart_create(MPI_Comm antiguo_com,

int numero_dimensiones,
int* tam_dimensiones,
int* periodicidades,
int reordenamiento,
MPI_Comm* com_cartesiano)
MPI_Cart_create() crea un nuevo comunicador, com_cartesiano, aplicando una topologa

cartesiana a antiguo_com. La informacin sobre la estructura de la topologa cartesiana est
contenida en los parmetros numero_dimensiones, tam_dimensiones y periodicidades. El
primero de ellos, numero_dimensiones, contiene el nmero de dimensiones que forman el sis-
tema de coordenadas cartesianas. Los dos siguientes, tam_dimensiones y periodicidades, son
7.6. DIVISIN DE REJILLAS 113
3 4 5
0 1 2
6 7 8
Cuadro 7.2: Topologa Fsica 3*3
vectores que tienen el mismo orden que numero_dimensiones. El vector tam_dimensiones

especifica el orden de cada dimensin, mientras que el vector periodicidades especifica para
cada dimensin si es circular o linear.
zu { {
Los procesos pertenecientes a com_cartesiano son ordenados de fila en fila. De este modo
la primera fila contiene los procesos DFE:1)EBGBGBG&E _W %i b D@d/1 , la segunda fila con-
zu {% { zu {% { zu {% {
tendr _ % b D@dE _ %i b D@d 1)EBGBGBG&Ec('* _ % b D@d4/1 , y as
sucesivamente. En este sentido podra ser ventajoso cambiar el orden relativo de los procesos
en com_antiguo. Por ejemplo, supongamos que la topologa fsica es una tabla *X y que los
procesos pertenecientes com_antiguo, representados por sus identificadores, estn asociados
a los procesadores como se expone en el cuadro 7.2.
Claramente la eficiencia del algoritmo de Fox se mejorara si reordenramos los procesos.
Sin embargo, y dado que el usuario no conoce cmo se asocian los procesos a los procesadores,
deberamos dejar al sistema hacerlo estableciendo el parmetro reordenamiento a 1.
Dado que MPI_Cart_create() construye un nuevo comunicador, se trata de una operacin
colectiva.
La sintaxis de las funciones que nos informan sobre el direccionamiento de los procesos
es:
int MPI_Cart_rank(MPI_Comm cart_com, int* coordenadas,

int* id)
int MPI_Cart_coords(MPI_Comm cart_com, int id,
int* coordenadas)
La funcin MPI_Cart_rank() retorna el identificador en cart_com del proceso que tiene las
coordenadas cartesianas representadas en el vector coordenadas. As, coordenadas es un vec-
tor de orden igual al nmero de dimensiones de la topologa cartesiana asociada a cart_com.
MPI_Cart_coords() es la inversa a MPI_Cart_rank(): retorna las coordenadas del proceso
que tiene como identificador id en el comunicador cartesiano cart_com. Notar que ambas
funciones son locales.
7.6. Divisin de Rejillas

Tambin se puede dividir una rejilla en rejillas de menores dimensiones. Por ejemplo,
podemos crear un comunicador para cada fila de la rejilla como sigue:
int var_coords[2];
MPI_Comm com_fila;
var_coords[0]=0; var_coords[1]=1;
MPI_Cart_sub(cart_com,var_coords,&com_fila);
La llamada a MPI_Cart_sub() crea m nuevos comunicadores. El argumento var_coords es

un vector de booleanos. Especifica para cada dimensin si pertenece al nuevo comunicador.
Dado que estamos creando comunicadores para las filas de la rejilla, cada nuevo comunicador
consiste en los procesos obtenidos al fijar la coordenada de la fila, permitiendo que la coor-
denada de la columna vare. Con este propsito le asignamos a var_coords[0] el valor 0 (la
primera coordenada no vara) y le asignamos a var_coords[1] el valor 1 (la segunda coor-
denada vara). En cada proceso retornamos el nuevo comunicador en com_fila. Si queremos
crear comunicadores para las columnas, simplemente invertimos los valores en los elementos
de var_coords.
MPI_Com com_columna;
var_coords[0]=1; var_coords[1]=0;
MPI_Cart_sub(cart_com,var_coords,&com_columna);
Notar la similaridad entre MPI_Cart_sub() y MPI_Comm_split(). Ambas llevan a cabo fun-

ciones similares (las dos dividen un comunicador en una coleccin de nuevos comunicadores).
Sin embargo MPI_Cart_sub() slo puede ser usada en comunicadores que tengan asociada
una topologa cartesiana, y el nuevo comunicador slo puede ser creado fijando (o variando)
una o ms dimensiones del antiguo comunicador. Notar tambin que MPI_Cart_sub() es,
como MPI_Comm_split(), una operacin colectiva.
7.7. Implementacin Multiplicacin de Matrices de Fox

En esta seccin mostramos la implementacin del algoritmo de Fox. En este programa la
funcin Config_cart() genera varios comunicadores e informacin asociada a ellos. Debido
a que este procedimiento requiere muchas variables, y dado que la informacin contenida en
dichas variables es necesaria en la ejecucin de otras funciones, utilizaremos una estructura
tipo Info_Cart para agrupar toda esa informacin generada. Luego realizaremos la multipli-
cacin de matrices por el mtodo de Fox mediante la llamada a la funcin Fox(); dicha funcin
se apoya en otra, Mult_Matrices(), creada para ejecutar la indispensable multiplicacin de
matrices locales.
Algoritmo 7.1: Multiplicacin de Matrices de Fox
1
2 /********************************************************************/
3 /*Fox:CODIGO MULTIPLICACION DE MATRICES MEDIANTE EL ALGORITMO DE FOX*/
4 /********************************************************************/
5
7.7. IMPLEMENTACIN MULTIPLICACIN DE MATRICES DE FOX 115
6 /*TAMAO MAXIMO DE LA MATRIZ DE CADA PROCESO*/

7 # define MAX_ORDEN_LOCAL 700
8
13
14 /*ESTRUCTURA QUE CONTIENE PARA CADA PROCESO LA INFORMACION RELEVANTE
15 A LA TOPOLOGIA CARTESIANA QUE COMPONEMOS*/
17 i n t numprocs ; /*NUM DE PROCESOS PERTENECIENTES*/
18 i n t orden_cart ; /*sqrt(p)--->ORDEN DE LA TOPOLOGIA*/
19 MPI_Comm comm_global ; /*COMM GLOBAL DE LA TOPOLOGIA COMPLETA*/
20 MPI_Comm comm_fila ; /*COMM FORMADO POR LOS PROCS DE LA FILA*/
21 MPI_Comm comm_columna ; /*COMM FORMADO POR LOS PROCS DE LA COLUMNA*/
22 int f i l a ; /*NUMERO DE FILA*/
23 i n t columna ; /*NUMERO DE COLUMNA*/
24 int id ; /*IDENTIFICADOR DENTRO DE LA TOPOLOGIA CREADA*/
25 } Info_cart ;
26
27 /*TIPO MATRIZ DE CADA PROCESO*/
28 typedef i n t M a t r i z L o c a l [MAX_ORDEN_LOCAL] [ MAX_ORDEN_LOCAL] ;
29
30 /*TIPO DE DATOS MPI UTILIZADO PARA EL ENVIO DE MATRICES ENTRE LOS PROCESOS*/
31 MPI_Datatype T i p o _ e n v i o _ m a t r i z ;
32
/*DECLARACION DE LAS FUNCIONES UTILIZADAS*/
L
33
int Config_cart ( Info_cart pcart ) ;
L
34
void o b t e n e r _dat os ( i n t minimo , i n t maximo , i n t o r d e n _ g l o b a l ) ;
L
35
36 void d i s t r i b u i r _ d a t o s ( i n t tamano_local ) ;
37 void i n i c i a l i z a c i o n _ m a t r i c e s ( M a t r i z L o c a l l o c a l A ,
38 MatrizLocal localB ,
39 MatrizLocal localC ,
40 int orden_local ,
int id ) ;
L
41
42 void Fox ( I n f o _ c a r t p c a r t ,
43 MatrizLocal matriz1 ,
45 MatrizLocal r e s u l t ,
46 int orden_local ) ;
47 i n t i m p r e s i o n _ m a t r i c e s ( i n t i d , i n t numprocs ,
51 i n t tamano ,
52 int f i l a ,
53 i n t columna ) ;
54 void m u l t _ m a t r i c e s ( M a t r i z L o c a l m a t r i z 1 ,
int orden_local ) ;
L
57
58 void i m p _ m a t r i z ( M a t r i z L o c a l m a t r i z , i n t o r d e n _ l o c a l , FILE s a l i d a ) ;
59
60
61 /*********************************************************************/
62 /*FUNCION MAIN: NORMALMENTE UTILIZAMOS COMUNICADOR MPI_COMM_WORLD EN */
63 /*LAS COMUNICACIONES.EMPLEAMOS COMUNICADOR TOPOLOGIA CARTESIANA SOLO */
64 /*PARA LA MULTIPLICACION DE LAS MATRICES */
/*********************************************************************/
L8L
65
Info_cart top_cart ; /*ESTRUCTURA CON INFO SOBRE LA TOP.CARTESIANA*/
L
67
MatrizLocal localA ; /*MATRIZ LOCAL*/
L
68
MatrizLocal localB ; /*MATRIZ LOCAL*/
L
69
70 MatrizLocal localC ; /*MATRIZ LOCAL (SOLUCION)*/
71 int orden_local ; /*ORDEN MATRIZ LOCAL DE CADA PROCESO*/
72 i n t orden_global ; /*ORDEN MATRIZ GLOBAL*/
73 i n t minimo ; /*MINIMO ORDEN GLOBAL*/
74 i n t maximo ; /*MAXIMO ORDEN GLOBAL*/
75 i n t id_comm_world ; /*ID PROCESO EN MPI_COMM_WORLD*/
76 i n t numprocs_comm_world ; /*NUMERO PROCESOS EN MPI_COMM_WORLD*/
77 i n t raiz_numprocs ; /*RAIZ DE NUMERO PROCESOS*/
84 MPI_Status s t a t u s ; /*STATUS MENSAJES DE PRUEBA*/
85 int origen ; /*ORIGEN MENSAJES DE PRUEBA*/
86
87
88
89 /*INICIALIZAMOS EL ENTORNO DE EJECUCION MPI*/
91
92 /*ALMACENAMOS EL IDENTIFICADOR DEL PROCESO EN MPI_COMM_WORLD*/
93 MPI_Comm_rank (MPI_COMM_WORLD,& id_comm_world ) ;
94
96 MPI_Comm_size (MPI_COMM_WORLD,& numprocs_comm_world ) ;
97
98 /*FINALIZAMOS SI NUMERO DE PROCESOS NO TIENE RAIZ ENTERA*/
99 raiz_numprocs= s q r t ( numprocs_comm_world ) ;
100 i f ( pow ( raiz_numprocs , 2 ) ! = numprocs_comm_world ) {
101 i f ( id_comm_world = = 0 ) {
102 f p r i n t f ( s t d o u t , " \ n E r r o r . Numero de p r o c e s o s u t i l i z a d o " ) ;
103 f p r i n t f ( stdout , " debe t e n e r r a i z e n t e r a \ n \ n " ) ;
104 }
106 return 0 ;
107 }
108
111 i f ( id_comm_world = = 0 ) {
112 f p r i n t f ( s t d o u t , " \ n P r o c e s o %d (MPI_COMM_WORLD) en %s " ,
113 id_comm_world , nombreproc ) ;
114 f p r i n t f ( s t d o u t , " E n c a r g a d o de l a E / S \ n " ) ;
115 }

117 /*if(id_comm_world==0){
118 * for (origen=1;origen<numprocs_comm_world;origen++){
121 * fprintf(stdout,"PROC %d (MPI_COMM_WORLD) en %s\n",
122 * origen,nombreproc);
123 * }
124 *}
125 *else{
128 *}
129 *
130 */
131
/*RESERVAMOS ESPACIO PARA MATRICES LOCALES*/
L
132
l o c a l A =( M a t r i z L o c a l ) m a l l o c ( s i z e o f ( M a t r i z L o c a l ) ) ;
L
133
l o c a l B =( M a t r i z L o c a l ) m a l l o c ( s i z e o f ( M a t r i z L o c a l ) ) ;
L
134
135 l o c a l C =( M a t r i z L o c a l ) m a l l o c ( s i z e o f ( M a t r i z L o c a l ) ) ;
136
138 i f ( id_comm_world = = 0 ) {
minimo=raiz_numprocs ; /*MINIMO ORDEN GLOBAL*/
L
139
140 maximo=raiz_numprocs MAX_ORDEN_LOCAL; /*MAXIMO ORDEN GLOBAL*/
141 o b t e n e r _dato s ( minimo , maximo,& o r d e n _ g l o b a l ) ; /*OBTENEMOS DATOS DEL USUARIO*/
o r d e n _ l o c a l= o r d e n _ g l o b a l / raiz_numprocs ; /*CALCULAMOS ORDEN MATRIZ LOCAL*/
L
142
143 o r d e n _ g l o b a l= o r d e n _ l o c a l raiz_numprocs ; /*TRUNCAMOS ORDEN MATRIZ GLOBAL*/
144 }
145
147 i f ( id_comm_world = = 0 ) {
148 f p r i n t f ( s t d o u t , " \ n U t i l i z a n d o %d m a t r i c e s de o r d e n %d c a d a una . \ n " ,
149 numprocs_comm_world , o r d e n _ l o c a l ) ;
150 f p r i n t f ( s t d o u t , " Orden M a t r i z G l o b a l : %d \ n " , o r d e n _ g l o b a l ) ;
151 f p r i n t f ( stdout , " Procesando . . . \ n \ n" ) ;
152 }
154
156 d i s t r i b u i r _ d a t o s (& o r d e n _ l o c a l ) ;
157
/*INICIALIZACION MATRICES*/
L L L
158
159 i n i c i a l i z a c i o n _ m a t r i c e s ( l o c a l A , l o c a l B , l o c a l C , o r d e n _ l o c a l , id_comm_world ) ;
160
161
162 /*----------------[UTILIZACION TOPOLOGIA CARTESIANA]------------------*/
163
164 /*DEFINICION TIPO DE DATOS MPI UTILIZADO PARA EL ENVIO DE MATRICES*/
165 MPI_Type_vector ( o r d e n _ l o c a l , o r d e n _ l o c a l ,MAX_ORDEN_LOCAL, MPI_INT ,
166 &T i p o _ e n v i o _ m a t r i z ) ;
167 MPI_Type_commit (& T i p o _ e n v i o _ m a t r i z ) ;
168
169 /*CREACION Y CONFIGURACION DE LA TOPOLOGIA CARTESIANA
170 SI LA SALIDA DE Config_cart ES ERRONEA,FINALIZAMOS EL PROCESO*/
171 i f ( C o n f i g _ c a r t (& t o p _ c a r t ) ) {
173 return 0 ;
174 }
175
/*LLAMADA MULTIPLICACION DE MATRICES MEDIANTE EL ALGORITMO DE FOX*/
L L L
176
177 Fox (& t o p _ c a r t , l o c a l A , l o c a l B , l o c a l C , o r d e n _ l o c a l ) ;
178
179 /*--------------------------------------------------------------------*/
180
181
182
183 /*IMPRIMIMOS RESULTADO.UTILIZAMOS FILA Y COLUMNA DE LA TOP.CARTESIANA*/
i m p r e s i o n _ m a t r i c e s ( id_comm_world , numprocs_comm_world ,
L L L
184
185 localA , localB , localC , orden_local ,
186 t o p _ c a r t . f i l a , t o p _ c a r t . columna ) ;
187
188 /*IMPRIMIMOS TIEMPO FINAL DE PROCESAMIENTO*/
190 i f ( id_comm_world = = 0 ) {
f p r i n t f ( s t d o u t , " \ nNumero P r o c e s o s : %d \ n " , numprocs_comm_world ) ;
N
191
193 }
194
195 /*FINALIZAMOS EL ENTORNO DE EJECUCION MPI*/
197 return 0 ;
198
199 } /*main*/
200
201
202 /*************************************************************/
203 /*FUNCION obtener_datos: PROCESO 0 EN MPI_COMM_WORLD OBTIENE */
204 /*LOS DATOS DE ENTRADA */
/*************************************************************/
L
205
206 void o b t e n e r _dat os ( i n t minimo , i n t maximo , i n t o r d e n _ g l o b a l ) {
207
208 i n t ok = 0 ; /*SEMAFORO PETICION DATOS*/
209
211
212 while ( ok = = 0 ) {
213 f p r i n t f ( s t d o u t , " I n t r o d u z c a o r d e n de l a m a t r i z g l o b a l a c a l c u l a r " ) ;
214 f p r i n t f ( s t d o u t , " ( minimo= %d , maximo= %d ) \ n " , minimo , maximo ) ;
s c a n f ( " %d " , o r d e n _ g l o b a l ) ;
L L
215
216 i f ( minimo <=( o r d e n _ g l o b a l ) & & ( o r d e n _ g l o b a l )<=maximo ) { ok = 1 ; }
217 else { f p r i n t f ( s t d o u t , " Orden e r r o n e o . \ n " ) ; }
218 }
219
220
222 /**orden_global=2800;*/
223
224 }
225
226 /*********************************************************************/
227 /*FUNCION distribuir_datos: UTILIZAMOS EL COMUNICACOR MPI_COMM_WORLD */
228 /*PARA DISTRIBUIR EL DATO DE ENTRADA */
/*********************************************************************/
L
229
230 void d i s t r i b u i r _ d a t o s ( i n t o r d e n _ l o c a l ) {
231
232 MPI_Bcast ( o r d e n _ l o c a l , 1 , MPI_INT , 0 ,MPI_COMM_WORLD ) ;
233
234 }
235
236 /***********************************************************/
237 /*FUNCION inicializacion_matrices:INICIALIZA LAS MATRICES */
238 /*ALEATORIAMENTE.LA MATRIZ RESULTADO SE DEJA A 0 */
239 /***********************************************************/
240 void i n i c i a l i z a c i o n _ m a t r i c e s ( M a t r i z L o c a l l o c a l A ,
241 MatrizLocal localB ,
242 MatrizLocal localC ,
244 int id ){
245
246 int i , j ; /*CONTADORES*/
247
249 srand ( i d ) ;
250
251 f o r ( i =0; i < o r d e n _ l o c a l ; i + + ) {
252 f o r ( j =0; j < o r d e n _ l o c a l ; j + + ) {
/*MATRICES LOCALES,ELEMENTOS PSEUDOALEATORIOS*/
L
253
l o c a l A [ i ] [ j ] = ( i n t ) ( 1 0 0 . 0 rand ( ) / ( RAND_MAX) ) ;
L
254
255 l o c a l B [ i ] [ j ] = ( i n t ) ( 1 0 0 . 0 rand ( ) / ( RAND_MAX) ) ;
256 /*RESULTADO,ELEMENTOS=0*/
257 localC [ i ] [ j ]=0;
258 }
259 }
260 } /*inicializacion_matrices*/
261
262
263 /************************************************************************/
264 /*FUNCION Config_cart:CREA Y CONFIGURA UN COMUNICADOR CUYA TOPOLOGIA ES */
265 /*CARTESIANA. ALMACENA EN LA ESTRUCTURA Info_cart LOS DATOS NECESARIOS */
/************************************************************************/
L
266
267 int Config_cart ( Info_cart pcart ) {
268 int antigua_id ; /*ID DENTRO DEL COMUNICADOR INICIAL MPI_COMM_WORLD*/
269 i n t dims [ 2 ] ; /*VECTOR QUE CONTIENE LA EXTENSION DE CADA DIMENSION*/
270 int periods [ 2 ] ; /*VECTOR BOOLEANO.CONTIENE PERIODICIDAD DE CADA DIMENSION*/
271 i n t coords [ 2 ] ; /*VECTOR QUE CONTIENE LAS COORDENADAS DE CADA PROCESO*/
272 i n t var_coords [ 2 ] ; /*VECTOR PARA GENERAR COMUNICADORES DE FILA Y COLUMNA*/
273
/*ALMACENAMOS EL NUM DE PROCESOS PERTENECIENTES A MPI_COMM_WORLD*/
N
274
275 MPI_Comm_size (MPI_COMM_WORLD, & ( p c a r t >numprocs ) ) ;
276 /*IDENTIFICADOR DE CADA PROCESO DENTRO DE MPI_COMM_WORLD*/
277 MPI_Comm_rank (MPI_COMM_WORLD,& a n t i g u a _ i d ) ;
278
279 /*ORDEN DE LA TOPOLOGIA CARTESIANA,QUE ES LA RAIZ DEL NUM DE PROCESOS*/
280 /*SI DICHA RAIZ NO ES ENTERA,DEBEMOS DESHACERNOS DE LOS PROCESOS SOBRANTES*/
281 N N
p c a r t >o r d e n _ c a r t =( i n t ) s q r t ( p c a r t >numprocs ) ;
282
283 /*PREPARAMOS LA CREACION DE LA TOPOLOGIA CARTESIANA.DEFINIMOS LA EXTENSION
Y PERIODICIDAD DE CADA UNA DE LAS DIMENSIONES,MEDIANTE SENDOS VECTORES*/
N
284
285 dims [ 0 ] = dims [ 1 ] = p c a r t >o r d e n _ c a r t ;
286 periods [0]= periods [1]=1;
/*CREACION DE LA TOPOLOGIA CARTESIANA.LA ALMACENAMOS EN pcart->comm_global*/
N
287
288 MPI_Cart_create (MPI_COMM_WORLD, 2 , dims , p e r i o d s , 1 , & ( p c a r t >comm_global ) ) ;
289
/*SI DICHO PROCESO NO ENCAJA EN LA TOPOLOGIA CARTESIANA,SALIDA ERRONEA*/
N
290
291 i f ( ! p c a r t >comm_global ) r e t u r n 1 ;
292
/*IDENTIFICADOR DE CADA PROCESO DENTRO DE LA TOPOLOGIA CARTESIANA*/
N N
293
294 MPI_Comm_rank ( p c a r t >comm_global , & ( p c a r t >i d ) ) ;
295
/*COORDENADAS ASOCIADAS AL PROCESO,SU FILA Y COLUMNA*/
N N
296
MPI_Cart_coords ( p c a r t >comm_global , p c a r t >i d , 2 , coords ) ;
N
297
p c a r t > f i l a =coords [ 0 ] ;
N
298
299 p c a r t >columna=coords [ 1 ] ;
300
301 /*CREAMOS UN COMUNICADOR ENTRE LOS PROCESOS DE LA MISMA FILA*/
var_coords [ 0 ] = 0 ; var_coords [ 1 ] = 1 ;
N N
302
303 MPI_Cart_sub ( p c a r t >comm_global , var_coords , & ( p c a r t >comm_fila ) ) ;
304 /*CREAMOS UN COMUNICADOR ENTRE LOS PROCESOS DE LA MISMA COLUMNA*/
var_coords [ 0 ] = 1 ; var_coords [ 1 ] = 0 ;
N N
305
306 MPI_Cart_sub ( p c a r t >comm_global , var_coords , & ( p c a r t >comm_columna ) ) ;
307
308 return 0 ;
309
310 } /*Config_cart*/
311
312
313 /**************************************************************************/
314 /*FUNCION Fox:MULTIPLICACION DE MATRICES MEDIANTE EL ALGORITMO DE FOX */
/**************************************************************************/
L
315
316 void Fox ( I n f o _ c a r t p c a r t ,
320 int orden_local ) {
321
323 int bcast_raiz ; /*PROCESO ORIGEN QUE ENVIA MATRIZ LOCAL 1 HACIA
324 LOS PROCESOS DE LA MISMA FILA*/
325 int origen , destino ; /*ORIGEN Y DESTINO DE MATRIZ LOCAL 2 ENTRE
326 LOS PROCESOS DE LA MISMA COLUMNA*/
327 int etiqueta =50; /*ETIQUETA*/
MPI_Status s t a t u s ; /*STATUS RECEPCION*/
L
328
329 M a t r i z L o c a l temp1 ; /*VBLE DONDE ALMACENAMOS LA MATRIZ
330 ENVIADA POR bcast_raiz*/
331
332
/*RESERVAMOS ESPACIO PARA MATRIZ LOCAL*/
L
333
334 temp1=( M a t r i z L o c a l ) m a l l o c ( s i z e o f ( M a t r i z L o c a l ) ) ;
335
336 /*ESTABLECEMOS EL NUMERO DE FILA DE LOS PROCESOS ORIGEN Y DESTINO

DE LA MATRIZ LOCAL 2*/
N N
337
o r i g e n =( p c a r t > f i l a + 1 ) % p c a r t >o r d e n _ c a r t ;
N N N N
338
339 d e s t i n o =( p c a r t > f i l a + p c a r t >o r d e n _ c a r t 1 ) % p c a r t >o r d e n _ c a r t ;
340
/*MIENTRAS QUEDEN PROCESOS EN LA FILA...*/
N
341
342 f o r ( i =0; i <( p c a r t >o r d e n _ c a r t ) ; i + + ) {
/*SE ELIGE EL PROCESO RAIZ*/
N N
343
344 b c a s t _ r a i z =( p c a r t > f i l a + i ) %( p c a r t >o r d e n _ c a r t ) ;
345 /*SI ES EL TURNO DEL PROPIO PROCESO EN EJECUCION ,SE ENVIA MATRIZ LOCAL 1
HACIA LOS PROCESOS DE LA MISMA FILA Y SE MULTIPLICA LOCALMENTE*/
N
346
i f ( b c a s t _ r a i z = = p c a r t >columna ) {
N
347
348 MPI_Bcast ( m a t r i z 1 , 1 , T i p o _ e n v i o _ m a t r i z , b c a s t _ r a i z , p c a r t >comm_fila ) ;
349 mult_matrices ( matriz1 , matriz2 , r e s u l t , orden_local ) ;
350 }
351 /*SI NO TOCA EL TURNO,SE RECIBE LA MATRIZ Y SE MULTIPLICA LOCALMENTE*/
else {
N
352
MPI_Bcast ( temp1 , 1 , T i p o _ e n v i o _ m a t r i z , b c a s t _ r a i z , p c a r t >comm_fila ) ;
L
353
354 m u l t _ m a t r i c e s ( temp1 , m a t r i z 2 , r e s u l t , o r d e n _ l o c a l ) ;
355 }
356
357 /*POR ULTIMO SE ENVIA HACIA ARRIBA EN LA COLUMNA LA MATRIZ LOCAL 2*/
358 MPI_Sendrecv_replace ( m a t r i z 2 , 1 , T i p o _ e n v i o _ m a t r i z ,
359 destino , etiqueta ,
origen , etiqueta ,
N
360
361 p c a r t >comm_columna,& s t a t u s ) ;
362 }
363
364 } /*Fox*/
365
366
367 /******************************************************************/
368 /*FUNCION impresion_matrices:PROCESO 0 RECIBE LAS MATRICES DE LOS */
369 /*DEMAS PROCESOS ORDENADAMENTE Y LAS IMPRIME */
370 /******************************************************************/
371 i n t i m p r e s i o n _ m a t r i c e s ( i n t i d , i n t numprocs ,
372 MatrizLocal matrizA ,
373 MatrizLocal matrizB ,
374 MatrizLocal matrizResult ,
376 int f i l a ,
377 i n t columna ) {
378
379 int BufferFila ; /*BUFFER RECEPCION FILA*/
i n t BufferColumna ; /*BUFFER RECEPCION COLUMNA*/
L
380
381 M a t r i z L o c a l B u f f e r M a t r i z ; /*BUFFER RECEPCION MATRIZ*/
382 int origen ; /*ORIGEN DE LOS DATOS*/
383 MPI_Request r e q u e s t s [ 5 ] ; /*VECTOR DE PETICIONES*/
384 MPI_Status s t a t u s [ 5 ] ; /*VECTOR DE STATUS*/
int etiqueta =10; /*ETIQUETA DE LOS MENSAJES*/
L
385
386 FILE s a l i d a ; /*FICHERO SALIDA*/
387
388
/*RESERVAMOS ESPACIO PARA MATRIZ LOCAL*/
L
389
390 B u f f e r M a t r i z =( M a t r i z L o c a l ) m a l l o c ( s i z e o f ( M a t r i z L o c a l ) ) ;
391
392 i f ( i d ==0){
393 /*APERTURA FICHERO SALIDA*/
394 /*UTILIZAR PREFERIBLEMENTE UN FICHERO LOCAL (EN LINUX
395 PODRIAMOS USAR ALGO COMO "/tmp/Result.txt")*/
396 i f ( ( s a l i d a=fopen ( " / tmp / R e s u l t . t x t " , "w" ) ) = =NULL ) {
397 f p r i n t f ( s t d e r r , " F a l l o de a p e r t u r a f i c h e r o s a l i d a . \ n " ) ;
398 return 1 ;
399 }
400 else {
401 f p r i n t f ( s t d o u t , " E s c r i b i e n d o r e s u l t a d o en f i c h e r o de s a l i d a . \ n " ) ;
402 }
403 /*IMPRESION MATRICES PROPIAS*/
404 f p r i n t f ( s a l i d a , "PROC %d : C o o r d e n a d a s( %d, %d ) . M a t r i z A\ n " , i d ,
405 f i l a , columna ) ;
406 imp_matriz ( matrizA , orden_local , s a l i d a ) ;
407 f p r i n t f ( s a l i d a , "PROC %d : C o o r d e n a d a s( %d, %d ) . M a t r i z B \ n " , i d ,
409 imp_matriz ( matrizB , orden_local , s a l i d a ) ;
410 f p r i n t f ( s a l i d a , "PROC %d : C o o r d e n a d a s( %d, %d ) . M a t r i z R e s u l t a d o \ n " , i d ,
412 imp_matriz ( matrizResult , orden_local , s a l i d a ) ;
413 /*IMPRESION OTRAS MATRICES*/
/*MATRIZ A*/
L
415
416 MPI_Irecv (& B u f f e r F i l a , 1 , MPI_INT , o r i g e n , e t i q u e t a o r i g e n +1,
MPI_COMM_WORLD,& r e q u e s t s [ 0 ] ) ;
L
417
418 MPI_Irecv (& BufferColumna , 1 , MPI_INT , o r i g e n , e t i q u e t a o r i g e n +2,
L
419
420 MPI_Irecv ( B u f f e r M a t r i z , 1 , T i p o _ e n v i o _ m a t r i z , o r i g e n , e t i q u e t a o r i g e n +3,
421 MPI_COMM_WORLD,& r e q u e s t s [ 2 ] ) ;
422 MPI_Waitall ( 3 , requests , status ) ;
423 f p r i n t f ( s a l i d a , "PROC %d : C o o r d e n a d a s( %d, %d ) . M a t r i z A \ n " , o r i g e n ,
B u f f e r F i l a , BufferColumna ) ;
L
424
425 i m p _ m a t r iz ( B u f f e r M a t r i z , o r d e n _ l o c a l , s a l i d a ) ;
/*MATRIZ B*/
L
426
429 MPI_Wait(& r e q u e s t s [ 0 ] , & s t a t u s [ 0 ] ) ;
430 f p r i n t f ( s a l i d a , "PROC %d : C o o r d e n a d a s( %d, %d ) . M a t r i z B \ n " , o r i g e n ,
L
431
/*MATRIZ Result*/
L
433
436 MPI_Wait(& r e q u e s t s [ 0 ] , & s t a t u s [ 0 ] ) ;
437 f p r i n t f ( s a l i d a , "PROC %d : C o o r d e n a d a s( %d, %d ) . M a t r i z R e s u l t \ n " , o r i g e n ,
L
438
440 }
441 /*CIERRE FICHERO SALIDA*/
442 fclose ( salida ) ;
443 }
444 else {
445 /*ENVIO DE DATOS*/
446 MPI_Isend(& f i l a , 1 , MPI_INT , 0 , e t i q u e t a i d +1, L

L
447
448 MPI_Isend(& columna , 1 , MPI_INT , 0 , e t i q u e t a i d +2,
L
449
450 MPI_Isend ( m a t r i z A , 1 , T i p o _ e n v i o _ m a t r i z , 0 , e t i q u e t a i d +3,
L
451
452 MPI_Isend ( m a t r i z B , 1 , T i p o _ e n v i o _ m a t r i z , 0 , e t i q u e t a i d +4,
L
453
454 MPI_Isend ( m a t r i z R e s u l t , 1 , T i p o _ e n v i o _ m a t r i z , 0 , e t i q u e t a i d +5,
456 }
457
458 } /*impresion_matrices*/
459
460
461 /**************************************************************/
462 /*FUNCION mult_matrices:MULTIPLICACION DE MATRICES LOCALMENTE */
463 /**************************************************************/
464 void m u l t _ m a t r i c e s ( M a t r i z L o c a l m a t r i z 1 ,
467 int orden_local ) {
468
469 int i , j , k ; /*CONTADORES*/
470
472 f o r ( j =0; j < o r d e n _ l o c a l ; j + + ) {
473 /*CALCULAMOS EL ELEMENTO i,j DE LA MATRIZ result*/
f o r ( k =0; k< o r d e n _ l o c a l ; k + + ) {
L
474
475 ( r e s u l t ) [ i ] [ j ] + = ( matriz1 ) [ i ] [ k ] ( matriz2 ) [ k ] [ j ] ;
476 }
477 }
478 }
479
480 } /*Mult_Matrices*/
481
482
483 /*********************************************/
484 /*FUNCION imp_matriz:IMPRESION DE UNA MATRIZ */
/*********************************************/
L
485
486 void i m p _ m a t r i z ( M a t r i z L o c a l m a t r i z , i n t o r d e n _ l o c a l , FILE salida ){
487
488 int i , j ; /*CONTADORES*/
489
491 f o r ( j =0; j < o r d e n _ l o c a l ; j ++)
492 f p r i n t f ( s a l i d a , " %d " , m a t r i z [ i ] [ j ] ) ;
493 f p r i n t f ( salida , " \ n" ) ;
494 }
495 }
Parte III
Anlisis del Rendimiento
125
Captulo 8
Evaluacin del Sistema
Para conseguir una cierta objetividad en el anlisis de los algoritmos ejecutados en un

determinado sistema paralelo, lo primero que debemos hacer es medir el rendimiento de dicho
sistema. Adems los distintos grupos de desarrolladores de software MPI tienen diferentes
razones para medir el rendimiento de sus sistemas:
Los desarrolladores de aplicaciones necesitan conocer el rendimiento de las imple-

mentaciones MPI sobre el sistema que van a emplear. De esta manera podrn elegir
de manera acertada el tipo de operaciones a implementar en sus algoritmos y, si hay
varias disponibles, la implementacin MPI a utilizar.
Los evaluadores encuentran la informacin sobre el rendimiento crtica a la hora de

decidir qu mquina adquirir para ejecutar sus aplicaciones y, si hay varias disponibles,
qu implementacin MPI utilizar.
Los implementadores necesitan entender el comportamiento de sus propias implementa-

ciones MPI para poder plantear modificaciones y medir los efectos de dichas modifica-
ciones.
Normalmente la medicin del rendimiento se realiza a travs de herramientas especializadas

en el anlisis, de modo que podemos saber fcilmente y con seguridad cunto de apropiado es
el sistema para la ejecucin de determinados algoritmos paralelos.
8.1. Utilidad mpptest

Mpptest es un programa que mide el rendimiento de las funciones bsicas MPI en una
amplia variedad de situaciones. Adems del clsico test de comunicacin entre dos procesos,
mpptest puede realizar tests de comunicacin con mltiples procesos implicados, exponiendo
problemas de escalabilidad. Tambin podremos elegir el tamao de los mensajes a enviar de
manera que se puedan tratar de manera aislada los problemas imprevistos en el rendimiento
del sistema.
Originalmente mpptest fu desarrollado antes de la aparicin del estndar MPI, carac-
terstica que todava se refleja en algunos de los nombres de las opciones (-force para ready-
send, etc.). Mpptest se distribuye con la implementacin MPICH aunque puede ser usada en
127
128 CAPTULO 8. EVALUACIN DEL SISTEMA
cualquier implementacin MPI. Las versiones ms actuales incluyen junto a mpptest una serie
de programas (stress y goptest entre otros) que estn adaptados especficamente a cierto tipo
de mediciones del rendimiento del sistema.
8.1.1. Compilacin y Ejecucin

La implementacin MPICH incluye en su propia distribucin la utilidad mpptest, por
lo cual los usuarios de MPICH no necesitarn un complicado proceso de instalacin. Para
compilar mpptest slo tendremos que ejecutar :
$ cd directorio_mpich/examples/perftest
$ make
Mpptest puede ser utilizado en otras implementaciones MPI; para realizar una instalacin
adecuada consulte la documentacin.
Para ejecutar mpptest debemos utilizar el programa de arranque de procesos que gen-
eralmente empleamos en la ejecucin de programas MPI. Normalmente utilizaremos mpirun
(seccin A.6).
De este modo utilizando la siguiente orden realizaremos un test simple de comunicacin
bloqueante entre dos procesos:
$ mpirun -np 2 mpptest
Para conocer todas las opciones de mpptest ejecutaremos:
$ mpptest -help
Tambin existe un script, llamado runmpptest, que facilita la realizacin de las pruebas de
rendimiento ms generales. Para utilizarlo no es necesario emplear el programa mpirun. Pode-
mos conocer sus opciones ejecutando:
$ runmpptest -help
8.1.2. Formatos de Salida

Por defecto mpptest est configurado para generar datos para el programa CIt. De es-
ta manera si queremos generar por la salida estndar los datos necesarios para visualizar el
resultado con el programa CIt usaremos:
$ mpirun -np 2 mpptest
Sin embargo mpptest tambin puede generar datos para el programa gnuplot, utilizando la
opcin -gnuplot. De esta manera obtendremos por la salida estndar los comandos necesarios
para que el programa gnuplot utilice los datos que la misma orden almacena en el fichero
mppout.gpl. La siguiente orden guarda en el fichero out.mpl los comandos que sern
ledos por gnuplot, y agrega los datos del test al fichero mppout.gpl:
$ mpirun -np 2 mpptest -gnuplot > out.mpl

8.1. UTILIDAD MPPTEST 129
Tambin podemos utilizar la opcin -fname. Con la siguiente orden guardaremos en el fichero
nombre.mpl los comandos que sern ledos por gnuplot, agregando los datos del test al
fichero nombre.gpl:
$ mpirun -np 2 mpptest -gnuplot -fname nombre.mpl
8.1.3. Visualizacin
En la visualizacin del contenido de los tests utilizaremos el programa gnuplot. Lo primero
que debemos hacer, como se explica en el apartado anterior, es generar el fichero de comandos
.mpl y el fichero de datos .gpl asociado.
Una vez hecho sto, para ejecutar los comandos del fichero out.mpl (analizando as los
datos almacenados en el fichero .gpl asociado) utilizaremos:
$ gnuplot out.mpl
o bien escribiremos el comando
> load out.mpl
dentro del programa gnuplot.
8.1.4. Grficos
Para generar grficos en formato Encapsulated Postscript tenemos dos opciones. La primera
es utilizar la opcin -gnuploteps en vez de -gnuplot para generar el fichero de comandos .mpl.
La siguiente secuencia de rdenes genera el grfico out.eps en monocromo:
$ mpirun -np 2 mpptest -gnuploteps -fname out.mpl

$ gnuplot out.mpl > out.eps
Otra posibilidad sera generar el fichero de comandos .mpl con la opcin -gnuplot (como
hacamos antes):
$ mpirun -np 2 mpptest -gnuplot -fname out.mpl
Para luego escribir una serie de comandos dentro del programa gnuplot. De esta manera po-
dremos elegir de una manera ms precisa el formato del grfico de salida. Con la siguiente
serie de comandos conseguiremos obtener el grfico en color:
> set term postscript eps color

> set output out.eps
> load out.mpl
8.1.5. Operaciones
Mpptest proporciona una amplia variedad de tests. Los distintos tipos de tests son selec-
cionados normalmente a travs de los argumentos asociados a la ejecucin del programa en
la lnea de comandos, aunque tambin puede ser necesario el empleo de otros programas para
ejecutarlos. La siguiente lista resume las opciones disponibles ms interesantes:
Comunicacin No Bloqueante. La comunicacin no bloqueante es importante; en muchas

aplicaciones usar funciones de comunicacin no bloqueante es la manera ms fcil de
asegurar la fiabilidad evitando problemas relacionados con la capacidad finita del buffer.
El rendimiento de las funciones no bloqueantes puede ser diferente al de las funciones
bloqueantes. Para utilizar este tipo de comunicacin emplearemos la opcin -async.
Nmero de Procesos. Cualquier nmero de procesos puede ser empleado. Por defecto s-
lo dos de los procesos se comunican. Utilizando la opcin -bisect todos los procesos
participan en la comunicacin.
Solapamiento entre comunicacin y procesamiento. La opcin -overlap realiza un simple

test que mide el solapamiento entre comunicacin y procesamiento del sistema enviando
mensajes con una longitud determinada y generando una carga variable de procesamien-
to.
Patrones de Comunicacin. Existen una gran variedad de patrones de comunicacin. De este

modo, no slo existe el modelo punto a punto; un modelo muy importante es el de
comunicacin colectiva, entre otros. La comunicacin colectiva se mide con el programa
goptest. Dicho programa utiliza muchas opciones similares a mpptest, y se maneja de
manera muy similar. Para conocer su funcionamiento ejecutaremos :
$ goptest -help
Como ocurre con mpptest, tambin existe un script que facilita el manejo del programa
goptest. Dicho script se denomina rungoptest. Podemos conocer sus opciones ejecu-
tando:
$ rungoptest -help
Fiabilidad. La fiabilidad se comprueba mediante el programa stress. Este programa enva

conjuntos de bits en mensajes de varios tamaos, y luego chequea cada bit del mensaje
recibido en el proceso receptor. Para conocer sus opciones ejecutaremos:
$ stress -help
8.2. Pruebas Realizadas

El sistema en el cual realizamos las pruebas consiste en una red de estaciones de trabajo
dedicadas a la realizacin de prcticas por parte de los alumnos de Ingeniera Tcnica de
8.2. PRUEBAS REALIZADAS 131
Informtica de Gestin de la Universidad de Cdiz. Dicho sistema se encuentra en el Aula de

Informtica II de la Escuela Superior de Ingeniera.
Las mquinas en las cuales ejecutaremos los algoritmos tienen las siguientes caractersti-
cas:
Procesador AMD Duron a 1,2 Ghz

256 Mb RAM
Distribucin SUSE Linux 8.0
Todas las mquinas estn conectadas a una red Ethernet (mediante una tarjeta Davicom Eth-
ernet 100/10 Mbit) y comparten el sistema de ficheros /home mediante NFS (Network File
System, Sistema de Ficheros en Red). El servidor de ficheros es un computador Compaq
DEC 3000/800S Alpha, con el sistema operativo Tru64 UNIX (Digital UNIX) V4.0E . La
implementacin MPI utilizada es MPICH Versin 1.2.4 .
A continuacin analizaremos el rendimiento y la fiabilidad de nuestro sistema al ejecutar
distintos tipos de comunicacin.
8.2.1. Comunicacin Bloqueante

Este test analiza el comportamiento del sistema en la situacin ms habitual: el paso de
mensajes bloqueantes.
E JECUCIN
Ejecutaremos 16 procesos de los cuales dos de ellos se comunicarn. El tamao de los
mensajes variar entre 0 y 1024 bytes. Para ejecutarlo daremos la orden:
$ mpirun -np 16 mpptest -gnuplot -fname ComBloq.mpl
Como podemos observar el nmero de procesos lo fijamos mediante el programa mpirun. Por
defecto mpptest utiliza para las pruebas mensajes cuyo tamao vara entre 0 y 1024 bytes, con
un salto de 32 bytes entre un tamao y el siguiente.
Con esta orden el fichero ComBloq.gpl almacenar los datos para el grfico, mientras
que ComBloq.mpl contendr los comandos gnuplot para visualizarlos. Modificaremos ste
ltimo para mejorar el aspecto del resultado:
set terminal postscript eps color

set xlabel "Tamano (bytes)"
set ylabel "Tiempo (micro-seg)"
set title "Comunicacion Bloqueante"
plot [] [:1200] ComBloq.gpl using 4:5 title "Com.Bloqueante" \
with lines lt 1 lw 3
exit
A continuacin daremos la siguiente orden para generar el grfico ComBloq.eps:

Comunicacion Bloqueante
1200
Com.Bloqueante
1000
800
Tiempo (micro-seg)
600
400
200
0
0 200 400 600 800 1000 1200
Tamano (bytes)
Figura 8.1: Grfico Comunicacin Bloqueante
$ gnuplot ComBloq.mpl > ComBloq.eps
El grfico que obtenemos como resultado lo tenemos en la figura 8.1. El eje T mide el tamao
de los mensajes, mientras que el eje U mide el tiempo necesario para transmitirlos. La lnea
roja representa el rendimiento de la comunicacin bloqueante.
A NLISIS DE LOS R ESULTADOS

Como caba esperar a medida que aumenta el tamao del mensaje tambin lo hace el tiem-
po requerido para transmitirlo. Debemos observar que el retardo mnimo en la comunicacin
bloqueante es de 200 <>=@?A , tiempo requerido para transmitir un mensaje sin contenido (0
bytes).
8.2.2. Comunicacin No Bloqueante

Este test analiza el rendimiento de la comunicacin no bloqueante en nuestro sistema.
E JECUCIN
Ejecutaremos 16 procesos de los cuales dos de ellos se comunicarn. El tamao de los
mensajes variar entre 0 y 1024 bytes. Utilizaremos comunicacin no bloqueante. Para ejecu-
tarlo daremos la orden:
$ mpirun -np 16 mpptest -async -gnuplot

-fname ComNoBloq.mpl
La opcin -async provoca la utilizacin de mensajes no bloqueantes en la comunicacin.

Con esta orden el fichero ComNoBloq.gpl almacenar los datos para el grfico, mientras
que ComNoBloq.mpl contendr los comandos gnuplot para visualizarlos. Modificaremos
ste ltimo para comparar el rendimiento de la comunicacin bloqueante y el de la no blo-
queante, relacionndolos en el mismo grfico:

set title "Comparacion Comunicacion Bloqueante-No Bloqueante"
plot [] [:1200] ComNoBloq.gpl using 4:5 title "Com.No Bloqueante" \
with lines lt 1 lw 3, \
ComBloq.gpl using 4:5 title "Com.Bloqueante" \
exit
$ gnuplot ComNoBloq.mpl > ComNoBloq.eps
de los mensajes, mientras que el eje U mide el tiempo necesario para transmitirlo. La lnea
roja representa el rendimiento de la comunicacin no bloqueante y la azul el rendimiento de
la comunicacin bloqueante.

En el grfico observamos que los resultados son muy parecidos a los del test anterior. La
pequea sobrecarga que genera el proceso de sincronizacin en este tipo de mensajes no afecta
casi nada al rendimiento de la comunicacin.
8.2.3. Participacin Total de los Procesos

Este test analiza el rendimiento de la comunicacin bloqueante cuando todos los procesos
participan en la comunicacin.
E JECUCIN
Ejecutaremos 16 procesos de manera que todos ellos participen en la comunicacin. La
mitad de los procesos envan mensajes a la otra mitad. El tamao de los mensajes variar entre
0 y 1024 bytes. Para ejecutarlo daremos la orden:
Comparacion Comunicacion Bloqueante-No Bloqueante

1200
Com.No Bloqueante
Com.Bloqueante
1000
800
Tiempo (micro-seg)
600
400
200
0
0 200 400 600 800 1000 1200
Tamano (bytes)
Figura 8.2: Comparacin Com.Bloqueante - No Bloqueante
$ mpirun -np 16 mpptest -bisect -gnuplot -fname Bisect.mpl
La opcin -bisect provoca la participacin de todos los procesos en la comunicacin.

Con esta orden el fichero Bisect.gpl almacenar los datos para el grfico, mientras que
Bisect.mpl contendr los comandos gnuplot para visualizarlos. Modificaremos ste ltimo
para comparar el rendimiento de la comunicacin participativa y el de la no participativa,
relacionndolos en el mismo grfico:

set title "Comparacion Com.Participativa-No Participativa"
plot [] [:1600]Bisect.gpl using 4:5 title "Com.Participativa" \
with lines lt 1 lw 3, \
ComBloq.gpl using 4:5 title "Com.No Participativa" \
exit
$ gnuplot Bisect.mpl > Bisect.eps

Comparacion Com.Participativa-No Participativa

1600
Com.Participativa
Com.No Participativa
1400
1200
Tiempo (micro-seg)
1000
800
600
400
200
0
0 200 400 600 800 1000 1200
Tamano (bytes)
Figura 8.3: Comparacin Com. Participativa - No Participativa
de los mensajes, mientras que el eje U mide el tiempo necesario para transmitirlos. La lnea
roja representa el rendimiento de la comunicacin participativa y la azul el rendimiento de la
comunicacin no participativa.

En el grfico observamos que los resultados son algo distintos a los obtenidos en la co-
municacin bloqueante convencional. La sobrecarga en la comunicacin que genera la par-
ticipacin de todos los procesos queda reflejada en un aumento del tiempo requerido para
transmitir los mensajes. El retardo en la comunicacin aumenta conforme crece el tamao de
la informacin a transmitir.
8.2.4. Solapamiento entre Comunicacin y Procesamiento

Los algoritmos paralelos en general suelen solapar comunicacin y procesamiento en sus
ejecuciones. Este test analiza el impacto que tiene sobre el rendimiento del sistema dicho
solapamiento.
E JECUCIN
Ejecutaremos 16 procesos de los cuales dos de ellos se comunicarn. Al mismo tiempo el
sistema realizar un determinado procesamiento. El tamao de los mensajes quedar fijado en
0 bytes (mensajes sin contenido). Para realizarlo daremos la orden:
$ mpirun -np 16 mpptest -overlap -gnuplot

-fname Overlap.mpl
La opcin -overlap realiza un simple test que mide el impacto que produce el solapamiento
entre comunicacin y procesamiento en el rendimiento del sistema. Este test se lleva a cabo
enviando mensajes no bloqueantes sin contenido a la vez que se genera una carga variable de
procesamiento.
Con esta orden el fichero Overlap.gpl almacenar los datos para el grfico, mientras
que Overlap.mpl contendr los comandos gnuplot para visualizarlos. Modificaremos ste
ltimo para comparar el rendimiento de la comunicacin solapada y el de la no solapada,
relacionndolos en el mismo grfico:

set xlabel "Carga de Procesamiento (bytes)"
set title "Impacto Solapamiento Comunicacion-Procesamiento"
plot [] [182:194] Overlap.gpl using 4:5 title "Com.Solapada" \
exit
$ gnuplot Overlap.mpl > Overlap.eps
El grfico que obtenemos como resultado lo tenemos en la figura 8.4. El eje T representa la
carga de procesamiento medida en bytes, mientras que el eje U mide el tiempo necesario para
transmitir un mensaje con dicha carga. La lnea roja representa el rendimiento de la comuni-
cacin solapada.

Como observamos en el grfico la presencia de procesamiento no provoca una cada del
rendimiento de la comunicacin en nuestro sistema. sto es lgico debido a que contamos con
equipos relativamente potentes. De este modo el tiempo requerido para transmitir un mensaje
de 0 bytes es prcticamente el mismo independientemente de la carga de trabajo del proce-
sador.
Por otro lado observamos muchos picos en la lnea de la comunicacin solapada; ello se
debe a que la carga de procesamiento que genera este test es variable, por lo que la incidencia
sobre el rendimiento tambin ser variable.
8.2.5. Comunicacin Colectiva

Este test analiza el rendimiento de la comunicacin colectiva utilizando el programa goptest.
Impacto Solapamiento Comunicacion-Procesamiento

194
Com.Solapada
192
190
Tiempo (micro-seg)
188
186
184
182
0 200 400 600 800 1000 1200
Carga de Procesamiento (bytes)
Figura 8.4: Comparacin Com. Solapada - No Solapada
E JECUCIN
En el caso de las operaciones colectivas las mediciones no se deben basar slo en el tamao
de los mensajes, ya que no es la nica variable determinante; tambin debemos analizar el
nmero de procesos que intervienen en su ejecucin.
Goptest es el programa encargado de generar datos para grficos basndose en el nmero
de procesos. La dificultad que entraa este tipo de mediciones es que no pueden ser realizadas
en un solo paso; ello es debido a que el programa de arranque mpirun slo puede seleccionar
un nmero de procesos en la ejecucin cada vez. Por lo tanto debemos realizar una ejecucin
del test para cada nmero de procesos que queramos incluir en el test.
As pues realizaremos cuatro ejecuciones consecutivas para medir el comportamiento del
sistema en una comunicacin colectiva de 2, 4, 8 y 16 procesos. La operacin se comunicacin
colectiva que realizaremos ser una operacin de reduccin que sumar los valores de todos
los procesos. Dichos valores sern de tipo entero:
$ mpirun -np 2 goptest -isum -sizelist 32,256,512,1024

-gnuplot -fname Goptest.mpl
Como podemos observar el tipo de operacin colectiva se determina mediante una opcin. La
opcin isum indica la realizacin de una operacin de reduccin donde se suman los valores de
todos los procesos, siendo dichos valores de tipo entero. La opcin -sizelist indica los tamaos
de mensajes a utilizar en las pruebas. En todo caso vemos que la ejecucin de goptest es muy
similar a la de mpptest, coincidiendo en la mayora de las opciones disponibles.
Lo siguiente ser preparar el fichero de datos. Dado que realizamos cuatro ejecuciones,
en cada una de ellas agregamos de manera dispersa informacin al fichero Goptest.gpl.
Tendremos que preparar dicho fichero para que pueda ser utilizado por el programa gnuplot.
Con esta finalidad debemos agrupar la informacin para que el fichero quede sin lneas vacas,
dejndolo de la siguiente manera:
#np time (us) for various sizes

2 579.500000 2037.400000 3946.940000 7333.680000
4 1606.820000 5923.540000 11683.560000 22859.700000
8 4418.800000 14938.040000 30276.300000 60126.700000
16 10821.880000 37237.340000 73761.080000 137344.780000
Ahora tenemos el fichero Goptest.gpl, que almacena los datos para el grfico, y el fichero
Goptest.mpl, que contiene los comandos gnuplot para visualizarlos. Modificaremos ste
ltimo de manera que gnuplot genere un grfico Encapsulated Postscript manteniendo un
buen aspecto:
set term postscript eps color

set xlabel "Num.Procesos"
set title "Comunicacion Colectiva Op.Reduccion-Entero"
plot [] [:160000] Goptest.gpl using 1:2 title 32 \
with lines lt 1 lw 3,\
Goptest.gpl using 1:3 title 256 with lines lt 3 lw 3,\
Goptest.gpl using 1:4 title 512 with line lt 4 lw 3,\
Goptest.gpl using 1:5 title 1024 with lines lt 7 lw 3
exit
A continuacin daremos la siguiente orden para generar el grfico Goptest.eps:
$ gnuplot Goptest.mpl > Goptest.eps
El grfico que obtenemos como resultado lo tenemos en la figura 8.5. El eje T representa
el nmero de procesos utilizados, mientras que el eje U mide el tiempo necesario realizar la
comunicacin colectiva. La lnea roja representa el rendimiento de la comunicacin colectiva
utilizando los mensajes de 32 bytes, la azul los de 256 bytes, la morada los de 512 y la negra
los de 1024 bytes.
Comunicacion Colectiva Op.Reduccion-Entero

160000
32
256
512
140000 1024
120000
Tiempo (micro-seg)
100000
80000
60000
40000
20000
0
0 2 4 6 8 10 12 14 16
Num.Procesos
Figura 8.5: Grfico Comunicacin Colectiva
En el grfico podemos observar la incidencia que tienen sobre el rendimiento de la comu-

nicacin tanto el nmero de procesos que toman parte en ella como el tamao de los mensajes
que se transmiten . sto lo vemos claramente analizando dos datos:
Una comunicacin colectiva entre 16 procesos utilizando mensajes de 1024 bytes tarda
unos 140.000 <>=@?A , mientras que con 4 procesos (una cuarta parte) tarda aproximanda-
mente 22.000 <>=&?BA . Observamos una reduccin del 85 %.
Una comunicacin colectiva de 16 procesos utilizando mensajes de 1024 bytes tarda

uno 140.000 <>=&?BA , mientras que utilizando mensajes de 256 bytes (una cuarta parte) el
tiempo total es de 35.000 <>=@?A aproximadamente. En este ejemplo slo observamos una
reduccin del 75 %.
Con estos datos vemos que el nmero de procesos es una variable algo ms determinante
que el tamao de los mensajes, aunque esta ltima tambin reviste mucha importancia. Por lo
dems vemos que el crecimiento de las funciones es similar en todos los tamaos de mensajes,
y que este tipo de comunicacin en general consume ms tiempo que la comunicacin punto
a punto.
8.2.6. Fiabilidad
Este test comprueba la fiabilidad de la comunicacin en el sistema utilizando el programa
stress.
E JECUCIN
El programa stress realiza un test de fiabilidad sobre un determinado sistema. Este pro-
grama enva conjuntos de bits en mensajes de varios tamaos, y luego chequea cada bit del
mensaje recibido en el proceso receptor. Podemos utilizar el nmero de procesos que creamos
conveniente. Con la siguiente orden realizaremos un test con 4 procesos:
$ mpirun -np 4 stress
Por defecto el tamao de los mensajes que utiliza est comprendido entre 0 y 1024 bytes, con
un salto de 32 bytes entre un tamao y el siguiente. La comunicacin es de tipo bloqueante,
aunque sto lo podemos cambiar con la opcin -async.
A continuacin exponemos la salida que genera este programa:
Each to All
................................+
................................+
................................+
................................+
................................+
................................+
................................+
................................+
................................+
................................+
................................+
................................+
................................+
stress runs to Tue Jul 1 12:15:19 2003 (1) [0.641943 MB/s aggregate]
Stress completed 1 tests
2.108621e+08 bytes sent
La primera lnea , Each to All, indica que cada proceso enviar mensajes a todos los
dems. Cada una de las lneas de puntos representa una serie de mensajes que enviamos de
un proceso a otro. Al utilizar la opcin -verbose la lnea de puntos es sustituida por una
informacin para cada mensaje, que indica su tamao y el patrn utilizado para generar el
conjunto de bits que forma dicho mensaje; de esta manera cada lnea de puntos representa lo
siguiente:
.Running size = 32 longs with pattern ffffffff

+

El hecho de no obtener un mensaje de error quiere decir que el test ha sido satisfactorio y
que disponemos de un sistema fiable para la ejecucin de programas MPI.
Captulo 9
Evaluacin de los Algoritmos
El presente documento aborda dos aspectos de los algoritmos paralelos: su diseo y su

anlisis. El concepto de anlisis se refiere al proceso de determinar cunto de bueno es un al-
goritmo, o lo que es lo mismo, cunto de rpido y eficiente es en el uso que le da a los recursos
disponibles. En este captulo hablaremos sobre las distintas herramientas de monitorizacin
que nos ayudan a estudiar la ejecucin de los algoritmos, definiremos ms formalmente los
criterios utilizados en la evaluacin de su rendimiento y aplicaremos dicho anlisis a los algo-
ritmos implementados.
9.1. Herramientas de Monitorizacin

La extensin MPE (Multi-Processing Environment, Entorno de Multi-Procesamiento)
(seccin A.7) trata de proporcionar a los programadores un conjunto completo de herramientas
de anlisis del rendimiento para los programas MPI. Entre estas herramientas tenemos un
conjunto de libreras de monitorizacin, un conjunto de programas de utilidad y un conjunto
de herramientas grficas.
Las libreras de monitorizacin proporcionan una coleccin de funciones que generan in-
formacin acerca de la ejecucin de los programas MPI. Se pueden utilizar manualmente
mediante la insercin de llamadas MPE en los programas MPI, o bien automticamente, en-
lazando el cdigo MPI con las libreras MPE adecuadas. Normalmente se utiliza la segunda
opcin, como veremos ms adelante. Las libreras de monitorizacin que actualmente estn
incluidas, y que a continuacin pasaremos a describir con ms precisin, son las siguientes:
Librera de generacin de ficheros de recorrido de la ejecucin
Librera de representacin del trazado de la ejecucin
Librera de animacin en tiempo real
Los programas de utilidad incluidos en MPE son bsicamente utilidades para el manejo y
tratamiento de ficheros de recorrido, y las herramientas grficas se utilizan en su visualizacin.
Todo ello se analiza con ms detalle en la siguiente seccin.
143
144 CAPTULO 9. EVALUACIN DE LOS ALGORITMOS
9.1.1. Ficheros de Recorrido

La librera para la generacin de ficheros de recorrido es sin duda la ms til y ampliamente
usada en MPE. Dicha librera se utiliza para volcar informacin relativa a la ejecucin de las
llamadas MPI en un fichero. Dichos ficheros representan el recorrido de la ejecucin de los
programas MPI, siendo generados durante su ejecucin.
Actualmente existen tres formatos de fichero.
CLOG Es el formato por defecto. Bsicamente es una coleccin de eventos asociados a eti-
quetas temporales que representan el momento en que se produjeron. Almacena los
datos en formato binario.
ALOG Existe por motivos de compatibilidad hacia atrs. Almacena los eventos en formato
de texto ASCII. Actualmente no es mantenido ni desarrollado.
SLOG Es el ms potente. Proviene de Scalable LOGfile, Fichero de Recorrido Escalable.
Almacena los datos como estados (esencialmente eventos con una duracin) en un for-
mato binario especial, diseado para permitir el tratamiento de ficheros de recorrido
muy grandes (del tamao de varios Gigas).
9.1.1.1. Creacin
Generalmente el mtodo ms sencillo y seguro para la utilizacin de las libreras MPE es
mediante el enlace del cdigo MPI con las libreras MPE adecuadas. Para ello slo debemos
proporcionar un argumento (-mpilog) al comando de compilacin que usemos normalmente
(seccin A.5). En realidad sto slo debe hacerse en el momento de enlazar el cdigo.
Por ejemplo, para crear una versin del programa RTrap (algoritmo Regla del Trapecio)
que genere un fichero de recorrido, compilaremos y enlazaremos dando las siguientes rdenes:
$ mpicc -c RTrap.c
$ mpicc -o RTrap -mpilog RTrap.o
Aunque tambin podemos compilar directamente:
$ mpicc -o RTrap -mpilog RTrap.c
Dado que el formato por defecto de salida es CLOG, el fichero de recorrido que obtendremos
al ejecutar RTrap se llamar RTrap.clog.
Si queremos que el fichero tenga otro formato de salida debemos utilizar la variable de
entorno MPE_LOG_FORMAT. Dicha variable determina el formato de salida de los ficheros
de recorrido. Los valores permitidos para MPE_LOG_FORMAT son CLOG, SLOG y ALOG.
Cuando la variable MPE_LOG_FORMAT no est establecida se asume CLOG.
As pues, para generar el fichero de recorrido de RTrap en formato SLOG ejecutaremos
lo siguiente:
$ MPE_LOG_FORMAT=SLOG
$ export MPE_LOG_FORMAT
$ mpicc -c RTrap.c
$ mpicc -o RTrap -mpilog RTrap.o
De esta manera el fichero de recorrido que obtendremos al ejecutar RTrap ser RTrap.slog.
9.1. HERRAMIENTAS DE MONITORIZACIN 145
9.1.1.2. Visualizacin
Para visualizar el contenido de los ficheros de recorrido, lo ms recomendable es ejecu-
tar el programa logviewer. Este script emplea el visualizador adecuado para tratar el fichero
basndose en su extensin. Dependiendo del formato que tenga el fichero, logviewer emplear
un visualizador u otro. Si queremos informacin acerca de sus opciones ejecutaremos:
$ logviewer -help
Si lo que queremos es visualizar un fichero de recorrido ejecutaremos:
$ logviewer nombrefichero.extension
El programa logviewer utiliza los siguientes visualizadores para mostrar el contenido de los
ficheros de recorrido:
upshot Utilizado para visualizar ficheros con el formato ALOG. Analiza eventos asociados
a etiquetas temporales que representan el momento en que se produjeron, almacenados
en formato de texto ASCII.
jumpshot-2 Utilizado para visualizar ficheros con el formato CLOG. Este visualizador es una
evolucin de nupshot, el cual a su vez es una versin ms rpida de upshot. Analiza los
ficheros en formato binario y est escrito en Java. Su inconveniente radica en el impacto
que tiene sobre su rendimiento el tamao del fichero a analizar. Cuando el fichero CLOG
sobrepasa los 4MB su rendimiento se deteriora de manera significativa.
jumpshot-3 Utilizado para visualizar ficheros con el formato SLOG. Es la evolucin natural
de jumpshot-2 y tambin est escrito en Java. Este visualizador es fruto del esfuer-
zo de investigacin desarrollado para solucionar los problemas de rendimiento de su
antecesor. De este modo visualiza programas de una manera ms escalable. Debido al
formato de los ficheros que trata, este visualizador no analiza eventos convencionales
si no estados (esencialmente eventos con una duracin) en un formato binario especial,
diseado para permitir el tratamiento de ficheros de recorrido muy grandes (del tamao
de varios Gigas).
9.1.1.3. Conversin
Para convertir los ficheros de recorrido de un formato a otro, tenemos las siguientes her-
ramientas:
clog2slog Conversor de ficheros CLOG a SLOG. Es muy til en aquellos casos en los que
la generacin directa del fichero SLOG no funciona debido mal comportamiento del
programa MPI. Adems este conversor nos permite ajustar ciertos parmetros del fichero
de recorrido, como el segmento del fichero a mostrar, etc. Para obtener ms informacin
ejecutaremos:
$ clog2slog -h
clog2alog Coversor de ficheros CLOG a ALOG. Se proporciona por motivos de compatibili-

dad hacia atrs.
9.1.1.4. Impresin en Modo Texto

Para imprimir los ficheros de recorrido en modo texto, tenemos los siguientes programas:
slog_print Programa que imprime ficheros SLOG en modo texto por la salida estndar. Sirve
para chequear el contenido del fichero de recorrido. Si el fichero SLOG es demasiado
grande, puede no ser til usar slog_print. Adems cuando el fichero SLOG no est
completo slog_print no funcionar. Por lo tanto servir como un simple test para saber
si el fichero SLOG est generado completamente.
clog_print Programa que imprime ficheros CLOG en modo texto por la salida estndar.
9.1.2. Trazado de la Ejecucin

La librera para la representacin del trazado de la ejecucin muestra todas las llamadas a
funciones MPI.
Cada llamada a MPI imprime dos lneas de texto: una indicando que la llamada ha sido ini-
cializada y otra indicando que la llamada ha sido completada. Tanto la primera como la segun-
da estn precedidas por el identificador del proceso que la ejecuta en MPI_COMM_WORLD.
Todo sto se muestra por la salida estndar.
La mayora de las funciones de envo y recepcin de mensajes indican adems los valores
de algunos de sus parmetros, como contador, etiqueta y compaero (proceso destino en
envos y origen en recepciones).
El mtodo ms sencillo y seguro para la utilizacin de la librera de trazado MPE es me-
diante el enlace del cdigo MPI con las libreras MPE adecuadas. Para ello slo debemos pro-
porcionar un argumento (-mpitrace) al comando de compilacin que usemos normalmente
(seccin A.5). Como ya dijimos, sto slo debe hacerse en el momento de enlazar el cdigo.
As, para crear una versin del programa HolaMundo (algoritmo Hola Mundo!) que
muestre el trazado de su ejecucin, compilaremos y enlazaremos dando las siguientes rdenes:
$ mpicc -c HolaMundo.c
$ mpicc -o HolaMundo -mpitrace HolaMundo.o
$ mpicc -o HolaMundo -mpitrace HolaMundo.c
De este modo al ejecutar:
$ mpirun -np 2 HolaMundo
la salida que obtendremos ser parecida a lo siguiente:
Starting MPI_Init...
Starting MPI_Init...
[0] Ending MPI_Init
[0] Starting MPI_Comm_rank...
9.1. HERRAMIENTAS DE MONITORIZACIN 147
[0] Ending MPI_Comm_rank

[0] Starting MPI_Comm_size...
[0] Ending MPI_Comm_size
[0] Starting MPI_Get_processor_name...
[0] Ending MPI_Get_processor_name
Hola Mundo!
Numero Procesos: 2
[0] Starting MPI_Finalize...

[1] Ending MPI_Init
[1] Starting MPI_Comm_rank...
[1] Ending MPI_Comm_rank
[1] Starting MPI_Comm_size...
[1] Ending MPI_Comm_size
[1] Starting MPI_Get_processor_name...
[1] Ending MPI_Get_processor_name
[1] Starting MPI_Finalize...
[1] Ending MPI_Finalize
[0] Ending MPI_Finalize
9.1.3. Animacin en Tiempo Real

La librera grfica MPE contiene funciones que permiten la comparticin por parte de un
conjunto de procesos de una ventana X, de manera que no est asociada a ningn proceso
especfico.
La librera de animacin en tiempo real utiliza esta capacidad para dibujar flechas que
representan el trfico de mensajes mientras el programa se ejecuta. Observemos que los pro-
gramas MPI pueden generar eventos de comunicacin mucho ms rpidamente de lo que un
servidor X11 puede mostrar dichos eventos.
Al igual que lo que ocurre con otras libreras, el mtodo ms sencillo y seguro para la
utilizacin de la librera de animacin en tiempo real es mediante el enlace del cdigo MPI
con las libreras MPE adecuadas. Para ello debemos proporcionar un argumento (-mpianim)
al comando de compilacin que usemos normalmente (seccin A.5). Como ya dijimos, sto
slo debe hacerse en el momento de enlazar el cdigo.
Sin embargo la librera de animacin requiere el uso de operaciones del sistema X Window
as como operaciones de la librera matemtica. De este modo para crear una versin del
programa RTrap (algoritmo Regla del Trapecio) que produzca una animacin en tiempo real
de su ejecucin, compilaremos y enlazaremos dando las siguientes rdenes:
$ mpicc -c RTrap.c
$ mpicc -o RTrap -L/usr/X11R6/lib -lX11 -lm
-mpianim RTrap.o
Figura 9.1: Animacin en Tiempo Real
$ mpicc -o RTrap -L/usr/X11R6/lib -lX11 -lm

-mpianim RTrap.c
Debido a que dicha librera utiliza operaciones del sistema XWindow, puede que tengamos
problemas con los permisos de acceso al servidor X. En ese caso utilizaremos la orden xhost
para permitir el acceso al servidor X. Si tiene problemas con la configuracin de seguridad
consulte al administrador del sistema.
Al ejecutar la siguiente orden:
$ mpirun -np 4 RTrap
obtendremos una salida como que se muestra en la figura 9.1.
9.2. Criterios de Evaluacin

Una vez que un nuevo algoritmo ha sido diseado, normalmente es evaluado usando los
siguientes criterios: el tiempo de ejecucin, el nmero de procesadores usados y el coste.
Aparte de estas medidas estndar pueden utilizarse otras muchas medidas relacionadas con el
hardware, aunque slo deben ser empleadas cuando se conoce bien el entorno particular en
donde dicho algoritmo es ejecutado.
9.2.1. Tiempo de Ejecucin

Dado que la mejora en la velocidad computacional es la principal razn por la cual se
construyen sistemas paralelos, podemos decir que la medida ms importante en la evaluacin
de un algoritmo paralelo es su tiempo de ejecucin. Se define como el tiempo empleado por
un algoritmo para resolver un problema en un computador paralelo, desde el momento en
que comienza hasta que acaba. Si los procesadores implicados en al ejecucin no empiezan y
terminan su procesamiento al mismo tiempo, el tiempo de ejecucin ser calculado desde el
momento en que el primer procesador comienza su ejecucin, hasta que el ltimo procesador
termina.
9.3. RESULTADOS OBTENIDOS 149
9.2.2. Nmero de Procesadores

El segundo criterio ms importante en la evaluacin de un algoritmo es el nmero de
procesadores que requiere para resolver un problema. Cuesta dinero comprar, mantener y hac-
er que funcionen los computadores. Cuando varios procesadores estn presentes el problema
del mantenimiento se complica, y el precio necesario para garantizar un alto grado de fia-
bilidad aumenta de manera considerable. De esta manera, cuanto mayor sea el nmero de
procesadores que utiliza un algoritmo para resolver un problema, ms cara ser la solucin
que obtendremos.
9.2.3. Coste
El coste de un algoritmo se obtiene de la multiplicacin de las dos medidas anteriores; de
esta manera
Coste = Tiempo de ejecucin * Nmero de procesadores
sta es la medida ms indicativa del rendimiento de un algoritmo paralelo. De hecho ser la

que utilicemos en la evaluacin de nuestros algoritmos. Su precisin radica en que relaciona
el nmero de procesadores empleados con el tiempo de ejecucin obtenido; por lo tanto, nos
ser til para conocer en qu proporcin aumenta el rendimiento del sistema al incrementar el
nmero de procesadores.
9.3. Resultados Obtenidos

A continuacin realizaremos un anlisis del rendimiento alcanzado por los algoritmos de-
sarrollados de manera objetiva, intentando eliminar las variables que entorpezcan dicha obje-
tividad.
9.3.1. Algoritmo Clculo de reas mediante Montecarlo Bloqueante

E JECUCIN
En la ejecucin del presente algoritmo debemos tener en cuenta algunos asuntos para que
los tiempos arrojados por los tests realizados sean vlidos. Lo primero que debemos hacer es
eliminar el tiempo aadido por el usuario al introducir los datos. De esta manera fijaremos los
datos de entrada mediante operaciones de asignacin en el cdigo.
El segundo asunto es que necesitamos realizar bajo las mismas condiciones todas las eje-
cuciones. Los datos de entrada deben ser fijados siempre a los mismos valores. De este modo
intentaremos buscar el nmero PI calculando el rea de una circunferencia de radio 1 . Para
computarlo generaremos el nmero de muestras
200.000.000 .
En la figura 9.2 observamos el modelo de ejecucin del algoritmo regla del trapecio con 8
procesos.
150
CAPTULO 9. EVALUACIN DE LOS ALGORITMOS
Figura 9.2: Modelo Ejecucin Clculo de reas Bloqueante 8 Procesos
Nmero Procesadores Tiempo Coste

1 140,1 seg 140,1
2 71,3 seg 142,6
4 36,1 seg 144,4
8 19,4 seg 155,2
16 11,0 seg 176,0
Cuadro 9.1: Evaluacin Clculo de reas Bloqueante
El cuadro 9.1 contiene para cada nmero de procesadores empleado el tiempo de ejecu-
cin medido en segundos y el coste obtenido. En el grfico de la figura 9.3 exponemos la
relacin entre tiempo de ejecucin y nmero de procesadores. La figura 9.4 contiene la curva
de crecimiento del coste con respecto al nmero de procesadores.

El modelo de ejecucin de este algoritmo puede ser interpretado fcilmente. En un princi-
pio el proceso 0 distribuye los datos de entrada a los dems procesos enviando a cada uno un
mensaje bloqueante. Si hubiramos introducido los datos a travs del terminal en vez de haber
fijado variables en estas pruebas, este paso hubiera sido ms largo debido a que el resto de
procesos tendran que esperar a que el proceso 0 terminara de consultar los datos al usuario.
Una vez realizado este paso se produce el procesamiento interno en cada uno de los pro-
cesos durante el cual no existe comunicacin entre los procesos. Cuando los procesos culmi-
nan el tiempo de procesamiento envan su resultado local al proceso 0 mediante un mensaje
bloqueante. El proceso 0 recoge dichos resultados locales, calcula la media de todos ellos e
imprime el resultado global. Una vez hecho sto el programa termina.
Como podamos esperar, cuantos ms procesadores intervienen en la ejecucin menor es
el tiempo de ejecucin. Sin embargo el coste aumenta gradualmente con respecto al nmero de
procesadores. Por lo tanto deberamos emplear ms o menos procesadores dependiendo de la
necesidad que tengamos de acelerar el procesamiento y de los recursos que podamos utilizar,
intentando llegar a un compromiso entre rendimiento y coste que sea ptimo para nuestras
necesidades.
9.3.2. Algoritmo Clculo de reas mediante Montecarlo No Bloqueante

E JECUCIN
En la ejecucin del presente algoritmo debemos tener en cuenta algunos asuntos para que
los tiempos arrojados por los tests realizados sean vlidos. Lo primero que debemos hacer es
intentaremos buscar el nmero PI calculando el rea de una circunferencia de radio 1 . Para
computarlo generaremos el nmero de muestras
200.000.000 .
Calculo de Areas No Bloqueante: Tiempo Ejecucion

160
Tiempo Ejecucion
140
120
100
Tiempo (seg)
80
60
40
20
0
0 2 4 6 8 10 12 14 16
Numero de Procesadores
Figura 9.3: Grfico Tiempo Ejecucin Clculo de reas Bloqueante
Calculo de Areas Bloqueante: Coste

180
Coste
175
170
165
160
Coste
155
150
145
140
135
0 2 4 6 8 10 12 14 16
Figura 9.4: Grfico Coste Clculo de reas Bloqueante

9.3. RESULTADOS OBTENIDOS
153
Figura 9.5: Modelo Ejecucin Clculo de reas No Bloqueante 8 Procesos

1 139,9 seg 139,9
2 71,3 seg 142,6
4 35,7 seg 142,8
8 18,8 seg 150,4
16 10,7 seg 171,2
Cuadro 9.2: Evaluacin Clculo de reas No Bloqueante
procesos.
El cuadro 9.2 contiene para cada nmero de procesadores empleado el tiempo de ejecu-
cin medido en segundos y el coste obtenido. En el grfico de la figura 9.6 exponemos la
relacin entre tiempo de ejecucin y nmero de procesadores. La figura 9.7 contiene la curva
de crecimiento del coste con respecto al nmero de procesadores.

El modelo de ejecucin de este algoritmo puede ser interpretado fcilmente. En un prin-
cipio el proceso 0 distribuye los datos de entrada a los dems procesos enviando a cada uno
un mensaje no bloqueante. Si hubiramos introducido los datos a travs del terminal en vez de
haber fijado variables en estas pruebas, este paso hubiera sido ms largo debido a que el resto
de procesos tendran que esperar a que el proceso 0 terminara de consultar los datos al usuario.
Una vez realizado este paso se produce el procesamiento interno en cada uno de los proce-
sos durante el cual no existe comunicacin entre los procesos. Cuando los procesos culminan
el tiempo de procesamiento envan su resultado local al proceso 0 mediante un mensaje no
bloqueante. El proceso 0 recoge dichos resultados locales, calcula la media de todos ellos e
imprime el resultado global. Una vez hecho sto el programa termina.
Podemos observar que la versin no bloqueante de este algoritmo es un poco ms eficiente
que la versin bloqueante. Los tiempos de ejecucin son algo menores, y por lo tanto el coste
tambin. De este modo nos percatamos de la mejora en el rendimiento que proporciona la
comunicacin no bloqueante.
9.3.3. Algoritmo Regla del Trapecio

E JECUCIN
En la ejecucin de este algoritmo debemos tener en cuenta algunos asuntos para que los
tiempos arrojados por los tests realizados sean vlidos. Lo primero que debemos hacer es

140
Tiempo Ejecucion
120
100
Tiempo (seg)
80
60
40
20
0
0 2 4 6 8 10 12 14 16
Figura 9.6: Grfico Tiempo Ejecucin Clculo de reas No Bloqueante
Calculo de Areas No Bloqueante: Coste

175
Coste
170
165
160
Coste
155
150
145
140
135
0 2 4 6 8 10 12 14 16
Figura 9.7: Grfico Coste Clculo de reas No Bloqueante

156
CAPTULO 9. EVALUACIN DE LOS ALGORITMOS
Figura 9.8: Modelo Ejecucin Regla del Trapecio 8 Procesos

1 124,4 seg 124,4
2 62,2 seg 124,4
4 31,8 seg 127,2
8 16,5 seg 132,0
16 8,5 seg 136,0
Cuadro 9.3: Evaluacin Regla del Trapecio
intentaremos buscar el nmero PI a travs de la regla del trapecio. Para este propsito, y como
ya explicamos en la seccin 6.1, utilizaremos la funcin ^ ,.T\3
o
qp n4rs y el intervalo b DFE:1d .
Para computarlo utilizaremos el nmero de segmentos
1.000.000.000 .
procesos.
El cuadro 9.3 contiene para cada nmero de procesadores empleado el tiempo de ejecucin
medido en segundos y el coste obtenido. En el grfico de la figura 9.9 exponemos la relacin
entre tiempo de ejecucin y nmero de procesadores. La figura 9.10 contiene la curva de
crecimiento del coste con respecto al nmero de procesadores.
El modelo de ejecucin de este algoritmo puede ser interpretado fcilmente. En un princi-

pio se produce una operacin broadcast, con la cual distribuimos los datos de entrada desde el
proceso 0 hacia los dems procesos. Si hubiramos introducido los datos a travs del terminal
en vez de haber fijado variables en estas pruebas, este paso hubiera sido ms largo debido a
que el resto de procesos tendran que esperar a que el proceso 0 terminara de consultar los
datos al usuario.
Una vez realizado este paso se produce el procesamiento interno en cada uno de los pro-
cesos durante el cual no existe comunicacin entre los procesos. Cuando cada proceso ha cul-
minado su propio procesamiento el proceso 0 recoge los resultados de cada proceso a travs
de una operacin reduce. Luego el proceso 0 imprime los resultados y el programa termina.
Como podamos esperar, cuantos ms procesadores intervienen en la ejecucin menor es
el tiempo de ejecucin. Sin embargo el coste aumenta gradualmente a partir de la utilizacin
de 4 procesadores. Por lo tanto deberamos emplear ms o menos procesadores dependiendo
de la necesidad que tengamos de acelerar el procesamiento y de los recursos que podamos
utilizar, intentando llegar a un compromiso entre rendimiento y coste que sea ptimo para
nuestras necesidades.
Regla del Trapecio: Tiempo Ejecucion

140
Tiempo Ejecucion
120
100
Tiempo (seg)
80
60
40
20
0
0 2 4 6 8 10 12 14 16
Figura 9.9: Grfico Tiempo Ejecucin Regla del Trapecio
Regla del Trapecio: Coste

138
Coste
136
134
132
Coste
130
128
126
124
122
0 2 4 6 8 10 12 14 16
Figura 9.10: Grfico Coste Regla del Trapecio

Orden \ Num.Procs. 1 4 9 16
700 19,0 / 19,1 10,3 / 14,9 10,0 / 15,37 19,1 / 23,2
1400 172,0 / 172,2 59,8 / 78,4 50,1 / 70,9 57,3 / 78,9
2100 2237,2 / 2252,8 190,9 / 232,7 135,1 / 183,6 134,0 / 183,3
2800 - 430,1 / 504,3 274,9 / 362,3 261,1 / 344,8
3500 - 2074,1 / 2202,5 491,3 / 626,8 458,5 / 599,9
4200 - - 833,1 / 1032,6 726,7 / 930,2
4900 - - 1257,1 / 1527,3 1016,4 / 1291,9
Cuadro 9.4: Evaluacin Multiplicacin de Matrices de Fox
9.3.4. Algoritmo Multiplicacin de Matrices de Fox

E JECUCIN
El algoritmo que presentamos ahora tiene una serie de caractersticas que lo diferencian
del resto. Para evaluarlo debemos tener en cuenta una serie de factores.
El primer factor es la sobrecarga en la comunicacin. Para multiplicar matrices de orden
6 utilizando procesos, este algoritmo necesita hacer operaciones de broadcast y +*
operaciones simples de paso de mensajes. El tamao de cada uno de estos mensajes tampoco
es una cuestin a desconsiderar; cada uno de los mensajes deber pasar una matriz de orden
6$ , dato que coincide con el orden de las matrices locales de cada uno de los procesos.
El segundo factor es que no podemos ejecutarlo con cualquier nmero de procesadores. El
nmero de procesadores utilizado debe tener raiz entera para que una matriz cuadrada pueda
ser distribuida equitativamente entre los procesos.
En la figura 9.13 observamos el modelo de ejecucin del algoritmo regla del trapecio con
9 procesos.
El cuadro 9.4 muestra los tiempos obtenidos en la ejecucin del algoritmo Multiplicacin
de Matrices de Fox. Contiene para cada cantidad de procesadores empleados los tiempos
obtenidos en la multiplicacin de matrices de distintos rdenes; los dos tiempos separados
por el carcter / representan el tiempo requerido para multiplicar las matrices por un lado,
y por otro el tiempo requerido para multiplicarlas y mostrar el resultado. Dichos tiempos se
miden en segundos. Para cada orden de matrices utilizado resaltaremos en negrita el tiempo
de multiplicacin ptimo.
Los tiempos marcados con el carcter - son omitidos debido a que no son razonables;
dichos clculos tardan demasiado. De este modo comprendemos el carcter exponencial de la
curva de crecimiento del tiempo con respecto al tamao de las matrices a multiplicar.
La figura 9.11 muestra la curva de crecimiento del tiempo de ejecucin con respecto al
orden de las matrices para cada una de las cantidades de procesos empleados. La figura 9.12
hace lo propio con el coste.
Comparacion Tiempo de distintas Cantidades de Procesos

2500
16
9
4
1
2000
1500
Tiempo (seg)
1000
500
0
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Orden Matriz
Figura 9.11: Comparacin Tiempos de distintas Cantidades de Procesos
Comparacion Coste de distintas Cantidades de Procesos
16
18000 9
4
1
16000
14000
12000
Coste
10000
8000
6000
4000
2000
0
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Orden Matriz
Figura 9.12: Comparacin Costes de distintas Cantidades de Procesos

9.3. RESULTADOS OBTENIDOS
161
Figura 9.13: Modelo Ejecucin Algoritmo de Fox 9 Procesos

El modelo de ejecucin de este algoritmo con 9 procesos demuestra la sobrecarga en la co-
municacin que genera. Cada uno de los procesos en ejecucin realiza 3 operaciones de brad-
cast y 6 de paso de mensajes bloqueantes (en realidad la funcin MPI_Sendrecv_replace()
realiza un envo y una recepcin por cada llamada). Cada una de los mensajes transmitidos
tendr al menos el mismo tamao que las matrices locales de los procesos. Una vez que los
procesos culminan el procesamiento de sus matrices locales, envan los resultados al proceso
0 para generar la salida.
Como podemos observar en la figura 9.11 el crecimiento del tiempo de ejecucin es ex-
ponencial para todas las cantidades de procesos utilizadas; sin embargo dicho crecimiento es
ms paulatino cuanto mayor es la cantidad de procesos empleados.
En la figura 9.12 observamos que el coste depende tanto del nmero de procesos emplead-
os como del tamao de las matrices a multiplicar. De hecho vemos que para matrices de orden
mayor a 2000 la utilizacin de 1 slo procesador es la ms costosa. Con este planteamiento
podemos prever que para tamaos de matrices superiores a los empleados en las pruebas la
utilizacin de 16 procesadores ser la ms rentable.
Apndice A
Instalacin, Configuracin y Manejo

de MPICH
MPICH es una implementacin del estndar MPI desarrollada por el Argonne National
Laboratory que funciona en una amplia variedad de sistemas. MPICH contiene, adems de la
librera MPI, un entorno de programacin para trabajar con programas MPI. El entorno de pro-
gramacin incluye un programa de arranque de procesos portable, libreras de monitorizacin
destinadas a analizar el rendimiento de los programas, y una interfaz grfica para X Window.
Las caractersticas principales de MPICH son las siguientes:
Compatibilidad total con MPI-1.2, incluyendo cancelaciones de envos.
Soporte para clusters heterogneos.
Los enlaces con C++ incluidos en la especificacin MPI-2 estn disponibles para las
funciones MPI-1.
Enlaces con Fortran 77 y Fortran 90.
Una versin de cdigo abierto est disponible para Windows NT. La instalacin, con-
figuracin y manejo de esta versin son diferentes a las explicadas en este apndice, el
cual cubre slo la versin Unix de MPICH.
Soporte para una amplia variedad de entornos, incluyendo MPPs y clusters de SMPs.
Sigue la mayora de las recomendaciones GNU acerca de la instalacin y compilacin,

incluyendo VPATH.
Compatibilidad con algunas partes de la especificacin MPI-2, de modo que incluye:

; La mayora de las funcionalidades de E/S paralela (MPI-IO) a travs de la imple-
mentacin ROMIO.
; Algunas funcionalidades de administracin de hilos (MPI_INIT_THREAD).
; Nuevas funciones MPI_Info() y MPI_Datatype().
163
164 APNDICE A. INSTALACIN, CONFIGURACIN Y MANEJO DE MPICH
Incluye componentes pertenecientes al entorno de programacin paralela, como son:

; Herramientas de monitorizacin.
; Herramientas para la visualizacin de los anlisis del rendimiento (upshot y jump-
shot).
; Amplios tests de fiabilidad y rendimiento.
; Ejemplos de aplicaciones tanto simples como complejos.
A.1. Dispositivos
La portabilidad de MPICH proviene de su diseo en dos capas. La mayor parte del cdigo
de MPICH es independiente del hardware y est implementado por encima de una ADI (Ab-
stract Device Interface, Interfaz de Dispositivo Abstracto). La interfaz ADI, llamada tambin
dispositivo, oculta la mayora de los detalles especficos del hardware permitiendo que MPICH
sea portado fcilmente a nuevas arquitecturas. La interfaz ADI (o dispositivo) se encarga de
facilitar el acceso al hardware de una manera eficiente, mientras que el resto del cdigo por
encima de la ADI se encarga de la sintaxis y la semntica de MPI.
A continuacin mostramos una lista con los dispositivos (ADIs) disponibles en MPICH.
Clusters, Beowulf y Estaciones de Trabajo Individuales. Los dispositivos ms importantes

son ch_p4 y ch_p4mpd. El dispositivo ch_p4 es el ms general y soporta nodos SMP,
programas MPMD y sistemas heterogneos. El dispositivo ch_p4mpd (ms rpido) so-
porta slo clusters homogneos de uniprocesadores, pero proporciona un arranque ms
rpido y escalable.
Topologas de tipo Rejilla. El dispositivo globus2 utiliza Globus (URL 19) para proporcionar
una implementacin diseada para topologas de tipo rejilla. Este dispositivo es apropi-
ado para sistemas en los que est instalado Globus.
Multiprocesadores Simtricos. El dispositivo ch_shmem es apropiado para sistemas basa-

dos en memoria compartida. Utiliza la memoria compartida para pasar mensajes entre
los procesadores, y hace uso de las facilidades proporcionadas por el sistema operati-
vo. El dispositivo ch_lfshmem es una versin de ch_shmem que no utiliza bloqueos,
desarrollada para el NEC-SX4.
Procesadores Paralelos Masivos (MPPs). MPICH fue desarrollado originalmente para pro-
porcionar una implementacin MPI a la mayora de los MPPs existentes, cada uno de
los cuales tiene su propio sistema de paso de mensajes. De este modo se incluyen los
dispositivos ch_meiko, ch_nx y ch_mpl en las distribuciones de MPICH.
Otros. MPICH ha sido diseado para permitir que otros grupos lo usen cuando desarrollen
sus propias implementaciones MPI. Tanto las compaas privadas como los grupos de
investigacin han usado MPICH como base para sus implementaciones. Una imple-
mentacin importante desarrollada de esta manera es MPICH-GM, la cual se emplea en
clusters Myrinet conectados mediante hubs dedicados.
A.2. OBTENCIN 165
A.2. Obtencin
El primer paso para poder utilizar MPICH ser descargarlo e instalar los parches necesar-
ios:
1. Obtener MPICH. El camino ms fcil para hacerlo es usar la seccin de descargas de

su pgina web (URL [10]). De esta manera podremos descargar fcilmente el fichero
mpich.tar.gz. Dicho fichero contiene la distribucin MPICH completa.
2. Descomprimir el fichero mpich.tar.gz en un directorio de trabajo. Se recomienda us-

ar una particin montada localmente antes que usar una particin NFS (Network File
System, Sistema de Ficheros en Red). La mayora de los sistemas tienen el directo-
rio /tmp o /sandbox montado localmente. Asegrese de que existe espacio sufi-
ciente disponible (100MB debera ser ms que suficiente). Para descomprimir el fichero
mpich.tar.gz (asumiendo que ha sido descargado en /tmp) usaremos:
$ cd /tmp
$ gunzip mpich.tar.gz
$ tar -xvf mpich.tar
3. Aplicar los parches. Visite la seccin de parches de la pgina web de MPICH (URL [11])
para verificar la existencia de parches que pueda necesitar. Normalmente las versiones
disponibles de MPICH tienen ya aplicados dichos parches; sto queda indicado por
cuatro nmeros en el nombre de la versin (p.ej. 1.2.2.3). En otros casos el parche
aislado se pone a disposicin antes que la versin parcheada. Para aplicar estos parches
siga las instrucciones expuestas en la pgina indicada y en la documentacin.
A.3. Compilacin e Instalacin

Antes de poder usar MPICH debemos configurarlo y compilarlo. El proceso de configu-
racin analiza nuestro sistema y determina las opciones y ajustes correctos; adems crea el
fichero Makefile, utilizado para compilar MPICH.
1. Decida dnde quiere instalar MPICH. Este paso no es estrictamente necesario (excep-
to en el caso del dispositivo ch_p4mpd); sin embargo la instalacin de MPICH (que
puede realizarse sin necesidad de privilegios en un directorio de usuario) hace ms f-
cil la aplicacin de actualizaciones y permite una reduccin del espacio en disco que
MPICH necesita, ya que la versin instalada slo contiene libreras, cabeceras, docu-
mentacin y algunos programas de soporte. Se recomienda una ruta de instalacin que
contenga el nmero de versin de MPICH. Para instalar MPICH de manera que puedan
usarlo otros usuarios podramos escoger el directorio /usr/local/mpich-1.2.4/, aunque
debemos tener en cuenta los permisos necesarios para hacerlo. Si estamos instalando
slo para uso propio, podramos usar algo como /home/me/software/mpich-1.2.4.
2. Invocar configure con el argumento -prefix adecuado:

$ ./configure -prefix=$HOME/mpich-1.2.4 | tee c.log
Este comando hace que MPICH utilice el dispositivo ch_p4 por defecto ; sta es nor-
malmente la eleccin adecuada. La salida de configure es encauzada hacia tee; este pro-
grama escribe la salida tanto en el fichero especificado en su argumento (aqu c.log)
como en la salida estndar . Si tenemos problemas en la configuracin o la compilacin
el fichero c.log nos servir de ayuda para identificar los posibles problemas.
En la seccin A.4.3 se explica cmo utilizar el programa ssh en vez de rsh para el
arranque de procesos remotos.
3. Compilar MPICH:
$ make | tee make.log
sto puede llevar un tiempo dependiendo de la carga de nuestro sistema y de nuestro

servidor de ficheros; puede durar desde algunos minutos hasta una hora o ms.
4. (Opcional) Si queremos instalar MPICH en un lugar pblico de manera que los dems
usuarios puedan usarlo, ejecutaremos:
$ make install
De este modo instalaremos MPICH en el directorio especificado por el argumento -

prefix del comando configure. La instalacin estar formada por los directorios in-
clude, lib, bin, sbin, www y man, adems de un pequeo directorio con ejem-
plos. Si queremos eliminar la instalacin debemos usar el script sbin/mpiuninstall
dentro del directorio de MPICH.
A.4. Configuracin
A.4.1. El Fichero de Mquinas
Cuando utilizamos el dispositivo ch_p4 el programa mpirun utiliza un fichero llamado
fichero de mquinas, el cual lista las mquinas o nodos que estn disponibles para ejecutar
programas MPICH.
La manera ms fcil de crear un fichero de mquinas consiste en editar el fichero mpich/u-
til/machines/machines.xxxx, el cual contiene los nombres de las mquinas pertenecientes a
la arquitectura xxxx. Cuando mpirun es ejecutado, el nmero de hosts requerido por dicho co-
mando es seleccionado del fichero de mquinas para su ejecucin. No existe una planificacin
compleja para elegir qu mquina usar; las mquinas son seleccionadas desde el principio del
fichero. Para ejecutar todos los procesos en una sola mquina, simplemente pondremos en
todas las lneas del fichero la misma mquina.
Debemos advertir que el fichero de mquinas no puede contener lneas en blanco. En caso
de querer darle cierta estructura y para aadir comentarios utilizaremos el carcter #. Un
ejemplo del fichero machines.LINUX podra ser:
A.4. CONFIGURACIN 167
#FICHERO MAQUINAS ARQ. LINUX

galba
neron
oton
#
vitelio
vespasiano
tito
#FINAL FICHERO MAQUINAS
Los nombres deben ser proporcionados con el mismo formato que la salida del comando
hostname. Por ejemplo, si el resultado de hostname en galba fuera galba.aulas y lo mis-
mo sucediera para los dems nombres, el fichero de mquinas sera entonces:

galba.aulas
neron.aulas
oton.aulas
#
vitelio.aulas
vespasiano.aulas
tito.aulas
En el caso de que tengamos nodos con mltiples procesadores, debemos indicar su nmero
de procesadores tras su nombre y dos puntos. Por ejemplo, si en el ejemplo anterior vitelio
tuviera dos procesadores el fichero de mquinas sera:

galba
neron
oton
#
vitelio:2
vespasiano
tito
A.4.2. RSH
El programa rsh (Remote SHell, Shell Remoto) es utilizado para iniciar procesos re-
motos en general. Si pretendemos usar rsh con el dispositivo ch_p4 necesitaremos configurar
nuestra mquina para permitir el uso de rsh. Por motivos de seguridad slo debemos hacer
sto si somos un administrador del sistema y entendemos lo que estamos haciedo, o en el caso
de que utilicemos una red aislada. Por ejemplo, si estamos utilizando una red Linux en nuestra
casa o en el trabajo, y estas mquinas no estn conectadas a una red ms grande, debemos
seguir las siguientes instrucciones. Si por el contrario alguna de nuestras mquinas est conec-
tada a otra red, debemos preguntarle a nuestro administrador del sistema acerca de la poltica
de utilizacin de rsh. Como alternativa podemos usar ssh.
Lo siguiente explica cmo configurar una mquina de manera que pueda usar rsh para
iniciar un proceso en ella misma. Para ello debemos asegurarnos de que exista un fichero
/etc/hosts.equiv que contenga al menos las siguientes lneas:
localhost
nombre_maquina
donde nombre_maquina es el nombre que le damos a nuestra mquina en /etc/hosts. Para

este propsito tambin podemos utilizar el fichero .rhosts en el directorio de casa si quer-
emos aplicarlo slo a una cuenta de usuario. Por otro lado debemos asegurarnos de que los
ficheros /etc/hosts.allow y /etc/hosts.deny estn vacos.
A.4.3. SSH
El mecanismo habitual para el arranque de procesos remotos al utilizar el dispositivo
ch_p4 en redes es rsh. El uso de rsh requiere ciertos permisos en las mquinas implicadas. Sin
embargo en algunas redes no conviene establecer los permisos de esta manera. La alternativa
ms simple a rsh es el uso de ssh (Secure Shell, Shell Seguro). ste puede ser utilizado como
mecanismo seguro de procesamiento distribuido. Requiere cierta configuracin que describire-
mos seguidamente, aunque su utilizacin es muy sencilla. Dicha configuracin depende de la
versin de ssh que vayamos a utilizar.
Exponemos a continuacin el conjunto de pasos necesarios para que ssh funcione correc-
tamente con MPICH.
1. Debemos asegurarnos de que ssh est instalado en nuestra red y, en caso de estarlo,
compruebaremos su versin. Si no est instalado podemos obtenerlo nosotros mismos
(URL [12]).
2. Crear nuestra clave de autentificacin.
a) Si utilizamos SSH Versin 1 ejecutaremos:

$ ssh-keygen
sto crear el par clave privada/pblica. La clave privada se almacenar en
~/.ssh/identity
y la clave pblica se guardar en
~/.ssh/identity.pub
b) Si utilizamos SSH Versin 2 ejecutaremos:
A.4. CONFIGURACIN 169
$ ssh-keygen -t dsa
Si no lo hacemos as, generaremos una clave rsa1 que no podr ser usada con SSH
Versin 2. Dicha orden crear el par clave privada/pblica. La clave privada se
almacenar en
~/.ssh/id_dsa
y la clave pblica se guardar en
~/.ssh/id_dsa.pub
3. Autorizar el acceso. Si estamos utilizando SSH Versin 1 aada su clave pblica al

fichero /.ssh/authorized_keys. Todas las claves de este fichero tendrn permitido el
acceso:
$ cp ~/.ssh/identity.pub ~/.ssh/authorized_keys
Si la mquina a la que queremos conectarnos no comparte el sistema de ficheros, en-

tonces debemos copiar el fichero ~/.ssh/identity.pub sobre el fichero
~/.ssh/authorized_keys de la mquina a la que queremos conectarnos. Debemos ase-
gurarnos de que el fichero ~/.ssh/authorized_keys no tenga permiso de escritura por
parte de los miembros de nuestro grupo, de manera que tendremos que ejecutar:
$ chmod go-rwx ~/.ssh/authorized_keys
En caso de utilizar SSH Versin 2 copiaremos el fichero id_dsa.pub sobre autho-

rized_keys2 en vez de authorized_keys. Por lo dems todo es igual.
Una vez hechos estos cuatro pasos ya podremos utilizar ssh en nuestro sistema. Ahora ten-
dremos que indicar a MPICH que haga uso de dicho programa; sto puede hacerse de dos
formas:
Ejecutar configure con la opcin -rsh=ssh para que el dispositivo ch_p4 utilice ssh en
vez de rsh. De esta manera tambin los scripts sern modificados para hacer uso de ssh.
Si MPICH ya haba sido compilado antes debemos reconfigurar y recompilar utilizando
los siguientes comandos:
$ configure -rsh=ssh
$ make
Si no es as utilizaremos las opciones -prefix para indicar el directorio de la instalacin,

y -rsh=ssh para elegir ssh como programa de arranque de procesos remotos. Luego
compilaremos:
$ ./configure -rsh=ssh -prefix=$HOME/mpich-1.2.4

| tee c.log
$ make
Establecer la variable de entorno P4_RSHCOMMAND de manera que contenga el nom-

bre del programa a utilizar como arranque de procesos remotos. En nuestro caso eje-
cutaremos:
$ P4_RSHCOMMAND=ssh
$ export P4_RSHCOMMAND
En caso de tener problemas:
Asegrese de que las mquinas listadas en nuestro fichero de mquinas estn tambin
listadas en el fichero /etc/ssh_known_hosts de la red o en el fichero
~/.ssh/known_hosts en el directorio de casa.
Es importante que el directorio /tmp tenga los permisos establecidos a 03777, con
root como dueo y grupo 0.
Openssh tiene el argumento -v, el cual es muy til para identificar posibles problemas.
A.4.4. Secure Server

Dado que todas las estaciones de trabajo pertenecientes a un cluster requieren (usualmente)
que cada nuevo usuario se conecte mediante login y password, y debido a que este proceso con-
sume mucho tiempo, MPICH proporciona un programa que puede ser utilizado para acelerar
este proceso. Este programa se llama Secure Server (Servidor Seguro) y se localiza en el
fichero bin/serv_p4 dentro del directorio de instalacin de MPICH.
El script bin/chp4_servs puede ser utilizado para iniciar el servidor seguro en aquellas
estaciones de trabajo en las que podamos ejecutar programas remotos mediante rsh, ssh o sim-
ilar. Tambin podemos iniciar el servidor a mano y permitir que se ejecute en segundo plano;
sto es apropiado en mquinas que no acepten conexiones remotas y sin embargo tengamos
una cuenta en ellas.
El servidor seguro requerir al usuario que introduzca un password si los ficheros /etc/hosts
o $HOME/.rhosts no tienen las entradas adecuadas. En otras palabras, si rsh requiere un
password, tambin lo requerir el servidor seguro. De este modo el servidor seguro tiene dos
implicaciones bien diferenciadas en la seguridad:
1. Para ejecutarlo de manera remota en otras mquinas necesitamos tener conexin rsh,
ssh o similar con ellas.
2. El servidor seguro utiliza el mismo procedimiento que rsh para comprobar los permisos
de ejecucin de los usuarios remotos.
Por lo tanto la manera ms cmoda de utilizarlo es empleando rsh como programa de arranque
de procesos remotos. Por otro lado tambin podemos usar ssh para ejecutar el servidor de
manera remota, y establecer la configuracin adecuada para poder ejecutar procesos mediante
el servidor seguro (aunque ni siquiera est instalado rsh). En este caso debemos tener en cuenta
que los scripts generados por MPICH utilizan por defecto rsh para su ejecucin; si queremos
que dichos scripts hagan uso de ssh, tendremos que modificarlos o configurar MPICH con la
opcin -rsh=ssh.
A.5. COMPILACIN Y ENLACE DE PROGRAMAS 171
Debemos aclarar que tanto el fichero serv_p4 como chp4_servs se encuentran en di-
rectorios pertenecientes a la instalacin de MPICH, generados por la ejecucin del comando
make install (seccin A.3).
Antes de arrancar el servidor debemos comprobar si el servidor seguro ha sido inicializado
en nuestro sistema para uso general; si es as, el mismo servidor puede ser utilizado por todos
los usuarios. Para realizarlo de esta manera necesitamos acceder al sistema como root. Si
el servidor seguro no ha sido inicializado, entonces podemos inicializarlo para nuestro uso
personal sin necesisdad de privilegios especiales con la orden:
$ chp4_servs -port=1234
Esta orden inicializa el servidor seguro en todas las mquinas listadas en el fichero de mquinas
(seccin A.4.1). El nmero de puerto proporcionado por la opcin -port (por defecto 1234)
debe ser diferente del resto de puertos utilizados en las estaciones de trabajo.
Para hacer uso del servidor seguro con el dispositivo ch_p4 debemos establecer las sigu-
ientes variables de entorno:
$ MPI_USEP4SSPORT=yes
$ export MPI_USEP4SSPORT
$ MPI_P4SSPORT=1234
$ export MPI_P4SSPORT
El valor de MPI_P4SSPORT debe ser el nmero de puerto en el cual inicializamos el servi-

dor seguro. Cuando estas variables de entorno estn establecidas, mpirun intenta utilizar el
servidor seguro para arrancar programas que usen el dispositivo ch_p4; si sto no da resultado
utilizar el programa de arranque de procesos remotos que tengamos por defecto (normal-
mente rsh o ssh). Tambin podemos hacer que mpirun utilice el servidor seguro empleando
la opcin -p4ssport <num>, que indica el nmero de puerto donde el servidor seguro est
instalado.
A.5. Compilacin y Enlace de Programas

La implementacin MPICH proporciona cuatro comandos para compilar y enlazar progra-
mas escritos en C (mpicc), C++ (mpiCC), Fortran 77 (mpif77) y Fortran 90 (mpif90).
Estos comandos se emplean de la misma manera en la que se utilizan los compiladores
de C, Fortran 77, C++ y Fortran 90. Por ejemplo, para compilar utilizaramos las siguientes
rdenes:
mpicc -c foo.c
mpif77 -c foo.f
mpiCC -c foo.C
mpif90 -c foo.f
Mientras que para enlazar utilizaramos:

mpicc -o foo foo.o

mpif77 -o foo foo.o
mpiCC -o foo foo.o
mpif90 -o foo foo.o
Las rdenes para enlazar cdigo pueden requerir la inclusin de libreras adicionales. Por
ejemplo, para utilizar la librera de funciones matemticas de C usaramos la siguiente orden:
mpicc -o foo foo.o -lm
Tambin podemos combinar la compilacin y el enlace en una sola orden, como exponemos a
continuacin:
mpicc -o foo foo.c

mpif77 -o foo foo.f
mpiCC -o foo foo.C
mpif90 -o foo foo.f
Notar que mientras los sufijos .c para los programas en C y .f para los programas en Fortran-77
son estndar, no existe concenso para los sufijos de los programas escritos en C++ y Fortran-
90. Los sufijos mostrados en los ejemplos expuestos son aceptados por la mayora de los
sistemas, aunque no todos. MPICH intenta determinar los sufijos aceptados, pero no es capaz
siempre.
Podemos modificar la eleccin del compilador a utilizar por MPICH especificando las vari-
ables de entorno MPICH_CC, MPICH_F77, MPICH_CCC y MPICH_F90. Sin embargo sto
slo funcionar si el compilador alternativo es compatible con el compilador por defecto (esto
quiere decir que utilice los mismos tamaos para los tipos de datos y sus composiciones, y que
genere un cdigo objeto que sea compatible con el utilizado en las libreras MPICH). Si lo que
queremos es modificar el enlazador, utilizaremos las variables de entorno MPICH_CLINKER,
MPICH_F77LINKER, MPICH_CCLINKER y MPICH_F90LINKER.
Si lo que queremos es ver los comandos que utilizara la orden de compilacin sin ejecu-
tarlos realmente emplearemos el argumento -show.
Las siguientes opciones nos ayudan a acceder a las libreras de monitorizacin del entorno
MPE:
-mpilog Compila una versin que genera el fichero de recorrido de la ejecucin.
-mpitrace Compila una versin que muestra el trazado de la ejecucin.
-mpianim Compila una versin que genera animacin en tiempo real.
A.6. Ejecucin de Programas con mpirun

Para ejecutar programas MPI debemos utilizar el programa mpirun, localizado en el di-
rectorio bin/ de MPICH. Bajo la mayora de los sistemas podremos usar la orden
mpirun -np 4 a.out

A.7. EXTENSIN MPE 173
para ejecutar el programa a.out en 4 procesadores. La orden mpirun -help nos ofrece una
lista completa de las opciones que tiene este programa.
Como salida mpirun retorna el status de uno de los procesos, usualmente el proceso con
identificador 0 en MPI_COMM_WORLD.
A.7. Extensin MPE

Como ya sabemos, MPI proporciona una base estable para la construccin de programas
paralelos. Uno de los objetivos de su diseo es permitir la construccin de extensiones que
contengan libreras de software paralelo que ayuden en el desarrollo de aplicaciones paralelas
extensas.
La extensin MPE (Multi-Processing Environment, Entorno de Multi-Procesamiento)
explota las caractersticas de MPI para ofrecer una serie de facilidades tiles. Dicha extensin
fu desarrollada para la implementacin MPICH (estando incluida en su distribucin), aunque
puede ser usada por cualquier implementacin MPI.
Actualmente los principales componentes de MPE son:
Libreras de monitorizacin utilizadas para generar informacin acerca del rendimiento

de los programas MPI, y herramientas para el estudio y visualizacin de dicha informa-
cin.
Librera grfica para la ejecucin de programas paralelos en X Window.
Funciones para la secuencializacin del cdigo ejecutado en paralelo.
Funciones para la depuracin de errores.

Apndice B
Manual de Referencia
Este apndice describe de manera resumida las funciones MPI utilizadas en los algoritmos
implementados. Pretendemos que sea una gua til como manual de consulta. Para mayor
comodidad las funciones estn expuestas en orden alfabtico.
Para cada una de las funciones definimos su funcionalidad y su sintaxis, especificando
cules son los parmetros de entrada y los de salida. Por ltimo, en algunos casos haremos un
breve comentario acerca de su funcionamiento.
175
176 APNDICE B. MANUAL DE REFERENCIA
B.1. MPI_Bcast
F UNCIONALIDAD
Enva un mismo mensaje desde un proceso a todos los dems. Es una operacin de comu-
nicacin colectiva.
S INTAXIS
int MPI_Bcast(void* mensaje, int contador,
MPI_Datatype tipo_datos, int raiz,
MPI_Comm com);
PARMETROS E NTRADA /S ALIDA

mensaje Direccin inicial de memoria del mensaje a enviar/recibir
contador Nmero de elementos del tipo tipo_datos que componen el mensaje
tipo_datos Tipo de datos MPI de cada elemento del mensaje (Cuadro 5.1)
raiz Identificador del proceso que enva el mensaje
com Comunicador en el cual se produce la comunicacin
C OMENTARIOS
Si el soporte hardware se hace responsable de la ejecucin de esta funcin, generalmente
se implementa mediante un algoritmo que estructura un modelo de comunicacin en rbol
entre los procesos. Para ms informacin, lase la seccin ??.
B.2. MPI_CART_COORDS 177
B.2. MPI_Cart_coords
F UNCIONALIDAD
Retorna las coordenadas de un proceso en un comunicador de topologa cartesiana, dado
su identificador.
S INTAXIS
int MPI_Cart_coords(MPI_Comm cart_com, int id,
int* coordenadas)
PARMETROS E NTRADA
cart_com Comunicador de topologa cartesiana
id Identificador del proceso dentro del comunicador cart_com
numero_dimensiones Nmero de dimensiones del vector coordenadas
PARMETROS S ALIDA
coordenadas Vector de enteros (de tamao numero_dimensiones) que contiene las coorde-
nadas cartesianas del proceso
B.3. MPI_Cart_create
F UNCIONALIDAD
Crea un nuevo comunicador de topologa cartesiana (tipo rejilla).
S INTAXIS
int MPI_Cart_create(MPI_Comm antiguo_com,
int* tam_dimensiones,
int* periodicidades,
int reordenamiento,
MPI_Comm* com_cartesiano)
PARMETROS E NTRADA
antiguo_com Comunicador original a partir del cual creamos el nuevo comunicador de topologa
cartesiana
numero_dimensiones Nmero de dimensiones de la rejilla cartesiana que queremos crear
tam_dimensiones Vector de enteros de tamao numero_dimensiones que especifica el nmero

de procesos en cada dimensin
periodicidades Vector de booleanos de tamao numero_dimensiones que especifica para

cada dimensin si es peridica (verdadero) o no (falso)
reordenamiento Booleano que especifica si pueden ser reordenados los identificadores de los
procesos (verdadero) o no (falso). En muchos casos es apropiado para la optimizacin
del sistema, en otros no es significante.
PARMETROS S ALIDA
com_cartesiano Nuevo comunicador de topologa cartesiana
B.4. MPI_CART_RANK 179
B.4. MPI_Cart_rank
F UNCIONALIDAD
Retorna el identificador de un proceso en un comunicador de topologa cartesiana, dadas
sus coordenadas.
S INTAXIS
int MPI_Cart_rank(MPI_Comm cart_com, int* coordenadas,

int* id)
PARMETROS E NTRADA
coordenadas Vector de enteros (de tamao numero_dimensiones, vase funcin B.3) que
especifica las coordenadas cartesianas del proceso
PARMETROS S ALIDA
id Identificador del proceso especificado
B.5. MPI_Cart_sub
F UNCIONALIDAD
Divide un comunicador de tipo rejilla (topologa cartesiana) en rejillas de menores dimen-
siones.
S INTAXIS
int MPI_Cart_sub(MPI_Comm cart_com, int* var_coords,
MPI_Comm nuevo_com)
PARMETROS E NTRADA
var_coords Vector de booleanos que especifica para cada dimensin de cart_com si pertenece
a nuevo_com, dejando que la coordenada vare (verdadero) o no (falso)
PARMETROS S ALIDA
nuevo_com Nuevo comunicador de topologa cartesiana con igual o menor nmero de di-
mensiones que cart_com
B.6. MPI_COMM_CREATE 181
B.6. MPI_Comm_create
F UNCIONALIDAD
Crea un nuevo comunicador a partir de otro.
S INTAXIS
int MPI_Comm_create(MPI_Comm antiguo_com,
MPI_Group nuevo_grupo,
MPI_Comm* nuevo_com)
PARMETROS E NTRADA
antiguo_com Comunicador original a partir del cual generamos el nuevo comunicador
nuevo_com Grupo que contiene los procesos que formarn parte del nuevo comunicador.
Debe ser un subconjunto del grupo asociado al comunicador original (antiguo_com).
PARMETROS S ALIDA
nuevo_com Nuevo comunicador
B.7. MPI_Comm_group
F UNCIONALIDAD
Retorna el grupo asociado a un comunicador determinado.
S INTAXIS
int MPI_Comm_group(MPI_Comm com, MPI_Group* grupo)
PARMETROS E NTRADA
com Comunicador
PARMETROS S ALIDA
grupo Grupo asociado al comunicador
B.8. MPI_COMM_RANK 183
B.8. MPI_Comm_rank
F UNCIONALIDAD
Retorna el identificador de un proceso dentro de un comunicador.
S INTAXIS
int MPI_Comm_rank(MPI_Comm com, int* id)
PARMETROS E NTRADA
com Comunicador dentro del cual el proceso tiene asociado el identificador
PARMETROS S ALIDA
id Identificador del proceso dentro del comunicador com
B.9. MPI_Comm_size
F UNCIONALIDAD
Determina el nmero de procesos pertenecientes al grupo asociado a un comunicador.
S INTAXIS
int MPI_Comm_size(MPI_Comm com, int* numprocs)
PARMETROS E NTRADA
com Comunicador al cual est asociado el grupo cuyo tamao queremos conocer
PARMETROS S ALIDA
numprocs Nmero de procesos en el grupo del comunicador (entero)
B.10. MPI_COMM_SPLIT 185
B.10. MPI_Comm_split
F UNCIONALIDAD
Particiona un comunicador en varios subconjuntos de procesos y crea un nuevo comuni-
cador para cada uno de ellos.
S INTAXIS
int MPI_Comm_split(MPI_Comm antiguo_com,
int clave_particion,
int clave_id, MPI_Comm* nuevo_com)
PARMETROS E NTRADA
antiguo_com Comunicador original a partir del cual creamos los nuevos comunicadores
clave_particion Nmero que representa el nuevo comunicador en el cual quedar englobado

el proceso
clave_id Identificador del proceso dentro del nuevo comunicador
PARMETROS S ALIDA
nuevo_com Nuevo comunicador (leer comentarios)
C OMENTARIOS
La llamada crea un comunicador para cada valor de clave_particion. Los procesos con el
mismo valor en clave_particion quedan englobados en el mismo comunicador.
Sin embargo los comunicadores creados tendrn el mismo nombre para todos los proce-
sos. Imaginemos que dividimos de manera escalonada un comunicador con 9 procesos en tres
comunicadores con 3 procesos, llamados todos nuevo_com. De esta manera, el grupo nue-
vo_com consistir en los procesos 0, 1 y 2 para los procesos 0, 1 y 2. En los procesos 3, 4
y 5 el grupo subyacente a nuevo_com ser el formado por los procesos 3, 4 y 5; y lo mismo
ocurrir con los procesos 6, 7 y 8.
B.11. MPI_Finalize
F UNCIONALIDAD
Finaliza el entorno de ejecucin MPI. Despus de que el programa haya acabado de utilizar
la librera MPI, se debe hacer una llamada a MPI_Finalize. Esta funcin limpia todos los
trabajos no finalizados dejados por MPI (por ejemplo, envos pendientes que no hayan sido
completados, etc.).
S INTAXIS
int MPI_Finalize()
Esta funcin no tiene parmetros.

B.12. MPI_GET_PROCESSOR_NAME 187
B.12. MPI_Get_processor_name
F UNCIONALIDAD
Retorna el nombre del procesador donde est ubicado el proceso.
S INTAXIS
int MPI_Get_processor_name(char* nombre, int* longnombre)
PARMETROS S ALIDA
nombre Vector de caracteres cuyo tamao debe ser al menos igual a la constante
MPI_MAX_PROCESSOR_NAME destinado a contener el nombre del procesador
longname Longitud (en caracteres) de la cadena obtenida
C OMENTARIOS
El nombre retornado debe identificar un elemento hardware especfico; el formato exacto
estar definido por la implementacin.
B.13. MPI_Group_incl
F UNCIONALIDAD
Crea un nuevo grupo a partir de una lista de procesos pertenecientes a un grupo existente.
S INTAXIS
int MPI_Group_incl(MPI_Group antiguo_grupo,
int tamano_nuevo_grupo,
int* ids_antiguo_grupo,
MPI_Group* nuevo_grupo)
PARMETROS E NTRADA
antiguo_grupo Grupo original a partir del cual generamos el nuevo grupo
tamano_nuevo_grupo Nmero de procesos que formarn el nuevo grupo
ids_antiguo_grupo Identificadores de los procesos que formarn parte del nuevo grupo (vec-
tor de enteros)
PARMETROS S ALIDA
nuevo_grupo Nuevo grupo derivado del existente, reordenado segn el vector ids_antiguo_grupo.
B.14. MPI_INIT 189
B.14. MPI_Init
F UNCIONALIDAD
Inicializa el entorno de ejecucin MPI. Antes de que podamos llamar a cualquier otra
funcin MPI, debemos hacer una llamada a MPI_Init; esta funcin slo debe ser llamada
una vez. Permite al sistema hacer todas la configuraciones necesarias para que la librera MPI
pueda ser usada.
S INTAXIS
int MPI_Init(int *argc, char ***argv);
PARMETROS E NTRADA
argc Puntero al nmero de argumentos
argv Puntero a los vectores de argumentos

B.15. MPI_Irecv
F UNCIONALIDAD
Inicializa la recepcin de un mensaje no bloqueante.
S INTAXIS
int etiqueta, MPI_Comm com,
PARMETROS E NTRADA
contador Nmero de elementos del tipo tipo_datos que componen el mensaje a recibir
tipo_datos Tipo de datos MPI de cada elemento del mensaje a recibir (Cuadro 5.1)
origen Identificador del proceso origen
etiq Etiqueta del mensaje
PARMETROS S ALIDA
mensaje Direccin inicial de memoria del mensaje a recibir
peticion Manejador de la peticin
C OMENTARIOS
Esta funcin recibe mensajes de tipo no bloqueante. Ello quiere decir que la ejecucin del
programa no se bloquea con la llamada a esta funcin.
B.16. MPI_ISEND 191
B.16. MPI_Isend
F UNCIONALIDAD
Inicializa el envo de un mensaje no bloqueante a un proceso determinado.
S INTAXIS
int MPI_Isend(void* mensaje, int contador,
int etiq, MPI_Comm com,
PARMETROS E NTRADA
mensaje Direccin inicial de memoria del mensaje a enviar
contador Nmero de elementos del tipo tipo_datos que componen el mensaje a enviar
tipo_datos Tipo de datos MPI de cada elemento del mensaje a enviar (Cuadro 5.1)
destino Identificador del proceso destino
com Comunicador en el que se produce la comunicacin
PARMETROS S ALIDA
C OMENTARIOS
Esta funcin enva mensajes de tipo no bloqueante. Ello quiere decir que la ejecucin del
programa no se bloquea con la ejecucin de la llamada.
B.17. MPI_Recv
F UNCIONALIDAD
Recibe un mensaje bsico de un proceso.
S INTAXIS
int etiqueta, MPI_Comm com,
MPI_Status* status)
PARMETROS E NTRADA
contador Nmero de elementos del tipo tipo_datos que componen el mensaje a recibir
tipo_datos Tipo de datos MPI de cada elemento del mensaje a recibir (Cuadro 5.1)
PARMETROS S ALIDA
mensaje Direccin inicial de memoria del mensaje a recibir
status Objeto que representa el estado de la recepcin
C OMENTARIOS
Esta funcin recibe mensajes de tipo bloqueante. Ello quiere decir que la ejecucin del
programa se bloquea hasta que el mensaje ha sido recibido.
B.18. MPI_REDUCE 193
B.18. MPI_Reduce
F UNCIONALIDAD
Reduce valores en todos los procesos a un solo valor. Realiza una operacin de reduccin.
S INTAXIS
int MPI_Reduce(void* operando, void* resultado,
int contador, MPI_Datatype tipo_datos,
MPI_Op operacion, int raiz,
MPI_Comm com);
PARMETROS E NTRADA
operando Direccin inicial de memoria de los valores a operar
contador Nmero de elementos del tipo tipo_datos que componen cada uno de los operandos
y el resultado
tipo_datos Tipo de datos MPI de los valores a operar
operacion Operacin de reduccin a realizar (Cuadro 6.1)
raiz Identificador del proceso que recibe el valor calculado
PARMETROS S ALIDA
resultado Direccin inicial de memoria del valor calculado a recibir (significante slo en el
proceso raiz)
B.19. MPI_Send
F UNCIONALIDAD
Enva un mensaje bsico a un proceso determinado.
S INTAXIS
int MPI_Send(void* mensaje, int contador,
int etiq, MPI_Comm com)
PARMETROS E NTRADA
mensaje Direccin inicial de memoria del mensaje a enviar
contador Nmero de elementos del tipo tipo_datos que componen el mensaje a enviar
tipo_datos Tipo de datos MPI de cada elemento del mensaje a enviar (Cuadro 5.1)
C OMENTARIOS
Esta funcin enva mensajes de tipo bloqueante. Ello quiere decir que la ejecucin del
programa se bloquea hasta que el mensaje ha sido enviado.
B.20. MPI_SENDRECV_REPLACE 195
B.20. MPI_Sendrecv_replace
F UNCIONALIDAD
Enva y recibe un mensaje bsico utilizando un slo buffer.
S INTAXIS
int MPI_Sendrecv_replace(void* mensaje, int contador,
MPI_Datatype tipo_datos,
int destino, int etiqdestino,
int origen, int etiqorigen,
MPI_Comm com, MPI_Status* status)
PARMETROS E NTRADA
mensaje Direccin inicial de memoria del mensaje a enviar y en la cual recibiremos el nuevo
mensaje
contador Nmero de elementos del tipo tipo_datos que componen el mensaje a enviar/recibir
tipo_datos Tipo de datos MPI de cada elemento del mensaje a enviar/recibir (Cuadro 5.1)
etiqdestino Etiqueta del mensaje a enviar
etiqorigen Etiqueta del mensaje a recibir
C OMENTARIOS
Esta funcin enva/recibe mensajes de tipo bloqueante. Ello quiere decir que la ejecucin
del programa se bloquea hasta que el mensaje ha sido enviado/recibido.
B.21. MPI_Type_commit
F UNCIONALIDAD
Acomete un tipo de datos MPI.
S INTAXIS
int MPI_Type_commit(MPI_Datatype* tipo_datos_MPI)
PARMETROS E NTRADA
tipo_datos_MPI Tipo de datos MPI
B.22. MPI_TYPE_STRUCT 197
B.22. MPI_Type_struct
F UNCIONALIDAD
Crea un tipo de datos MPI para estructuras.
S INTAXIS
int MPI_Type_struct(int contador,
int longitudes_bloque[],
MPI_Aint indices[],
MPI_Datatype antiguos_tipos_datos,
PARMETROS E NTRADA
contador Nmero de bloques
longitud_bloque Nmero de elementos de tipo tipo_datos_elem de cada bloque
indices Direccin relativa de cada bloque
antigus_tipo_datos Tipos de datos de cada bloque
PARMETROS S ALIDA
nuevo_tipo Nuevo tipo de datos MPI
B.23. MPI_Type_vector
F UNCIONALIDAD
Crea un tipo de datos MPI para vectores.
S INTAXIS
int MPI_Type_vector(int contador, int longitud_bloque,
int salto, MPI_Datatype tipo_datos_elem,
PARMETROS E NTRADA
contador Nmero de bloques
longitud_bloque Nmero de elementos de tipo tipo_datos_elem en cada bloque
salto Nmero de elementos de tipo tipo_datos_elem que hay entre los sucesivos elementos
de nuevo_tipo.
tipo_datos_elem Antiguo tipo de datos
PARMETROS S ALIDA
nuevo_tipo Nuevo tipo de datos MPI
B.24. MPI_WAIT 199
B.24. MPI_Wait
F UNCIONALIDAD
Espera a que se complete un envo o una recepcin de un mensaje.
S INTAXIS
int MPI_Wait(MPI_Request* peticion,
MPI_Status* status)
PARMETROS E NTRADA
PARMETROS S ALIDA
status Objeto que representa el estado del envo/recepcin del mensaje
B.25. MPI_Waitall
F UNCIONALIDAD
Espera a que se completen todas las peticiones especificadas en un vector.
S INTAXIS
int MPI_Waitall(int contador,
MPI_Status* status)
PARMETROS E NTRADA
contador Longitud del vector de peticiones
vector_peticiones Vector de peticiones
PARMETROS S ALIDA
B.26. MPI_WAITANY 201
B.26. MPI_Waitany
F UNCIONALIDAD
Espera a que se complete cualquiera de las peticiones especificadas en un vector.
S INTAXIS
int MPI_Waitany(int contador,
int* indice,
MPI_Status* status)
PARMETROS E NTRADA
contador Longitud del vector de peticiones
vector_peticiones Vector de peticiones
PARMETROS S ALIDA
indice Posicin de la peticin satisfecha en el vector de peticiones

B.27. MPI_Wtime
F UNCIONALIDAD
Retorna el tiempo transcurrido para un proceso.
S INTAXIS
double MPI_Wtime()
VALOR DE R ETORNO
Tiempo en segundos desde que comenz la ejecucin del proceso.
Conclusiones
Para llegar a ciertas conclusiones en el estudio realizado lo primero que debemos hacer es
analizar los resultados obtenidos en las ejecuciones de los algoritmos paralelos. Slo de este
modo podremos demostrar la utilidad y potencialidad del procesamiento paralelo ejecutado en
redes bajo Linux.
Sumario de Resultados
Comenzaremos el anlisis observando algunos grficos ciertamente determinantes. La
figura 1 muestra un grfico que representa el tiempo de ejecucin del algoritmo Clculo de
reas mediante Montecarlo utilizando paso de mensajes no bloqueantes.

140
Tiempo Ejecucion
120
100
Tiempo (seg)
80
60
40
20
0
0 2 4 6 8 10 12 14 16
Figura 1: Grfico Tiempo Ejecucin Clculo de reas No Bloqueante
En el grfico observamos una notoria reduccin en el tiempo de ejecucin de dicho algo-

ritmo conforme incorporamos procesadores al cmputo. Ello es lgico debido a que se trata de
203
204 CONCLUSIONES
un algoritmo cuyo rendimiento depende bsicamente de la capacidad de cmputo que tenga la

mquina en la cual lo ejecutamos. Adems tenemos la gran ventaja de que si dividimos dicho
cmputo en varios elementos procesadores, el proceso de converger los resultados parciales
de cada uno de los elementos procesadores es bastante sencillo: slo tenemos que hacer la me-
dia de todos ellos. As pues este algoritmo se muestra muy apropiado para el procesamiento
paralelo. El rendimiento obtenido en la versin bloqueante de dicho algoritmo es slo un poco
inferior al obtenido en la versin no bloqueante, aunque su comportamiento es similar.
En la misma lnea se encuentra el algoritmo Regla del Trapecio. En la figura 2 tenemos el
grfico que muestra el rendimiento de dicho algoritmo. De nuevo observamos una importante
reduccin del tiempo necesario para su ejecucin. Debemos hacer notar que en este tipo de al-
goritmos el nivel de detalle es un elemento a tener en cuenta. La calidad de las aproximaciones
que hacemos en estos algoritmos depender del nmero de muestras aleatorias recogidas en el
algoritmo Clculo de reas mediante Montecarlo, y del nmero de intervalos generados en el
algoritmo Regla del Trapecio. Por supuesto el nivel de detalle queda fijado de antemano antes
de realizar las pruebas de rendimiento con distintas cantidades de procesadores.
Regla del Trapecio: Tiempo Ejecucion

140
Tiempo Ejecucion
120
100
Tiempo (seg)
80
60
40
20
0
0 2 4 6 8 10 12 14 16
Figura 2: Grfico Tiempo Ejecucin Regla del Trapecio
Por otro lado el algoritmo Multiplicacin de Matrices de Fox tiene una serie de carac-
tersticas que lo diferencian del resto. Una de ellas es la exactitud; aqu no tratamos de hacer
aproximaciones precisas, a diferencia de los algoritmos anteriormente expuestos. En este al-
goritmo multiplicamos matrices cuadradas particionndolas en submatrices. Cada proceso en
este caso se encargar de calcular una submatriz de la matriz resultado.
La principal dificultad en este caso es la sobrecarga en la comunicacin. El hecho de tener
que transmitir submatrices enteras entre los procesadores dificulta mucho el clculo fluido.
205
Sin embargo obtenemos resultados muy interesantes en el cmputo de matrices de un orden

elevado. Como podemos observar en la figura 3 el crecimiento del tiempo de ejecucin es
exponencial para todas las cantidades de procesos utilizadas; sin embargo dicho crecimiento
es ms paulatino cuanto mayor es la cantidad de procesos empleados.
Comparacion Tiempo de distintas Cantidades de Procesos

2500
16
9
4
1
2000
1500
Tiempo (seg)
1000
500
0
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Orden Matriz
Figura 3: Comparacin Tiempo Distintas Cantidades de Procesos Fox
El cuadro 1 muestra los tiempos obtenidos en la ejecucin del algoritmo Multiplicacin de

Matrices de Fox.
Orden \ Num.Procs. 1 4 9 16
700 19,0 / 19,1 10,3 / 14,9 10,0 / 15,37 19,1 / 23,2
1400 172,0 / 172,2 59,8 / 78,4 50,1 / 70,9 57,3 / 78,9
2100 2237,2 / 2252,8 190,9 / 232,7 135,1 / 183,6 134,0 / 183,3
2800 - 430,1 / 504,3 274,9 / 362,3 261,1 / 344,8
3500 - 2074,1 / 2202,5 491,3 / 626,8 458,5 / 599,9
4200 - - 833,1 / 1032,6 726,7 / 930,2
4900 - - 1257,1 / 1527,3 1016,4 / 1291,9
Cuadro 1: Evaluacin Multiplicacin de Matrices de Fox
Contiene para cada cantidad de procesadores empleados los tiempos obtenidos en la mul-
tiplicacin de matrices de distintos rdenes; los dos tiempos separados por el carcter / rep-
resentan el tiempo requerido para multiplicar las matrices por un lado, y por otro el tiempo
requerido para multiplicarlas y mostrar el resultado. Dichos tiempos se miden en segundos.
206 CONCLUSIONES
Para cada orden de matrices utilizado resaltaremos en negrita el tiempo de multiplicacin p-

timo.
Pero en el anlisis de los algoritmos no slo se deben medir sus tiempos de ejecucin.
Una variable importante a tener en cuesta es el coste. Dicha variable relaciona el nmero de
procesadores empleados con el tiempo de ejecucin obtenido; de este modo nos permite saber
si es rentable el uso de una cantidad mayor de procesadores en la ejecucin de un algoritmo
dado.
El coste normalmente aumenta en la mayora de los algoritmos al emplear una cantidad
mayor de procesadores en su ejecucin. En la figura 4 mostramos el coste de ejecucin del
algoritmo Clculo de reas mediante Montecarlo. La curva de crecimiento del coste prctica-
mente se repite en la mayora de los algoritmos (figura 5).
Calculo de Areas No Bloqueante: Coste

175
Coste
170
165
160
Coste
155
150
145
140
135
0 2 4 6 8 10 12 14 16
Figura 4: Grfico Coste Clculo de reas No Bloqueante
Sin embargo en la comparacin de costes del algoritmo de Fox (figura 6) observamos que
el coste depende tanto del nmero de procesos empleados como del tamao de las matrices
a multiplicar. De hecho vemos que para matrices de orden mayor a 2000 la utilizacin de 1
slo procesador es la ms costosa. Con este planteamiento podemos prever que para tamaos
de matrices superiores a los empleados en las pruebas la utilizacin de 16 procesadores ser la
ms rentable.
207
Regla del Trapecio: Coste

138
Coste
136
134
132
Coste
130
128
126
124
122
0 2 4 6 8 10 12 14 16
Figura 5: Grfico Coste Regla del Trapecio
Comparacion Coste de distintas Cantidades de Procesos
16
18000 9
4
1
16000
14000
12000
Coste
10000
8000
6000
4000
2000
0
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Orden Matriz
Figura 6: Comparacin Costes Distintas Cantidades de Procesos Fox

208 CONCLUSIONES
Corolario
Las demostraciones de la seccin anterior nos permiten argumentar que el procesamien-
to paralelo es una tcnica que arroja resultados muy satisfactorios para cierto tipo de com-
putaciones. Ciertamente en todos los algoritmos desarrollados obtenemos una mejora del
rendimiento al aumentar el nmero de procesadores utilizados.
Sin embargo debemos advertir de que no slo debemos tener en cuenta el tiempo de ejecu-
cin de los algoritmos para evaluarlos. En muchos ambientes la incorporacin de una mayor
cantidad de procesadores a la ejecucin de un algoritmo realmente cuesta dinero. En estos ca-
sos la variable coste nos permitir medir la rentabilidad de la inclusin de nuevos procesadores
en la ejecucin. Por lo tanto deberamos emplear ms o menos procesadores dependiendo de
la necesidad que tengamos de acelerar el procesamiento y de los recursos que podamos utilizar
(o adquirir), intentando llegar a un compromiso entre rendimiento y coste que sea ptimo para
nuestras necesidades.
Debemos insistir en que el paralelismo es un campo realmente extenso en el cual convergen
una amplia variedad de tcnicas y tecnologas, como vimos en la primera parte del presente
documento. Nosotros slo hemos investigado sobre el paralelismo llevado a cabo mediante la
utilizacin de clusters; no obstante el hacerlo conlleva el obtener una cierta perspectiva del
amplio abanico de posibilidades que existen por explorar.
En este panorama cabe destacar la importancia de la existencia de herramientas de de-
sarrollo de software paralelo que hacen del paralelismo una tcnica al alcance de todos. Los
estndares como MPI no slo ofrecen este tipo de facilidades, si no que adems aaden porta-
bilidad a los algoritmos implementados mediante su utilizacin.
Con todo lo expuesto anteriormente debemos darnos cuenta de que slo necesitamos un
grupo de ordenadores convencionales conectados en red bajo Linux para poder ejecutar aplica-
ciones paralelas de manera eficiente. De este modo podemos disponer por muy poco dinero (o
incluso nada) de todo un computador paralelo con una potencia relativamente alta. As pues...
por qu no aprovecharlo?.
Direcciones URL
1. CHIMP Download
<ftp://ftp.epcc.ed.ac.uk/pub/chimp/release/>
2. FireWire
<http://www.apple.com/firewire/>
3. FSMLabs Inc. creadores de RTLinux

<http://www.rtlinux.org/>
4. Intel Compilers
<http://www.intel.com/software/products/compilers/>
5. Internet Parallel Computing Archive

<http://wotug.ukc.ac.uk/parallel/>
6. LAM/MPI Parallel Computing

<http://www.lam-mpi.org/>
7. MMX Emulator
<http://www-sop.inria.fr/prisme/personnel/pion/progs/mmx-emu/>
8. MPI Forum
<http://www.mpi-forum.org/>
9. MPICH - A Portable Implementation of MPI

<http://www.mcs.anl.gov/mpi/mpich/>
10. MPICH Downloads

<http://www.mcs.anl.gov/mpi/mpich/download.html>
11. MPICH Parches

<http://www.mcs.anl.gov/mpi/mpich/buglist-tbl.html>
12. OpenSSH - Versin libre de SSH

<http://www.openssh.com/>
13. Packet Engines Gigabit Ethernet with Linux

<http://www.scyld.com/network/yellowfin.html>
209
210 DIRECCIONES URL
14. PVM - Parallel Virtual Machine

<http://www.epm.ornl.gov/pvm/pvm_home.html>
15. SWAR Homepage at Purdue University

<http://shay.ecn.purdue.edu/~swar/>
16. The Aggregate

<http://aggregate.org/>
17. The Beowulf Underground

<http://www.beowulf-underground.org/>
18. The Berkeley NOW Project

<http://now.cs.berkeley.edu/>
19. The Globus Project

<http://www.globus.org/>
20. USB - Universal Serial Bus

<http://www.usb.org/>
21. WineHQ - Windows Emulator

<http://www.winehq.com/>

Mpi Spanish PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Mpi Spanish PDF

Cargado por

Copyright:

Formatos disponibles

Procesamiento Paralelo en Redes Linux Utilizando MPI

Alumno: Vicente F. Reyes Puerta

El presente documento realiza un estudio de investigacin que aborda el procesamiento pa-

I Sistemas de Procesamiento Paralelo 1

2. Herramientas Desarrollo Software Paralelo 43

7. Comunicadores y Topologas 105

7.5. Topologas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

III Anlisis del Rendimiento 125

8. Evaluacin del Sistema 127

9. Evaluacin de los Algoritmos 143

A. Instalacin, Configuracin y Manejo de MPICH 163

A.5. Compilacin y Enlace de Programas . . . . . . . . . . . . . . . . . . . . . . 171

B. Manual de Referencia 175

Direcciones URL 209

1.1. Clasificacin Paralelismo Implcito . . . . . . . . . . . . . . . . . . . . . . . 6

2.1. Modelo Bsico para Paso de Mensajes . . . . . . . . . . . . . . . . . . . . . 44

3.1. Logo MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1. Generacin Puntos Aleatorios . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.1. Procesos estructurados en rbol . . . . . . . . . . . . . . . . . . . . . . . . . 95

8.1. Grfico Comunicacin Bloqueante . . . . . . . . . . . . . . . . . . . . . . . 132

9.1. Animacin en Tiempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

1.1. Dimetros Topologas Hipercubo y Malla . . . . . . . . . . . . . . . . . . . 28

5.1. Tipos de Datos MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.1. Operaciones de Reduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.1. Particin Matriz 6*6 en 9 Procesos . . . . . . . . . . . . . . . . . . . . . . . 106

9.1. Evaluacin Clculo de reas Bloqueante . . . . . . . . . . . . . . . . . . . . 151

4.1. Hola Mundo! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

El objetivo principal del presente proyecto de investigacin consiste en demostrar la utili-

Figura 1: Objetivo Procesamiento Paralelo en Clusters

A continuacin explicaremos detenidamente el desarrollo de la investigacin llevada a

Sistemas de Procesamiento Paralelo

Paralelismo implcito o de bajo nivel

Paralelismo explcito o de alto nivel

La tcnicas de paralelismo implcito estn dirigidas al reforzamiento del nivel de concurrencia

Figura 1: Clasificacin Paralelismo Implcito

Memoria Compartida Memoria Distribuida

Figura 3: Esquema Funcionamiento MPI

A continuacin en el captulo 4 vemos los conceptos bsicos sobre la utilizacin de MPI

identificar los procesos en ejecucin. Para ejemplificarlo escribiremos un sencillo programa

Figura 4: Algoritmo Clculo de reas mediante Montecarlo

Anlisis del Rendimiento

Figura 6: Grfico Comunicacin Bloqueante

Comunicacion Colectiva Op.Reduccion-Entero

Figura 7: Grfico Comunicacin Colectiva

El captulo 9 aborda el estudio de los resultados obtenidos en las ejecuciones explicando

Sistemas de Procesamiento Paralelo

Definimos como procesamiento paralelo al concepto de agilizar la ejecucin de un pro-

1.1. Utilidades del Procesamiento Paralelo

Si no es el procesamiento paralelo lo que se busca, pero queremos mejorar el rendimiento

1.2. Definiciones Bsicas

1.2.1. Caractersticas Fsicas de la Comunicacin

1.2.2. Estndares Relacionados

Los modos de operacin

La estructura de los registros

El direccionamiento de los operandos

Los tipos de datos

Figura 1.1: Clasificacin Paralelismo Implcito

2. Los datos se distribuyen a travs de las unidades fsicas de un conjunto.

3. La capacidad de los discos redundantes se usa para almacenar informacin de paridad,

1.3. Clasificacin Sistemas Paralelos

Paralelismo implcito o de bajo nivel

Paralelismo explcito o de alto nivel

1.3.1. Paralelismo Implcito o de Bajo Nivel