Procesamiento Paralelo en Redes Linux Utilizando MPI · 2005-04-05 · Resumen El presente...

Procesamiento Paralelo en Redes Linux Utilizando MPI

Alumno: Vicente F. Reyes PuertaDirector: Jose Antonio Jiménez Millán

Julio 2003

Resumen

El presente documento realiza un estudio de investigación que aborda el procesamiento pa-ralelo en redes de ordenadores. De esta manera se analiza la utilización de los clusters (gruposde ordenadores conectados en red) a modo de computador virtual paralelo como plataformapara la ejecución de aplicaciones paralelas.

El entorno utilizado para realizar dicho estudio es el sistema operativo Linux, el cual ofrecetodas las facilidades de acceso a dispositivos y comunicación necesarias para la ejecución delos algoritmos paralelos. Para la implementación de los algoritmos paralelos desarrolladoshemos utilizado la interfaz MPI (“Message Passing Interface”, Interfaz de Paso de Mensajes).Dicha interfaz es un estándar que define la sintaxis y la semántica de las funciones contenidasen una librería de paso de mensajes diseñada para ser usada en programas que exploten laexistencia de múltiples procesadores. De este modo no sólo conseguimos que el desarrollo delos algoritmos sea más claro y sencillo, si no que además 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 procesamientoparalelo, y establecemos una clasificación detallada sobre los distintos tipos de paralelismoexistentes en la actualidad. En la segunda parte realizamos un análisis detallado de la interfazde paso de mensajes MPI, ejemplificando la información ofrecida con diversos algoritmos es-critos en C que realizan cómputos paralelos utilizando dicha interfaz. Por último generamosun estudio de los resultados obtenidos en las ejecuciones explicando paso a paso la manera enla que han sido cosechados.

3

Índice general

Objetivos I

Desarrollo III

I Sistemas de Procesamiento Paralelo 1

1. Introducción 31.1. Utilidades del Procesamiento Paralelo . . . . . . . . . . . . . . . . . . . . . 31.2. Definiciones Básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1. Características Físicas de la Comunicación . . . . . . . . . . . . . . 41.2.2. Estándares Relacionados . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Clasificación Sistemas Paralelos . . . . . . . . . . . . . . . . . . . . . . . . 61.3.1. Paralelismo Implícito o de Bajo Nivel . . . . . . . . . . . . . . . . . 61.3.2. Paralelismo Explícito o de Alto Nivel . . . . . . . . . . . . . . . . . 7

1.4. Arquitecturas Basadas en Paralelismo Implícito . . . . . . . . . . . . . . . . 91.4.1. Segmentación o pipeline . . . . . . . . . . . . . . . . . . . . . . . . 91.4.2. Tecnología SWAR . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.3. Procesadores Auxiliares . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5. Arquitecturas Basadas en Paralelismo Explícito . . . . . . . . . . . . . . . . 191.5.1. Multiprocesadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5.2. Multicomputadores . . . . . . . . . . . . . . . . . . . . . . . . . . 261.5.3. Procesadores Matriciales . . . . . . . . . . . . . . . . . . . . . . . 371.5.4. Procesadores Vectoriales . . . . . . . . . . . . . . . . . . . . . . . . 38

2. Herramientas Desarrollo Software Paralelo 432.1. Modelos de Interacción entre Procesadores . . . . . . . . . . . . . . . . . . 43

2.1.1. Paso de Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.1.2. Memoria Compartida . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.2. Utilidades de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.2.1. PVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.2.2. MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.2.3. P4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.2.4. Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.2.5. Linda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5

6 ÍNDICE GENERAL

II Guía MPI 55

3. El Estándar MPI 573.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.2. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4. Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.5. Plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.6. Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.6.1. MPI-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.6.2. MPI-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.7. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4. Conceptos Básicos 674.1. Algoritmo ¡Hola Mundo! . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2. Programas MPI en General . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3. Informándonos del Resto del Mundo . . . . . . . . . . . . . . . . . . . . . . 694.4. El Problema de la Entrada/Salida . . . . . . . . . . . . . . . . . . . . . . . . 694.5. Ubicación de los Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.6. Información Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.7. Implementación Algoritmo ¡Hola Mundo! . . . . . . . . . . . . . . . . . . . 71

5. Paso de Mensajes 735.1. Algoritmo Cálculo de Áreas mediante Montecarlo . . . . . . . . . . . . . . . 735.2. El Entorno del Mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.3. Funciones de Paso de Mensajes Bloqueantes . . . . . . . . . . . . . . . . . . 765.4. Funciones de Paso de Mensajes No Bloqueantes . . . . . . . . . . . . . . . . 775.5. Agrupaciones de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.5.1. Tipos Derivados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.5.2. Vectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.6. Implementación Cálculo de Áreas mediante Montecarlo . . . . . . . . . . . . 805.6.1. Implementación con Mensajes Bloqueantes . . . . . . . . . . . . . . 805.6.2. Implementación con Mensajes No Bloqueantes . . . . . . . . . . . . 86

6. Comunicación Colectiva 936.1. Algoritmo Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . . 936.2. Distribución y Recolección de los Datos . . . . . . . . . . . . . . . . . . . . 946.3. Operaciones de Comunicación Colectiva . . . . . . . . . . . . . . . . . . . . 966.4. Operaciones de Reducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.5. Implementación Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . 98

7. Comunicadores y Topologías 1057.1. Algoritmo Multiplicación de Matrices de Fox . . . . . . . . . . . . . . . . . 1057.2. Comunicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.3. Trabajando con Grupos, Contextos y Comunicadores . . . . . . . . . . . . . 1077.4. Particionamiento de los Comunicadores . . . . . . . . . . . . . . . . . . . . 110

ÍNDICE GENERAL 7

7.5. Topologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.6. División de Rejillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137.7. Implementación Multiplicación de Matrices de Fox . . . . . . . . . . . . . . 114

III Análisis del Rendimiento 125

8. Evaluación del Sistema 1278.1. Utilidad mpptest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8.1.1. Compilación y Ejecución . . . . . . . . . . . . . . . . . . . . . . . . 1288.1.2. Formatos de Salida . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.1.3. Visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.1.4. Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.1.5. Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

8.2. Pruebas Realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308.2.1. Comunicación Bloqueante . . . . . . . . . . . . . . . . . . . . . . . 1318.2.2. Comunicación No Bloqueante . . . . . . . . . . . . . . . . . . . . . 1328.2.3. Participación Total de los Procesos . . . . . . . . . . . . . . . . . . . 1338.2.4. Solapamiento entre Comunicación y Procesamiento . . . . . . . . . . 1358.2.5. Comunicación Colectiva . . . . . . . . . . . . . . . . . . . . . . . . 1368.2.6. Fiabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

9. Evaluación de los Algoritmos 1439.1. Herramientas de Monitorización . . . . . . . . . . . . . . . . . . . . . . . . 143

9.1.1. Ficheros de Recorrido . . . . . . . . . . . . . . . . . . . . . . . . . 1449.1.2. Trazado de la Ejecución . . . . . . . . . . . . . . . . . . . . . . . . 1469.1.3. Animación en Tiempo Real . . . . . . . . . . . . . . . . . . . . . . 147

9.2. Criterios de Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489.2.1. Tiempo de Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . 1489.2.2. Número de Procesadores . . . . . . . . . . . . . . . . . . . . . . . . 1499.2.3. Coste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

9.3. Resultados Obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499.3.1. Algoritmo Cálculo de Áreas mediante Montecarlo Bloqueante . . . . 1499.3.2. Algoritmo Cálculo de Áreas mediante Montecarlo No Bloqueante . . 1519.3.3. Algoritmo Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . 1549.3.4. Algoritmo Multiplicación de Matrices de Fox . . . . . . . . . . . . . 159

A. Instalación, Configuración y Manejo de MPICH 163A.1. Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164A.2. Obtención . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165A.3. Compilación e Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . 165A.4. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

A.4.1. El Fichero de Máquinas . . . . . . . . . . . . . . . . . . . . . . . . 166A.4.2. RSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167A.4.3. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168A.4.4. Secure Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

8 ÍNDICE GENERAL

A.5. Compilación y Enlace de Programas . . . . . . . . . . . . . . . . . . . . . . 171A.6. Ejecución de Programas con mpirun . . . . . . . . . . . . . . . . . . . . . . 172A.7. Extensión MPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

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

Conclusiones 203

Bibliografía 208

Direcciones URL 209

Índice de figuras

1.1. Clasificación Paralelismo Implícito . . . . . . . . . . . . . . . . . . . . . . . 61.2. Clasificación Paralelismo Explícito . . . . . . . . . . . . . . . . . . . . . . . 71.3. Ciclo de Instrucción de 2 etapas (A) . . . . . . . . . . . . . . . . . . . . . . 91.4. Ciclo de Instrucción de 10 etapas . . . . . . . . . . . . . . . . . . . . . . . . 101.5. Ciclo de Instrucción de 2 etapas (B) . . . . . . . . . . . . . . . . . . . . . . 111.6. Cauce de 6 etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.7. Procesamiento Digital de Señales . . . . . . . . . . . . . . . . . . . . . . . . 161.8. Esquema Multiprocesador . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.9. Organización Básica Bus de Tiempo Compartido . . . . . . . . . . . . . . . 201.10. Organización Bus de Tiempo Compartido con Caché . . . . . . . . . . . . . 211.11. Organización Memorias Multipuerto . . . . . . . . . . . . . . . . . . . . . . 221.12. Topología Anillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.13. Topología Malla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.14. Topología Árbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.15. Topología Hipercubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.16. Objetivo Procesamiento Paralelo en Clusters . . . . . . . . . . . . . . . . . . 301.17. Esquema Procesador Matricial . . . . . . . . . . . . . . . . . . . . . . . . . 371.18. Esquema Procesador Vectorial . . . . . . . . . . . . . . . . . . . . . . . . . 401.19. Cray SX-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.1. Modelo Básico para Paso de Mensajes . . . . . . . . . . . . . . . . . . . . . 442.2. Modelo Básico para Memoria Compartida . . . . . . . . . . . . . . . . . . . 472.3. Esquema Básico Utilización MPI . . . . . . . . . . . . . . . . . . . . . . . . 51

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

5.1. Generación Puntos Aleatorios . . . . . . . . . . . . . . . . . . . . . . . . . 745.2. Cálculo Hipotenusa Punto Aleatorio . . . . . . . . . . . . . . . . . . . . . . 75

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

8.1. Gráfico Comunicación Bloqueante . . . . . . . . . . . . . . . . . . . . . . . 1328.2. Comparación Com.Bloqueante - No Bloqueante . . . . . . . . . . . . . . . . 1348.3. Comparación Com. Participativa - No Participativa . . . . . . . . . . . . . . 1358.4. Comparación Com. Solapada - No Solapada . . . . . . . . . . . . . . . . . . 1378.5. Gráfico Comunicación Colectiva . . . . . . . . . . . . . . . . . . . . . . . . 139

9

10 ÍNDICE DE FIGURAS

9.1. Animación en Tiempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489.2. Modelo Ejecución Cálculo de Áreas Bloqueante 8 Procesos . . . . . . . . . . 1509.3. Gráfico Tiempo Ejecución Cálculo de Áreas Bloqueante . . . . . . . . . . . 1529.4. Gráfico Coste Cálculo de Áreas Bloqueante . . . . . . . . . . . . . . . . . . 1529.5. Modelo Ejecución Cálculo de Áreas No Bloqueante 8 Procesos . . . . . . . . 1539.6. Gráfico Tiempo Ejecución Cálculo de Áreas No Bloqueante . . . . . . . . . 1559.7. Gráfico Coste Cálculo de Áreas No Bloqueante . . . . . . . . . . . . . . . . 1559.8. Modelo Ejecución Regla del Trapecio 8 Procesos . . . . . . . . . . . . . . . 1569.9. Gráfico Tiempo Ejecución Regla del Trapecio . . . . . . . . . . . . . . . . . 1589.10. Gráfico Coste Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . 1589.11. Comparación Tiempos de distintas Cantidades de Procesos . . . . . . . . . . 1609.12. Comparación Costes de distintas Cantidades de Procesos . . . . . . . . . . . 1609.13. Modelo Ejecución Algoritmo de Fox 9 Procesos . . . . . . . . . . . . . . . . 161

Índice de cuadros

1.1. Diámetros Topologías Hipercubo y Malla . . . . . . . . . . . . . . . . . . . 281.2. Ejemplos Computadores Vectoriales . . . . . . . . . . . . . . . . . . . . . . 42

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

6.1. Operaciones de Reducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.1. Partición Matriz 6*6 en 9 Procesos . . . . . . . . . . . . . . . . . . . . . . . 1067.2. Topología Física 3*3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

9.1. Evaluación Cálculo de Áreas Bloqueante . . . . . . . . . . . . . . . . . . . . 1519.2. Evaluación Cálculo de Áreas No Bloqueante . . . . . . . . . . . . . . . . . . 1549.3. Evaluación Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . . 1579.4. Evaluación Multiplicación de Matrices de Fox . . . . . . . . . . . . . . . . . 159

11

12 ÍNDICE DE CUADROS

Índice de algoritmos

4.1. ¡Hola Mundo! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.1. Cálculo de Áreas mediante Montecarlo (Bloqueante) . . . . . . . . . . . . . 815.2. Cálculo de Áreas mediante Montecarlo (No Bloqueante) . . . . . . . . . . . 866.1. Regla del Trapecio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.1. Multiplicación de Matrices de Fox . . . . . . . . . . . . . . . . . . . . . . . 114

13

14 ÍNDICE DE ALGORITMOS

Objetivos

El objetivo principal del presente proyecto de investigación consiste en demostrar la utili-dad y potencialidad del procesamiento paralelo, concretamente en lo relativo a su aplicaciónen clusters (redes de computadores). Debemos probar con resultados reales y análisis gráficosla mejora en el rendimiento que produce la ejecución 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 situarel paralelismo basado en redes dentro de la amplia variedad de sistemas dedicados al proce-samiento paralelo. Propondremos una clasificación para los distintos tipos de paralelismo ex-istentes en la actualidad, y explicaremos las características principales de cada uno de ellos.

Un aspecto básico para el desarrollo de la investigación consiste en diseñar e implemetarun conjunto de algoritmos paralelos que pongan en práctica los tipos de comunicación másimportantes que se dan en el procesamiento paralelo basado en redes. Para lograr este objetivoestudiaremos las caracteríticas más importantes de MPI (“Message Passing Interface”, Interfazde Paso de Mensajes) y emplearemos dicha interfaz en el desarrollo de diversos algoritmosparalelos.

Por último haremos un estudio detallado de los resultados obtenidos en las ejecuciones delos algoritmos desarrollados, explicando paso a paso la manera en la que han sido realizados.

I

II OBJETIVOS

Dichos resultados serán utilizados para la generación de gráficos que nos ayuden a entenderlas importantes ventajas que nos aporta el procesamiento paralelo.

Desarrollo

A continuación explicaremos detenidamente el desarrollo de la investigación llevada acabo para la realización del presente proyecto. Dicho desarrollo coincide en la práctica con laestructura del documento realizado.

Sistemas de Procesamiento Paralelo

En primer lugar debemos llevar a cabo una visión general del procesamiento paralelo, paraasí poder valorar la importancia de este amplio campo de estudio.

En el capítulo 1 se estudian los conceptos básicos relacionados con este modelo de proce-samiento, y proponemos una clasificación para los distintos tipos de paralelismo existentes enla actualidad, explicando las características principales de cada uno de ellos.

Nuestra clasificación divide el paralelismo de los computadores en dos grandes ramas:� Paralelismo implícito o de bajo nivel� Paralelismo explícito o de alto nivel

La técnicas de paralelismo implícito están dirigidas al reforzamiento del nivel de concurrenciadentro de la CPU, de manera que queda oculta a la arquitectura del ordenador. Por lo tantopueden ser vistos como sistemas de un sólo procesador.

SegmentaciónProcesadores

Auxiliares

Paralelismo Implícito

Múltiples ALUs

Figura 1: Clasificación Paralelismo Implícito

El paralelismo explícito o de alto nivel hace referencia a aquellos sistemas en los cualesse interconectan varios procesadores para cooperar en la ejecución de los programas de apli-cación. Se trata de sistemas que ofrecen una infraestructura explícita 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 investigación, centrándonos concretamente en las arquitecturas MIMDcon memoria distribuida.

III

IV DESARROLLO

(Procesadores Vectoriales)MISD

Memoria CompartidaMultiprocesadores

(SMP)

Memoria DistribuidaMulticomputadores

(Cluster)

(Procesadores Matriciales)

Paralelismo Explícito

SIMDMIMD

Figura 2: Clasificación Paralelismo Explícito

Una vez resuelto el sistema de intercomunicación física de los equipos, deben abordarselos mecanismos para lograr la coordinación entre los procesadores. En el capítulo 2 analizamoslas características básicas de los dos modelos de interacción entre procesadores (paso de men-sajes y memoria compartida), para luego centrarnos en las utilidades de desarrollo de softwareparalelo más populares que existen en la actualidad: PVM, MPI, p4, Express y Lynda.

Guía MPI

La segunda parte de nuestro estudio se centra en la utilización 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 capítulo 3 con una explicación sobre el origeny la motivación que promovieron la creación del estándar. Por otro lado analizamos los con-tenidos del estándar, sus objetivos, su funcionamiento básico y sus distintas versiones. Comovemos en la figura 3, MPI es implementado normalmente como interfaz de comunicaciones,utilizando las facilidades ofrecidas por el sistema que vayamos a usar (comunicación vía sock-ets, operaciones de memoria compartida, etc).

SO

MPI

SO

MPIMPI_Send() MPI_Recv()

Figura 3: Esquema Funcionamiento MPI

A continuación en el capítulo 4 vemos los conceptos básicos sobre la utilización de MPIpara el desarrollo de programas escritos en C. Todos los programas MPI comparten una seriede características. La inicialización y finalización del entorno de ejecución se llevan a cabomediante funciones que explicaremos en este capítulo. También analizamos los métodos para

V

identificar los procesos en ejecución. Para ejemplificarlo escribiremos un sencillo programaen C que hace uso de funciones MPI para ejecutar una versión paralela del conocido algoritmo¡Hola Mundo!.

El capítulo 5 aborda la función más importante y característica del estándar MPI: el paso demensajes. Se utiliza básicamente para el intercambio de datos entre los procesos en ejecución.En este capítulo estudiamos las características más importantes de los mensajes bloqueantesy no bloqueantes, aplicando dicha teoría a la implementación de un algoritmo diseñado parael cálculo de áreas circulares. El algoritmo Cálculo de Áreas mediante Montecarlo realiza unaaproximación del área de una circunferencia con un radio determinado mediante la simulaciónde variables aleatorias, empleando un método estadístico (figura 4).

Figura 4: Algoritmo Cálculo de Áreas mediante Montecarlo

Las operaciones de comunicación colectiva son aquellas que se aplican al mismo tiempoa todos los procesos pertenecientes a un comunicador. Tienen una gran importancia en elestándar MPI, debido a la claridad de su sintaxis y a su eficiencia. En el capítulo 6 analizamossu utilidad y conveniencia implementando el algoritmo Regla del Trapecio de manera que hagaun uso inteligente de dichas operaciones.

El capítulo 7 aborda el uso de comunicadores y topologías. Esta característica hace a MPIdiferente de la mayoría de los demás sistemas de paso de mensajes. En pocas palabras, uncomunicador es una colección de procesos que pueden mandarse mensajes entre ellos. Unatopología es una estructura impuesta en los procesos de un comunicador que permite a losprocesos ser direccionados de diferentes maneras. Para ilustrar estas ideas desarrollaremos elcódigo que implementa el algoritmo de Fox para multiplicar dos matrices cuadradas mediantesu subdivisión en una serie de procesos (cuadro 1).

Análisis del Rendimiento

Todo el trabajo anteriormente realizado no tendría ningún sentido si no viniera avalado porunos resultados satisfactorios en la ejecución de algoritmos paralelos.

Para conseguir una cierta objetividad en el análisis de los algoritmos ejecutados en un

VI DESARROLLO

Proceso 0 Proceso 1 Proceso 2�� Proceso 3 Proceso 4 Proceso 5�� Proceso 6 Proceso 7 Proceso 8��

Cuadro 1: Subdivisión de Matrices Algoritmo de Fox

determinado sistema paralelo, lo primero que debemos hacer es medir el rendimiento de dichosistema. Dicha medición se realiza a través de herramientas especializadas en el análisis, demodo que podemos saber fácilmente y con seguridad cuánto de apropiado es el sistema para laejecución de determinados algoritmos paralelos. En las figuras 6 y 7 mostramos el rendimientodel sistema en la ejecución de paso de mensajes bloqueantes y operaciones de comunicacióncolectiva, respectivamente.

0

200

400

600

800

1000

1200

0 200 400 600 800 1000 1200

Tie

mpo

(m

icro

-seg

)

Tamano (bytes)

Comunicacion Bloqueante

Com.Bloqueante

Figura 6: Gráfico Comunicación Bloqueante

VII

0

20000

40000

60000

80000

100000

120000

140000

160000

0 2 4 6 8 10 12 14 16

Tie

mpo

(m

icro

-seg

)

Num.Procesos

Comunicacion Colectiva Op.Reduccion-Entero

32256512

1024

Figura 7: Gráfico Comunicación Colectiva

El capítulo 9 aborda el estudio de los resultados obtenidos en las ejecuciones explicandopaso a paso la manera en la que han sido cosechados. Dichos resultados los analizaremos másdetenidamente en el apartado de conclusiones, ya que nos ayudan a demostrar el éxito delpresente proyecto de investigación.

VIII DESARROLLO

Parte I

Sistemas de Procesamiento Paralelo

1

Capítulo 1

Introducción

Definimos como procesamiento paralelo al concepto de agilizar la ejecución de un pro-grama mediante su división en fragmentos que pueden ser ejecutados simultáneamente, cadauno en un procesador. De este modo un programa que se ejecute en � procesadores podríaejecutarse � veces más rápido que usando un solo procesador, al menos en teoría...

1.1. Utilidades del Procesamiento Paralelo

Aunque el uso de múltiples procesadores puede agilizar muchas operaciones, la mayoría delas aplicaciones no están diseñadas para aprovechar los beneficios del procesamiento paralelo.Básicamente el procesamiento paralelo es apropiado para:� Aplicaciones con suficiente paralelismo como para hacer bueno el uso de múltiples

procesadores. El problema radica en identificar las porciones de programa que puedanser ejecutadas independiente y simultáneamente en procesadores separados; ésto en re-alidad es complejo, ya que encontraremos aplicaciones que podrían ser ejecutadas enparalelo y sin embargo se ralentizan al ser paralelizadas en un sistema particular. Porejemplo, un programa que tarda 4 segundos en ser ejecutado en una sola máquina podríatardar 1 segundo de procesamiento en cada uno de los cuatro procesadores disponiblesen una red, pero no lograríamos nada si la coordinación entre dichos procesadores tar-dase más de 3 segundos.� Implementaciones de algoritmos que o bien ya son paralelos (escritos para obtener lasventajas 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 puedeproporcionarnos el rendimiento de un supercomputador, aplicado a algunos programas querealizan complejas operaciones u operan en grandes bloques de datos. Y lo que es más, ello sepuede lograr con hardware relativamente barato. Además es posible utilizar dichos sistemasparalelos para la realización de otros trabajos cuando no estén ocupados con una tarea enparalelo.

3

4 CAPÍTULO 1. INTRODUCCIÓN

Si no es el procesamiento paralelo lo que se busca, pero queremos mejorar el rendimientode nuestra aplicación, se pueden hacer multitud de cosas. En aplicaciones secuenciales pode-mos usar un procesador más rápido, añadir memoria al sistema, etc.

1.2. Definiciones Básicas

Aunque el procesamiento paralelo haya sido utilizado durante muchos años en una granvariedad de sistemas, todavía no es familiar para la mayoría de los usuarios. Antes de comenzarla discusión de las varias alternativas existentes para implementar el procesamiento paralelo,es importante precisar el significado de algunos conceptos fundamentales.

1.2.1. Características Físicas de la Comunicación

Velocidad de Transferencia de Datos

En el campo de las redes de comunicación el intercambio de información entre orde-nadores se realiza generalmente mediante transmisiones analógicas. En una transmisión analóg-ica el ancho de banda se define como la diferencia máxima entre la frecuencia más alta y másbaja de la señal sobre la que se transporta la información. Existe una relación directa entreel ancho de banda y la velocidad de transmisión: cuanto mayor es el ancho de banda de unsistema de transmisión, mayor es la velocidad a la que se pueden transmitir los datos en elmedio.

Podemos definir la velocidad de modulación de una señal analógica como el número deveces por segundo que la señal cambia su valor en la línea o medio de transmisión. Estavelocidad se mide en baudios. El número de baudios determina la cantidad de cambios deestado por segundo que se producen en una transmisión. Cuantos más estados, más cantidadde bits por segundo se podrán transmitir.

Definimos la velocidad de transmisión como el número de bits transmitidos por segundo.Su unidad es el bps (bits por segundo). En general si el número de estados posibles de la líneade comunicación es � , a cada estado le corresponderán � �"! � � bits de información.

Imaginemos que en una red telefónica que funciona a 2400 baudios podemos transmitir4 bits en cada baudio. En ese caso la velocidad de transmisión sería de 2400 baudios x 4(bits/baudio) = 9600 bits por segundo.

En la transmisión de información 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-ción a transmitir se le deben añadir otras informaciones adicionales para detección/correcciónde errores, para establecer y controlar la comunicación, etc. Aparece aquí un nuevo conceptode velocidad que llamaremos velocidad de transferencia de datos, y que representa la cantidadde información útil que puede transmitirse por unidad de tiempo.

Latencia

En un sistema de comunicación llamamos latencia al mínimo tiempo empleado en transmi-tir un dato, incluyendo la información de control necesaria para enviarlo o recibirlo. La latenciaes muy importante en procesamiento paralelo porque determina el tamaño granular, es decir,

1.2. DEFINICIONES BÁSICAS 5

lo mínimo que debe tardar la ejecución de un segmento de código para que su ejecución enparalelo sea rentable, hablando en términos de rendimiento computacional.

Básicamente si un segmento de código se ejecuta en menos tiempo del que se emplea entransmitir su resultado (latencia), entonces será más rápido ejecutar dicho segmento de códigode manera secuencial en el procesador que necesita dicho resultado; de este modo la ejecuciónsecuencial evitaría la sobrecarga en la comunicación.

1.2.2. Estándares Relacionados

IA32

El modelo IA32 (“Intel Architecture, 32-bit”) es una especificación para microproce-sadores que define su arquitectura y funcionalidad, o lo que es lo mismo, su comportamientodesde el punto de vista del software. Dicha especificación define entre otros elementos lassiguientes características de los microprocesadores:� Los modos de operación� La organización 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 más recientes: Pentium, P6, Pentium 4, Pentium M y Xeon. AMD y Cyrix tambiéndesarrollan multitud de procesadores compatibles con la arquitectura IA32.

Dado que Linux se desarrolló en principio en procesadores IA32, y dado que ésta fue lamanera en que se centró en el mercado, es conveniente usar dicha denominación IA32 paradistinguir este tipo de procesadores de los PowerPC, Alpha, PA-RISC, MIPS, SPARC, etc.

RAID

Como en otras áreas de rendimiento en los computadores, los diseñadores de memorias dedisco reconocen que si uno de los componentes sólo puede alcanzar un determinado límite, sepuede conseguir una ganancia en prestaciones adicional usando varios de esos componentesen paralelo. En el caso de las memorias de disco, esto conduce al desarrollo de conjuntos dediscos que operen independientemente y en paralelo.

Siguiendo este principio, el esquema RAID (“Redundant Array of Independent Disks”,Conjunto Redundante de Discos Independientes) es una tecnología sencilla para mejorar tantoel 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 relación jerárquica, pero designan diseños dearquitecturas diferentes que poseen tres características comunes:


SegmentaciónProcesadores

Auxiliares

Paralelismo Implícito

Múltiples ALUs

Figura 1.1: Clasificación Paralelismo Implícito

1. RAID es un conjunto de unidades físicas de disco vistas por el sistema operativo comouna única unidad lógica.

2. Los datos se distribuyen a través de las unidades físicas de un conjunto.

3. La capacidad de los discos redundantes se usa para almacenar información de paridad,que garantice la recuperación de los datos en caso de fallo de disco.

Los detalles de la característica segunda y tercera cambian según los distintos niveles de RAID.RAID 0 no soporta la tercera característica. Linux soporta los estándares RAID 0, 1, 4 y 5además de hardware RAID especializado.

1.3. Clasificación Sistemas Paralelos

En general, se puede dividir el paralelismo de los computadores en dos grandes ramas:� Paralelismo implícito o de bajo nivel� Paralelismo explícito o de alto nivel

1.3.1. Paralelismo Implícito o de Bajo Nivel

La técnicas de paralelismo implícito están dirigidas al reforzamiento del nivel de concur-rencia dentro de la CPU, de manera que queda oculta a la arquitectura del ordenador. Por lotanto pueden ser vistos como sistemas de un sólo procesador. Como ejemplos de paralelismode bajo nivel están:� Segmentación o pipeline: La ejecución de cada instrucción se divide en una secuencia

de etapas, de forma que varias instrucciones pueden ejecutarse en paralelo, cada una enuna etapa distinta de su ejecución.� Múltiples Unidades Funcionales en el Procesador: La repetición de ALUs permite unaaproximación superescalar, con la ejecución paralela de varias instrucciones, todas enla misma etapa de su ejecución. Un procesador superescalar es aquel en el que las in-strucciones comunes (aritmética entera y en punto flotante, cargas, almacenamientos ybifurcaciones condicionales) pueden iniciar su ejecución simultáneamente y ejecutarsede manera independiente. Estas implementaciones plantean problemas complejos de

1.3. CLASIFICACIÓN SISTEMAS PARALELOS 7

(Procesadores Vectoriales)MISD

Memoria CompartidaMultiprocesadores

(SMP)

Memoria DistribuidaMulticomputadores

(Cluster)

(Procesadores Matriciales)

Paralelismo Explícito

SIMDMIMD

Figura 1.2: Clasificación Paralelismo Explícito

diseño relacionados con el cauce de instrucciones.En esta línea, la tecnología SWAR consiste en agilizar las operaciones en registros de en-teros mediante la división de dichos registros en una serie de campos de igual longitud,asignando una ALU a cada uno de los campos y realizando la ejecución paralelamente.En este caso se ejecuta la misma instrucción sobre distintos datos en paralelo.� Procesadores Auxiliares (“Attached Processors”): Los procesadores auxiliares son es-encialmente computadores de propósito específico que se conectan a un sistema host oservidor para acelerar determinados tipos de cómputo. El ejemplo más común es el usode procesadores de E/S, que liberan a la CPU de la responsabilidad del control detalladode las operaciones de E/S.

1.3.2. Paralelismo Explícito o de Alto Nivel

El paralelismo explícito o de alto nivel hace referencia a aquellos sistemas en los cualesse interconectan varios procesadores para cooperar en la ejecución de los programas de apli-cación. Se trata de sistemas que ofrecen una infraestructura explícita para el desarrollo delsoftware del sistema y aplicaciones que exploten el paralelismo.

La forma más común de clasificar los sistemas de procesadores paralelos fue la introducidapor Flynn, la cual establece las siguientes categorías 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 losdatos almacenados en una memoria. De este modo en cualquier momento sólo se es-tá ejecutando una única instrucción. Esta categoría responde a la arquitectura de VonNeumann, también llamados computadores serie escalares.� SIMD (“Single Instruction Multiple Data”, Flujo de instrucciones único y flujo de datosmúltiple): Una única instrucción es aplicada sobre diferentes datos al mismo tiempo. Enlas máquinas de este tipo un cierto número de elementos procesadores son controladosy sincronizados mediante una unidad de control. Cada elemento procesador tiene unamemoria asociada, de manera que cada instrucción es ejecutada simultáneamente por


todos los elementos procesadores pero sobre un conjunto de datos diferentes. Debidoa su utilidad en el procesamiento de matrices, a este tipo de máquinas se les llamaprocesadores matriciales.� MISD (“Multiple Instruction Single Data”, Flujo de instrucciones múltiple y flujo dedatos único): Varias instrucciones actúan simultáneamente sobre un único trozo de datos.Este tipo de máquinas se pueden interpretar de dos maneras. En principio, podemos con-siderarlas como máquinas formadas por varias unidades de procesamiento, las cualesreciben 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 siguiendoeste modelo. Otra forma de interpretar el modelo MISD es considerarlo como una clasede máquinas donde un mismo flujo de datos fluye a través de numerosas unidades deprocesamiento. Arquitecturas altamente segmentadas, como la que poseen los arrayssistólicos o los procesadores vectoriales, son clasificadas a menudo bajo esta categoría.Estas arquitecturas realizan el procesamiento vectorial a través de una serie de etapas,cada una ejecutando una función particular produciendo un resultado intermedio. Larazón por la cual dichas arquitecturas son clasificadas como MISD es que los elementosde un vector pueden ser considerados como pertenecientes al mismo dato, y todas lasetapas del cauce representan múltiples instrucciones que son aplicadas sobre ese vector.� MIMD (“Multiple Instruction Multiple Data”, Flujo de instrucciones múltiple y flujode datos múltiple): Un conjunto de unidades de procesamiento ejecuta simultáneamentediferentes secuencias de instrucciones sobre conjuntos de datos diferentes. Es la organi-zación que poseen los sistemas multiprocesadores y multicomputadores en general.SPMD es una versión restringida de MIMD en la cual todos los procesadores ejecutanel mismo programa. Al contrario que SIMD, cada procesador ejecuta una secuencia deinstrucciones diferente.

En la organización MIMD, los procesadores son de uso general, puesto que deben ser capacesde procesar todas las instrucciones necesarias para realizar las transformaciones apropiadas delos datos. Las arquitecturas MIMD se pueden subdividir además según la forma que tienenlos procesadores para comunicarse (figura 1.2). Si los procesadores comparten una memoriacomún, entonces cada procesador accede a los programas y datos almacenados en la memoriacompartida, y los procesadores se comunican unos con otros a través de esa memoria. Estetipo de sistemas se conocen como multiprocesadores fuertemente acoplados o simplementemultiprocesadores.

Si cada procesador tiene una memoria dedicada, entonces cada elemento de proceso esen sí mismo un computador. La comunicación entre los computadores se realiza a través decaminos fijos o mediante algún mecanismo de conmutación de mensajes. Este tipo de sistemasse conocen como multiprocesadores débilmente acoplados o multicomputadores.

1.4. ARQUITECTURAS BASADAS EN PARALELISMO IMPLÍCITO 9

Istrucción ResultadoIstrucciónEjecuciónCaptación

Figura 1.3: Ciclo de Instrucción de 2 etapas (A)

1.4. Arquitecturas Basadas en Paralelismo Implícito

1.4.1. Segmentación o pipeline

Desde 1960 esta arquitectura ha recibido una gran atención debido a la considerable mejoraque ha producido en la velocidad de proceso sin que ello aumente, en la misma medida, el costedel sistema.

La segmentación de instrucciones es similar al uso de una cadena de montaje en una fábri-ca. Una cadena de montaje saca partido al hecho de que el producto pasa a través de variasetapas de producción. De esta manera se puede trabajar sobre los productos en varias etapassimultáneamente. A este proceso se le llama segmentación (“pipelining”) porque, como en unatubería o cauce (“pipeline”), en un extremo se aceptan nuevas entradas antes de que algunasentradas aceptadas anteriormente aparezcan como salidas en el otro extremo.

Para aplicar este concepto a la ejecución de instrucciones debemos darnos cuenta de que enrealidad una instrucción tiene varias etapas. La figura 1.4 muestra, por ejemplo, una particióndel ciclo de instrucción en 10 etapas que tienen lugar secuencialmente. Claramente puedepensarse en la utilización de la segmentación.

Como una aproximación sencilla consideremos la subdivisión del procesamiento de unainstrucción en dos etapas: captación de instrucción y ejecución de instrucción. Hay períodosen la ejecución de una instrucción en los que no se accede a memoria principal. Este tiempopodría utilizarse para captar la siguiente instrucción en paralelo con la ejecución de la actual.La figura 1.3 representa esta aproximación.

El cauce tiene dos etapas independientes. La primera etapa capta una instrucción y laalmacena en un buffer. Cuando la segunda etapa está libre la primera le pasa la instrucciónalmacenada. Mientras que la segunda etapa ejecuta la instrucción, la primera etapa utilizaalgún ciclo de memoria no usado para captar y almacenar la siguiente instrucción. A ésto sele llama prebúsqueda o precaptación de la instrucción (“instruction prefetch”) o solapamientode la captación (“fetch overlap”). Debería estar claro que ese proceso acelerará la ejecución deinstrucciones.

10C

APÍT

UL

O1.

INT

RO

DU

CC

IÓN

Almacenamientodel operando

del operando

Cálculo dela dirección Chequeo de

interrupciones

Más deun resultado

Indirección

Nointerrupción

Interrupción

datos

Operacióncon los

Captación deloperando

Más deun operando

del operando

Cálculo dela dirección

de la instrucciónde la operaciónDecodificación

Captación deinstrucción

de la instrucción

Cálculo dela dirección

Solicitud deinstrucción

Solicitud deoperando

Indirección

Cadenao vector

Siguienteinstrucción

Figura 1.4: Ciclo de Instrucción de 10 etapas


Descartar

Istrucción

Nueva dirección

Resultado

Esperar

Istrucción

Esperar

Captación Ejecución

Figura 1.5: Ciclo de Instrucción de 2 etapas (B)

Si las etapas de captación y ejecución fueran de igual duración, el tiempo de ciclo deinstrucción se reduciría a la mitad. Sin embargo si miramos más atentamente el cauce de lafigura 1.5 veremos que la duplicación de la velocidad de ejecución es poco probable por dosrazones:

1. El tiempo de ejecución será generalmente más largo que el tiempo de captación. Laejecución implicará la lectura y almacenamiento de los operandos y la realización dealguna operación. De este modo la etapa de captación puede tener que esperar algúntiempo antes de que pueda vaciar su buffer.

2. Una instrucción de bifurcación condicional hace que la dirección de la siguiente instruc-ción a captar sea desconocida. De este modo, la etapa de captación debe esperar hastaque reciba la dirección de la siguiente instrucción desde la etapa de ejecución. La etapade ejecución puede entonces tener que esperar mientras se capta la siguiente instrucción.

La pérdida de tiempo debida a la segunda razón puede reducirse haciendo una estimación.Una regla simple es la siguiente: cuando una instrucción de bifurcación condicional pasa dela etapa de captación a la de ejecución, la etapa de captación capta la instrucción de memoriaque sigue a la instrucción de salto. Entonces si el salto no se produce no se pierde tiempo. Siel salto se produce debe desecharse la instrucción captada y captar una nueva instrucción.

Aunque estos factores reduzcan la efectividad potencial del cauce de dos etapas, se producealguna aceleración. Para conseguir una mayor aceleración, el cauce debe tener más etapas.Consideremos la siguiente descomposición del procesamiento de una instrucción:� Captar Instrucción (“Fetch Instruction”, FI): Leer la supuesta siguiente instrucción en

un buffer.� Decodificar Instrucción (“Decode Instruction”, DI): Determinar el código de operacióny los campos del operando.� Calcular Operandos (“Calculate Operands”, CO): Calcular la dirección efectiva de ca-da operando fuente. Esto puede involucrar varios modos de direccionamiento: mediantedesplazamiento, indirecto a través de registro, indirecto u otros.� Captar Operandos (“Fetch Operands”, FO): Captar cada operando de memoria. Losoperandos en registros no tienen que ser captados.


DIFI EO WOCO FO

DIFI EO WOCO FO

DIFI EO WOCO FO

DIFI EO WOCO FO

DIFI EO WOCO FO

DIFI EO WOCO FO

DIFI EO WOCO FO

DIFI EO WOCO FO

DIFI EO WOCO FO

4 5 61 2 3 7 8 9 10 11 12 13 14

Instrucción 2

Instrucción 3

Instrucción 4

Instrucción 5

Instrucción 6

Instrucción 7

Instrucción 8

Instrucción 9

Instrucción 1

Figura 1.6: Cauce de 6 etapas� Ejecutar Instrucción (“Execute Instruction”, EI): Realizar la operación indicada y al-macenar el resultado, si lo hay, en la posición de operando destino especificada.� Escribir Operando (“Write Operand”, WO): Almacenar el resultado en memoria.

Con esta descomposición las diversas etapas tienen casi igual duración. Por motivos de clar-idad asumamos que tienen igual duración. La figura 1.6 muestra cómo un cauce de 6 etapaspuede reducir el tiempo de ejecución de 9 instrucciones de 54 a 14 unidades de tiempo.

En realidad dicha simulación es demasiado idealista. Para empezar no todas las instruc-ciones recorren las 6 etapas del cauce; por ejemplo, una instrucción de carga no necesita laetapa WO. Ello complica el hardware del cauce. Además la mayoría de los sistemas no per-miten varios accesos a memoria simultáneos, por lo que las etapas FI, FO y WO no podríanejecutarse al mismo tiempo.

Otros factores como la dificultad en la ejecución de la bifurcación condicional ya comenta-da, o la espera que se produce en ciertas etapas cuando no todas las etapas son de igual duración(lo cual es lo más común), complican el diseño y limitan la mejora de las prestaciones.

Según toda esta discusión precedente, puede parecer que cuanto mayor sea el número deetapas en el cauce, más rápida será la velocidad de ejecución. Algunos diseñadores del IBMS/360 observaron dos factores que frustran este aparente sencillo patrón de diseño de altasprestaciones, y que siguen siendo ciertos hoy día:

1. En cada etapa, hay algún gasto extra debido a la transferencia de datos de buffer a buffery a la realización de varias funciones de preparación y distribución.


2. La cantidad de control lógico necesario para manejar dependencias de memoria y reg-istros y para optimizar el uso del cauce aumenta enormemente con el número de etapas.

En definitiva, la segmentación de instrucciones es una poderosa técnica para aumentar lasprestaciones pero requiere un diseño cuidadoso si se quieren obtener resultados óptimos conuna complejidad razonable.

La emergencia de la segmentación y su temprana evolución se produjo en la primera líneade supercomputadores IBM. El modelo IBM 7030 (llamado computador “a toda mecha”) su-peró en 100 veces la velocidad del computador más rápido en producción de aquella época,el IBM 704. Dicho logro sólo se pudo alcanzar mediante la segmentación de instrucciones.Luego vinieron otros éxitos como el IBM 360/91, el procesador 6502, y un largo etc. Hoy díatodas las compañías implementan es sus procesadores este tipo de arquitectura.

1.4.2. Tecnología SWAR

SWAR (“SIMD Within A Register”, Paralelismo SIMD Dentro de un Registro) es el tér-mino genérico aplicado a un tipo de paralelismo interno al procesador. La idea consiste enagilizar las operaciones en registros de enteros mediante la división de dichos registros enuna serie de campos de igual longitud, asignando una unidad de procesamiento (una ALU endefinitiva) a cada uno de los campos y realizando la ejecución paralelamente.

Dada una máquina con registros de # bits y � ALUs, se puede lograr que sus operacionessobre registros funcionen como operaciones paralelas SIMD en � campos de #%$&� bits. Detodas formas sólo con el empuje de las tecnologías multimedia, que han conseguido acelerarlas operaciones en un rango de 2x hasta 8x, se ha llegado a la popularidad e importancia dedicha tecnología. Ya en 1997 la mayoría de los microprocesadores incorporaban soporte dehardware 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”, Extensionesde Aceleración 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 MediaDigital 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 demás conjuntos de instrucciones son difícilmente compara-bles, y mutuamente incompatibles. Con el paso del tiempo las MMX también evolucionaron,generandose nuevas extensiones como las EMMX de Cyrix, las 3DNow! de AMD o las SSEy SSE2 de Intel, entre otras.

1.4.2.1. Utilidades de SWAR

Aunque todos los procesadores actuales son capaces de ejecutar al menos algún tipo deparalelismo basado en la tecnología SWAR, la realidad es que ni siquiera los juegos de instruc-ciones SWAR más desarrollados soportan paralelismo de carácter general. De hecho, muchospiensan que la diferencia de rendimiento entre un procesador Pentium y un Pentium MMX sedebe más a factores como el mayor tamaño de la caché que a la aparición de las MMX. Asípues... ¿para qué es realmente buena la tecnología SWAR?� Operaciones sobre datos de tipo entero, cuanto más pequeños mejor. Dos valores de 32

bits caben en un registro MMX de 64 bits, pero también lo hacen ocho caracteres de unbyte o incluso un tablero de ajedrez con valores de un bit. Cuando un dato ocupa varioscampos 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 tamaño de dichos enteros, más limpias serán las operaciones y porlo tanto mejor aprovecharemos el parelismo generado por la repetición de ALUs.Nota: En los juegos de instrucciones más actuales, como lal EMMX, las 3DNow! o lasSSE2, también se admiten operaciones sobre datos de tipo flotante.� Paralelismo SIMD o de vectores, en el cual la misma operación es aplicada a todos loscampos simultáneamente. Hay maneras de anular la operación en algunos campos selec-cionados (enmascaramiento), pero ello complica el código y disminuye el rendimiento.� Referencias a memoria localizadas y regulares. SWAR en general y MMX en particularno obtienen buenos resultados utilizando accesos aleatorios. Reunir con dichos accesosun vector x[y] (donde y es un índice de dicho vector) resulta demasiado costoso.

Es cierto que todas éstas son restricciones muy duras, pero también es cierto que dicho tipode paralelismo se da en muchos algoritmos paralelos (no sólo en aplicaciones multimedia).Enfocada al tipo de paralelismo adecuado, la tecnología SWAR puede ser más eficiente queutilizar SMPs o Clusters... y no cuesta nada utilizarla.

1.4.2.2. Soporte MMX Bajo Linux

Bajo Linux los procesadores IA32 son nuestro principal interés. Lo bueno es que tantolos AMD, como los Cyrix y los Intel tienen una base común, las instrucciones MMX. Sinembargo el rendimiento de dichas instrucciones varía, y además, actualmente cada firma tienesus propias extensiones; por lo tanto programar un soporte para dichas instrucciones puederesultar algo engorroso.

Existen tres métodos para utilizar MMX en SWAR:


1. Utilizar una librería de funciones MMX ya desarrollada. En la Universidad de Purdueexiste un grupo de trabajo (URL [15]) que ha desarrollado librerías adaptadas a variosjuegos de instrucciones determinados. Así, tenemos la librería libmmx diseñada paralas instrucciones MMX en general, la librería libxmmx para las Cyrix EMMX y lalibrería libsse para las Intel SSE. También existe una librería un tanto curiosa, MMXEmulator (URL [7]), diseñada para ejecutar programas que usen instrucciones MMXen 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. Elprimer 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 elensamblador para IA32 que utilicemos en Linux podría no soportar dichas instruccionesMMX.

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]) seha desarrollado un lenguaje llamado SWARC y su compilador, el Scc, el cual está enpermanente fase experimental, aunque disponible. Como sus autores señalan, Scc nopretende ser un producto de alta calidad en términos de eficiencia; en cambio propor-ciona una implementación básica 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 propósito específico quese conectan a un sistema host o servidor para acelerar determinados tipos de cómputo. Porejemplo, muchas tarjetas de vídeo y audio para PCs contienen procesadores auxiliares diseña-dos, respectivamente, para acelerar operaciones sobre gráficos y audio.

Aunque esta técnica ya no está en auge, es muy difícil que otros métodos de procesamientoparalelo alcancen su bajo coste y alto rendimiento. Una buena manera de sacarle partido a estosprocesadores es utilizar un PC bajo Linux como servidor. El problema es que no existe muchosoftware de soporte disponible, por lo que en ocasiones tendremos que trabajar por nuestracuenta desarrollándolo 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 actúe 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 ampliación, de manera fácil y barata. Recursos como la memoria, discos, redes, etc.son añadidos a un PC de manera trivial. La segunda es su facilidad de interconexión a otrosdispositivos a través de sus interfaces estándar. No sólo están ampliamente disponibles losprototipos de los buses ISA y PCI si no que además disponemos del puerto paralelo, el cual


Figura 1.7: Procesamiento Digital de Señales

ofrece un rendimiento razonable en un iterfaz independiente. Además la separación del es-pacio de E/S en los microprocesadores IA32 facilita la interconexión, proporcionando unaprotección 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 código fuente y la extensa documentación existente son una ayuda tremenda,obviamente. Además Linux proporciona una planificación cercana al tiempo real, e inclusoexiste una versión de Linux en tiempo real desarrollada por FSMLabs (URL [3]). Pero lo quequizás es más importante es el hecho de que a la vez que proporciona un entorno UNIX com-pleto, Linux soporta herramientas de desarrollo que están diseñadas para ser ejecutadas bajoMicrosoft DOS o Windows. Los programas MSDOS pueden ser ejecutados en Linux usandodosemu, el cual proporciona una máquina virtual protegida que ejecuta MSDOS. El soportede Linux para los programas diseñados para Windows 3.xx es aún más directo: software li-bre como wine. Este software (URL [21]) simula Windows 3.xx y Win32 lo suficientementebien como para que la mayoría de los programas se ejecuten correcta y eficientemente en unentorno UNIX/X.

Las siguientes dos secciones arrojan ejemplos de sistemas paralelos que utilizan esta ar-quitectura que podrían ser soportados bajo Linux.

1.4.3.2. Procesadores DSP

Un DSP (“Digital Signal Processor”, Procesador de Señales Digitales) es un tipo de mi-croprocesador muy rápido y potente. Un DSP procesa los datos en tiempo real. Esta capacidadde tiempo real hace de los DSPs perfectos para aplicaciones que no pueden tolerar demoras.Así, suelen emplearse en el Procesamiento Digital de Señales, un método de procesamientode señales del mundo real que utiliza técnicas matemáticas para realizar transformaciones oextraer información, como se muestra en la figura 1.7.

Aquí tenemos algunas de las ventajas de dichos procesadores:� Operaciones de multiplicación y suma en un sólo ciclo� Funcionamiento en tiempo real, simulación y emulación� Flexibilidad� Fiabilidad� Aumenta rendimiento del sistema

1.4. ARQUITECTURAS BASADAS EN PARALELISMO IMPLÍCITO 17� Disminuye costes

Existe un próspero mercado para estos procesadores. Aunque estos chips fueron generalmentediseñados para ser utilizados en sistemas de aplicación específica, también pueden ser utiliza-dos como magníficos computadores paralelos auxiliares. Estos son los beneficios de utilizardichos procesadores como computadores paralelos auxiliares:� Muchos de ellos, como los Texas Instruments TMS320 y los Analog Devices SHARC

DSP, están diseñados para construir máquinas paralelas con poca o ninguna lógica deenlace.� Son económicos, especialmente por MIP o MFLOP. Incluyendo el coste de la lógicade soporte básica, suele decirse que su coste es una décima parte de lo que cuesta unprocesador para PC con un rendimiento comparable.� No utilizan mucha energía ni desprenden demasiado calor. Esto significa que es posibletener un grupo de estos chips alimentados por una fuente de alimentación convencionalpara 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 operación“Bit Reverse Addressing”. Usando un sistema paralelo auxiliar, es posible compilar yejecutar la mayoría del código en el servidor, ejecutando aquellos algoritmos que hacenun mayor consumo de tiempo en los DSPs. Dichos algoritmos pueden ser implementa-dos mediante un código cuidadosamente adaptado.� Los procesadores DSP no están diseñados para ejecutar un sistema operativo UNIX, ygeneralmente no son muy buenos como procesadores de propósito general. Por ejemplo,muchos de ellos no tienen hardware de manejo de memoria. En otras palabras, funcionanmejor como clientes de un servidor de propósito más general... como un PC bajo Linux.

Muchas tarjetas de sonido y modems incluyen procesadores DSP que pueden ser accedidosmediante controladores de Linux sin ninguna dificultad. Lo difícil llega cuando utilizamos unsistema paralelo auxiliar que contenga cuatro o más procesadores DSP... y eso es exactamentelo que nos interesa. Existen dos familias de procesadores DSP utilizados ampliamente paraprocesamiento paralelo:

Texas Instruments TMS320 Muy populares durante mucho tiempo, resulta muy sencilloconstruir un procesador paralelo basado en el TMS320. Existen versiones del TMS320sólo para enteros y también para punto flotante; los diseños más antiguos usaban algúntipo inusual del formato punto flotante de precisión simple, pero los nuevos modelos so-portan los formatos IEEE. El antiguo TMS320C4x consigue hasta 80 Mflops usando elformato punto flotante simple precisión específico de Texas Instruments; en constraste,el TMS320C67x proporciona hasta 1Gflop simple precisión o 420 Mflops doble pre-cisión para los cálculos en formato punto flotante IEEE. No sólo es fácil configurar ungrupo de estos chips como un multiprocesador, si no que además 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 esclavoscon unidad de entero.


Analog Devices SHARC Estos chips pueden ser utilizados como un multiprocesador de 6procesadores con memoria compartida y sin lógica de conexionado externa. Sistemasmayores pueden ser construidos usando 6 enlaces de 4 bits por chip. Muchos de lossistemas más grandes son empleados en aplicaciones militares, y resultan económicos.En esta línea la compañía Integrated Computing Engines, llamada en la actualidad Me-dia100, ofrece una gama de tarjetas PCI llamadas GreeICE y BlueICE, ésta última másactual. La primera versión (GreenICE) contiene una matriz de 16 procesadores SHARCy es capaz de proporcionar picos de velocidad de hasta 1,9 Gflops usando el formatoIEEE simple precisión. BlueICE triplica dicha velocidad, y su coste no es elevado.

1.4.3.3. FPGAs y Computadores de Lógica Reprogramable

Si el paralelismo consiste en conseguir la máxima velocidad, ¿por qué no construimosnuestro propio hardware? El problema es que cuesta mucho, lleva mucho tiempo su desarrollo,se vuelve inservible cuando cambiamos el algoritmo aunque sea sólo un poco, etc. Sin embargorecientes avances en los FPGAs (“Field Programmable Gate Array”, Matriz de CompuertasLógicas Programable) eléctricamente reprogramables han anulado dichas objeciones. Ahorala densidad de compuertas es lo suficientemente alta como para un procesador simple puedaser construido en un único FPGA. Además el tiempo de reconfiguración (reprogramación) delos FPGAs ha bajado a un nivel en el que es razonable incluso reconfigurar el FPGA cuandopasamos de una fase de un algoritmo a otra.

Normalmente debemos trabajar con lenguajes de descripción de hardware como VHDLpara la reconfiguración del FPGA, así como escribir código de bajo nivel que haga de interfazcon los programas del sistema host Linux. Pero el esfuerzo merece la pena, ya que el coste delos FPGAs es bajo, especialmente para algoritmos que operen con enteros de baja precisión(en realidad un subconjunto de aquellas operaciones para las que fué diseñado SWAR). LosFPGAs pueden realizar complejas operaciones tan rápido como podamos introducir los datos.Por ejemplo, sistemas basados en un único FPGA han alcanzado tiempos mejores que lossupercomputadores en la búsqueda de bases de datos genéticas.

Las siguientes dos compañías desarrollan hardware basado en FPGA:

Virtual Computer Company Esta compañía ofrece una variedad de productos que usan FP-GAs Xilinx dinámicamente 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 ProtoBoard” de Virtual Computer Company, pero utiliza FPGAs Altera y el interfaz PCI envez del ISA.

Muchas de las herramientas de diseño, lenguajes de descripción de hardware, compiladores,etc. funcionan sólo bajo Windows o DOS, por lo que podríamos utilizar dosemu o wine paraejecutarlos bajo Linux.

1.5. ARQUITECTURAS BASADAS EN PARALELISMO EXPLÍCITO 19

E/S

E/S

E/S

CPU CPU CPU

Interconexión

Memoria Principal

Figura 1.8: Esquema Multiprocesador

1.5. Arquitecturas Basadas en Paralelismo Explícito

1.5.1. Multiprocesadores

Un sistema multiprocesador es aquel que está formado por un conjunto de procesadoresque comparten una memoria principal común y están bajo el control de un mismo sistemaoperativo. Las principales características de un procesador de este estilo son:

1. Posee dos o más procesadores de propósito general similares y de capacidades compa-rables.

2. Todos los procesadores comparten el acceso a una memoria global (común). Tambiénpueden utilizarse memorias locales (privadas).

3. Todos los procesadores comparten el acceso a los dispositivos de E/S, bien a través delos mismos canales o bien a través de canales distintos que proporcionan caminos deacceso a los mismos dispositivos.

4. El sistema está controlado por un sistema operativo integrado que permite la interacciónentre los procesadores y los programas.

La figura 1.8 describe en términos generales la organización de un sistema multiproce-sador. Hay dos o más CPUs. Cada CPU es autónoma, incluyendo una unidad de control, una


CPU CPU E/S E/S Memoria Memoria

Bus del Sistema

Figura 1.9: Organización Básica Bus de Tiempo Compartido

ALU, registros y posiblemente una caché. Cada CPU tiene acceso a una memoria principalcompartida y a los dispositivos de E/S a través de algún mecanismo de interconexión. Losprocesadores pueden comunicarse entre sí a través de la memoria (mensajes de informaciónde control almacenada en áreas comunes de datos). También es posible que las CPUs inter-cambien señales directamente, como indican las líneas discontinuas. La memoria a menudose organiza de forma que sean posibles los accesos simultáneos a bloques de memoria separa-dos. En algunas configuraciones cada CPU puede tener también su propia memoria principalprivada y sus canales de E/S además de los recursos compartidos.

1.5.1.1. Organización

La organización de un sistema multiprocesador puede clasificarse como sigue:� Bus de Tiempo Compartido o Común� Memoria Multipuerto� Unidad de Control Central

Bus de Tiempo Compartido

El Bus de Tiempo Compartido es el mecanismo más simple para construir un sistema mul-tiprocesador (figura 1.9). La estructura y las interfaces son básicamente las mismas que las deun sistema monoprocesador que utilice un bus para la interconexión. El bus consta de líneasde control, dirección 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 módulos del bus para determinar la

fuente y el destino del mensaje.� Arbitraje: Cualquier módulo de E/S puede funcionar temporalmente como maestro. Seproporciona un mecanismo para arbitrar entre las peticiones que compiten por el controldel bus, utilizando algún tipo de esquema de prioridad.


CPU

Caché

CPU

CachéE/S E/S Memoria Memoria

Bus del Sistema

Figura 1.10: Organización Bus de Tiempo Compartido con Caché� Tiempo Compartido: Cuando un módulo está controlando el bus, los demás módulos notienen acceso al mismo y deben, si es necesario, suspender su funcionamiento hasta quedispongan del bus.

Estos elementos son utilizables directamente en una configuración de multiprocesador. En estecaso hay varias CPUs además de varios procesadores de E/S que intentan acceder a uno o másmódulos de memoria a través del bus.

La organización de Bus de Tiempo Compartido presenta diversas ventajas en comparacióncon otras aproximaciones:� Simplicidad: Es la aproximación más sencilla para organizar el multiprocesador. La

interfaz física y la lógica de cada procesador para el direccionamiento, el arbitraje, y paracompartir el tiempo del bus es la misma que la de un sistema con un solo procesador.� Flexibilidad: Es generalmente sencillo expandir el sistema conectando más CPUs al bus.� Fiabilidad: El bus es esencialmente un medio pasivo, y el fallo de cualquiera de losdispositivos conectados no provocaría el fallo de todo el sistema.

La principal desventaja de la organización de bus compartido son las prestaciones. Todas lasreferencias a memoria pasan por el bus. En consecuencia, la velocidad del sistema está limitadapor el tiempo de ciclo. Para mejorar las prestaciones es deseable equipar a cada CPU con unamemoria caché (figura 1.10). Ésta reduciría considerablemente el número de accesos.

El uso de cachés introduce algunas consideraciones de diseño nuevas. Puesto que cadacaché local contiene una imagen de una parte de la memoria, si se altera una palabra en unacaché es posible que quede invalidada una palabra en otra caché. Para evitarlo debe avisarse alas otras CPUs de que se ha producido una actualización de la memoria. Esto por lo generalcomplica el diseño del sistema.

Memorias Multipuerto

La organización de memorias multipuerto permite el acceso directo e independiente alos módulos de memoria desde cada una de las CPUs y los módulos de E/S (figura 1.11).Se necesitará un sistema de arbitraje para resolver los conflictos. El método que se utiliza amenudo para ello consiste en asignar prioridades fijas a cada puerto de memoria. Normalmente


CPU1

CPUn

M1 M2 Mk

E/S 1

E/S m

Figura 1.11: Organización Memorias Multipuerto

la interfaz física y eléctrica en cada puerto es idéntica a la que aparece en un módulo dememoria de un sólo puerto. Así, se necesitan pocas o ninguna modificación en las CPUs o enlos módulos de E/S para adaptarlas a este modelo de organización.

La organización de memorias multipuerto es más compleja que la organización de buscompartido, precisándose añadir al sistema una buena cantidad de lógica. No obstante se con-siguen mejores prestaciones puesto que cada procesador tiene un camino específico a cada mó-dulo de memoria. Otra ventaja del multipuerto es que permite configurar partes de la memoriacomo “privadas” para una o más CPUs y/o módulos de E/S. Estas características permitenincrementar 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 otrosprocesadores.

Unidad de Control Central

La unidad de control central encauza las distintas secuencias de datos entre los distintosmódulos independientes: CPU, memoria, E/S. El controlador puede almacenar temporalmentepeticiones y realizar las funciones de arbitraje y temporización. Además puede transmitir men-sajes de estado y control entre las CPUs y alertar sobre cambios en las cachés.

Puesto que toda la lógica de coordinación de la configuración de multiprocesador se con-centra en la unidad de control central, las interfaces de E/S, memoria, y CPU no sufren cambiosesenciales. Esto proporciona la flexibilidad y simplicidad de conexión propias de la aproxi-mación del bus compartido. Las desventajas clave de esta aproximación son que la unidad decontrol es bastante compleja y que representa un cuello de botella potencial para las presta-ciones.


1.5.1.2. Multiprocesadores Simétricos (SMP)

SMP (“Symmetric Multi-Processor”, Multiprocesadores Simétricos) se refiere, en térmi-nos de sistemas operativos, al concepto de grupo de procesadores trabajando juntos comopares, de manera que cualquier parte del trabajo puede ser realizada por cualquiera de losprocesadores sin diferencia alguna. Este tipo de sistemas son multiprocesadores, es decir,pertenecen al modelo MIMD con memoria compartida. En el mundo IA32, SMP significacumplir con la norma MPS (“Intel MultiProcessor Specification”, Especificación Multiproce-sador de Intel).

En un SMP todos los procesadores pueden acceder a la misma memoria, generalmentemediante un bus compartido de alta velocidad. La comunicación entre los procesadores esfácil en principio. Cualquier procesador puede dejar datos o mensajes en una posición deter-minada y luego indicar a otro procesador la dirección en la que puede encontrar los datos.Esto es típico del multiprocesamiento; así, un computador ejecuta una o más aplicaciones quese componen de una serie de procesos secuenciales que cooperan entre sí. Este esquema sepuede implementar en un sistema monoprocesador, pero también se puede implementar fácil-mente en un sistema multiprocesador SMP: en cualquier momento cada uno de los múltiplesprocesadores está ejecutando un proceso distinto. La comunicación entre procesos se realizamediante mensajes y señales de estado que pueden intercambiarse los procesadores a travésde la memoria.

En la práctica el nivel de prestaciones deseado complica la comunicación entre los proce-sadores. Cuando se tienen muchos procesadores rápidos compitiendo por acceder a la mismamemoria a través del mismo bus, los conflictos pueden degradar seriamente el rendimientodel conjunto del sistema. La solución, como hemos visto, es añadir una caché local a cadaprocesador. Esta solución ocasiona el problema adicional de la coherencia de caché. La coor-dinación entre los procesadores que se requiere para resolver el problema origina un cuello debotella en el bus compartido. El resultado es que los multiprocesadores típicos están limitadosa unas pocas decenas de procesadores. Un multiprocesador SMP con miles de procesadoresno parece que sea muy práctico.

1.5.1.3. Soporte SMP Bajo Linux

Antes de entrar a discutir aspectos más técnicos, debemos hacernos primero un par de cues-tiones acerca de esta arquitectura que, si bien es una de las más extendidas en procesamientoparalelo, tiene un soporte relativamente reciente en Linux.

¿Funciona realmente SMP en Linux? Funciona. Además es una opción con una buenarelación coste/rendimiento para paralelizar nuestro sistema, ya que una placa base con soportepara varios procesadores y sus correspondientes micros normalmente elevará poco el preciodel sistema con respecto a un sistema uniprocesador.

En la mayoría de las ocasiones para hacer que Linux se ejecute en dicho hardware sólonecesitamos realizar una instalación de Linux con soporte para un solo procesador, y luegorecompilar el núcleo con la fila SMP=1 del fichero ‘Makefile’ activa. Entonces informaremosa lilo o nuestro gestor de arranque acerca del nuevo núcleo compilado, y a disfrutar. En cuantoa rendimiento y estabilidad podemos decir son sistemas bastante firmes. En resumen, SMPLinux realmente funciona.


La siguiente cuestión es cuánto soporte de alto nivel está disponible para escribir y ejecutarprogramas paralelos con memoria compartida en SMP Linux. Actualmente existe bastantesoftware dedicado a este propósito. Por ejemplo, ahora podemos contar con una librería muycompleta para el manejo de hilos POSIX.

Aunque el rendimiento puede ser menor que utilizando mecanismos especialmente creadospara trabajar con memoria compartida, un sistema SMP Linux también puede usar la mayoríadel software de procesamiento paralelo desarrollado originalmente para clusters de estacionesde trabajo. Dicho tipo de software utiliza comunicación vía sockets, y puede funcionar en unsistema SMP Linux e incluso en múltiples SMP conectados en red formando un cluster. Detodas formas la comunicación vía sockets implica mucha sobrecarga innecesaria en un sistemaSMP. Gran parte de esta sobrecarga se produce dentro del núcleo y en el manejo de interrup-ciones; ésto empeora el problema ya que SMP Linux generalmente sólo admite un procesadoren el núcleo al mismo tiempo y el manejador de interrupciones está implementado de maneraque sólo el procesador de arranque (“boot processor”) puede procesar interrupciones. A pesarde ello el hardware de comunicación de un SMP típico es tan superior a la mayoría de lasredes de comunicación de los clusters, que el software diseñado para dichos clusters a menudofuncionará mejor en los sistemas SMP que en los clusters para los que fué creado.

En el resto de esta sección estudiaremos qué tipo de sistemas SMP soporta Linux,aclararemos qué es la Especificación Multiprocesador de Intel, y haremos algunas observa-ciones acerca del uso de la memoria caché y la configuración del bus a utilizar.

Especificación Multiprocesador de Intel

Aunque los sistemas SMP han existido desde hace muchos años, hasta hace poco cadamáquina tendía a implementar sus funciones básicas de manera distinta al resto, de forma queel soporte del sistema operativo no era portable. Lo que ha cambiado esta situación es la MPS(“Intel MultiProcessor Specification”, Especificación Multiprocesador de Intel).

Los únicos sistemas que no cumplen la norma MPS ni la IA32 y tienen soporte bajo Linuxson las máquinas multiprocesador Sun4m de SPARC. Linux tiene soporte para la mayoría delas máquinas 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 losprocesadores Intel 386, Intel 486SX/SLC (la falta de unidad de punto flotante interfiere en losmecanismos SMP) y los procesadores AMD y Cyrix (requieren chips de soporte SMP que noparecen estar disponibles por el momento).

Es importante entender que el rendimiento de los sistemas que cumplen la norma MPSpuede variar ampliamente. Como era previsto, una causa de las diferencias de rendimiento esla velocidad del procesador: mayores frecuencias de reloj tienden a proporcionar sistemas máspotentes, teniendo en cuenta que un procesador Pentium Pro es más rápido que un Pentium. Detodas formas la norma MPS no especifica realmente cómo implementa el hardware la memoriacompartida; lo que sí especifica es la manera en la que esta implementación debe funcionardesde el punto de vista del software. Esto significa que el rendimiento está también en funciónde cómo interactúa la implementación de la memoria compartida con las características SMPLinux y nuestro sistema particular.

La principal diferencia entre los sistemas que cumplen la norma MPS es la manera en laque implementan físicamente el acceso a la memoria compartida.


Aspectos sobre la Memoria Caché

Algunos sistemas MPS con procesadores Pentium y todos los que llevan procesadoresPentium Pro y superiores tienen cachés L2 (“Level 2”, De Nivel 2) independientes (la memoriacaché L2 va dentro del módulo que contiene el procesador). El hecho de tener cachés L2separadas es considerado generalmente como una optimización del rendimiento; sin embargoésto no es tan obvio bajo Linux. La principal complicación está en que el planificador de SMPLinux no intenta mantener cada proceso en el mismo procesador, siendo éste un conceptodenominado afinidad con el procesador. Ésto podría cambiar pronto; recientemente se hangenerado discusiones sobre el tema en la comunidad SMP Linux bajo el título “Enlace conel procesador”. Sin afinidad con el procesador, el hecho de tener cachés L2 separadas podríaintroducir una sobrecarga importante cuando le demos ciclos de reloj a un proceso en unprocesador distinto al que estaba ejecutando dicho proceso anteriormente.

Muchos sistemas relativamente económicos están organizados de manera que dos proce-sadores Pentium comparten una memoria caché L2. Lo malo es que ésto provoca competenciaentre los procesadores por el uso de la caché, degradando seriamente el rendimiento cuandose ejecutan múltiples programas secuenciales independientes. Sin embargo la mayoría de losprogramas paralelos se benefician de la memoria caché compartida en situaciones en las queambos procesadores intentan acceder a la misma línea de la memoria compartida; en dichassituaciones sólo uno de los procesadores debe acceder a la caché y la competencia entre losprocesadores es evitada. De este modo se crea el efecto “búsqueda compartida”. Además lafalta de afinidad con el procesador provoca menos daño con una caché L2 compartida. Así, enprogramas paralelos no está realmente claro que la compartición de caché L2 sea tan dañinacomo 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 núcleo requerida. En el peorde los casos el aumento es 1.2 veces la velocidad del procesador. De todas maneras también sehan observado picos de aumento de hasta 2.1 veces la velocidad del procesador, lo cual sugiereque el cómputo intensivo de código con el modelo SPMD saca provecho del efecto “búsquedacompartida”.

Configuración del Bus

Lo primero que hay que decir es que la mayoría de los sistemas modernos conectan losprocesadores (en turnos) a uno o más buses PCI que hacen de puente hacia uno o más busesISA/EISA. Estos puentes añaden latencia, y además 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 vídeo y otros componentes de altorendimiento deben ser conectados al bus PCI.

Aunque un sistema MPS puede alcanzar una buena velocidad en la ejecución de muchosprogramas paralelos de cómputo intensivo (incluso si sólo hay un bus PCI de tiempo com-partido), las operaciones de E/S no se ejecutan mejor que en los sistemas uniprocesador... dehecho irán 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 emplearun sistema MPS con múltiples buses PCI independientes y controladoras E/S (por ejemplo,múltiples controladoras SCSI). Antes que nada necesitaremos estar seguros de que SMP Lin-


ux soporta el sistema que se desea emplear. Además debemos tener en cuenta que actualmenteLinux permite sólo un procesador en el núcleo al mismo tiempo, de manera que elegiremosaquellas controladoras E/S que minimicen el tiempo requerido en el núcleo para realizar cadaoperación 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... estono es tan difícil como parece, y tampoco debería comprometer la seguridad.

Es importante hacer notar que la relación entre la velocidad del bus y la frecuencia de relojdel procesador se ha vuelto más difusa durante los últimos años. Actualmente no es extrañoencontrar sistemas con mayor frecuencia de reloj en el procesador y a la vez menor frecuenciaen el bus, en comparación con otros sistemas. El ejemplo clásico de ésto es el Pentium 133,el cual usa generalmente un bus más rápido que el Pentium 150, debido a la búsqueda de unmayor rendimiento en varios bancos de prueba. Estos efectos se amplifican en los sistemasSMP. De todos modos, en la mayoría de los casos es más importante tener un bus rápido.

1.5.2. Multicomputadores

Un sistema multicomputador es aquel que está formado por un conjunto de sistemas rel-ativamente autónomos, en los que cada CPU dispone de su propia memoria principal y suscanales de E/S.

En este tipo de sistemas, cada procesador tiene su propio espacio de memoria privado, queno resulta visible para los otros procesadores. Según ésto los resultados y la información decoordinación debe pasarse entre los nodos a través de una red de interconexión, usualmente enforma 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 modolos multicomputadores poseen una mayor escalabilidad. Se define como escalabilidad de unsistema a su capacidad para responder a cargas de trabajo crecientes. En un sistema de proce-samiento paralelo, se mide mediante el número de máquinas que pueden conectarse al sistemasin que el rendimiento del sistema caiga. El objetivo es desarrollar una organización escalableque pueda dar cabida a un amplio rango de número de procesadores.

Puesto que los procesadores en un multicomputador deben comunicarse mediante el in-tercambio de mensajes, un elemento clave en el diseño es la red de interconexión, que deberealizarse para operar lo más eficientemente posible. En general existe un compromiso entrela distancia máxima entre dos nodos y el número de conexiones físicas que se desea en cadanodo. Se han explorado varias tecnologías de interconexión para proporcionar escalabilidad yhacer posible un comportamiento eficiente. A continuación describiremos las topologías másextendidas:� Anillo: Si la comunicación es bidireccional a lo largo del anillo, entonces la distancia

máxima entre dos nodos cualesquiera para un anillo de � nodos es �'$)( . Usualmentese utilizan paquetes de mensajes de tamaño fijo que contienen la dirección del destinodeseado. Esta topología es apropiada para un número relativamente pequeño de proce-sadores con una comunicación de datos mínima. La figura 1.12 ilustra un anillo concuatro nodos.


Figura 1.12: Topología Anillo

Figura 1.13: Topología Malla� Malla: La forma más simple de una malla es una matriz bidimensional en la que cadanodo se conecta a cuatro vecinos. En una malla simple de �+*�� nodos, la distanciamáxima entre dos nodos es (-,.�0/2143 . Si hay conexiones cíclicas utilizando los nodosde los bordes, la distancia máxima se reduce a (-,.�'$)(53 . La organización en malla esadecuada para ejecutar algoritmos orientados a matrices. La figura 1.13 ilustra una mallade 3*3 nodos.� Árbol: Las redes con topología de árbol se han investigado para ejecutar algoritmos detipo divide-y-vencerás, tales como los de búsqueda y ordenación. La figura 1.14 ilustra

Figura 1.14: Topología Árbol


Figura 1.15: Topología Hipercubo

Número de nodos Malla Hipercubo

16 6 saltos 4 saltos256 30 saltos 8 saltos

1024 62 saltos 10 saltos2048 126 saltos 11 saltos

16384 254 saltos 16 saltos

Cuadro 1.1: Diámetros Topologías Hipercubo y Malla

un árbol binario sencillo.� Hipercubos: Una topología hipercubo utiliza 6 � (87 procesadores distribuidos en unhipercubo de dimensión � . Cada enlace tiene � enlaces bidireccionales a nodos adya-centes. También � representa la distacia máxima entre dos nodos de dicho hipercubo. Enla figura 1.15 mostramos un hipercubo de dimensión 4, con 6 � ( � � 1:9 procesadores.

Desde la perspectiva de la implementación hardware de una topología, la topología hiper-cubo es la más atractiva. En el cuadro 1.1 comparamos la comunicación en el peor caso enlas topologías hipercubo y malla. El hipercubo se escala bien: el diámetro del sistema crecelentamente con el número de nodos, en comparación con la malla.

Recientemente ha surgido un interés creciente por pasar de topologías fijas a topologíasseleccionables por el usuario y controladas por una red de enrutamiento. En lugar de conectartodos los procesadores juntos mediante enlaces directos, se conectan a una red de enrutamien-to rápida que utiliza conmutadores para establecer e interrumpir las conexiones virtuales, deuna forma similar a la conmutación de paquetes. Si los conmutadores se diseñan para queocasionen retardos mínimos en los mensajes, el retardo de comunicación se incrementará lig-eramente al añadir más nodos al sistema. Otra propiedad atractiva es que cada procesadornecesita sólo una conexión bidireccional a la red de conmutadores.


Los sistemas multicomputador pueden dividirse básicamente en dos categorías:� Clusters (o agrupamientos de nodos). Estos sistemas son grupos de nodos que se comu-nican a través de una interfaz de red. Deben tener un buena relación coste/rendimiento,por lo que en principio sólo debemos utilizar para su montaje componentes hardwarerelativamente comunes.� MPPs (“Massively Parallel Processors”, Procesadores Masivamente Paralelos). Estossistemas pueden distinguirse de los anteriores por las propiedades que los hacen Masi-vamente Paralelos:; Utilización de interconexiones de muy alto rendimiento; Capacidad de E/S inmensa; Tolerancia a fallos

Seguramente quedemos sorprendidos al comprobar que estos sistemas no necesitanCPUs de gama alta. La mayoría de los mejores sistemas MPPs tienen miles de CPUs,siendo más importante para el rendimiento del sistema la calidad de las interconexionesy su topología.

1.5.2.1. Clusters o Agrupamientos de Nodos

Una de las posibilidades de mejor relación coste/rendimiento es la proporcionada por losclusters, grupos de nodos conectados a través de una interfaz de red. Dicha organización creaun sistema multicomputador, es decir, un sistema de procesamiento paralelo perteneciente almodelo MIMD con memoria distribuida. Por supuesto su tipología 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 popularidadde esta tecnología.

La utilización de clusters en procesamiento paralelo supone muchas ventajas, como son:� Cada una de las máquinas de un cluster puede ser un sistema completo, que puedeser utilizado para ejecutar una amplia gama de aplicaciones. Ésto lleva a pensar que elprocesamiento paralelo bajo clusters no es más que una manera de aprovechar los “ciclosdesperdiciados” por los usuarios de PCs. Sin embargo no es tan sencillo aprovecharestos ciclos sin ralentizar el trabajo primario para el que se utilizan dichas estaciones detrabajo, pero puede hacerse.� La creciente popularidad de los sistemas en red hace que la mayoría del hardware quenecesitamos para construir un cluster se fabrique a gran escala, con la correspondientebajada de precios como resultado. También reduce el coste del sistema el hecho de quesólo necesitamos una consola (es decir, una tarjeta de vídeo, un monitor y un teclado)para todo el cluster, aunque necesitemos conectar dicha consola a cada máquina al prin-cipio para hacer una instalación inicial; una vez hecha la instalación, un PC bajo Linuxno necesita una consola para funcionar. En comparación, los SMP y los ProcesadoresAuxiliares pertenecen a mercados mucho más restringidos, con lo que suelen tener pre-cios más elevados.


Figura 1.16: Objetivo Procesamiento Paralelo en Clusters� Los clusters pueden llegar a formar sistemas verdaderamente amplios, no teniendo laslimitaciones de escala de los SMP. Mientras que es complicado encontrar sistemas SMPcompatibles con Linux con más de 4 procesadores, podemos construir un cluster dehasta 16 sistemas con casi cualquier hardware de red común. Con no mucho trabajo,cientos e incluso miles de máquinas pueden ser interconectadas. De hecho, Internetentero 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 muchomayor en los clusters cuidadosamente diseñados. Ésto es importante no sólo en aplica-ciones particulares que no toleren interrupciones en el servicio, si no que también ensistemas de uso general que contengan suficientes procesadores como para que seanmuy comunes los fallos aislados. Por ejemplo, incluso cuando la media de fallo de unPC sea de dos años, en un cluster con 32 máquinas la probabilidad de que una falle enlos primeros 6 meses es muy alta.

La conclusión es que los clusters son económicos, que los dispositivos necesarios para con-struirlo están disponibles, y que se pueden construir sistemas verdaderamente amplios; peropor supuesto no todo son ventajas. También existen una serie de problemas:� Excepto muy pocas excepciones, el hardware de red no está diseñado para el proce-

samiento paralelo. Normalmente la latencia es muy alta y la velocidad de transferenciade datos relativamente baja comparada con la proporcionada por los SMPs y los proce-sadores auxiliares. Por ejemplo, la latencia casi nunca supera unos pocos microsegundosen 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 más rápido (Gigabyte Ethernet) ofrece una ve-locidad comparable, la mayoría de las redes comunes son entre 10 y 1000 veces máslentas.El rendimiento del hardware de red puede ser suficiente si es una red aislada para cluster.Si la red no está aislada de otro tráfico, el rendimiento puede ser sustancialmente peor.� Existe poco soporte de software para manejar un cluster como si se tratara de un sólosistema. Por ejemplo, el comando ps nos informa de los procesos que concurren en unsistema Linux, pero no nos informa de todos los procesos que concurren en el cluster desistemas Linux.

Con todo ésto, podemos decir que los clusters ofrecen una gran potencia, pero dicha potenciapuede ser difícil de alcanzar en la mayoría de las aplicaciones. Lo bueno es que existe una grancantidad de software que nos puede ayudar a conseguir un alto rendimiento en programas bienadaptados a este entorno, y que existen redes diseñadas específicamente para ampliar el rangode programas que pueden alcanzar un buen rendimiento.

1.5.2.2. Sistemas Beowulf

Un sistema Beowulf es básicamente un cluster dedicado al procesamiento paralelo. Es unsistema que usualmente consta de un nodo servidor y uno o más nodos clientes conectadosvía Ethernet o algún otro tipo de red. Es un tipo de sistema que se construye empleandohardware común, como por ejemplo PCs bajo Linux, adaptadores Ethernet estándar y hubsconvencionales. No contiene ningún hardware especializado y es trivialmente reproducible.Además Beowulf usa software común como Linux, PVM y MPI.

El nodo servidor controla todo el cluster y ofrece ficheros a los nodos clientes. Tambiénes la consola del cluster y su conexión al exterior. Los sistemas Beowulf más grandes puedentener más de un nodo servidor, y posiblemente otros nodos dedicados a tareas particulares, porejemplo consolas o estaciones de monitorización. En la mayoría de los casos los nodos clientesno tienen dispositivos directos de E/S; son controlados y configurados por el nodo servidor.En una configuración de clientes sin disco, los clientes no conocen su IP ni su nombre hastaque el nodo servidor se lo envía. Una de las principales diferencias entre un Beowulf y unCOW(“Cluster Of Workstations”, Cluster de Estaciones de Trabajo) es que el comportamientode un Beowulf es más parecido al de una única máquina que al de un grupo de estaciones detrabajo. En la mayoría de los casos los clientes no tienen teclado ni monitor, y son accedidossólo a través de login remoto o posiblemente mediante un terminal serie. Podemos pensar enlos nodos de un sistema Beowulf como en paquetes CPU+Memoria que pueden ser agregadosal cluster, de la misma manera que una CPU o un módulo de memoria puede ser agregado auna placa base.

Beowulf no es un paquete especial de software, ni una nueva topología de red, ni la últimamodificación del núcleo de Linux. Beowulf es una manera de crear clusters de PCs bajo Linuxpara formar un supercomputador virtual paralelo. Existen muchos paquetes software comomodificaciones del núcleo de Linux, librerías PVM y MPI, y herramientas de configuraciónque hacen la arquitectura Beowulf más rápida, fácil de configurar y útil. Sin embargo podemosconstruir una máquina de tipo Beowulf usando una distribución estándar Linux sin softwareadicional. Si tenemos dos ordenadores con Linux en red que comparten un sistema de ficheros


‘/home’ vía NFS (“Network File System”, Sistema de Ficheros en Red) y podemos ejecutarshell remoto (rsh) desde una máquina a otra, entonces podemos argumentar que tenemos unsistema Beowulf simple de dos nodos.

Clasificación Sistemas Beowulf

En la práctica los sistemas Beowulf han sido construidos de distintas maneras. Debido ala búsqueda de un mayor rendimiento a veces han sido empleados componentes no comunes,como por ejemplo aquellos que son comercializados por sólo un fabricante. Para tener encuenta los diferentes tipos de sistemas existe la siguiente clasificación.

BEOWULF CLASE I:

Este tipo de máquinas son construidas a base de componentes sacados del mercado común.La definición estricta es que un Beowuf CLASE I debe se ensamblado a partir de componentesque se puedan encontrar en al menos tres catálogos de publicidad nacionales o internacionales.

Las ventajas de los sistemas de CLASE I son:� El hardware está disponible en múltiples fuentes (bajo precio, fácil mantenimiento).� Ausencia de dependencia con respecto a un único fabricante.� Soporte bajo Linux garantizado en sus distribuciones más comunes.� Usualmente basado en estándares (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 máquina que no pueda ser ensambladautilizando únicamente hardware común. Ésto no es un impedimento. De hecho ésto es sólo unaclasificación.

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 distribución a otra.� Existencia de dependencia con respecto a un único fabricante.� Suelen ser sistemas más caros que los de CLASE I.

Una clase no tiene porqué ser necesariamente mejor que la otra. Todo depende de nuestrasnecesidades y nuestro presupuesto. Ésta clasificación sólo pretende que las discusiones sobrelos 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-nologías y la aparición de nuevos productos hacen que cada vez esté más al alcance de todosgenerar procesamiento paralelo a través de un cluster. Sin embargo no existe una tecnologíade red que resuelva todos los problemas de la mejor manera; de hecho, la variedad de posibil-idades, costes y rendimientos es tremenda.

A continuación definiremos las características de algunos de los tipos de red más popu-lares:

ATM� Soporte bajo Linux: controladores del núcleo, librería AAL� Velocidad de Transferencia de Datos: 155 Mb/seg� Latencia: 120 <>=@?�A� Disponibilidad: varios fabricantes� Interfaz: PCI� Estructura de Red: conexión mediante hub dedicado

Al menos en parte podría decirse que la tecnología ATM (“Asynchronous Transfer Mode”,Modo de Transferencia Asíncrona) es el futuro. ATM no tiene un coste elevado y es más rápidaque Fast Ethernet; además puede ser usada a través de las largas distancias que las compañíasde teléfono pueden cubrir. El protocolo de red ATM está diseñado para proporcionar una in-terfaz software con poca sobrecarga y un manejo más eficiente de los mensajes pequeños y delas comunicaciones en tiempo real (p.ej. vídeo y audio digital). Además es una de las redescon mayor velocidad de transferencia de datos que Linux soporta actualmente. Lo malo es queno es una tecnología barata y que aún existen algunos problemas de compatibilidad entre losdistintos fabricantes.

Ethernet� Soporte bajo Linux: controladores del núcleo� Velocidad de Transferencia de Datos: 10 Mb/seg� Latencia: 100 <>=@?�A� Disponibilidad: hardware común� Interfaz: PCI� Estructura de Red: hub dedicado o compartido, o bus multipuerto sin hub


Durante algunos años, la Ethernet de 10 Mb/seg ha sido la tecnología estándar de red. Dehecho un gran número de PCs tienen su controladora Ethernet integrada en la placa base. Enredes con poca carga podemos organizar las conexiones Ethernet como un bus multipuertosin hub; esta configuración puede servirnos para conectar hasta 200 ordenadores con un costemínimo, pero no es apropiado para procesamiento paralelo. Añadir un hub compartido no va amejorar el rendimiento en realidad. Sin embargo los hubs dedicados proporcionan la máximavelocidad de transferencia de datos a conexiones simultáneas y no tienen un alto coste porordenador. Linux soporta un amplio rango de interfaces Ethernet, pero es importante recordarque las variaciones en el hardware de la interfaz pueden suponer importantes diferencias en elrendimiento.

Fast Ethernet� Soporte bajo Linux: controladores del núcleo� Velocidad de Transferencia de Datos: 100 Mb/seg� Latencia: 80 <>=&?BA� Disponibilidad: hardware común� Interfaz: PCI� Estructura de Red: hub dedicado o compartido

Aunque existen varias tecnologías que se llaman a sí mismas “Fast Ethernet” este término seusa 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 podíamos esperar esta tecnología posee un enorme mercado, con lo cual su relaciónprestaciones/precio es bastante mejor que en otras configuraciones. Sin embargo la trampaestá en que al dividir el ancho de banda de un único bus de 100 Mb/seg entre un grupo deordenadores mediante un hub compartido, el rendimiento puede quedar por debajo del queobtendríamos al utilizar una Ethernet de 10 Mb/seg con un hub dedicado, la cual proporcionaa cada ordenador una conexión completa de 10 Mb/seg. Los hubs dedicados que proporcionan100 Mb/seg a cada computador simultáneamente son caros, aunque sus precios bajan a diario yproporcionan un rendimiento muy superior al que obtenemos utilizando los hubs compartidos.

Gigabit Ethernet� Soporte bajo Linux: controladores del núcleo� Velocidad de Transferencia de Datos: 1000 Mb/seg� Latencia: 300 <>=&?BA� Disponibilidad: varios fabricantes� Interfaz: PCI� Estructura de Red: hub dedicado o FDRs


En principio Gigabit Ethernet no tiene buenas razones tecnológicas para ser llamada Ethernet.Sin embargo dicho nombre refleja la intención de que en un futuro sea una tecnología baratay destinada a un amplio mercado, con soporte nativo para IP. Sin embargo su precio actualhace que no resulte económica su utilización. Al contrario que en otras tecnologías Ethernet,Gigabit Ethernet ofrece un control a bajo nivel que aporta fiabilidad a dicho tipo de red. LosFDRs (“Full Duplex Repeaters”, Repetidores Full Duplex) multiplexan las líneas utilizandobuffers y control de flujo localizado para mejorar el rendimiento. La mayoría de los hubsdedicados están siendo construidos con nuevos módulos interfaces para que sean compatiblescon los dispositivos Gigabit. Existe un driver bajo Linux para la interfaz Yellowfin G-NIC dePacket Engines (URL [13]). Los primeros test bajo Linux arrojaron un ancho de banda unas2,5 veces superior a la 100 Mb/seg Fast Ethernet; en las redes Gigabit la configuración del busPCI es un factor crítico.

FireWire (IEEE 1394)� Soporte bajo Linux: no� Velocidad de Transferencia de Datos: 394 Mb/seg� Disponibilidad: varios fabricantes� Interfaz: PCI� Estructura de Red: aleatorio sin ciclos (configuración automática)

FireWire (URL [2]), el estándar IEEE 1394-1995, está destinado a ser la red digital de bajocoste y alta velocidad para consumidores en general. Aunque suela promocionarse como lainterfaz a la cual conectar cámaras de vídeo digitales a nuestro ordenador, FireWire está pen-sada para ser utilizada en aplicaciones que van desde ser el sustituto de SCSI hasta conectarlos componentes de reproducción de vídeo y audio. Permite conectar hasta 64k dispositivosutilizando cualquier topología que haga uso de buses y puentes sin ciclos, y automáticamentedetecta los componentes cuando son conectados o desconectados (conexión en caliente). So-porta mensajes cortos con baja latencia así como trasmisiones asíncronas al estilo ATM (usadaspara mantener sincronizados los mensajes multimedia). Adaptec tiene productos FireWire quepermiten la conexión de hasta 63 dispositivos a una tarjeta PCI. Aunque FireWire no será lared de mayor ancho de banda disponible dentro de un tiempo, el mercado de consumo (quepuede abaratar bastante los precios) y el soporte para mensajes con baja latencia hacen de éstauna de las mejores tecnologías para construir clusters de PCs bajo Linux utilizando redes depaso de mensajes, al menos durante los próximos años.

PLIP� Soporte bajo Linux: controladores del núcleo� Velocidad de Transferencia de Datos: 1,2 Mb/seg� Latencia: 1000 <>=@?�A� Disponibilidad: hardware común

36 CAPÍTULO 1. INTRODUCCIÓN� Interfaz: SPP� Estructura de Red: cable entre dos ordenadores

Sólo por el coste de un cable LapLink, PLIP (“Parallel Line Interface Protocol”, Protocolo deInterfaz de Línea Paralela) permite comunicar dos máquinas Linux a través del puerto paraleloestándar utilizando software basado en sockets. En términos de velocidad de transferencia dedatos, latencia y escalabilidad, no es una tecnología de redes seria; sin embargo, su bajísimocoste y alta compatibilidad lo hacen útil. El controlador forma parte de las distribucionesestándar del núcleo de Linux.

SLIP� Soporte bajo Linux: controladores del núcleo� Velocidad de Transferencia de Datos: 0,1 Mb/seg� Latencia: 1000 <>=&?BA� Disponibilidad: hardware común� Interfaz: RS232C� Estructura de Red: cable entre dos ordenadores

Aunque SLIP (“Serial Line Interface Protocol”, Protocolo de Interfaz de Línea Serie) estásituado al final del espectro de rendimiento, SLIP (o CSLIP o PPP) permite establecer comu-nicación mediante sockets entre dos ordenadores a través del puerto serie RS232 ordinario.Los puertos RS232 pueden ser conectados mediante un cable serie “null-modem” RS232 oincluso a través de un módem. En cualquier caso la latencia es alta y la velocidad de transfer-encia de datos baja, de manera que SLIP sólo debe ser usado cuando no exista otra alternativadisponible. Sin embargo es mejor que nada; además la mayoría de los PCs tienen dos puertosRS232, de manera que podemos crear una red conectando un grupo de ordenadores de maneralinear o en topología de anillo. También existe un software de compartición llamado EQL.

USB� Soporte bajo Linux: controladores del núcleo� Velocidad de Transferencia de Datos: 12 Mb/seg� Disponibilidad: hardware común� Interfaz: USB� Estructura de Red: bus


DISTRIBUIDOR DE LA RED

UNIDAD DE CONTROL

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 conexión en caliente (pode-mos “enchufar” cualquier dispositivo USB con el ordenador encendido) y puede manejar si-multáneamente hasta 127 periféricos que van desde teclados hasta cámaras de videoconferen-cia.

En realidad no existe una especificación clara sobre la metodología a seguir para conectarvarios PCs mediante este puerto; sin embargo la importancia del estándar y su comodidadhacen de esta interfaz una alternativa a tener en cuenta. Se puede decir que USB es la versiónbarata 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 instrucción operasimultáneamente sobre múltiples datos. Un procesador matricial está formado por un conjun-to de elementos procesadores (EPs) sincronizados que funcionan bajo la supervisión de unaunidad de control (UC).

Normalmente dicha UC es un procesador escalar que cuenta con su propia memoria paraalmacenar programas y datos. Además, cada EP tendrá también su propia memoria. En lafigura 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 instrucción, son ejecutadas direc-tamente en la unidad de control o bien son transmitidas a los EPs para su ejecución. Las


instrucciones escalares y de control de flujo como saltos, etc. se ejecutan en la UC, mientrasque las instrucciones aritmético-lógicas, las de enrutado de datos y otras operaciones localesson 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 instrucción que ejecutan simultáneamente los EPs es la misma, mientrasque los datos serán los de la memoria de cada EP, y por tanto serán diferentes. Por todo elloun procesador sólo requiere un único programa para controlar todos los EPs.

La idea de utilización de los procesadores matriciales es la de explotar el parlalelismo enlos datos de un problema más que la de paralelizar la secuencia de ejecución de las instruc-ciones. El problema se paraleliza dividiendo los datos en particiones sobre las que se puedenrealizar las mismas operaciones. Un tipo de datos altamente particionable es el formado porvectores y matrices, siendo éste último el tipo de datos hacia el cual están más orientadas estetipo de arquitecturas. Por ello a estos procesadores se les llama matriciales.

Aparte del propio paralelismo obtenido por el cálculo en paralelo sobre los elementos deun vector o matriz, la propia red de interconexión entre los EPs reduce el tiempo de ejecuciónen determinadas tareas. Dicha red se encarga de conectar a los EPs con sus propios vecinos.De esta manera la topología de la red de interconexión determinará qué tipo de cálculos sacanel máximo partido a determinado procesador matricial. Por ejemplo, en el tratamiento de imá-genes, donde muchas operaciones son cálculos entre píxels vecinos, una arquitectura matricialcon una topología adecuada paralelizaría con facilidad dichos cálculos.

Un caso particular de los procesadores matriciales son los Procesadores Asociativos o “As-sociative Processors” cuya principal característica es la utilización de memorias asociativas.

La ejecución de la misma operación sobre distintas informaciones se usa en la simulaciónde condiciones climatológicas, control de tráfico aéreo, operaciones con matrices, etc. Ejem-plos de computadores con esta organización son el ILLIAC IV, PEPE, BSP STARAN y ICL-DAP.

1.5.4. Procesadores Vectoriales

En esencia los procesadores vectoriales son máquinas con unidades funcionales vectorialessegmentadas (en definitiva ALUs segmentadas) diseñadas para optimizar las operaciones conestructuras de tipo vectorial. Este tipo de paralelismo es considerado MISD por la mayoría delos científicos debido a la utilización de ALUs segmentadas. La segmentación hace posible quevarias instrucciones pueden ser ejecutadas simultáneamente sobre un mismo dato (el vector).

Al igual que en los procesadores matriciales el paralelismo viene de que al operar convectores 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. Estopermite que muchas de las operaciones aplicadas a un determinado vector y todas las que sehacen entre elementos de unos vectores con otros puedan realizarse en paralelo, o al menos endistintas 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 unprocesador vectorial diseñado específicamente para operar con vectores. Dicho procesadorvectorial contendrá a su vez varias ALUs, cada una de las cuales opera sobre un vector com-pleto. Además dichas ALUs se encuentran completamente segmentadas y pueden comenzaruna nueva operación cada ciclo de reloj. De esta manera el paralelismo proviene de la repeti-


ción de ALUs y de su segmentación. Sin embargo es la segmentación la que hace que variasinstrucciones puedan ser ejecutadas al mismo tiempo sobre un determinado vector.

Dependiendo del tipo de procesador vectorial cada ALU será totalmente funcional o biense encargará de realizar una función específica, como suma/resta, multiplicación, división, etc.Además debe existir una unidad de Carga/Almacenamiento encargada de leer los vectoresdesde 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 dedatos continuos. Así mientras en los procesadores matriciales sólo 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 procesadorescalar envía un flujo de datos continuo hacia el procesador vectorial, indicándole la operaciónque debe realizar mediante el flujo de instrucciones. En la figura 1.18 mostramos el diseño típi-co de un procesador vectorial con registros.

40C

APÍT

UL

O1.

INT

RO

DU

CC

IÓN

Cauces funcionalesescalares

Datosvectoriales

escalarUnidad de control

vectorialesRegistros

Cauce func. vectorial

Cauce func. vectorial

anfitriónComputador

Procesador escalar

Instrucciones escalares

(Programa y datos)Memoria principal

Instrucciones

Datosescalares

Instrucciones vectoriales

vectorialUnidad de control

Procesador vectorial

Control

masivoAlmacenamiento

E/S Usuario

Figura 1.18: Esquema Procesador Vectorial


Figura 1.19: Cray SX-6

Los procesadores vectoriales, según el método de almacenamiento de los operandos, seclasifican en:� Máquinas vectoriales con registros :

En una máquina de este tipo todas las operaciones vectoriales excepto las de carga y al-macenamiento operan con vectores almacenados en registros. La mayoría de máquinasvectoriales modernas utilizan este tipo de arquitectura. Ejemplos: Cray Research (CRAY-1, CRAY-2, X-MP, Y-MP y C90), supercomputadores japoneses (NEC SX Series, lasFujitsu VP200 y VP400 y la Hitachi S820).� Máquinas vectoriales memoria-memoria :En este tipo de máquinas, todas las operaciones vectoriales son de memoria a memoria.Como la complejidad interna así como el coste son menores, es la primera arquitecturavectorial que se empleó. Ejemplo: el CDC.

Los supercomputadores vectoriales empezaron con modelos monoprocesadores como elCray 1 en 1976. Los supercomputadores vectoriales recientes ofrecen ambos modelos, elmonoprocesador y el multiprocesador. La mayoría de supercomputadores de altas prestacionesmodernos ofrecen multiprocesadores con hardware vectorial como una característica más delos equipos. En el cuadro 1.2 vemos algunos ejemplos de procesadores vectoriales con suscaracterísticas principales.


Computadora Año Ciclo Reloj Ciclo Reloj máx Pico CPU Pico Total(ns) (Mhz) CPUs (Mflop/s) (Mflop/s)

Hitachi S820 1983 4.0 71 1 2000 2000Cray 2 1985 4.1 166 4 488 1952

Cray Y-MP 1988 6.0 166 8 333 2667NEC SX-3 1989 2.9 400 4 5500 22000Cray C90 1991 4.0 240 16 1000 16000

Cray 3 1995 2.0 500 16 2000 32000

Cuadro 1.2: Ejemplos Computadores Vectoriales

Capítulo 2

Herramientas para el Desarrollo deSoftware Paralelo

Una vez resuelto el sistema de intercomunicación física de los equipos, deben abordarselos mecanismos para lograr la coordinación entre los procesadores.

Básicamente existen dos modelos de interacción entre procesadores: paso de mensajes ymemoria compartida. Dichos modelos se pueden utilizar de varias formas. Como en todas lasáreas de la programación, existen varios métodos para alcanzar el objetivo:� Por un lado podemos implementar dichos modelos a bajo nivel, utilizando código máquina,

ensamblador o compiladores de lenguajes no especializados. Dicha alternativa nos per-mite desarrollar un código más adaptado y optimizado para el hardware que vayamos ausar.� Por otro lado podemos emplear utilidades de desarrollo de software paralelo, que sonbásicamente facilidades para la programación a alto nivel de aplicaciones distribuidas(compiladores, librerías, etc.) y herramientas para su ejecución y monitorización. Dichasutilidades de programación permiten al programador generar de manera automática co-municación mediante paso de mensajes y memoria compartida sin que deba preocuparsede los detalles. Las ventajas de emplear dichas utilidades son su facilidad de manejo yla portabilidad de los algoritmos desarrollados.

A continuación estudiaremos las características básicas de los dos modelos de interacciónantes mencionados, para luego centrarnos en las utilidades de desarrollo más populares queexisten en la actualidad.

2.1. Modelos de Interacción entre Procesadores

2.1.1. Paso de Mensajes

El paso de mensajes es un modelo de interacción entre los procesadores que forman unsistema paralelo. A grandes rasgos un mensaje es un conjunto de datos definido mediante soft-ware por un procesador y enviado a través de una red de comunicaciones hacia otro procesador,el cual debe aceptar el mensaje y actuar según su contenido.

43

44 CAPÍTULO 2. HERRAMIENTAS DESARROLLO SOFTWARE PARALELO

MEMORIACPU

MEMORIACPU

MEMORIACPU

MEMORIACPU

MEMORIACPU

Figura 2.1: Modelo Básico 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 alsistema operativo y el número de saltos o puntos de intercomunicación por los que el mensajedebe pasar dependerán de la topología de la máquina en uso. Este sistema puede utilizarse al-canzando un rendimiento óptimo en multicomputadores y en multiprocesadores con memoriadistribuida.

Aunque la sobrecarga en la comunicación (latencia) en cada paso de mensaje puede seralta normalmente hay pocas restricciones sobre la cantidad de información que pueden con-tener dichos mensajes. De este modo si contamos con un ancho de banda amplio el paso demensajes puede ser un método muy efectivo para transmitir grandes bloques de datos de entrelos procesadores.

Sin embargo para minimizar la necesidad de costosas operaciones de paso de mensajes losdatos 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 distribuciónde datos (“data layout”).

Una gran ventaja del paso de mensajes reside en su elevada portabilidad, puesto que porlo general consiste en el protocolo de comunicaciones estándar de la red más las rutinas desincronización y comunicación de procesos, que se ejecutan sobre dicho protocolo. Ademásdicho modelo puede usarse en una red de computadores heterogénea.

2.1.1.1. Comunicación mediante Sockets

En un sistema multitarea como Linux los sockets son la base para la comunicación me-diante paso de mensajes. Un socket es un punto de comunicación que se comunica con otrosocket para enviarle mensajes. Son bidireccionales, los hay de varios tipos y nos permitencomunicarnos 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 hastaque nos lleguen datos. En caso de querer enviar datos lo que hacemos es crear un socket,cumplimentar los datos de la dirección de destino y enviar los datos al otro socket a través delnuestro. Por consiguiente para que dos procesos se comuniquen mediante sockets cada unodebe 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 laextensa Internet. En estas redes los ordenadores se identifican mediante una dirección IP quees propia de cada nodo, o sea, no existen dos nodos con la misma dirección IP en una mismared. De esta manera los sockets pueden ser identificados unívocamente en toda la red. Ello es

2.1. MODELOS DE INTERACCIÓN ENTRE PROCESADORES 45

importante ya que, conociendo todos los datos necesarios, podemos ponernos en contacto concualquier punto de comunicación de cualquier nodo de nuestra red.

Los datos que identifican unívocamente a estos puntos de transmisión son:� La dirección IP del nodo en donde reside el proceso que está usando ese punto de conex-ión.� El número del puerto. El puerto es un número entero sin signo de 16 bits cuyo propósitoes el de permitir que en un ordenador puedan existir 65536 puntos posibles de comu-nicación para cada tipo de socket AF_INET. Esto es suficiente para que no suponga unlímite (en la práctica) para el número de puntos de comunicación diferentes que puedehaber al mismo tiempo en un ordenador.� Y el tipo de socket, dato que no reside en la información de direccionamiento, ya quees algo implícito al socket. Si usamos un socket de un tipo, éste sólo se comunicará consockets del mismo tipo.

Para referirnos a un socket usaremos la dirección de socket. Las direcciones de socket sondiferentes según la familia. Llevan todos un primer parámetro que identifica la familia desocket y luego, según ésta, los datos correspondientes.

En el caso de la familia de sockets para redes IP estos datos son la dirección del ordenadory el número de puerto. Los tipos de sockets de esta familia son dos, que se correspondencon los dos tipos transmisión de datos en una red de paquetes, y son los que definiremos acontinuación.

Datagramas (UDP)

Es el modelo más sencillo y también el menos robusto. Consiste en enviar paquetes dedatos a un destino determinado. Cada paquete que enviamos ha de llevar la dirección de desti-no y es guiado por la red de manera independiente. Estos paquetes con la dirección de destinoincluida se llaman datagramas. Los datagramas tienen una longitud limitada, por lo que losdatos que enviamos no pueden exceder de esa longitud. Además hay ciertos problemas deriva-dos del hecho de que los paquetes transiten por una red, que se agravan cuanto más extensasea ésta:� Pérdida de paquetes. En el nivel de red y en los nodos de enrutamiento se pueden perder

paquetes debido a congestión, problemas en la transmisión, etc.� Orden de los paquetes. En una red de área extensa los paquetes atraviesan varios nodospara llegar a su destino. En estos nodos los algoritmos de enrutamiento no suelen serestáticos. De este modo para llegar al mismo destino un paquete puede seguir diferentesrutas, debido a que en un momento dado un nodo puede decidir encaminar el paquetepor un sitio y luego por otro. Esto obedece sobre todo a causas derivadas del control dela congestión (el congestionamiento de las líneas influye a la hora de determinar por cualde ellas se envía el paquete) y de la robustez del sistema (si un nodo se cae se encaminanlos paquetes por otro sitio). La consecuencia es que dos paquetes que fueron enviadospueden llegar desordenados por haber seguido distintas rutas.


Estos problemas no suceden si las transmisiones se realizan dentro de una red de área local, yaque no es necesario encaminar los paquetes. El protocolo de soporte sobre IP que sigue esteesquema se llama UDP (“User Datagram Protocol”, Protocolo de Datagramas de Usuario) ypor consiguiente hablaremos de UDP/IP.

Comunicaciones Orientadas a Conexión (TCP)

Consiste en realizar una conexión entre las dos partes. Tiene la desventaja de que se pierdetiempo en establecer la conexión, pero después la comunicación es fiable, ordenada y utilizacabeceras más pequeñas.

El protocolo de soporte sobre IP que sigue este esquema se denomina TCP (“Transfer DataProtocol”, Protocolo de Transferencia de Datos); hablaremos de flujos TCP/IP debido a que seestablece un canal por donde los datos fluyen de manera continua y ordenada.

El protocolo TCP es bastante más complejo que UDP e implementa segmentación, locual nos permite pasar datos de gran longitud. Dichos datos serán segmentados en partes máspequeñas, enviados conservando el orden y ensamblados en el destino.

2.1.2. Memoria Compartida

La memoria compartida es otro modelo de interacción entre los procesadores que formanun sistema paralelo. Muchos sistemas con MultiProcesadores Simétricos (SMP) compartenfísicamente una sola memoria entre sus procesadores, de manera que un dato escrito por unprocesador 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 compartidapuede implementarse lógicamente convirtiendo cada referencia a memoria no local en unacomunicación apropiada entre procesadores.

Físicamente la memoria compartida puede tener una velocidad de transferencia de datosamplia y una latencia baja, pero sólo cuando los múltiples procesadores no intentan acceder albus simultáneamente; así, la distribución de datos influye seriamente en el rendimiento, la uti-lización de la caché, etc. de manera que puede resultar complicado determinar qué distribuciónde datos es la mejor para un determinado sistema.

Normalmente la idea esencial de este modelo consiste en identificar las regiones paralela ysecuencial de un programa. La región secuencial se ejecuta en un solo procesador y la paralelaen múltiples procesadores. La región paralela consistirá normalmente en múltiples hilos, cadauno ejecutándose 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 UNIXy, lo que es más importante, tienen acceso compartido a un mismo mapa de memoria.

En muchos programas la identificación de las regiones paralela y secuencial puede ser sen-cillo, pero en otros es necesario indicar al compilador que realice la paralelización automática,lo cual hasta el momento es un método poco refinado y requiere intervención del programadorpara la mejora final del código. Aún así los sistemas de memoria compartida suelen ser mássencillos que los de paso de mensajes, y pueden desarrollarse más rápidamente. En todo casoel rendimiento dependerá del compilador que utilicemos.

Un compilador para memoria compartida deberá generar código para creación de hilos,sincronización y acceso a los datos en memoria compartida. En comparación un compilador

2.1. MODELOS DE INTERACCIÓN ENTRE PROCESADORES 47

Hilo sencillo

Hilo 1

Hilo 2

Hilo 3

Hilo 4

Hilo sencillo

Regiónsecuencial

Regiónsecuencial

Regiónparalela

Figura 2.2: Modelo Básico para Memoria Compartida

para paso de mensajes es considerablemente más simple, pues consistirá sólo en un compiladorbase y las librerías para comunicaciones.

La sincronización es un concepto altamente importante en este tipo de sistemas. La com-partición de recursos globales está llena de riesgos. Por ejemplo, si dos procesos hacen uso almismo 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 crítico.

Así surge el concepto de exclusión mutua. Dos o más procesos no pueden acceder a de-terminados recursos al mismo tiempo. Así, existen varias maneras de conseguir la exclusiónmutua. Por un lado podemos hacerlo a nivel hardware, a través de instrucciones máquina es-peciales o de inhabilitación por interrupciones. También a nivel de sistema operativo, con lautilización de semáforos u otros mecanismos. A nivel de compilador contamos con la ayudade los monitores. Como vemos existen varios mecanismos para conseguir la sincronización delos procesos en este tipo de sistemas.

2.1.2.1. Todo Compartido Vs. Algo Compartido

Hay dos modelos fundamentales usados comúnmente en programación con memoria com-partida: Todo Compartido y Algo Compartido. Ambos modelos permiten la comunicaciónentre procesadores mediante lecturas y escrituras de/en la memoria compartida; la diferenciaconsiste en que el modelo Todo Compartido ubica todos los datos en memoria compartida,mientras que el modelo Algo Compartido requiere que el usuario indique explícitamente quédatos pueden ser compartidos y cuáles son privados para un único procesador.

¿Qué modelo de datos debemos usar? Lógicamente debemos usar el modelo que mejor seadapte a nuestras necesidades, aunque muchas veces ésto es sólo cuestión de gustos. Muchagente prefiere el modelo Todo Compartido porque no hay necesidad de identificar qué datosdeben ser compartidos en el momento de su declaración... simplemente bloqueamos los acce-sos potencialmente conflictivos a objetos compartidos para asegurarnos de que sólo un proce-sador tenga acceso en un momento dado. De nuevo, ésto no es tan simple... por ello muchagente prefiere la relativa seguridad del modelo Algo Compartido.


Modelo Todo Compartido

Lo mejor de este modelo es que fácilmente podemos analizar un programa secuencialexistente 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 losprocesadores.

En principio el principal problema de este modelo es que cualquier acción ejecutada porun procesador podría afectar a otros procesadores. El problema sale a la luz de dos maneras:� Muchas librerías contienen estructuras de datos que simplemente no se pueden compar-

tir. Por ejemplo, una convención UNIX es que la mayoría de las funciones retornan sucódigo de error en una variable llamada errno; si dos procesos bajo el modelo TodoCompartido ejecutan varias llamadas, tendrían conflictos entre ellas porque en realidadcomparten la misma variable errno. Aunque ahora existe una versión de la librería quecorrige ésto, todavía existen otros muchos problemas similares en la mayoría de las li-brerías. Por ejemplo, a menos que sean tomadas precauciones especiales la librería Xno funcionará si las llamadas son hechas por múltiples procesos bajo el modelo TodoCompartido.� Normalmente en cualquier otro modelo de programación el peor caso para un programacon un puntero defectuoso o un error de segmentación es que el proceso que contiene elcódigo erróneo muera. Incluso en este caso el núcleo podría generar un fichero que nosdé una pista de lo sucedido. En procesamiento paralelo bajo el modelo Todo Compartidoes común que los accesos perdidos provoquen el fallecimiento de un proceso distinto alque 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 sólo los datos explícitamente marcados son compartidos. Además resultaobvio que el modelo Todo Compartido sólo funciona si todos los procesos tienen exáctamentela misma imagen de la memoria; de este modo no es posible usar el modelo Todo Compartidocon diferentes imágenes del código (sólo se puede usar SPMD, no MIMD en general).

El soporte más común en programación bajo el modelo Todo Compartido son las libreríasde hilos. Los hilos son esencialmente procesos “poco pesados” que podrían no ser planificadosde la misma manera que los procesos UNIX y, lo que es más importante, pueden tener accesocompartido a un mismo mapa de memoria.

La primera librería que soportó paralelismo en SMP Linux es la ahora algo obsoletabb_threads, una librería muy pequeña que utiliza la llamada clone() para crear nuevos pro-cesos planificados independientemente que comparten un mismo espacio de direcciones. Loscomputadores SMP Linux pueden ejecutar múltiples hilos de este tipo en paralelo, ya que eneste caso cada hilo es en realidad un proceso Linux completo; la desventaja es que no obten-emos la misma planificación optimizada que realizan otras librerías de hilos.

Más recientemente ha sido desarrollada una versión de la librería de hilos POSIX. Estalibrería, LinuxThreads, es claramente la librería preferida para ser usada bajo el modelo TodoCompartido bajo SMP Linux. Dicha librería de hilos POSIX está bien documentada. Ahorael principal problema es que la librería tiene muchos detalles por definir y acabar, de modoque LinuxThreads está todavía en proceso de desarrollo. Además tenemos el problema de

2.2. UTILIDADES DE DESARROLLO 49

que la librería POSIX se ha visto involucrada en el proceso de estandarización, de manera quetenemos que ser cuidadosos para no programar utilizando versiones obsoletas del estándar.

Modelo Algo Compartido

El modelo Algo Compartido en realidad significa “compartir sólo lo necesario”. Esteplanteamiento puede funcionar en MIMD de manera general (no sólo en SPMD) teniendoen cuenta que debemos ubicar los objetos compartidos en la misma posición de memoria paracada uno de los mapas de memoria de cada procesador. Y lo que es más importante, el modeloAlgo Compartido hace más fácil la predicción y puesta a punto del rendimiento, el filtrado deerrores, etc. Los únicos problemas son:� Puede ser difícil saber de antemano qué necesita realmente ser compartido.� La verdadera posición de los objetos en memoria compartida puede ser difícil de estable-

cer, especialmente para los objetos ubicados en una pila. Por ejemplo, puede ser nece-sario ubicar explícitamente objetos compartidos en un segmento de memoria separado,requiriendo de este modo rutinas de ubicación en memoria separada e introduciendopunteros indirectos extra en cada referencia.

Hoy día existen dos mecanismos muy parecidos para permitir a grupos de procesos de Lin-ux tener espacios de memoria independientes, compartiendo sólo un pequeño segmento dememoria. Asumiendo que no hemos excluido el System V IPC en el momento de la con-figuración de nuestro sistema Linux, tendremos un mecanismo muy portable que ha venidoa denominarse System V Shared Memory. La otra alternativa es una utilidad de mapeo dememoria cuya implementación varía ampliamente entre distintos sistemas UNIX: la llamadaal sistema mmap().

2.2. Utilidades de Desarrollo

2.2.1. PVM

PVM (“Parallel Virtual Machine”, Máquina Virtual Paralela) es una librería de paso demensajes libre y portable, generalmente implementada por encima de los sockets. Está clara-mente establecida como el estándar de paso de mensajes para el procesamiento paralelo enclusters.

PVM puede ser utilizado en monoprocesadores, máquinas 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 máquinas con diferentes tipos de procesadores, configura-ciones, o diferentes tipos de red (clusters heterogéneos). Puede incluso tratar un grupo bastanteamplio de máquinas conectadas a Internet como una sóla máquina paralela (una máquina vir-tual paralela, de ahí su nombre).

Lo mejor de todo, PVM es desde hace tiempo una distribución libre (URL [14]), lo queha llevado a muchos lenguajes de programación, librerías de aplicaciones, herramientas deprogramación y depuración de errores, etc. a utilizar PVM como su librería portable de pasode mensajes.


El modelo de funcionamiento de PVM es simple pero muy general, y se acomoda a unaamplia variedad de estructuras de programas de aplicación. La interfaz de programación esmuy sencilla, permitiendo que las estructuras de los programas sencillos sean implementadasde manera intuitiva.

El usuario escribe su aplicación como un conjunto de tareas que cooperan. Dichas tareasacceden a los recursos de PVM a través de una librería de funciones con una interfaz estándar.Estas funciones permiten la inicialización y finalización de las tareas a través de la red, así co-mo la comunicación y la sincronización entre dichas tareas. Las operaciones de comunicaciónutilizan estructuras predefinidas, tanto las encargadas del envío y recepción de datos comoaquellas más complejas (sincronización en barrera, suma global, broadcast, etc.).

Debido a su portabilidad, su disponibilidad y su simple pero completa interfaz de pro-gramación, el sistema PVM ha ganado una amplia aceptación en la comunicad de cálculocientífico de alto rendimiento.

2.2.2. MPI

MPI (“Message Passing Interface”, Interfaz de Paso de Mensajes) es un estándar que definela sintaxis y la semántica de las funciones contenidas en una librería de paso de mensajes,diseñada para ser usada en programas que exploten la existencia de múltiples procesadores.Aunque la interfaz no cambie, puede implementarse tanto en sistemas que utilicen paso demensajes, como sistemas de memoria compartida.

La primera versión de MPI fué desarrollada en 1993-1994 por un grupo de investigadoresal servicio de la industria, el gobierno y el sector académico. Debido al apoyo recibido MPI esrelativamente el nuevo estándar para la programación de procesadores paralelos basado en elpaso de mensajes, tomando el testigo de PVM.

Sin embargo existen frecuentes dudas y discusiones por parte de los usuarios acerca de cuáles el estándar a utilizar. Así pues haremos un resumen de las diferencias más característicasentre los sistemas más utilizados, PVM y MPI:

Entorno de Ejecución:Simplemente PVM tiene uno definido, mientras que MPI no especifica cómo debe serimplementado. Así el inicio de la ejecución de un programa PVM será realizado demanera idéntica en cualquier plataforma, mientras que para MPI depende de la imple-mentación que estemos utilizando.

Soporte para Clusters Heterogéneos:PVM fué desarrollado para aprovechar ciclos de CPU de estaciones de trabajo ociosas,por lo que maneja de manera directa mezclas heterogéneas de máquinas y sistemas op-erativos. En contraste MPI asume que su principal objetivo son los MPPs y los clustersdedicados de estaciones de trabajo casi idénticas. Sin embargo, dependiendo de la im-plementación que utilicemos, tendremos un soporte más o menos adecuado.

Amplitud del Campo de Estudio:PVM evidencia una unidad de propósito que MPI no tiene. Como veremos en el capítulo3 la especificación MPI-1 centra su atención en el modelo de paso de mensajes, al igualque PVM. Sin embargo la especificación MPI-2 incluye muchas características que van


SO

MPI

SO

MPIMPI_Send() MPI_Recv()

Figura 2.3: Esquema Básico Utilización MPI

más allá del modelo de paso de mensajes, como el acceso paralelo a ficheros de E/S o elacceso a memoria remota, entre otros muchos ejemplos.

Diseño de Interfaz de Usuario:MPI fué diseñado después de PVM, y claramente aprendió de él. MPI ofrece una interfazmás clara y eficiente, con manejo de buffers y abstracciones de alto nivel que permitendefinir las estructuras de datos a ser transmitidas por los mensajes.

Importancia del Estándar:El hecho de que MPI sea respaldado por un estándar formal ampliamente apoyado sig-nifica que el uso de MPI es, en muchas instituciones, cuestión de política.

MPI no está concebido para ser una infraestructura software aislada y autosuficiente para serusada en procesamiento distribuido. MPI no necesita planificación de procesos, herramientasde configuración de la plataforma a usar, ni soporte para E/S. Como resultado MPI es imple-mentado normalmente como interfaz de comunicaciones, utilizando las facilidades ofrecidaspor el sistema que vayamos a usar, tal como se indica en la figura 2.3 (comunicación vía sock-ets, operaciones de memoria compartida, etc). Éste escenario es ideal para que los programasPVM sean portados a MPI, de manera que se aproveche el alto rendimiento de comunicaciónque ofrecen algunas compañías en sus arquitecturas.

Dado que éste es el estándar en el que nos basaremos para el desarrollo del presente doc-umento, en el capítulo 3 haremos una descripción más elaborada de sus características.

2.2.3. P4

El sistema p4 es una librería de macros y funciones desarrollada por el Argonne NationalLaboratory 1 destinadas a la programación de una gran variedad de máquinas paralelas. Elsistema p4 soporta tanto el modelo de memoria compartida (basado en monitores) como elmodelo 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 desincronización de procesos en sistemas con memoria compartida. Para el modelo de memoriadistribuida, p4 proporciona operaciones de envío y recepción, y un método de administración

1Desarrollador de la implementación MPICH, apéndice A


de procesos basado en un fichero de configuración que describe la estructura de los grupos yprocesos.

Dicho fichero especifica el nombre del servidor, el fichero que será ejecutado en cadamáquina, el número de procesos que serán iniciados en cada servidor (principalmente parasistemas multiprocesador) e información auxiliar. Un ejemplo de fichero de configuración es:

# start one eslave on each of sun2 and sun3local 0sun2 1 /home/mylogin/pupgms/sr_testsun3 1 /home/mylogin/pupgms/sr_test

Dos cosas son notables en lo que se refiere al mecanismo de administración de los procesosen p4. Primero, existe la noción de procesos maestros y procesos esclavos, y pueden formarsejerarquías multinivel para implementar el denominado modelo de cluster de procesamiento.Segundo, el principal modo de creación de procesos es estático, a través del fichero de con-figuración; la creación dinámica de procesos es posible sólo mediante procesos creados es-táticamente que deben invocar una función p4 que expande un nuevo proceso en la máquinalocal. A pesar de estas restricciones una gran variedad de paradigmas de aplicación pueden serimplementados en el sistema p4 de una manera bastante sencilla.

El paso de mensajes es conseguido en el sistema p4 a través del uso de primitivas sendy receive tradicionales, con casi los mismos parámetros que los demás sistemas de paso demensajes. Algunas variantes han sido proporcionadas por cuestiones semánticas, como el in-tercambio heterogéneo y las transferencias bloqueantes o no bloqueantes. Sin embargo unaproporción significativa de la administración del buffer y su carga se le deja al usuario. Apartedel paso de mensajes básico, p4 ofrece también una variedad de operaciones globales incluyen-do broadcast, máximo y mínimo globales, y sincronización por barrera.

2.2.4. Express

En contraste con lo que sucede con otros sistemas de procesamiento paralelo descritosen esta sección, Express es una colección de herramientas que individualmente dirigen variosaspectos del procesamiento concurrente. Dicho paquete software es desarrollado y comercial-izado por Parasoft Corporation, una compañía creada por algunos miembros del proyecto deprocesamiento concurrente de Caltech.

La filosofía de Express se basa en comenzar con la versión secuencial de un algoritmoy aplicarle un ciclo de desarrollo recomendado, para así llegar a la versión paralela de dichoalgoritmo de manera óptima. Los ciclos de desarrollo típicos comienzan con el uso de la her-ramienta VTOOL, una aplicación gráfica que permite mostrar por pantalla el progreso de losalgoritmos secuenciales dinámicamente. Puede mostrar actualizaciones y referencias a estruc-turas de datos individuales, con la intención de demostrar la estructura de los algoritmos yproporcionar la información necesaria para su paralelización.

En relación con este programa tenemos la herramienta FTOOL, que proporciona un análi-sis en profundidad de los programas. Dicho análisis incluye información acerca del uso devariables, 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 automático que convierte programas se-cuenciales escritos en C o Fortran en sus versiones paralelas o distribuidas, usando los modelosde programación Express.

El núcleo del sistema Express es un conjunto de librerías de comunicación, E/S y gráficosparalelos. Las primitivas de comunicación son parecidas a las encontradas en otros sistemas depaso de mensajes e incluyen una variedad de primitivas para realizar operaciones globales y dedistribución de datos. Las funciones de E/S extendida permiten la E/S paralela. Un conjunto defunciones similar es proporcionado para mostrar gráficos de múltiples procesos concurrentes.Express contiene además la herramienta NDB, un depurador paralelo que utiliza comandosbasados en la popular interfaz dbx.

2.2.5. Linda

Linda es un modelo concurrente de programación fruto de la evolución de un proyecto deinvestigación de la Universidad de Yale. El concepto principal en Linda es el espacio de tuplas,una abstración a través de la cual se comunican los procesos. Este tema central de Linda hasido propuesto como paradigma alternativo a los dos métodos tradicionales de procesamientoparalelo: el basado en memoria compartida, y el basado en paso de mensajes. El espacio detuplas es esencialmente una abstracción de la memoria compartida/distribuida, con una difer-encia importante: los espacios de tuplas son asociativos. También existen otras distincionesmenores. 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 paralenguajes de programación que facilitan la programación paralela. Proporciona una abstrac-ción de la memoria compartida que no requiere la existencia de hardware específico que com-parta memoria físicamente.

El término Linda se refiere a menudo a implementaciones específicas software que sopor-tan el modelo de programación Linda. Este tipo de software establece y mantiene espacios detuplas, siendo utilizado en conjunción con librerías que interpretan y ejecutan primitivas Lin-da. Dependiendo del entorno (mutiprocesadores con memoria compartida, sistemas de pasode mensajes, etc.) el macanismo de espacio de tuplas será implementado utilizando diferentestécnicas 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 losprocesos basándose en su disponibilidad y conveniencia. Este esquema puede ser implemen-tado en múltiples plataformas y es conocido como Sistema Pirhana o Sistema Linda-Pirhana.

Parte II

Guía MPI

55

Capítulo 3

El Estándar MPI

MPI (“Message Passing Interface”, Interfaz de Paso de Mensajes) es un estándar que de-fine la sintaxis y la semántica de las funciones contenidas en una librería de paso de mensajesdiseñada para ser usada en programas que exploten la existencia de múltiples procesadores.Dicha librería puede ser utilizada por una amplia variedad de usuarios para implementar pro-gramas que utilicen paso de mensajes.

Desde la finalización de su primera versión en Junio de 1994, MPI ha sido ampliamenteaceptado y usado. Existen implementaciones muy estables y eficientes, incluyendo algunas dedominio público. Además dichas implementaciones están disponibles para un amplia variedadde máquinas. Gracias a ello MPI ha alcanzado uno de sus principales objetivos: darle credibil-idad al procesamiento paralelo. Ahora las companías y los investigadores tienen una manerasencilla y segura para desarrollar programas paralelos portables de paso de mensajes.

3.1. Origen

El paso de mensajes es un paradigma de programación ampliamente utilizado en computa-dores paralelos, especialmente en aquellas con memoria distribuida. Aunque existen muchasvariantes, el concepto básico de procesos comunicándose mediante mensajes está muy consol-idado.

Durante los años anteriores a la aparición del estándar MPI se percibía un progreso sustan-cial en proyectar aplicaciones importantes en este paradigma. De hecho, cada compañía habíaimplementado ya su propia variante. Más recientemente algunos sistemas de dominio públicohabían demostrado que el paso de mensajes podía implementarse eficientemente de maneraportable.

Figura 3.1: Logo MPI

57

58 CAPÍTULO 3. EL ESTÁNDAR MPI

Por todo ello comprendemos que éste era el momento apropiado para definir tanto la sin-taxis como la semántica de una librería estándar de funciones que fuera útil a una ampliavariedad de usuarios y que pudiera implementarse eficientemente en una amplia gama de com-putadores. Y de esa idea nació el estándar MPI.

Los diseñadores de MPI pretendieron incorporar la mayoría de las características másatractivas de los sistemas existentes de paso de mensajes, antes que seleccionar uno de ellosy adoptarlo como el estándar. Así, en su origen MPI estuvo muy influenciado por el trabajodel Centro de Investigación T.J.Watson de IBM, el sistema NX/2 de Intel, Express, Vertex denCUBE y PARMACS. Otras contribuciones importantes fueron las realizadas por Zipcode,Chimp, PVM, Chameleon y PICL. Los diseñadores de MPI identificaron algunos defectoscríticos de los sistemas de paso de mensajes existentes en áreas como la composición de datoscomplejos, la modularidad y las comunicaciones seguras. Ésto permitió la introducción denuevas características en MPI.

3.2. Historia

El esfuerzo de estandarización de MPI involucró a unas 60 personas procedentes de 40organizaciones, principalmente de EEUU y Europa. La mayoría de las principales compañíasde computadores paralelos del momento estuvieron involucradas en MPI, así como investi-gadores provenientes de universidades, laboratorios de gobierno y la industria. El proceso deestandarización comenzó con el Seminario sobre Estándares de Paso de Mensajes en Entornosde Memoria Distribuida, patrocinado por el Centro de Investigaciones sobre Procesamien-to Paralelo, mantenido durante los días 29-30 de Abril de 1992 en Williansburg, Virginia(EEUU). En este seminario se discutieron las características esenciales que debía tener unainterfaz estándar de paso de mensajes y se estableció un grupo de trabajo para continuar conel proceso de estandarización.

Un borrador preliminar, conocido como MPI1, fué propuesto por Dongarra, Hempel, Heyy Walker en Noviembre de 1992 y una versión revisada fué completada en Febrero de 1993.MPI1 abarcaba las características principales que fueron identificadas en el seminario deWilliansburg como necesarias en un estándar de paso de mensajes. Dado que fué generadopara promover la discusión, este primer borrador se centró principalmente en las comuni-caciones punto-a-punto. Aunque tocaba muchos asuntos referentes a la estandarización, noincluía operaciones colectivas ni tenía en cuenta la utilización de hilos.

En Noviembre de 1992 una reunión del grupo de trabajo de MPI tuvo lugar en Minneapo-lis, en la cual se decidió hacer el proceso de estandarización de una manera más formal, adop-tando la organización y los procedimientos del “High Performance Fortran Forum” (Foro For-tran de Alto Rendimiento). Fueron formados subcomités para cada una de las principales áreasque componen el estándar, y se estableció un foro de discusión vía e-mail para cada una deellas. De esta manera quedó conformado el Foro MPI (URL [8]), a cuyo cargo quedaría elproceso de estandarización de MPI.

En dicha reunión se propuso el objetivo de presentar un borrador del estándar MPI enel otoño de 1993. Para conseguirlo el Foro MPI mantuvo reuniones cada 6 semanas durantelos primeros 9 meses de 1993, presentando el borrador del estándar MPI en la conferenciaSupercomputing ’93 en Noviembre de 1993. Después de un período de comentarios públicos,

3.3. OBJETIVOS 59

que resultaron en algunos cambios en MPI, la versión 1.0 de MPI fué presentada en Junio de1994.

A principios de Marzo de 1995 el Foro MPI empezó a reunirse de nuevo para considerarcorrecciones y extensiones al documento original del estándar MPI. El primer producto frutode estas deliberaciones fué la versión 1.1 de MPI, presentada en Junio de 1995.

En Julio de 1997 aparecen al mismo tiempo la versión 1.2 de MPI y la especificación MPI-2. La versión 1.2 de MPI contiene correcciones y clarificaciones referentes a la versión 1.1.Sin embargo MPI-2 añade nuevos elementos al estándar MPI-1, definiendo la versión 2.0 deMPI.

Todavía hoy continúan las discusiones acerca de las áreas hacia las cuales podría ser útilexpandir el estándar MPI; sin embargo en muchas de ellas es necesario obtener más expe-riencia y realizar más discusiones. De todo ello se encarga un documento separado, el MPI“Journal Of Development” (Periódico de Desarrollo), que no forma parte de la especificaciónMPI-2. Y por supuesto el Foro MPI sigue abierto a las aportaciones que puedan realizar losusuarios del estándar, con el objetivo de mantenerlo y desarrollarlo.

3.3. Objetivos

La finalidad de MPI, de manera concisa, es desarrollar un estándar para escribir programasde paso de mensajes que sea ampliamente utilizado. Para ello la interfaz debe establecer unestándar práctico, portable, eficiente, escalable, formal y flexible.

Objetivos Principales

Portabilidad

El principal objetivo de MPI, como ocurre en la mayoría de los estándares, es conseguirun alto grado de portabilidad entre diferentes máquinas. Esta portabilidad sería parecida ala que se consigue con lenguajes de programación como Fortran. De esta manera el mismocódigo fuente de paso de mensajes debería poder ser ejecutado en una variedad de máquinastan grande como la soportada por las distintas implementaciones de MPI, aunque pueda sernecesaria una puesta a punto para obtener la máxima ventaja de las características de cadasistema. A pesar de que el paso de mensajes muchas veces es considerado algo propio de lossistemas paralelos de memoria distribuida, el mismo código podría ser ejecutado en un sistemaparalelo de memoria compartida. Puede ejecutarse en clusters o incluso en un conjunto de pro-cesos ejecutándose en una misma máquina. El hecho de saber que existen implementacionesde MPI eficientes para una amplia variedad de sistemas nos da cierto grado de flexibilidad enel desarrollo del código, la búsqueda de errores y la elección de la plataforma que finalmenteutilizaremos.

Heterogeneidad

Otro tipo de compatibilidad ofrecido por MPI es su capacidad para ejecutarse en sistemasheterogéneos de manera transparente. Así pues, una implementación MPI debe ser capaz deextender una colección 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 código estáenviando mensajes entre procesadores de la misma o distinta arquitectura. La implementaciónMPI hará automáticamente cualquier conversión que sea necesaria y utilizará el protocolode comunicación adecuado. Sin embargo MPI no prohibe implementaciones destinadas a unúnico y homogéneo sistema, así como tampoco ordena que distintas implementaciones MPIdeban tener la capacidad de interoperar. En definitiva, los usuarios que quieran ejecutar susprogramas en sistemas heterogéneos deberán utilizar implementaciones MPI diseñadas parasoportar heterogeneidad.

Rendimiento

La portabilidad es un factor importante, pero el estándar no conseguiría una amplia uti-lización si se consiguiera dicha portabilidad a expensas del rendimiento. Por ejemplo, ellenguaje Fortran es comúnmente usado por encima de los lenguajes ensambladores porquelos compiladores casi siempre ofrecen un rendimiento aceptable comparado con la alternativano portable que representa el lenguaje ensamblador. Un punto crucial es que MPI fué cuida-dosamente diseñado de manera que permite implementaciones eficientes. Las elecciones en eldiseño parecen haber sido hechas correctamente, dado que las implementaciones MPI están al-canzando un alto rendimiento en una amplia variedad de plataformas; de hecho el rendimientoalcanzado en dichas implementaciones es comparable al de los sistemas presentados por lascompañías, los cuales están diseñados para arquitecturas específicas y tienen menor capacidadde portabilidad.

Un objetivo importante de diseño en MPI fué el de permitir implementaciones eficientespara máquinas de diferentes características. Por ejemplo, MPI evita cuidadosamente especi-ficar la manera en que las operaciones tienen lugar. Sólo especifica qué hace una operaciónlógicamente. Como resultado MPI puede ser fácilmente implementado en sistemas que tienenbuffer 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-municación de varias máquinas a través de sus características específicas. En máquinas concoprocesadores de comunicación inteligentes podemos cargar sobre dichos coprocesadores lamayoría del procesamiento relativo al protocolo de paso de mensajes. En otros sistemas lamayoría del código de comunicación 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 práctico ésto significa que los detallesde su representación interna dependen de la implementación MPI particular, y como conse-cuencia el usuario no puede acceder directamente a ellos. En vez de ello el usuario accede a unmanejador que referencia al objeto opaco, de manera que dichos objetos opacos son manipu-lados por funciones MPI especiales. De esta manera cada implementación es libre de hacer lomejor en determinadas circunstancias.

Otra elección de diseño importante para la eficiencia es la manera de evitar el trabajo in-necesario. MPI ha sido cuidadosamente diseñado de modo que no sea necesaria demasiadainformación extra con cada mensaje, ni complejas codificaciones o decodificaciones sobre lascabeceras de dichos mensajes. MPI también evita computaciones extra o tests en funcionescríticas que degraden el rendimiento. Otra manera de minimizar el trabajo es reducir la repeti-ción de computaciones previas. MPI proporciona esta capacidad a través de construcciones

3.3. OBJETIVOS 61

como peticiones de comunicación persistente o los atributos de los comunicadores. El diseñode MPI evita la necesidad de operaciones extra de copia o almacenamiento sobre los datos: enla mayoría 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 diseñado para reducir la sobrecarga en la comunicación producida por elprocesamiento, utilizando agentes de comunicación inteligentes y ocultando latencias en lacomunicación. Ésto se ha logrado usando llamadas no bloqueantes, que separan el inicio de lacomunicación de su final.

Escalabilidad

La escalabilidad es otro objetivo importante del procesamiento paralelo. La escalabilidadde un sistema es su capacidad para responder a cargas de trabajo crecientes. De este modo losprogramas MPI deben mantener su nivel de rendimiento aunque incrementemos el número deprocesos a ejecutar.

MPI permite o soporta la escalabilidad a través de algunas de sus características de diseño.Por ejemplo, una aplicación puede crear subgrupos de procesos que, en turnos, puedan ejecutaroperaciones de comunicación colectiva para limitar el número de procesos involucrados.

Formalidad

MPI, como todos los buenos estándares, es valioso debido a que define el comportamientode las implementaciones de manera concisa. Esta característica libera al programador de tenerque preocuparse de aquellos problemas que puedan aparecer. Un ejemplo de ello es la garantíade seguridad en la transmisión de mensajes que ofrece MPI. Gracias a esta característica elusuario no necesita comprobar si los mensajes son recibidos correctamente.

Resumen de Objetivos� Diseñar una interfaz para la programación de aplicaciones.� La interfaz debe ser diseñada para que pueda ser implementada en la mayoría de lasplataformas, sin necesidad de cambios importantes en la comunicación o el software delsistema.� Permitir implementaciones que puedan ser utilizadas en entornos heterogéneos.� Permitir una comunicación eficiente.� Asumir una interfaz de comunicación fiable: el usuario no debe preocuparse por losfallos en la comunicación.� La semántica de la interfaz debe ser independiente del lenguaje.� La interfaz debe permitir la utilización de hilos.� Proporcionar extensiones que añadan más flexibilidad.


3.4. Usuarios

El estándar MPI está pensado para ser utilizado por todo aquel que pretenda desarrollarprogramas de paso de mensajes codificados en Fortran 77 y C. Ésto incluye programadoresde aplicaciones individuales, desarrolladores de software para máquinas paralelas y creadoresde entornos y herramientas. Para que esta amplia audiencia lo considere atractivo, el estándardebe proporcionar al usuario básico una interfaz simple y fácil de manejar, que no impida eluso de las operaciones de alto rendimiento disponibles en máquinas 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 podrían ser ejecutados en multicomputadores,multiprocesadores o combinaciones de ambos. Además es posible realizar implementacionesbasadas en memoria compartida. El paradigma no queda obsoleto al combinar arquitecturas dememoria distribuida con arquitecturas de memoria compartida, o al incrementar la velocidadde la red. Debe ser a la vez posible y útil implementar dicho estándar en una gran variedad demáquinas, incluyendo dichas “máquinas” que se componen de colecciones de otras máquinas,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 explícito para la ejecución de hilos la interfaz ha sido diseñada de maneraque no perjudique su uso.

MPI proporciona muchas características encaminadas a mejorar el rendimiento en com-putadores paralelos con hardware de comunicación especializado entre procesadores. De estemodo es posible realizar implementaciones nativas MPI de alto rendimiento para este tipo demáquinas. Al mismo tiempo existen implementaciones MPI que utilizan los protocolos están-dares de comunicación entre procesadores de Unix, las cuales proporcionan portabilidad a losclusters y redes heterogéneas.

3.6. Versiones

El estándar MPI se divide básicamente en dos especificaciones, MPI-1 y MPI-2. La sigu-iente clasificación muestra el nivel de compatibilidad con MPI que posee una implementacióndada:� Mantener compatibilidad con la especificación MPI-1 significa ser compatible con la

versión 1.2 de MPI.� Mantener compatibilidad con la especificación MPI-2 significa proporcionar toda la fun-cionalidad definida por la especificación MPI-2.

En todo caso la compatibilidad hacia atrás está preservada. De esta manera un programa MPI-1.1 válido será un programa MPI-1.2 válido y un programa MPI-2 válido; un programa MPI-1.2 válido será un programa MPI-2 válido.

3.6. VERSIONES 63

3.6.1. MPI-1

Las versiones 1.0, 1.1 y 1.2 del estándar MPI se engloban en la especificación MPI-1.Dicha especificación centra su atención en el modelo de paso de mensajes. A continuaciónmostramos una lista con los elementos contenidos en dicha especificación, y aquellos quequedan fuera de ella.

Elementos Incluidos� Comunicaciones punto a punto� Operaciones colectivas� Grupos de procesos� Contextos de comunicación� Topologías de procesos� Administración del entorno� Enlaces con Fortran 77 y C� Interfaz para la creación de perfiles de ejecución

Elementos No Incluidos� Operaciones de memoria compartida� Operaciones ya soportadas por el sistema operativo de manera estandarizada durante laadopción de MPI; por ejemplo, manejadores de interrupción o ejecución remota� Herramientas para la construcción de programas� Facilidades para la depuración de errores� Soporte específico para hilos� Soporte para planificación y creación de procesos� Funciones de E/S paralela

Como vemos MPI-1 está diseñado para aprovechar todas las facilidades ofrecidas por el sis-tema que vayamos a usar, tanto aquellas pertenecientes al sistema de comunicación (opera-ciones de memoria compartida, comunicación vía sockets, etc.) como las relativas al entornode programación (herramientas para la construcción de programas, facilidades para la depu-ración de errores, etc). Como resultado MPI es implementado normalmente como interfaz decomunicaciones, utilizando dichas facilidades ofrecidas por el sistema.

Existen muchas características 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 enacabar la especificación; el sentimiento de no tener suficiente experiencia en algunos de los


campos; y la preocupación de que el añadir más características podría retrasar la apariciónde implementaciones. De todas maneras las características no incluidas siempre pueden serañadidas como extensiones en implementaciones específicas, como es el caso de la extensiónMPE dentro de la implementación MPICH (sección A.7).

3.6.2. MPI-2

La especificación MPI-2 es básicamente una extensión a MPI-1 que añade nuevos elemen-tos al estándar. La versión 2.0 de MPI pertenece a la especificación MPI-2. Entre las nuevasfuncionalidades que se añaden destacan las siguientes:� Administración y Creación de Procesos� Comunicaciones Unilaterales� E/S Paralela� Operaciones Colectivas Extendidas� Enlaces con Fortran 90 y C++

La razón por la cual se creó la especificación MPI-2 fué la demanda por parte de los usuariosy desarrolladores de nuevas características en el estándar. De todos modos MPI-2 sólo añadenuevos elementos a MPI-1, pero no lo modifica.

3.7. Implementaciones

Desde que se completó la primera versión del estándar en 1994 un gran número de imple-mentaciones MPI han sido puestas a disposición de los usuarios. Esto incluye tanto algunasimplementaciones portables e independientes como aquellas que han sido desarrolladas y op-timizadas por las principales compañías de computadores paralelos. La alta calidad de dichasimplementaciones ha sido un punto clave en el éxito de MPI.

A continuación destacamos las tres implementaciones de dominio público más importantesque pueden ser utilizadas en clusters de sistemas Linux:� MPICH (URL [9]) es sin duda la implementación más importante de MPI. Muchas im-

plementaciones comerciales desarrolladas por las grandes compañías de computadoresparalelos se basan en ella. La primera versión de MPICH fué escrita durante el procesode estandarización de MPI, siendo finalmente presentada al mismo tiempo que la versión1.0 de MPI. De hecho las experiencias de los autores de MPICH se convirtieron en unagran ayuda para el Foro MPI en el proceso de desarrollo del estándar. Su portabilidad esenorme y su rendimiento elevado. Posee compatibilidad total con MPI-1 e implemen-ta muchos elementos de MPI-2. En el apéndice A se analizan de manera detenida suscaracterísticas y se informa sobre su instalación, configuración y manejo.� LAM (URL [6]) fué desarrollada originalmente en el Centro de Supercómputo de Ohioantes de que el estándar MPI fuera presentado. Cuando MPI apareció, LAM adoptó

3.7. IMPLEMENTACIONES 65

el estándar. LAM no sólo consiste en la librería MPI, si no que además contiene her-ramientas de depuración y monitorización. Ha sido optimizada para funcionar con clus-ters heterogéneos de sistemas Unix; sin embargo es muy portable, siendo utilizada enuna amplia variedad de plataformas Unix, desde estaciones de trabajo a supercomputa-dores. LAM posee compatibilidad total con MPI-1 e implementa muchos elementos deMPI-2.� CHIMP (URL [1]) fué desarrollada en el Centro de Cómputo Paralelo de Edimburgo.Como LAM, CHIMP comenzó como una infraestructura independiente de paso de men-sajes que luego evolucionó hacia una implementación MPI. CHIMP es conocida princi-palmente por haber sido utilizada como versión optimizada de MPI para los CRAY T3Dy 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.

Capítulo 4

Conceptos Básicos

Todos los programas MPI comparten una serie de características. La inicialización y final-ización del entorno de ejecución se llevan a cabo mediante funciones que explicaremos en estecapítulo. También analizaremos los métodos para identificar los procesos en ejecución.

Por otro lado estudiaremos funciones para informarnos de dónde está ubicado cada procesoy el momento temporal en que nos encontramos, y explicaremos el problema de la E/S enprocesadores paralelos. Para ejemplificar todo ésto implementaremos un sencillo programaque envía un mensaje de saludo e indica el número de procesos en ejecución.

4.1. Algoritmo ¡Hola Mundo!

Basándonos en el primer programa que muchos de nosotros vimos en C expondremos unavariante que hará uso de múltiples procesos.

En MPI los procesos implicados en la ejecución de un programa paralelo se identificanpor una secuencia de enteros no negativos. Si hay C procesos ejecutando un programa, éstostendrán los identificadores DFE:1)EBGBGBG@EHC�/I1 . El siguiente programa hace que el proceso 0 (encar-gado de la E/S, sección 4.4) imprima un mensaje de saludo e informe del número de procesosen ejecución, así como del tiempo empleado en el procesamiento.

Los detalles sobre la compilación y ejecución de este programa dependen del sistema queestemos usando. De este modo debemos conocer cómo compilar y ejecutar programas par-alelos que usen MPI. En la sección A.5 explicamos cómo compilarlo bajo la implementaciónMPICH, y en la sección A.6 se habla sobre la ejecución de programas MPI.

Cuando el programa es compilado y ejecutado con dos procesos, la salida debería ser dela siguiente manera:

Proceso 0 en linux.local Encargado de la E/S¡Hola Mundo!Numero Procesos: 2Tiempo Procesamiento: 0.000065

Si lo ejecutamos con cuatro procesos la salida sería:

Proceso 0 en linux.local Encargado de la E/S

67

68 CAPÍTULO 4. CONCEPTOS BÁSICOS

¡Hola Mundo!Numero Procesos: 4Tiempo Procesamiento: 0.034216

Aunque los detalles de qué ocurre cuando el programa es ejecutado varían de una máquina aotra, lo esencial es lo mismo en todos los sistemas, a condición de que ejecutemos un procesoen cada procesador.

1. El usuario manda una directiva al sistema operativo que crea una copia del programaejecutable en cada procesador.

2. Cada procesador comienza la ejecución de su copia del ejecutable.

3. Diferentes procesos pueden ejecutar diferentes instrucciones bifurcando el programa através de condicionantes. Dichos condicionantes suelen basarse, como veremos, en elidentificador 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 función necesarios paracompilar los programas MPI.

Antes de que podamos llamar a cualquier otra función MPI debemos hacer una llamada aMPI_Init(); esta función sólo debe ser llamada una vez. Sus argumentos son punteros a losparámetros de la función main(), argc y argv. Dicha función permite al sistema hacer todasla configuraciones necesarias para que la librería MPI pueda ser usada. Después de que el pro-grama haya acabado de utilizar la librería MPI debemos hacer una llamada a MPI_Finalize().Esta función limpia todos los trabajos no finalizados dejados por MPI (por ejemplo, envíospendientes que no hayan sido completados, etc.). Así, un programa MPI típico tiene la sigu-iente composición:

...#include “mpi.h”...main(int argc, char** argv){

.../*Ninguna llamada a función MPI anterior a esta*/MPI_Init(&argc, &argv);...MPI_Finalize();/*Ninguna llamada a función MPI posterior a esta*/...

}/*main*/

4.3. INFORMÁNDONOS DEL RESTO DEL MUNDO 69

4.3. Informándonos del Resto del Mundo

MPI ofrece la función MPI_Comm_rank(), la cual retorna el identificador de un procesoen 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 colección deprocesos que pueden enviarse mensajes entre sí. Normalmente para diseñar programas básicosel único comunicador que necesitaremos será MPI_COMM_WORLD. Está predefinido enMPI y consiste en todos los procesos que se ejecutan cuando el programa comienza.

Muchas de las construcciones que empleamos en nuestros programas dependen tambiéndel número de procesos que se ejecutan. MPI ofrece la función MPI_Comm_size() para de-terminar dicho número de procesos. Su primer argumento es el comunicador. En el segundoargumento retorna el número 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 estándar (laventana del terminal). Prácticamente todos los procesadores paralelos proporcionan este méto-do de E/S. De hecho la mayoría de ellos permiten a todos los procesos tanto leer de la entradaestándar como escribir en la salida estándar. Sin embargo la dificultad aparece cuando variosprocesos están intentando ejecutar operaciones de E/S simultáneamente. Para comprender éstoexpondremos un ejemplo.

Supongamos que diseñamos un programa de manera que cada proceso intente leer losvalores

�, J y K añadiendo la siguiente instrucción:

scanf(“%d%d%d”, &a, &b, &c);

Además 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 sólo? O lo que es peor,¿obtiene el proceso 0 el número 10 y el 20 mientras que el proceso 1 obtiene el 30? Si todos losprocesos obtienen los datos, ¿qué ocurre cuando escribimos un programa en el que queremosque el proceso 0 obtenga el primer valor de entrada, el proceso 1 el segundo, etc.? Y si sóloun proceso obtiene los datos, ¿qué le ocurre a los demás? ¿Es razonable hacer que múltiplesprocesos lean de una sola terminal?

Por otra parte, ¿qué ocurre si varios procesos intentan escribir datos en la terminal si-multáneamente? ¿Se imprimirán antes los datos del proceso 0, después los del proceso 1,y así sucesivamente? ¿O se imprimirán dichos datos aleatoriamente? ¿O, lo que es peor, se


mostrarán los datos de los distintos procesos todos mezclados (una línea del proceso 0, doscaracteres del proceso 1, 3 caracteres del 0, 2 líneas del 2, etc.)?

Las operaciones estándar de E/S en C no proporcionan soluciones simples a dicho proble-ma; así, la E/S sigue siendo objeto de investigación por parte de la comunidad de procesamien-to paralelo.

Por todo ello asumiremos que el proceso 0 puede al menos escribir en la salida estándar.También asumiremos que puede leer de la entrada estándar. En todos los casos asumiremos quesólo el proceso 0 puede interactuar con la E/S. Ésto podría parecer una debilidad, ya que comomencionamos antes la mayoría de las máquinas paralelas permiten que múltiples procesosinteractuen con la E/S. Sin embargo es un método muy sólido que nos permitirá realizar unmanejo limpio de la E/S en nuestros programas.

4.5. Ubicación de los Procesos

La función MPI_Get_processor_name() nos permite conocer el nombre del procesadordonde está ubicado cada proceso. Ésto puede ser útil para monitorizar nuestros programas enredes heterogéneas. Conocer en qué máquina concreta se está ejecutando un proceso específicopuede ser determinante para explicar su comportamiento, para lo cual podemos ayudarnos conlas herramientas de monitorización (sección 9.1).

La sintaxis de dicha función es la siguiente:

int MPI_Get_processor_name(char* nombre, int* longnombre)

El parámetro nombre es una cadena (vector de caracteres) cuyo tamaño debe ser al menosigual a la constante MPI_MAX_PROCESSOR_NAME. En dicho vector quedará almacena-do el nombre del procesador. El parámetro longnombre es otro parámetro de salida que nosinforma de la longitud de la cadena obtenida.

4.6. Información Temporal

Con el objeto de facilitar el control y la monitorización, MPI nos ofrece funciones en-caminadas a proporcionar información temporal sobre la ejecución de nuestros programas. Lafunción MPI_Wtime() nos informa sobre el tiempo transcurrido en un determinado proceso.

Dicha función no tiene parámetros; su valor de retorno es de tipo double y representa eltiempo transcurrido en segundos desde el comienzo de la ejecución del proceso. Si el atributoMPI_WTIME_IS_GLOBAL está definido y su valor es true (por defecto es así) el valor de-vuelto por la función estará sincronizado con todos los procesos pertenecientes al comunicadorMPI_COMM_WORLD.

Nosotros utilizaremos esta función para ofrecer cierta información al usuario sobre el tiem-po de ejecución de nuestro programa por la salida estándar. Nos permitirá en estos casos difer-enciar entre el tiempo de ejecución de un programa y el tiempo de procesamiento.

Definimos el tiempo de ejecución de un programa como el tiempo que emplea para re-solver un problema en un computador paralelo, desde el momento en que es generado elprimer proceso hasta que acaba el último. Este tiempo no debe ser calculado con la función

4.7. IMPLEMENTACIÓN ALGORITMO ¡HOLA MUNDO! 71

MPI_Wtime() debido a que dicha función forma parte del entorno MPI, el cual debe ser fi-nalizado antes de que el programa termine. Por lo tanto el tiempo que arrojaría es incorrecto,siempre menor al que debería; en su lugar usaremos las herramientas de monitorización paradeterminar el tiempo de ejecución.

Por otro lado llamamos tiempo de procesamiento al tiempo que emplea el computador encalcular el resultado, eliminando el tiempo de inicialización y finalización de los procesos, yla comunicación con el usuario. De esta manera si el usuario tarda diez segundos en introducirlos datos para un problema, ese tiempo no será añadido al tiempo de procesamiento perosí al tiempo de ejecución. La función MPI_Wtime() nos ayudará a calcular el tiempo deprocesamiento de un programa para después mostrarlo al usuario por la salida estándar.

En el caso del algoritmo ¡Hola Mundo! el tiempo de procesamiento no es indicativo. Sinembargo es muy útil en programas donde un proceso (normalmente el proceso 0) desencadenala ejecución de los demás (normalmente al distribuir entre todos los procesos los datos que elusuario introduce por la entrada estándar). Éste será el caso más común entre los algoritmosexpuestos en el presente documento.

4.7. Implementación Algoritmo ¡Hola Mundo!

A continuación exponemos el código del algoritmo ¡Hola Mundo!. Como vemos dichoprograma utiliza el paradigma SPMD (“Same Program Multiple Data”, Programa Único y Flu-jo de Datos Múltiple). Obtenemos el efecto de diferentes programas ejecutándose en distintosprocesadores bifurcando la ejecución del programa. Para ello nos basamos en el identificadordel proceso: las instrucciones ejecutadas por el proceso 0 son distintas de las ejecutadas porotros procesos, aunque todos los procesos estén ejecutando el mismo programa. Éste es elmétodo más común para escribir programas MIMD.

Algoritmo 4.1: ¡Hola Mundo!

1

2 /********************************************************/3 /*Hola Mundo: CODIGO PROGRAMA QUE SALUDA */4 /********************************************************/5

6 # define TAMCADENA 1007 # include " mpi . h "8 # include < s t d i o . h>9

10 /**************/11 /*FUNCION MAIN*/12 /**************/13 i n t main ( i n t argc , char LML argv ) {14 i n t i d ; /*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 tmp in i c = 0 . 0 ; /*TIEMPO INICIO DE LA EJECUCION*/20 double tmpf in ; /*TIEMPO FINAL DE LA EJECUCION*/21


22

23 /*INICIALIZAMOS EL ENTRORNO DE EJECUCION MPI*/24 MPI_In 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 tdout , " \ nProceso %d en %s Encargado de l a E / S \ n \ n " ,36 i d , nombreproc ) ;37 }38

39 /*TIEMPO INICIAL DE LA EJECUCION*/40 tmp in i c=MPI_Wtime ( ) ;41

42 /*E/S:PROCESAMIENTO*/43 i f ( i d ==0){44 f p r i n t f ( s tdout , " ¡Ho la Mundo ! \ n \ n " ) ;45 }46

47 /*TIEMPO FINAL DE LA EJECUCION*/48 tmpf in =MPI_Wtime ( ) ;49

50 /*E/S:INFORMACION SOBRE LA EJECUCION*/51 i f ( i d ==0){52 f p r i n t f ( s tdout , " Numero P r o c e s o s : %d \ n " , numprocs ) ;53 f p r i n t f ( s tdout , " Tiempo P r o c e s a m i e n t o : %f \ n \ n " , tmpf in N tmp in i c ) ;54 }55

56 /*FINALIZAMOS EL ENTRORNO DE EJECUCION MPI*/57 MPI_Final ize ( ) ;58 return 0 ;59 }

Capítulo 5

Paso de Mensajes

El paso de mensajes es quizás la función más importante y característica del estándar MPI.Se utiliza básicamente para el intercambio de datos entre los procesos en ejecución. En estecapítulo estudiaremos las características más importantes de los mensajes bloqueantes y nobloqueantes, aplicando dicha teoría a la implementación de un algoritmo diseñado para elcálculo de áreas circulares.

5.1. Algoritmo Cálculo de Áreas mediante Montecarlo

El método de Montecarlo es un método numérico que permite resolver problemas matemáti-cos mediante la simulación de variables aleatorias. Utilizaremos dicho método para aproximarel área de un círculo con un radio determinado.

Supongamos que queremos calcular el área de un círculo de radio O . Para hacerlo tomare-mos un cuadrado de lado (@O y lo pondremos alrededor del círculo de radio O , de manera quequede circunscrito. A continuación generaremos un número de puntos aleatorios dentro delárea del cuadrado. Algunos caerán dentro del área del círculo y otros no, como se expone enla figura 5.1.

Tomaremos 6 como el número de puntos aleatorios generados dentro del cuadrado y �como el número de puntos que caen dentro del círculo. Si sabemos que el área del círculo esP O �

y que el área del cuadrado es ,Q(@OM3 � , tendremos la siguiente igualdad:P O � � �6 ,Q(@OM3 �Con lo cual llegamos fácilmente a que:P �SR * �6Utilizando dicha aproximación de

Py sabiendo el radio del círculo aproximaremos fá-

cilmente su área medianteP O �

. Lógicamente cuantas más muestras tomemos, o lo que es lomismo, cuantos más puntos generemos, mejor será la aproximación de

P. También interviene

mucho la aleatoriedad de las muestras; cuanto más aleatorias sean, mejor.La cuestión ahora es determinar los puntos que caen dentro del círculo y los que caen

fuera. Para explicarlo observemos la figura 5.2. Dado un punto ,.T'E�U-3 podremos saber si hacaído dentro del círculo mediante la regla de Pitágoras:

73

74 CAPÍTULO 5. PASO DE MENSAJES

Figura 5.1: Generación Puntos Aleatorios

V � � T �XW U �Si la hipotenusa es mayor que el radio del círculo querrá decir que el punto está fuera de

dicho círculo. Si la hipotenusa es menor que el radio, consideraremos que está dentro. Comopodemos observar en la figura, también podemos generar puntos en sólo una cuarta parte delcuadrado y el círculo, de manera que la proporción no queda alterada. Así lo hacemos en laimplementación del algoritmo Cálculo de Áreas mediante Montecarlo (sección 5.6).

5.2. El Entorno del Mensaje

El paso de mensajes bloqueantes se lleva a cabo en nuestros programas por las funcionesMPI_Send() y MPI_Recv() principalmente. La primera función envía un mensaje a un pro-ceso determinado. La segunda recibe un mensaje de un proceso. Éstas son las funciones másbásicas de paso de mensajes en MPI. Para que el mensaje sea comunicado con éxito, el sistemadebe adjuntar alguna información a los datos que el programa intenta transmitir. Esta infor-mación adicional conforma el entorno del mensaje. En MPI el entorno contiene la siguienteinformación:

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

h

y

x

(x,y)

Figura 5.2: Cálculo Hipotenusa Punto Aleatorio

La etiqueta es un int especificado por el usuario que puede ser usado para distinguir mensajesrecibidos por un único proceso. Por ejemplo, supongamos que el proceso

�está enviando dos

mensajes al proceso Y ; ambos mensajes contienen un número flotante. Uno de los flotantesse emplea en un cálculo, mientras que otro debe ser impreso. Para determinar cuál es cuál,

�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 enterosdentro del intervalo 0-32767 pueden ser usados como etiquetas. La mayoría de las imple-mentaciones permiten valores mucho mayores.

Como dijimos antes un comunicador es básicamente una colección de procesos que puedenmandarse mensajes entre sí. La importancia de los comunicadores se acentúa cuando losmódulos de un programa han sido escritos independientemente de los demás. Por ejemplo,supongamos que queremos resolver un sistema de ecuaciones diferenciales y, en el transcursode resolverlo, tenemos que resolver un sistema de ecuaciones lineales. Mejor que escribir laresolución del sistema de ecuaciones lineales desde el principio, podríamos usar una libreríade 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

�yY con los mensajes enviados en la librería de funciones? Sin la ventaja de los comunicadores

probablemente haríamos una partición del rango de las posibles etiquetas, haciendo que partede ellas sólo puedan ser usadas por la librería de funciones. Ésto es tedioso y puede causarnosproblemas si ejecutamos el programa en otro sistema: puede que la librería del otro sistemano haga uso del mismo rango de etiquetas. Con la ventaja de los comunicadores, simple-mente creamos un comunicador para uso exclusivo en la resolución del sistema de ecuacioneslineales, y se lo pasamos a la librería encargada de hacerlo como argumento en la llamada.Comentaremos los detalles más adelante. Por ahora continuaremos utilizando el comunicadorMPI_COMM_WORLD, el cual consiste en todos los procesos que se ejecutan cuando elprograma comienza.


Tipo de Datos MPI Tipo de Datos CMPI_CHAR signed charMPI_SHORT signed short int

MPI_INT signed intMPI_LONG signed long int

MPI_UNSIGNED_CHAR unsigned charMPI_UNSIGNED_SHORT unsigned short int

MPI_UNSIGNED unsigned intMPI_UNSIGNED_LONG unsigned long int

MPI_FLOAT floatMPI_DOUBLE double

MPI_LONG_DOUBLE long doubleMPI_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 más 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 mayoría de las funciones de la biblioteca estándar de C, la mayoría de lasfunciones MPI retornan un entero como código de error. Sin embargo, como la mayoría de losprogramadores de C, ignoraremos esos valores de retorno en casi todos los casos.

Los contenidos del mensaje son almacenados en un bloque de memoria referenciado porel argumento mensaje. Los siguientes dos argumentos, contador y tipo_datos, permiten alsistema identificar el final del mensaje: éste contiene una secuencia de contador valores, cadauno del tipo MPI datatype. Este tipo no es un tipo de C, aunque la mayoría de los tipospredefinidos corresponden a tipos de C. En el cuadro 5.1 se listan los tipos predefinidos deMPI con sus correspondientes tipos de C, si éstos existen.

Los últimos dos tipos, MPI_BYTE y MPI_PACKED, no corresponden con tipos están-dar de C. El tipo MPI_BYTE puede ser usado si queremos forzar que el sistema no realiceconversión alguna entre las distintas representaciones de los datos (por ejemplo, en una redheterogénea de estaciones de trabajo que utilicen una representación 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. Porejemplo, podría darse el caso de que el tamaño del mensaje que el proceso 1 envía al proceso 0sea de 28 caracteres (strlen(mensaje)+1), aunque el proceso 0 reciba el mensaje en un bufferque tiene capacidad para 100 caracteres. Ésto tiene sentido. En general el proceso receptor noconoce el tamaño exacto del mensaje que se le está enviando. MPI permite recibir mensajestan largos como capacidad reservada tengamos. Si no tenemos suficiente capacidad, tendremosun error de desbordamiento.

Los argumentos destino y origen son los identificadores del proceso receptor y del procesoemisor, respectivamente. MPI permite que el argumento origen sea un comodín. Existe unaconstante predefinida llamada MPI_ANY_SOURCE que puede ser usada si un proceso estápreparado para recibir un mensaje procedente de cualquier proceso. No existe comodín paradestino.

Como dijimos anteriormente MPI contiene dos mecanismos diseñados específicamentepara “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 argumentoetiqueta es un int y, por ahora, nuestro único comunicador es MPI_COMM_WORLD, elcual, como comentamos antes, está predefinido en todos los sistemas MPI y consiste en todoslos procesos que se ejecutan cuando el programa comienza. Existe un comodín,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 procesoY el argumento comunicador que

�usa en MPI_Send() debe ser idéntico al argumento queY usa en MPI_Recv().

El último argumento de MPI_Recv(), status, retorna información acerca de los datos quehemos recibido. Referencia a un registro con dos campos, uno para el origen y otro para laetiqueta. Por ejemplo, si el origen era MPI_ANY_SOURCE en la llamada a MPI_Recv(), elargumento 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 comunicación y procesamiento en los algoritmos. Un método para realizarésto es mediante la comunicación no bloqueante. Las funciones de envío de mensajes no blo-queantes inician el envío del mensaje, pero no lo completan; para ello se necesita una llamadaa la función de finalización de envíos no bloqueantes. De la misma manera una llamada a unafunción de recepción de mensajes no bloqueantes no detiene la ejecución del algoritmo hastaque dicho mensaje sea realmente recibido, como ocurre con las versiones bloqueantes. De estemodo podemos solapar comunicación 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_Datatype tipo_datos, int destino,int etiqueta, MPI_Comm comunicador,MPI_Request* peticion)


int MPI_Irecv(void* mensaje, int contador,MPI_Datatype tipo_datos, int origen,int etiqueta, MPI_Comm comunicador,MPI_Request* peticion)

A simple vista la diferencia entre estas funciones y sus versiones bloqueantes es la existenciadel argumento peticion en sus llamadas. Este argumento es utilizado por las funciones definalización de transmisiones bloqueantes para su ejecución.

Las funciones de finalización 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_Request* vector_peticiones,MPI_Status* status)

La función MPI_Wait() espera a que se complete un envío o una recepción de un mensaje.Para ello le pasamos como argumento de entrada el argumento de salida que nos proporcionala función de paso de mensajes no bloqueantes en el momento de la llamada. El argumento desalida status nos proporciona información acerca de los datos que hemos recibido.

Por su parte MPI_Waitany() espera a que se complete cualquiera de las peticiones que lepasamos en vector_peticiones, devolviendo en el argumento indice la posición de la peticiónsatisfecha.

MPI_Waitall() espera a que se completen todas las peticiones que le pasamos en vec-tor_peticiones.

5.5. Agrupaciones de Datos

Con la generación de máquinas actual el envío de mensajes es una operación costosa.Según esta regla, cuantos menos mensajes enviemos mejor será el rendimiento general delalgoritmo. Así pues en el algoritmo Cálculo de Áreas mediante Montecarlo podríamos mejorarel 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 parámetros permiten al usuario agrupar datos que tengan elmismo tipo básico en un único mensaje. Para usarlo dichos datos deben estar almacenados endirecciones de memoria contiguas. Debido a que el lenguaje C garantiza que los elementosde un vector están almacenados en direcciones de memoria contiguas, si queremos enviar loselementos de un vector, o un subconjunto de ellos, podremos hacerlo en un solo mensaje.

Desafortunadamente esto no nos ayuda en el algoritmo Cálculo 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 número de muestras no tienen porqué es-tar alojadas en direcciones de memoria contiguas. Tampoco debemos almacenar estos datos enun vector debido a que ello restaría claridad y elegancia al código. Para lograr nuestro objetivoutilizaremos una facilidad de MPI para la agrupación de los datos.

5.5.1. Tipos Derivados

Una opción razonable para conseguir nuestro objetivo podría ser almacenar el radio y elnúmero de muestras en una estructura con dos miembros (un flotante largo y un entero largo)como se muestra a continuación:

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 funcionesde paso de mensajes. El problema aquí es que el tipo de datos de la estructura no es un tipode datos MPI; necesitamos construir un tipo de datos MPI a partir del tipo de datos de C. MPIpropone una solución a ésto permitiendo al usuario construir tipos de datos MPI en tiempo deejecución. Para construir un tipo de datos MPI básicamente se especifica la distribución de losdatos en el tipo (los tipos de los miembros y sus direcciones relativas de memoria). Un tipode datos MPI construido de este modo se denomina tipo de datos derivado. Para ver cómofunciona ésto expondremos la función 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 ESTRUCTURARELATIVOS 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 número de elementos de cada tipo. La funciónMPI_Address() nos ayuda a calcular los desplazamientos de cada uno de los miembros conrespecto a la dirección inicial del primero. Con esta información ya sabemos los tipos, lostamaños y las direcciones relativas de memoria de cada uno de los miembros del tipo de datosde 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-cación de MPI. Para usarlo simplemente usaremos como primer argumento de las funcionesla dirección inicial de la estructura a enviar, y el tipo de datos MPI creado en el argumentotipo_datos.

5.5.2. Vectores

La función 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 argumentosalto es el número de elementos de tipo tipo_datos_elem que hay entre los sucesivos elemen-tos de nuevo_tipo.

5.6. Implementación Cálculo de Áreas mediante Montecarlo

A continuación exponemos las versiones bloqueante y no bloqueante del algoritmo Cálcu-los de Áreas mediante Montecarlo.

5.6.1. Implementación con Mensajes Bloqueantes

5.6. IMPLEMENTACIÓN CÁLCULO DE ÁREAS MEDIANTE MONTECARLO 81

Algoritmo 5.1: Cálculo de Áreas mediante Montecarlo (Bloqueante)

1

2 /***************************************************/3 /*Calculo de Areas: CODIGO APROXIMACION DE AREAS */4 /*CIRCULARES MEDIANTE MONTECARLO (BLOQUEANTE) */5 /***************************************************/6

7 # include < s t d i o . h>8 # include < s t d l i b . h>9 # include < math . h>

10 # include " mpi . h "11

12 /*DECLARACION ESTRUCTURA DATOS ENTRADA*/13 typedef struct {14 long double rad io ;15 long nmuestras_local ;16 } Tipo_Datos_Entrada ;17

18 /*DECLARACION DE LA FUNCIONES QUE VAMOS A UTILIZAR*/19 long double MonteCarlo ( i n t i d , long double rad io , long l o ca l_n ) ;20 void obtener_datos ( long double L prad io , long L pnmuestras_global ) ;21 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 L prad io ,22 long L pnmuestras_local ) ;23 void reco lec ta r_datos ( i n t i d , i n t numprocs , long double L paprox_ loca l ,24 long double L paprox_global ) ;25 void c o n s t r u i r _ t i po_d e r i v a do ( Tipo_Datos_Entrada L pdatos ,26 MPI_Datatype L pMPI_Tipo_Datos ) ;27

28 /**************/29 /*FUNCION MAIN*/30 /**************/31 i n t main ( i n t argc , char LML argv ) {32

33 long double PI25DIGITOS=3.141592653589793238462643;34 /*VALOR PI PARA CALCULAR EL ERROR*/35 i n t i d ; /*IDENTIFICADOR DEL PROCESO*/36 i n t numprocs ; /*NUMERO DE PROCESOS*/37 char nombreproc [MPI_MAX_PROCESSOR_NAME] ;38 /*NOMBRE PROCESADOR*/39 i n t lnombreproc ; /*LONGITUD NOMBRE PROCESADOR*/40 long double rad io ; /*RADIO CIRCUNFERENCIA*/41 long nmuestras_global ; /*NUMERO DE MUESTRAS*/42 long nmuestras_local ; /*NUMERO DE MUESTRAS DE CADA PROCESO*/43 long double aprox_ loca l ; /*APROX LOCAL DE CADA PROCESO*/44 long double aprox_global ; /*APROX GENERAL (MEDIA DE TODAS LAS LOCALES)*/45 i n t r a i z = 0 ; /*PROCESO QUE RECIBE LAS LOCALES Y LAS SUMA*/46 double tmp in i c = 0 . 0 ; /*TIEMPO INICIO DE LA EJECUCION*/47 double tmpf in ; /*TIEMPO FINAL DE LA EJECUCION*/48

49 i n t e t i que ta =50; /*ETIQUETA MENSAJES DE PRUEBA*/50 MPI_Status s ta tus ; /*STATUS RECEPCION MENSAJES DE PRUEBA*/51 i n t or igen ; /*PROCESO ORIGEN MENSAJES DE PRUEBA*/52

53

54 /*INICIALIZAMOS EL ENTRORNO DE EJECUCION MPI*/


55 MPI_In i t (& argc ,& argv ) ;56


60 /*ALMACENAMOS EL NUMERO DE PROCESOS*/61 MPI_Comm_size (MPI_COMM_WORLD,&numprocs ) ;62

63 /*E/S:NOMBRE DEL PROCESADOR,PROCESADOR 0*/64 MPI_Get_processor_name ( nombreproc,& lnombreproc ) ;65 i f ( i d ==0){66 f p r i n t f ( s tdout , " \ nProceso %d en %s Encargado de l a E / S \ n " ,67 i d , nombreproc ) ;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 obtener_datos(& rad io ,& nmuestras_global ) ;86 /*NUMERO DE MUESTRAS PARA CADA PROCESO*/87 nmuestras_local=nmuestras_global / numprocs ;88 /*TRUNCAMOS NUMERO DE MUESTRAS GLOBAL*/89 nmuestras_global=nmuestras_local L numprocs ;90 }91

92 /*TIEMPO INICIAL DE PROCESAMIENTO*/93 i f ( i d ==0){ f p r i n t f ( s tdout , " Procesando . . . \ n \ n " ) ; }94 tmp in i c=MPI_Wtime ( ) ;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 ,& rad io ,& nmuestras_local ) ;98

99 /*CALCULAMOS LA INTEGRAL PARCIAL DEL PROCESO*/100 aprox_ loca l = MonteCarlo ( i d , rad io , nmuestras_local ) ;101

102 /*RECOLECTAMOS AREAS CALCULADAS POR LOS PROCESOS Y HACEMOS LA MEDIA*/103 reco lec ta r_da tos ( i d , numprocs ,& aprox_ loca l ,& aprox_global ) ;104

105 /*TIEMPO FINAL DE PROCESAMIENTO*/106 tmpf in =MPI_Wtime ( ) ;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 tdout , " 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 nmuestras_global ) ;112 f p r i n t f ( s tdout , " de l a c i r c u n f e r e n c i a con r a d i o %Lf es \ n " , r ad io ) ;113 f p r i n t f ( s tdout , " %.60 Lf \ n " , aprox_global ) ;114 f p r i n t f ( s tdout , " E r r o r < %f \ n \ n " ,115 fabs ( PI25DIGITOS L rad io L rad io N aprox_global ) ) ;116 f p r i n t f ( s tdout , " Numero P r o c e s o s : %d \ n " , numprocs ) ;117 f p r i n t f ( s tdout , " Tiempo P r o c e s a m i e n t o : %f \ n \ n " , tmpf in N tmp in i c ) ;118 }119

120 /*FINALIZAMOS EL ENTRORNO DE EJECUCION MPI*/121 MPI_Final ize ( ) ;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 */129 /***************************************************************/130 void obtener_datos ( long double L prad io , long L pnmuestras_global ) {131

132 /*E/S:PETICION DE DATOS*/133

134 f p r i n t f ( s tdout , " 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 scanf ( " %Lf " , p rad io ) ;136 f p r i n t f ( s tdout , " I n t r o d u z c a numero de m u e s t r a s \ n " ) ;137 scanf ( " %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 */149 /**********************************************************************/150 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 L prad io ,151 long L pnmuestras_local ) {152

153 MPI_Datatype MPI_Tipo_Datos_Entrada ;154 Tipo_Datos_Entrada datos_entrada ;155 i n t or igen = 0 ; /*PROCESO ORIGEN MENSAJES*/156 i n t dest ino ; /*PROCESO DESTINO DATOS*/157 i n t e t i que ta ; /*ETIQUETA MENSAJES*/158 MPI_Status s ta tus ; /*STATUS RECEPCION MENSAJES*/159

160

161 c o n s t r u i r _ t i po _de r i v ado(& datos_entrada,& MPI_Tipo_Datos_Entrada ) ;162

163 i f ( i d ==0){164 /*ENVIO DE LOS DATOS*/


165 datos_entrada . rad io= L prad io ;166 datos_entrada . nmuestras_local= L pnmuestras_local ;167 for ( des t ino =1; des t ino<numprocs ; des t ino ++){168 e t i que ta =30;169 MPI_Send(& datos_entrada , 1 , MPI_Tipo_Datos_Entrada , des t ino ,170 e t i que ta ,MPI_COMM_WORLD) ;171 }172 }173 else {174 /*RECEPCION DE LOS DATOS*/175 e t i que ta =30;176 MPI_Recv(& datos_entrada , 1 , MPI_Tipo_Datos_Entrada , or igen ,177 e t i que ta ,MPI_COMM_WORLD,& s ta tus ) ;178 L prad io=datos_entrada . rad io ;179 L pnmuestras_local=datos_entrada . nmuestras_local ;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 rad io , 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 ip ; /*HIPOTENUSA MUESTRA ACTUAL*/195 long a c i e r t o s = 0 ; /*NUM.MUESTRAS QUE CAEN DENTRO DE LA CIRCUNFERENCIA*/196 long f a l l o s = 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 for ( i =0; i != nummuestras ; i ++){205 x =( long double ) rand ( ) /RAND_MAX;206 y =( long double ) rand ( ) /RAND_MAX;207 h ip= s q r t (pow( x ,2 )+pow( y , 2 ) ) ;208 i f ( h ip >1) { f a l l o s ++; }209 else { a c i e r t o s ++; }210 }211 p i =4 .0 L ( ( long double ) a c i e r t o s / nummuestras ) ;212

213 /*CALCULAMOS AREA*/214 area=pow( rad io , 2 ) L p i ;215

216 return area ;217

218 }/*MonteCarlo*/219


220

221 /*********************************************************************/222 /*FUNCION recolectar_datos:PROCESO 0 HACE LA MEDIA DE LAS */223 /*APROXIMACIONES LOCALES */224 /*********************************************************************/225 void reco lec ta r_datos ( i n t i d , i n t numprocs , long double L paprox_ loca l ,226 long double L paprox_global ) {227

228 i n t or igen ; /*PROCESO ORIGEN MENSAJES*/229 i n t dest ino = 0 ; /*PROCESO DESTINO DATOS*/230 i n t e t i que ta ; /*ETIQUETA MENSAJES*/231 MPI_Status s ta tus ; /*STATUS RECEPCION MENSAJES*/232 long double b u f f e r ; /*BUFFER RECEPCION APROXIMACIONES LOCALES*/233

234 i f ( i d ==0){235 /*RECOLECTAMOS LOS CALCULOS LOCALES Y HACEMOS LA MEDIA*/236 L paprox_global= L paprox_ loca l ;237 for ( o r igen =1; or igen<numprocs ; or igen ++){238 e t i que ta =30+or igen ;239 MPI_Recv(& b u f f e r , 1 ,MPI_LONG_DOUBLE, or igen , e t i que ta ,240 MPI_COMM_WORLD,& s ta tus ) ;241 L paprox_global =( L paprox_global+ b u f f e r ) / 2 . 0 ;242 }243 }244 else {245 /*ENVIO DE LOS DATOS*/246 e t i que ta =30+ i d ;247 MPI_Send( paprox_ loca l , 1 ,MPI_LONG_DOUBLE, des t ino , e t i que ta ,248 MPI_COMM_WORLD) ;249 }250 }/*distribuir_datos*/251

252

253 /*********************************************************************/254 /*FUNCION construir_tipo_derivado: CONSTRUYE EL TIPO DE DATOS MPI */255 /*NECESARIO PARA DISTRIBUIR LOS DATOS DE ENTRADA EMPAQUETADOS */256 /*********************************************************************/257 void c o n s t r u i r _ t i po_d e r i v a do ( Tipo_Datos_Entrada L pdatos ,258 MPI_Datatype L pMPI_Tipo_Datos ) {259

260 MPI_Datatype t i p o s [ 2 ] ;261 i n t l ong i t udes [ 2 ] ;262 MPI_Aint d i recc [ 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 l ong i t udes [ 0 ] = 1 ;272 l ong i t udes [ 1 ] = 1 ;273

274 /*CALCULAMOS LOS DESPLAZAMIENTOS DE LOS MIEMBROS DE LA ESTRUCTURA


275 RELATIVOS AL COMIENZO DE DICHA ESTRUCTURA*/276 MPI_Address( pdatos ,& d i recc [ 0 ] ) ;277 MPI_Address(&( pdatos N >rad io ) ,& d i recc [ 1 ] ) ;278 MPI_Address(&( pdatos N >nmuestras_local ) ,& d i recc [ 2 ] ) ;279 desplaz [ 0 ] = d i recc [1] N d i recc [ 0 ] ;280 desplaz [ 1 ] = d i recc [2] N d i recc [ 0 ] ;281

282 /*CREACION TIPO DATOS DERIVADO*/283 MPI_Type_struct ( 2 , l ong i t udes , 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. Implementación con Mensajes No Bloqueantes

Algoritmo 5.2: Cálculo 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 1289

10 # include < s t d i o . h>11 # include < s t d l i b . h>12 # include <math . h>13 # include " mpi . h "14

15 /*DECLARACION ESTRUCTURA DATOS ENTRADA*/16 typedef struct {17 long double rad io ;18 long nmuestras_local ;19 } Tipo_Datos_Entrada ;20

21 /*DECLARACION DE LA FUNCIONES QUE VAMOS A UTILIZAR*/22 long double MonteCarlo ( i n t i d , long double rad io , long l o ca l_n ) ;23 void obtener_datos ( long double L prad io , long L pnmuestras_global ) ;24 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 L prad io ,25 long L pnmuestras_local ) ;26 void reco lec ta r_datos ( i n t i d , i n t numprocs , long double L paprox_ loca l ,27 long double L paprox_global ) ;28 void c o n s t r u i r _ t i po_d e r i v ad o ( Tipo_Datos_Entrada L pdatos ,29 MPI_Datatype L pMPI_Tipo_Datos ) ;30

31 /**************/32 /*FUNCION MAIN*/33 /**************/34 i n t main ( i n t argc , char L8L argv ) {


35

36 long double PI25DIGITOS=3.141592653589793238462643;37 /*VALOR PI PARA CALCULAR EL ERROR*/38 i n t i d ; /*IDENTIFICADOR DEL PROCESO*/39 i n t numprocs ; /*NUMERO DE PROCESOS*/40 char nombreproc [MPI_MAX_PROCESSOR_NAME] ;41 /*NOMBRE PROCESADOR*/42 i n t lnombreproc ; /*LONGITUD NOMBRE PROCESADOR*/43 long double rad io ; /*RADIO CIRCUNFERENCIA*/44 long nmuestras_global ; /*NUMERO DE MUESTRAS*/45 long nmuestras_local ; /*NUMERO DE MUESTRAS DE CADA PROCESO*/46 long double aprox_ loca l ; /*APROX LOCAL DE CADA PROCESO*/47 long double aprox_global ; /*APROX GENERAL (MEDIA DE TODAS LAS LOCALES)*/48 i n t r a i z = 0 ; /*PROCESO QUE RECIBE LAS LOCALES Y LAS SUMA*/49 double tmp in i c = 0 . 0 ; /*TIEMPO INICIO DE LA EJECUCION*/50 double tmpf in ; /*TIEMPO FINAL DE LA EJECUCION*/51

52 i n t e t i que ta =50; /*ETIQUETA MENSAJES DE PRUEBA*/53 MPI_Status s ta tus ; /*STATUS RECEPCION MENSAJES DE PRUEBA*/54 i n t or igen ; /*PROCESO ORIGEN MENSAJES DE PRUEBA*/55

56

57 /*INICIALIZAMOS EL ENTRORNO DE EJECUCION MPI*/58 MPI_In i t (& argc ,& argv ) ;59



66 /*E/S:NOMBRE DEL PROCESADOR,PROCESADOR 0*/67 MPI_Get_processor_name ( nombreproc,& lnombreproc ) ;68 i f ( i d ==0){69 f p r i n t f ( s tdout , " \ nProceso %d en %s Encargado de l a E / S \ n " ,70 i d , nombreproc ) ;71 }72 /*E/S:NOMBRE DEL PROCESADOR,TODOS LOS PROCESOS (PRUEBAS)*/73 /*if(id==0){74 * for (origen=1;origen<numprocs;origen++){75 * MPI_Recv(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,origen,76 * etiqueta,MPI_COMM_WORLD,&status);77 * fprintf(stdout,"Proceso %d en %s\n",origen,nombreproc);78 * }79 *}80 *else{81 * MPI_Send(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,0,82 * etiqueta,MPI_COMM_WORLD);83 *}84 */85

86 /*OBTENEMOS DATOS INTRODUCIDOS POR EL USUARIO*/87 i f ( i d ==0){88 obtener_datos(& rad io ,& nmuestras_global ) ;89 /*NUMERO DE MUESTRAS PARA CADA PROCESO*/


90 nmuestras_local=nmuestras_global / numprocs ;91 /*TRUNCAMOS NUMERO DE MUESTRAS GLOBAL*/92 nmuestras_global=nmuestras_local L numprocs ;93 }94

95 /*TIEMPO INICIAL DE PROCESAMIENTO*/96 i f ( i d ==0){ f p r i n t f ( s tdout , " \ nProcesando . . . \ n \ n " ) ; }97 tmp in i c=MPI_Wtime ( ) ;98

99 /*DISTRIBUIMOS DATOS INTRODUCIDOS POR EL USUARIO*/100 d i s t r i b u i r _ d a t o s ( i d , numprocs ,& rad io ,& nmuestras_local ) ;101

102 /*CALCULAMOS LA INTEGRAL PARCIAL DEL PROCESO*/103 aprox_ loca l = MonteCarlo ( i d , rad io , nmuestras_local ) ;104

105 /*RECOLECTAMOS AREAS CALCULADAS POR LOS PROCESOS Y HACEMOS LA MEDIA*/106 reco lec ta r_da tos ( i d , numprocs ,& aprox_ loca l ,& aprox_global ) ;107


111 /*E/S:IMPRIMIMOS RESULTADO Y TIEMPO DE PROCESAMIENTO*/112 i f ( i d ==0){113 f p r i n t f ( s tdout , " 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 nmuestras_global ) ;115 f p r i n t f ( s tdout , " de l a c i r c u n f e r e n c i a con r a d i o %Lf es \ n " , r ad io ) ;116 f p r i n t f ( s tdout , " %.60 Lf \ n " , aprox_global ) ;117 f p r i n t f ( s tdout , " E r r o r < %f \ n \ n " ,118 fabs ( PI25DIGITOS L rad io L rad io N aprox_global ) ) ;119 f p r i n t f ( s tdout , " Numero P r o c e s o s : %d \ n " , numprocs ) ;120 f p r i n t f ( s tdout , " Tiempo P r o c e s a m i e n t o : %f \ n \ n " , tmpf in N tmp in i c ) ;121 }122


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 */132 /***************************************************************/133 void obtener_datos ( long double L prad io , long L pnmuestras_global ) {134


137 f p r i n t f ( s tdout , " 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 scanf ( " %Lf " , p rad io ) ;139 f p r i n t f ( s tdout , " I n t r o d u z c a numero de m u e s t r a s \ n " ) ;140 scanf ( " %l d " , pnmuestras_global ) ;141

142

143 /*E/S SIN PETICION:UTILIZAR EN CASO DE PRUEBAS*/144 /**pradio=1.0;*pnmuestras_global=200000000;*/


145


148

149 /**********************************************************************/150 /*FUNCION distribuir_datos:PROCESO 0 DISTIBUYE RADIO DE LA */151 /*CIRCUNFERENCIA Y EL NUMERO DE MUESTRAS (n) ENTRE LOS DEMAS PROCESOS */152 /**********************************************************************/153 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 L prad io ,154 long L pnmuestras_local ) {155

156 MPI_Datatype MPI_Tipo_Datos_Entrada ;157 Tipo_Datos_Entrada datos_entrada ;158 i n t or igen = 0 ; /*PROCESO ORIGEN MENSAJES*/159 i n t dest ino ; /*PROCESO DESTINO DATOS*/160 i n t e t i que ta ; /*ETIQUETA MENSAJES*/161 MPI_Request request ; /*PETICION MENSAJES NO BLOQUEANTES*/162 MPI_Status s ta tus ; /*STATUS RECEPCION*/163

164 c o n s t r u i r _ t i po _de r i v ado(& datos_entrada,& MPI_Tipo_Datos_Entrada ) ;165

166 i f ( i d ==0){167 /*ENVIO DE LOS DATOS*/168 datos_entrada . rad io= L prad io ;169 datos_entrada . nmuestras_local= L pnmuestras_local ;170 for ( des t ino =1; des t ino<numprocs ; des t ino ++){171 e t i que ta =30;172 MPI_Isend(& datos_entrada , 1 , MPI_Tipo_Datos_Entrada , des t ino , e t i que ta ,173 MPI_COMM_WORLD,& request ) ;174 }175 }176 else {177 /*RECEPCION DE LOS DATOS*/178 e t i que ta =30;179 MPI_Irecv(& datos_entrada , 1 , MPI_Tipo_Datos_Entrada , or igen , e t i que ta ,180 MPI_COMM_WORLD,& request ) ;181 MPI_Wait(& request ,& s ta tus ) ;182 L prad io=datos_entrada . rad io ;183 L pnmuestras_local=datos_entrada . nmuestras_local ;184 }185 }/*distribuir_datos*/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 rad io , 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 ip ; /*HIPOTENUSA MUESTRA ACTUAL*/199 long a c i e r t o s = 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


207 /*ESTIMACION DE PI*/208 for ( i =0; i != nummuestras ; i ++){209 x =( long double ) rand ( ) /RAND_MAX;210 y =( long double ) rand ( ) /RAND_MAX;211 h ip= s q r t (pow( x ,2 )+pow( y , 2 ) ) ;212 i f ( h ip >1) { f a l l o s ++; }213 else { a c i e r t o s ++; }214 }215 p i =4 .0 L ( ( long double ) a c i e r t o s / nummuestras ) ;216

217 /*CALCULAMOS AREA*/218 area=pow( rad io , 2 ) L p i ;219

220 return area ;221

222 }/*MonteCarlo*/223

224

225 /*********************************************************************/226 /*FUNCION recolectar_datos:PROCESO 0 HACE LA MEDIA DE LAS */227 /*APROXIMACIONES LOCALES */228 /*********************************************************************/229 void reco lec ta r_datos ( i n t i d , i n t numprocs , long double L paprox_ loca l ,230 long double L paprox_global ) {231

232 i n t or igen ; /*PROCESO ORIGEN MENSAJES*/233 i n t dest ino = 0 ; /*PROCESO DESTINO DATOS*/234 i n t e t i que ta ; /*ETIQUETA MENSAJES*/235 long double b u f f e r ; /*BUFFER RECEPCION APROXIMACIONES LOCALES*/236 i n t i ; /*CONTADOR*/237 MPI_Request request ;238 MPI_Request requests [MAX_NUM_PROCS] ;239 MPI_Status s ta tus ;240

241

242 i f ( i d ==0){243 L paprox_global= L paprox_ loca l ;244 /*MANDAMOS LAS PETICIONES DE DATOS*/245 for ( o r igen =1; or igen<numprocs ; or igen ++){246 e t i que ta =30+or igen ;247 MPI_Irecv(& b u f f e r , 1 ,MPI_LONG_DOUBLE, or igen , e t i que ta ,248 MPI_COMM_WORLD,& requests [ o r igen ] ) ;249 }250 /*RECOLECTAMOS LOS CALCULOS LOCALES Y HACEMOS LA MEDIA*/251 for ( i =1; i <numprocs ; i ++){252 MPI_Waitany ( numprocs , requests ,& or igen ,& s ta tus ) ;253 L paprox_global =( L paprox_global+ b u f f e r ) / 2 . 0 ;254 }


255 }256 else {257 /*ENVIO DE LOS DATOS*/258 e t i que ta =30+ i d ;259 MPI_Isend ( paprox_ loca l , 1 ,MPI_LONG_DOUBLE, des t ino , e t i que ta ,260 MPI_COMM_WORLD,& request ) ;261 }262 }/*distribuir_datos*/263

264


272 MPI_Datatype t i p o s [ 2 ] ;273 i n t l ong i t udes [ 2 ] ;274 MPI_Aint d i recc [ 3 ] ;275 MPI_Aint desplaz [ 2 ] ;276

277

278 /*PRIMERO ESPECIFICAMOS LOS TIPOS*/279 t i p o s [ 0 ] =MPI_LONG_DOUBLE;280 t i p o s [ 1 ] =MPI_LONG;281

282 /*ESPECIFICAMOS EL NUMERO DE ELEMENTOS DE CADA TIPO*/283 l ong i t udes [ 0 ] = 1 ;284 l ong i t udes [ 1 ] = 1 ;285

286 /*CALCULAMOS LOS DESPLAZAMIENTOS DE LOS MIEMBROS DE LA ESTRUCTURA287 RELATIVOS AL COMIENZO DE DICHA ESTRUCTURA*/288 MPI_Address( pdatos ,& d i recc [ 0 ] ) ;289 MPI_Address(&( pdatos N >rad io ) ,& d i recc [ 1 ] ) ;290 MPI_Address(&( pdatos N >nmuestras_local ) ,& d i recc [ 2 ] ) ;291 desplaz [ 0 ] = d i recc [1] N d i recc [ 0 ] ;292 desplaz [ 1 ] = d i recc [2] N d i recc [ 0 ] ;293




Capítulo 6

Comunicación Colectiva

Las operaciones de comunicación colectiva son aquellas que se aplican al mismo tiempoa todos los procesos pertenecientes a un comunicador. Tienen una gran importancia en elestándar MPI, debido a la claridad de su sintaxis y a su eficiencia. Para analizar su utilidad yconveniencia implementaremos el algoritmo Regla del Trapecio de manera que haga un usointeligente de dichas operaciones.

6.1. Algoritmo Regla del Trapecio

La regla del trapecio estima Z\[]�^ ,.T_3a`5T mediante la división del intervalo b � EcJcd en � seg-mentos iguales, calculando la siguiente suma:V b ^ ,.T � 3�$)( W ^ ,.T 7 3�$)( W 7Me fgih ^ ,.T g 3�d

DondeV � ,QJj/ � 3�$&� , y T g � � Wlk V

,k � DFEBGBGBG4E�� .

Una manera de realizar este cálculo 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 susubintervalo. Para estimar la integral completa se suman los cálculos 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 losprimeros �'$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 � VC E � W ,Hm W 143 � VC d

Cada proceso necesita la siguiente información:� El número de procesos C� Su identificador� El intervalo de integración completo b � EcJcd93

94 CAPÍTULO 6. COMUNICACIÓN COLECTIVA� El número de segmentos �� La función ^ ,.T\3 a integrar

Los dos primeros datos se pueden conseguir llamando a las funciones MPI_Comm_size() yMPI_Comm_rank(). Sin embargo tanto el intervalo b � EcJcd como el número de segmentos �deben ser introducidos por el usuario. Por otro lado sería positivo que el usuario pudiera elegirla función ^ ,.T_3 a integrar (dentro de un conjunto predefinido de funciones). Como explicamosen la sección 4.4 sólo un proceso (normalmente el proceso 0) debe encargarse de obtenerlos datos de la entrada estándar y distribuirlos entre los demás procesos. Ésto puede hacersemediante paso de mensajes o mediante comunicación colectiva, siendo la segunda opción máseficiente. En la sección 6.2 se explica el uso de las operaciones de comunicación colectiva condicho propósito.

Por otro lado una buena forma de sumar los cálculos individuales de los procesos es hacerque cada proceso envíe su cálculo local al proceso 0, y que el proceso 0 haga la suma final. Denuevo podemos emplear al menos dos técnicas: paso de mensajes y operaciones de reducción.Dado que las operaciones de reducción son más eficientes, utilizaremos la segunda opción.

Las funciones que ofreceremos al usuario estarán codificadas en funciones de código C,por lo que tendremos que modificar el código y compilarlo de nuevo para introducir nuevasfunciones. Entre las funciones ofrecidas incluiremos al menos las siguientes:� ^ ,.T_3 � (@T� ^ ,.T_3 � T �� ^ ,.T_3 � n� ^ ,.T_3 � �o qp n4r�sEsta última función nos permite realizar la búsqueda del número

P. El área bajo la curvaU � qp n r nos proporciona un método para computar

P:t � R,�1 W T � 3 `MT � b Rvu)wyx�z�u"{ ,.T\3�d � �SR , P R /0DM3 � P

Por lo tanto tenemos que para computarP

mediante la regla del trapecio utilizaremos^ ,.T\3 � �o qp n r s , � � D y J � 1 .

6.2. Distribución y Recolección de los Datos

La distribución y recolección de los datos se puede realizar mediante dos técnicas: paso demensajes (como hicimos en el algoritmo Cálculo de Áreas mediante Montecarlo) y comuni-cación colectiva. Las operaciones de comunicación colectiva son más eficientes debido a quereducen el tiempo empleado en dichas operaciones, reduciendo el número de pasos necesariospara su ejecución.

En la técnica de paso de mensajes el problema radica en que cargamos a un proceso condemasiado trabajo. Al utilizar esta técnica para distribuir los datos damos básicamente lossiguientes pasos:

6.2. DISTRIBUCIÓN Y RECOLECCIÓN DE LOS DATOS 95

0

0

0 2 4 6

4

765320 1 4

Figura 6.1: Procesos estructurados en árbol

1. Proceso 0 recoge los datos de la entrada estándar

2. Proceso 0 envía un mensaje a cada uno de los restantes procesos comunicándole losdatos de entrada

Si utilizamos un bucle para realizar el segundo paso, los procesos con identificador mayordeben continuar esperando mientras el proceso 0 envía los datos de entrada a los procesos conidentificador menor. Éste no es sólo un asunto de E/S y por supuesto no es un comportamientodeseable: el punto principal del procesamiento paralelo es conseguir que múltiples procesoscolaboren para resolver un problema. Si uno de los procesos está haciendo la mayoría deltrabajo, podríamos usar mejor una máquina convencional de un solo procesador.

Por otro lado observamos que existe una ineficiencia similar en el final del algoritmo alutilizar paso de mensajes en el proceso de recolección, donde el proceso 0 hace todo el trabajode recolectar y sumar las integrales locales.

La pregunta que surge es... ¿cómo podemos dividir el trabajo más equitativamente entre losprocesos? Una solución natural es imaginar que tenemos un árbol de procesos, con el proceso0 como raíz.

Durante la primera etapa de la distribución de los datos pongamos que el proceso 0 envíalos datos al 4. Durante la siguiente etapa el 0 envía los datos al 2, mientras que el 4 los envíaal 6. Durante la última etapa el 0 se los envía al 1, mientras el 2 los envía al 3, el 4 al 5 y el6 al 7 (mirar la figura 6.1). Así reducimos el bucle de distribución de la entrada de 7 etapas a3 etapas. De manera más general, si tenemos C procesos este procedimiento permite distribuirlos 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 distribución estructurado en árbol en nuestro algorit-mo, necesitamos introducir un bucle con �i�"! � ,|C\3 etapas. En la implementación de dicho buclecada proceso necesita calcular en cada etapa:� Si recibe, y en caso de hacerlo, el origen; y

96 CAPÍTULO 6. COMUNICACIÓN COLECTIVA� Si envía, y en caso de hacerlo, el destino

Como puede suponerse estos cálculos pueden ser algo complicados, especialmente porque nohay un ordenamiento fijo. En nuestro ejemplo elegimos:

1. 0 envía al 4

2. 0 envía al 2, 4 al 6

3. 0 envía al 1, 2 al 3, 4 al 5, 6 al 7

Aunque podríamos haber elegido también:

1. 0 envía al 1

2. 0 envía al 2, 1 al 3

3. 0 envía al 4, 1 al 5, 2 al 6, 3 al 7

De hecho, a menos que sepamos algo acerca de la topología subyacente de nuestra máquinano podremos decidir realmente qué esquema es mejor.

Lo ideal sería usar una función diseñada específicamente para la máquina que estemosusando de manera que no nos tengamos que preocupar acerca de todos los detalles, y que notengamos que modificar el código cada vez que cambiamos de máquina. Y como habrá podidoadivinar MPI proporciona dicha función.

6.3. Operaciones de Comunicación Colectiva

Un patrón de comunicación que engloba a todos los procesos de un comunicador es unacomunicación colectiva. Como consecuencia una comunicación colectiva implica a más de dosprocesos. Un broadcast es una operación de comunicación colectiva en donde un proceso envíaun mismo mensaje a todos los procesos. En MPI la función para hacer ésto es MPI_Bcast():

int MPI_Bcast(void* mensaje, int contador,MPI_Datatype tipo_datos, int raiz,MPI_Comm com);

La función envía 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 pertenecientesal comunicador con los mismos argumentos para raiz y com. Por lo tanto un mensaje broad-cast no puede ser recibido con la función MPI_Recv(). Los parámetros contador y tipo_datostienen la misma finalidad que en MPI_Send() y MPI_Recv(): especifican la extensión delmensaje. Sin embargo, al contrario que en las funciones punto a punto, MPI insiste en que enlas operaciones de comunicación colectiva contador y tipo_datos deben ser iguales en todoslos procesos pertenecientes al comunicador. La razón de ésto es que en algunas operacionescolectivas un único proceso recibe datos de otros muchos procesos, y para que el programadetermine qué cantidad de datos han sido recibidos necesitaría un vector de status de retorno.

6.4. OPERACIONES DE REDUCCIÓN 97

6.4. Operaciones de Reducción

En el algoritmo Regla del Trapecio, tras la fase de introducción de datos, todos los proce-sadores ejecutan esencialmente las mismas instrucciones hasta el final de la fase de suma. Deeste modo, a menos que la función ^ ,.T_3 sea muy complicada (p.ej. que requiera más trabajoser evaluada en ciertas zonas del intervalo b � EcJcd ), esta parte del programa distribuye el trabajoequitativamente entre los procesos. Como hemos dicho antes, éste no es el caso en la fase desuma 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 lasflechas de la figura 6.1 podemos usar la comunicación estructurada en árbol. De esta manerapodemos distribuir el trabajo de calcular la suma entre los procesos como sigue:

1. (a) 1 envía 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 envía al 0, 6 al 4(b) 0 suma, 4 suma

3. (a) 4 envía al 0(b) 0 suma

Por supuesto caemos en la misma cuestión que cuando discutiamos la implementación de nue-stro propio broadcast: ¿Hace un uso óptimo de la topología de nuestra máquina esta estructuraen árbol? Una vez más debemos responder que ello depende de la máquina. Así que, comoantes, debemos dejar a MPI hacer dicho trabajo utilizando una función optimizada.

La “suma global” que queremos calcular es un ejemplo de una clase general de operacionesde comunicación colectiva llamadas operationes de reducción. Las operaciones de reducciónforman un subconjunto de las operaciones de comunicación colectiva. En una operación de re-ducción global todos los procesos (pertenecientes a un comunicador) aportan datos, los cualesse combinan usando una operación binaria. Las operaciones binarias típicas son la suma, elmáximo, el mínimo, AND lógico, etc. La función MPI que implementa una operación de re-ducción es:

int MPI_Reduce(void* operando, void* resultado,int contador, MPI_Datatype tipo_datos,MPI_Op operacion, int raiz,MPI_Comm comunicador);

La función MPI_Reduce combina los operandos referenciados por operando usando la op-eración señalada por operacion y almacena el resultado en la variable resultado pertenecienteal 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 pertenecientesa comunicador; además contador, tipo_datos y operacion deben ser iguales para todos losprocesos.

El argumento operacion puede adquirir uno de los valores predefinidos mostrados en elcuadro 6.1. También es posible definir operaciones adicionales.

98 CAPÍTULO 6. COMUNICACIÓN COLECTIVA

Nombre de Operación Significado

MPI_MAX MáximoMPI_MIN MínimoMPI_SUM SumaMPI_PROD ProductoMPI_LAND AND LógicoMPI_BAND AND Bit a BitMPI_LOR OR LógicoMPI_BOR OR Bit a Bit

MPI_LXOR OR Exclusivo LógicoMPI_BXOR OR Exclusivo Bit a Bit

MPI_MAXLOC Máximo y su LocalizaciónMPI_MINLOC Mínimo y su Localización

Cuadro 6.1: Operaciones de Reducción

6.5. Implementación Regla del Trapecio

A continuación exponemos la implementación del algoritmo Regla del Trapecio. Notar quecada proceso llama a MPI_Reduce() con los mismos argumentos; de hecho, aunque la variableque almacena la suma global sólo tiene significado para el proceso 0, todos los procesos debensuministrar 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

7 # include < s t d i o . h>8 # include " mpi . h "9

10 /*DECLARACION ESTRUCTURA DATOS ENTRADA*/11 typedef struct {12 long double a ;13 long double b ;14 long nsegmentos ;15 i n t nfuncion ;16 } Tipo_Datos_Entrada ;17

18 /*DECLARACION DE LA FUNCIONES QUE VAMOS A UTILIZAR*/19 long double Trapecio ( long double l o ca l_a , long double l o ca l_b , long l o ca l_n ,20 long double h , i n t numfuncion ) ;21 long double F1( long double x ) ;22 long double F2( long double x ) ;23 long double F3( long double x ) ;

6.5. IMPLEMENTACIÓN REGLA DEL TRAPECIO 99

24 long double F4( long double x ) ;25 void obtener_datos ( i n t i d , long double L pa , long double L pb ,26 long L pn , i n t L pnumfuncion ) ;27 void d i s t r i b u i r _ d a t o s ( i n t i d , long double L pa , long double L pb ,28 long L pn , i n t L pnumfuncion ) ;29 void reco lec ta r_datos ( i n t i d , i n t numprocs , long double L p p a r c i a l ,30 long double L pcompleta ) ;31 void c o n s t r u i r _ t i po_d e r i v a do ( Tipo_Datos_Entrada L pdatos ,32 MPI_Datatype L pMPI_Tipo_Datos ) ;33

34 /**************/35 /*FUNCION MAIN*/36 /**************/37 i n t main ( i n t argc , char LML argv ) {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

43 i n t i d ; /*IDENTIFICADOR DEL PROCESO*/44 i n t numprocs ; /*NUMERO DE PROCESOS*/45 char nombreproc [MPI_MAX_PROCESSOR_NAME] ;46 /*NOMBRE PROCESADOR*/47 i n t lnombreproc ; /*LONGITUD NOMBRE PROCESADOR*/48 long double h ; /*ANCHO DE CADA SEGMENTO*/49 long double l o ca l_a ; /*COMIENZO DEL SUBINTERVALO DE CADA PROCESO*/50 long double l o ca l_b ; /*FINAL DEL SUBINTERVALO DE CADA PROCESO*/51 long l o ca 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)*/54 double tmp in i c = 0 . 0 ; /*TIEMPO INICIO DE LA EJECUCION*/55 double tmpf in ; /*TIEMPO FINAL DE LA EJECUCION*/56 i n t numfuncion ; /*NUMERO DE FUNCION A UTILIZAR*/57 i n t e t i que ta =50;58 MPI_Status s ta tus ;59 i n t or igen ;60

61

62 /*INICIALIZAMOS EL ENTORNO DE EJECUCION MPI*/63 MPI_In i t (& argc ,& argv ) ;64



71 /*E/S:NOMBRE DEL PROCESADOR,PROCESADOR 0*/72 MPI_Get_processor_name ( nombreproc,& lnombreproc ) ;73 i f ( i d ==0){74 f p r i n t f ( s tdout , " \ nProceso %d en %s Encargado de l a E / S \ n " ,75 i d , nombreproc ) ;76 }77 /*E/S:NOMBRE DEL PROCESADOR,TODOS LOS PROCESOS (PARA PRUEBAS)*/78 /*if(id==0){


79 * for (origen=1;origen<numprocs;origen++){80 * MPI_Recv(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,origen,81 * etiqueta,MPI_COMM_WORLD,&status);82 * fprintf(stdout,"Proceso %d en %s\n",origen,nombreproc);83 * }84 *}85 *else{86 * MPI_Send(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,0,87 * etiqueta,MPI_COMM_WORLD);88 *}89 */90

91 /*OBTENEMOS DATOS INTRODUCIDOS POR EL USUARIO*/92 obtener_datos ( i d ,&a,&b,&n,& numfuncion ) ;93

94 /*TIEMPO INICIAL DE PROCESAMIENTO*/95 i f ( i d ==0){ f p r i n t f ( s tdout , " \ nProcesando . . . \ n \ n " ) ; }96 tmp in i c=MPI_Wtime ( ) ;97

98 /*DISTRIBUIMOS DATOS INTRODUCIDOS POR EL USUARIO*/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*/102 l o ca l_n=n / numprocs ; /*NUMERO DE SEGMENTOS PARA CADA PROCESO*/103 n= loca l_n L numprocs ; /*NUMERO DE SEGMENTOS EN TOTAL (TRUNCADO)*/104 h=(b N a ) / n ; /*ANCHO DE SEGMENTO.SIMILAR PARA TODOS LOS PROCESOS*/105

106 /*EL SUBINTERVALO DEL PROCESO TENDRA UN ANCHO DE local_n*h Y ESTARA107 COMPRENDIDO ENTRE local_a Y local_b*/108 l o ca l_a = a + i d L l o ca l_n L h ;109 l o ca l_b = loca l_a + loca l_n L h ;110

111 /*CALCULAMOS LA INTEGRAL PARCIAL DEL PROCESO*/112 p a r c i a l=Trapecio ( l oca l_a , l oca l_b , l oca l_n , h , numfuncion ) ;113

114 /*RECOLECTAMOS INTEGRALES CALCULADAS POR LOS PROCESOS Y LAS SUMAMOS*/115 reco lec ta r_da tos ( i d , numprocs ,& p a r c i a l ,& completa ) ;116


120 /*E/S:IMPRIMIMOS RESULTADO Y TIEMPO DE PROCESAMIENTO*/121 i f ( i d ==0){122 f p r i n t f ( s tdout , " 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 tdout , " de l a f u n c i o n s e l e c c i o n a d a desde " ) ;124 f p r i n t f ( s tdout , " %Lf h a s t a %Lf es \ n %.60Lf \ n \ n " , a , b , completa ) ;125 f p r i n t f ( s tdout , " Numero P r o c e s o s : %d \ n " , numprocs ) ;126 f p r i n t f ( s tdout , " Tiempo P r o c e s a m i e n t o : %f \ n \ n " , tmpf in N tmp in i c ) ;127 }128


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) */138 /***********************************************************************/139 void obtener_datos ( i n t i d , long double L pa , long double L pb ,140 long L pn , i n t L pnumfuncion ) {141


144 i f ( i d ==0){145 f p r i n t f ( s tdout , " \ 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 tdout , " \ nF1=2x F2=x^2 F3 =1 / x F4 =4 / (1+ x ^ 2 ) \ nF " ) ;147 scanf ( " %d " , pnumfuncion ) ;148 i f ( L pnumfuncion < 1 | | L pnumfuncion >4) {149 f p r i n t f ( s tdout , " 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=2x \ n " ) ;150 L pnumfuncion =1;151 }152 f p r i n t f ( s tdout , " 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 scanf ( " %Lf " , pa ) ;154 f p r i n t f ( s tdout , " 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 scanf ( " %Lf " , pb ) ;156 f p r i n t f ( s tdout , " I n t r o d u z c a numero de segmen tos \ n " ) ;157 scanf ( " %l d " , pn ) ;158 }159

160

161 /*E/S SIN PETICION:UTILIZAR EN CASO DE PRUEBAS*/162 /*if(id==0){*pa=0;*pb=1;*pn=1000000000;*pnumfuncion=4;}*/163


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 */170 /**************************************************************************/171 void d i s t r i b u i r _ d a t o s ( i n t i d , long double L pa , long double L pb ,172 long L pn , i n t L pnumfuncion ) {173

174 MPI_Datatype MPI_Tipo_Datos_Entrada ;175 Tipo_Datos_Entrada datos_entrada ;176 i n t r a i z = 0 ; /*PROCESO QUE ENVIA LOS DATOS A LOS DEMAS PROCESOS*/177

178

179 /*CONSTRUIMOS EL TIPO MPI PARA EMPAQUETAR LOS DATOS DE ENTRADA*/180 c o n s t r u i r _ t i po _de r i v ado(& datos_entrada,& MPI_Tipo_Datos_Entrada ) ;181

182 i f ( i d ==0){183 /*EMPAQUETADO DE DATOS*/184 datos_entrada . a= L pa ;185 datos_entrada . b= L pb ;186 datos_entrada . nsegmentos= L pn ;187 datos_entrada . nfuncion = L pnumfuncion ;188 }


189

190 MPI_Bcast (& datos_entrada , 1 , MPI_Tipo_Datos_Entrada , r a i z ,MPI_COMM_WORLD) ;191

192 i f ( i d ! = 0 ) {193 /*RECOGIDA DE DATOS*/194 L pa=datos_entrada . a ;195 L pb=datos_entrada . b ;196 L pn=datos_entrada . nsegmentos ;197 L pnumfuncion=datos_entrada . nfuncion ;198 }199

200 }/*distribuir_datos*/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 TAMAÑO DE SEGMENTO h */207 /************************************************************************/208 long double Trapecio ( long double l o ca l_a , long double l o ca l_b , long l o ca l_n ,209 long double h , i n t numfuncion ) {210

211 long double ( L 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*/214 i n t i ; /*CONTADOR*/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 oca l_a )+ f ( l oca l_b ) ) / 2 . 0 ;223 x= loca l_a ;224 for ( i =1; i <= loca l_n N 1; i ++){225 x+=h ;226 i n t e g r a l += f ( x ) ;227 }228 i n t e g r a l 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. */237 /*******************************************************************/238 void reco lec ta r_datos ( i n t i d , i n t numprocs , long double L p p a r c i a l ,239 long double L pcompleta ) {240

241 i n t r a i z = 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 va lo r_ re to rno ;254

255 va lo r_ re to rno =2 L x ;256 return va lo r_ re to rno ;257 }258

259

260 /*********************************/261 /*FUNCION F2(x):FUNCION f(x)=x^2 */262 /*********************************/263 long double F2( long double x ) {264 long double va lo r_ re to rno ;265

266 va lo r_ re to rno=x L x ;267 return va lo r_ re to rno ;268 }269

270 /*********************************/271 /*FUNCION F3(x):FUNCION f(x)=1/x */272 /*********************************/273 long double F3( long double x ) {274 long double va lo r_ re to rno ;275

276 va lo r_ re to rno =1/x ;277 return va lo r_ re to rno ;278 }279

280 /***************************************/281 /*FUNCION F4(x):FUNCION f(x)=4/(1+x^2) */282 /***************************************/283 long double F4( long double x ) {284 long double va lo r_ re to rno ;285

286 va lo r_ re to rno =4/(1+x L x ) ;287 return va lo r_ re to rno ;288 }289

290


298 MPI_Datatype t i p o s [ 4 ] ;


299 i n t l ong i t udes [ 4 ] ;300 MPI_Aint d i recc [ 5 ] ;301 MPI_Aint desplaz [ 4 ] ;302

303

304 /*PRIMERO ESPECIFICAMOS LOS TIPOS*/305 t i p o s [ 0 ] =MPI_LONG_DOUBLE;306 t i p o s [ 1 ] =MPI_LONG_DOUBLE;307 t i p o s [ 2 ] =MPI_LONG;308 t i p o s [ 3 ] =MPI_INT ;309

310 /*ESPECIFICAMOS EL NUMERO DE ELEMENTOS DE CADA TIPO*/311 l ong i t udes [ 0 ] = 1 ;312 l ong i t udes [ 1 ] = 1 ;313 l ong i t udes [ 2 ] = 1 ;314 l ong i t udes [ 3 ] = 1 ;315

316 /*CALCULAMOS LOS DESPLAZAMIENTOS DE LOS MIEMBROS DE LA ESTRUCTURA317 RELATIVOS AL COMIENZO DE DICHA ESTRUCTURA*/318 MPI_Address( pdatos ,& d i recc [ 0 ] ) ;319 MPI_Address(&( pdatos N >a ) ,& d i recc [ 1 ] ) ;320 MPI_Address(&( pdatos N >b ) ,& d i recc [ 2 ] ) ;321 MPI_Address(&( pdatos N >nsegmentos) ,& d i recc [ 3 ] ) ;322 MPI_Address(&( pdatos N >nfuncion ) ,& d i recc [ 4 ] ) ;323 desplaz [ 0 ] = d i recc [1] N d i recc [ 0 ] ;324 desplaz [ 1 ] = d i recc [2] N d i recc [ 0 ] ;325 desplaz [ 2 ] = d i recc [3] N d i recc [ 0 ] ;326 desplaz [ 3 ] = d i recc [4] N d i recc [ 0 ] ;327




Capítulo 7

Comunicadores y Topologías

El uso de comunicadores y topologías hace a MPI diferente de la mayoría de los demássistemas de paso de mensajes. En pocas palabras, un comunicador es una colección de proce-sos que pueden mandarse mensajes entre ellos. Una topología es una estructura impuesta enlos procesos de un comunicador que permite a los procesos ser direccionados de diferentesmaneras. Para ilustrar estas ideas desarrollaremos el código que implementa el algoritmo deFox para multiplicar dos matrices cuadradas.

7.1. Algoritmo Multiplicación de Matrices de Fox

Asumimos que las matrices principales�� , � g�� 3 y Y � ,QJ g�� 3 tienen orden � . También

asumimos que el número de procesos C es un cuadrado perfecto, cuya raiz m es tal que elresultado de �'$@m es un entero. Digamos que C � m �

, y que � � �'$@m . En el algoritmo deFox las matrices principales son particionadas en bloques y repartidas entre los procesos. Asívemos nuestros procesos como una tabla virtual de m��Im elementos, donde a cada proceso sele asigna una submatriz �� de cada una de las matrices principales. De manera más formal,tenemos la siguiente correspondencia:��-� DFE:1)EBG G G EHC�/�1@��/�� ,Q=ME��3 � D��~=ME��~m�/~1@�

La siguiente afirmación define nuestra tabla de procesos: el procesok

pertenece a la filay la columna dadas por

� , k 3 . Además diremos que el proceso con dirección

� e ,Q=5E��3 tieneasignadas las submatrices:�� q� 7 � �� 7 �B�B� � o �qp' s � 78e �� 7...

...� �a� 7 � o ��p' s � 7�e �B�B� � o �ap' s � 7�e �� o ��p' s � 7Fe ��c��Y �� J �q� 7 � �� 7 �B�B� J o �qp' s � 7�e �� 7...

...J �a� 7 � o ��p' s � 7�e �B�B� J o �ap' s � 7�e �� o ��p' s � 7�e �c��105

106 CAPÍTULO 7. COMUNICADORES Y TOPOLOGÍAS

Proceso 0 Proceso 1 Proceso 2�� Proceso 3 Proceso 4 Proceso 5�� Proceso 6 Proceso 7 Proceso 8��

Cuadro 7.1: Partición Matriz 6*6 en 9 Procesos

Por ejemplo, si C �¡ ,

� ,.T_3 � ,.T_$)¢�E�T�£�¤�5¥�¢53 y � � 9 entonces la matriz�

estaríaparticionada como se indica en el cuadro 7.1.

En el algoritmo de Fox las submatrices�§¦��

y Y ��, = � DFE:1)EBGBGBG4E�m�/+1 son multiplicadas y

acumuladas por el proceso

� e ,.O@E��3 .Algoritmo básico

Desde paso=0 hasta paso=q-1(aumentar paso en cada iteración):

1. Elegir una submatriz de A de cada una de las filas de procesos. La submatriz elegidaen la fila ¨ será ©«ªq¬ , donde ®°¯± ¨«²�³8´"µ�¶:·¹¸»º¼&½�¾

2. En cada una de las filas de procesos hacer un broadcast de la submatriz elegida hacialos demás procesos en dicha fila.

3. En cada proceso multiplicar la submatriz recibida de A por la matriz de B que resideen dicho proceso, sin modificar ninguna de estas matrices. Sumar el resultado de lamultiplicación 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 enviarán la submatriz a la última fila).

7.2. Comunicadores

Si intentamos implementar el algoritmo de Fox, parece claro que nuestro trabajo se facil-itaría si pudiéramos tratar ciertos subconjuntos de procesos como el universo de la comuni-cación, al menos temporalmente. Por ejemplo, en el pseudocódigo

2. En cada una de las filas de procesos hacer un broadcast de la submatriz elegida hacialos demás procesos en dicha fila.

7.3. TRABAJANDO CON GRUPOS, CONTEXTOS Y COMUNICADORES 107

sería útil tratar cada fila como el universo de la comunicación, 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 enviarán la submatriz a la última fila).

sería útil tratar cada columna de procesos como el universo de la comunicación.El mecanismo que MPI proporciona para tratar a un subconjunto de procesos como el uni-

verso de la comunicación son los comunicadores. Hasta ahora hemos definido al comunicadorcomo una colección de procesos que pueden mandarse mensajes entre ellos. Ahora que quer-emos construir nuestros propios comunicadores necesitaremos una discusión más profunda.

En MPI existen dos tipos de comunicadores: intracomunicadores e intercomunicadores.Los intracomunicadores son esencialmente una colección de procesos que pueden mandarsemensajes entre ellos y utilizar operaciones de comunicación colectivas. Por ejemplo,MPI_COMM_WORLD es un intracomunicador, y queremos formar para cada fila y cadacolumna del algoritmo de Fox otro intracomunicador. Los intercomunicadores, como su pro-pio nombre indica, son utilizados para mandar mensajes entre los procesos pertenecientes aintracomunicadores disjuntos. Por ejemplo, un intercomunicador podría ser útil en un entornoque nos permitiera crear procesos dinámicamente: un nuevo conjunto de procesos que for-men un intracomunicador podría ser enlazado al conjunto de procesos original (por ejemploMPI_COMM_WORLD) mediante un intercomunicador. Nosotros sólo utilizaremos intraco-municadores.

Un intracomunicador mínimo está compuesto de:� Un Grupo, y� Un Contexto.

Un grupo es una colección ordenada de procesos. Si un grupo consiste en C procesos, a cadaproceso en el grupo se le asigna un único identificador, que no es más que un entero no negativoen el rango DFE:1)EBGBGBG@EHC�/¿1 . Un contexto puede ser entendido como una etiqueta definida porel sistema que es atribuida al grupo. De este modo dos procesos que pertenecen al mismogrupo y usan el mismo contexto pueden comunicarse. Esta paridad grupo-contexto es la formamás básica de comunicador. Otros datos pueden ser asociados al comunicador. En particular,se le puede asociar una estructura o topología al comunicador, permitiendo un esquema dedireccionamiento de los procesos más natural. Abordaremos las topologías en la sección 7.5.

7.3. Trabajando con Grupos, Contextos y Comunicadores

Para ilustrar las bases del uso de los comunicadores, vamos a crear un comunicador cuyogrupo consiste en los procesos de la primera fila de nuestra tabla virtual. Supongamos queMPI_COMM_WORLD contiene C procesos, donde m � � C . Supongamos también que

� ,.T\3 �,.T_$@m8E�TÀ£�¤�5¥�m53 . Así la primera fila de procesos consistirá en los procesos cuyo identificadores DFE:1)EBGBGBG&E�m§/�1 (aquí los identificadores pertenecen a MPI_COMM_WORLD). Para crearel grupo de nuestro nuevo comunicador podemos ejecutar el siguiente código:


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 código construye de una manera muy estricta el nuevo comunicador. Primero crea unalista de los procesos que deberán ser asignados al nuevo comunicador. Luego crea un grupocon dichos procesos. Ésto requiere dos llamadas; primero se obtiene el grupo asociado aMPI_COMM_WORLD, dado que éste es el grupo del cual se extraen los procesos parael 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 implícitamente un contexto al nuevo grupo. El resultado es el comunicadorcom_primera_fila. Ahora los procesos pertenecientes a com_primera_fila pueden ejecutaroperaciones de comunicación colectivas. Por ejemplo, el proceso 0 (en grupo_primera_fila)puede hacer un broadcast de su matriz

��a los otros procesos del grupo grupo_primera_fila:

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 práctico éstosignifica que los detalles de su representación interna dependen de la implementación MPIparticular, y como consecuencia el usuario no puede acceder directamente a ellos. En vezde esto el usuario accede a un manejador que referencia al objeto opaco, de manera quedichos objetos opacos son manipulados por funciones MPI especiales, como por ejemploMPI_Comm_create(), MPI_Group_incl() y MPI_Comm_group().

Los contextos no son explícitamente usados en ninguna función MPI. En vez de ello, sonimplícitamente asociados a los grupos cuando los comunicadores son creados.

La sintaxis de los comandos que hemos usado para crear com_primera_fila es bastantesencilla. 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 número de procesos en el nuevo grupo es tamano_nuevo_grupo, y los pro-cesos que serán incluidos son listados en ids_antiguo_grupo. El proceso 0 en nuevo_grupotiene el identificador ids_antiguo_grupo[0] en antiguo_grupo, el proceso 1 en nuevo_grupoes 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 quieredecir que no hay comunicación entre los procesos implicados en dicha ejecuciòn. Sin embar-go MPI_Comm_create() es una operación colectiva. Todos los procesos en antiguo_grupodeben llamar a MPI_Comm_create() con los mismos argumentos. El estándar MPI da tresrazones para ello:� Permite a la implementación colocar a MPI_Comm_create() como la primera de las

comunicaciones colectivas regulares.

110 CAPÍTULO 7. COMUNICADORES Y TOPOLOGÍAS� Proporciona mayor seguridad.� Permite que las implementaciones eviten comunicaciones relativas a la creación delcontexto.

Notemos que como MPI_Comm_create() es colectiva tendrá un comportamiento sincronizador.En particular, si varios comunicadores están 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 multiplicación de matrices necesitamos crear múltiples comuni-cadores (uno para cada fila de procesos y uno para cada columna). Éste podría ser un procesoextremadamente tedioso si C fuera grande y tuviéramos que crear cada comunicador usandolas tres funciones comentadas en la sección anterior. Afortunadamente MPI proporciona unafunción, MPI_Comm_split(), que puede crear varios comunicadores simultáneamente. Paraejemplificar 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 elmismo nombre com_fila. Por ejemplo, si C �Á

el grupo com_fila consistirá en los procesos0, 1 y 2 para los procesos 0, 1 y 2. En los procesos 3, 4 y 5 el grupo subyacente a nuevo_comserá 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 elmismo valor en clave_particion forman un nuevo grupo. El identificador de los procesos enel nuevo grupo estará determinado por su valor en clave_id. Si los procesos

�y Y llaman

ambos a la función 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 . Sillaman a la función con el mismo valor en clave_id el sistema asignará arbitrariamente a unode los procesos un identificador menor.

7.5. TOPOLOGÍAS 111

MPI_Comm_split() es una operación colectiva y debe ser llamada por todos los procesospertenecientes a antiguo_com. La función puede ser utilizada incluso si no deseamos asig-narle un comunicador a todos los procesos. Ésto puede ser realizado pasando la constantepredefinida MPI_UNDEFINED en el argumento clave_particion. Los procesos que haganésto obtendrán como valor de retorno en nuevo_com el valor MPI_COMM_NULL.

7.5. Topologías

Recordemos que es posible asociar información adicional (más allá del grupo y del con-texto) a un comunicador. Una de las piezas de información más importantes que se puedenadjuntar al comunicador es la topología. En MPI una topología no es más que un mecanis-mo para asociar diferentes esquemas de direccionamiento a los procesos pertenecientes a ungrupo. Notar que las topologías en MPI son topologías virtuales, lo que quiere decir que po-dría no haber una relación simple entre la estructura de procesos de una topología virtual y laestructura física real de la máquina paralela.

Esencialmente existen dos tipos de topologías virtuales que se pueden crear en MPI: latopología cartesiana o rejilla, y la topología gráfica. Conceptualmente ésta última engloba ala primera. De todos modos, y debido a la importancia de las rejillas en las aplicaciones, existeuna colección separada de funciones en MPI cuyo propósito es la manipulación de rejillasvirtuales.

En el algoritmo de Fox queremos identificar los procesos en MPI_COMM_WORLDmediante las coordenadas de una rejilla, y cada fila y cada columna de la rejilla necesita formarsu propio comunicador. Observemos un método para construir dicha estructura.

Comenzamos asociando una estructura de rejilla a MPI_COMM_WORLD. Para haceresto necesitamos especificar la siguiente información:

1. El número de dimensiones de la rejilla. Tenemos 2.

2. El tamaño de cada dimensión. En nuestro caso, no es más que el número de filas y elnúmero de columnas. Tenemos m filas y m columnas.

3. La periodicidad de cada dimensión. En nuestro caso esta información especifica si laprimera entrada de cada fila o columna es “adyacente” a la última entrada de dichafila o columna, respectivamente. Dado que nosotros queremos un paso “circular” de lasmatrices en cada columna, sería provechoso que la segunda dimensión fuera periódica.No es importante si la primera dimensión es periódica 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 alcomunicador asociado, para así aprovechar mejor la estructura física de dichos procesos.Dado que no necesitamos preservar el orden de los procesos en MPI_COMM_WORLD,deberíamos permitir al sistema el reordenamiento.

Para implementar estas decisiones simplemente ejecutaremos el siguiente código:

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 código el comunicador com_rejilla contendrá los procesos pertenecientesa MPI_COMM_WORLD (posiblemente reordenados) y tendrá asociado un sistema de co-ordenadas cartesianas de dos dimensiones. Para determinar las coordenadas de un procesosimplemente llamaremos a la función 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 delproceso 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 unproceso 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 procesoen su tercer parámetro 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 topologíacartesiana a antiguo_com. La información sobre la estructura de la topología cartesiana estácontenida en los parámetros numero_dimensiones, tam_dimensiones y periodicidades. Elprimero de ellos, numero_dimensiones, contiene el número de dimensiones que forman el sis-tema de coordenadas cartesianas. Los dos siguientes, tam_dimensiones y periodicidades, son

7.6. DIVISIÓN DE REJILLAS 113

3 4 50 1 26 7 8

Cuadro 7.2: Topología Física 3*3

vectores que tienen el mismo orden que numero_dimensiones. El vector tam_dimensionesespecifica el orden de cada dimensión, mientras que el vector periodicidades especifica paracada dimensión si es circular o linear.

Los procesos pertenecientes a com_cartesiano son ordenados de fila en fila. De este modola primera fila contiene los procesos DFE:1)EBGBGBG&E z�u £ _ ¥%Âi£ÄÃ {ÆÅ Â � { Ã Å b D@d�/¿1 , la segunda fila con-tendrá

z�u £ _ ¥%Â�£ÄÃ {%Å Â � { Ã Å b D@d�E z�u £ _ ¥%Âi£�Ã {%Å Â � { Ã Å b D@d W 1)EBGBGBG&Ec('* z�u £ _ ¥%Â�£ÄÃ {%Å Â � { Ã Å b D@d4/�1 , y asísucesivamente. En este sentido podría ser ventajoso cambiar el orden relativo de los procesosen com_antiguo. Por ejemplo, supongamos que la topología física es una tabla ¢�*X¢ y que losprocesos pertenecientes com_antiguo, representados por sus identificadores, están asociadosa los procesadores como se expone en el cuadro 7.2.

Claramente la eficiencia del algoritmo de Fox se mejoraría si reordenáramos los procesos.Sin embargo, y dado que el usuario no conoce cómo se asocian los procesos a los procesadores,deberíamos dejar al sistema hacerlo estableciendo el parámetro reordenamiento a 1.

Dado que MPI_Cart_create() construye un nuevo comunicador, se trata de una operacióncolectiva.

La sintaxis de las funciones que nos informan sobre el direccionamiento de los procesoses:

int MPI_Cart_rank(MPI_Comm cart_com, int* coordenadas,int* id)

int MPI_Cart_coords(MPI_Comm cart_com, int id,int numero_dimensiones,int* coordenadas)

La función MPI_Cart_rank() retorna el identificador en cart_com del proceso que tiene lascoordenadas cartesianas representadas en el vector coordenadas. Así, coordenadas es un vec-tor de orden igual al número de dimensiones de la topología cartesiana asociada a cart_com.MPI_Cart_coords() es la inversa a MPI_Cart_rank(): retorna las coordenadas del procesoque tiene como identificador id en el comunicador cartesiano cart_com. Notar que ambasfunciones son locales.

7.6. División de Rejillas

También 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 esun vector de booleanos. Especifica para cada dimensión si “pertenece” al nuevo comunicador.Dado que estamos creando comunicadores para las filas de la rejilla, cada nuevo comunicadorconsiste en los procesos obtenidos al fijar la coordenada de la fila, permitiendo que la coor-denada de la columna varíe. Con este propósito le asignamos a var_coords[0] el valor 0 (laprimera coordenada no varía) y le asignamos a var_coords[1] el valor 1 (la segunda coor-denada varía). En cada proceso retornamos el nuevo comunicador en com_fila. Si queremoscrear comunicadores para las columnas, simplemente invertimos los valores en los elementosde 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 colección de nuevos comunicadores).Sin embargo MPI_Cart_sub() sólo puede ser usada en comunicadores que tengan asociadauna topología cartesiana, y el nuevo comunicador sólo puede ser creado fijando (o variando)una o más dimensiones del antiguo comunicador. Notar también que MPI_Cart_sub() es,como MPI_Comm_split(), una operación colectiva.

7.7. Implementación Multiplicación de Matrices de Fox

En esta sección mostramos la implementación del algoritmo de Fox. En este programa lafunción Config_cart() genera varios comunicadores e información asociada a ellos. Debidoa que este procedimiento requiere muchas variables, y dado que la información contenida endichas variables es necesaria en la ejecución de otras funciones, utilizaremos una estructuratipo Info_Cart para agrupar toda esa información generada. Luego realizaremos la multipli-cación de matrices por el método de Fox mediante la llamada a la función Fox(); dicha funciónse apoya en otra, Mult_Matrices(), creada para ejecutar la indispensable multiplicación dematrices locales.

Algoritmo 7.1: Multiplicación de Matrices de Fox

1

2 /********************************************************************/3 /*Fox:CODIGO MULTIPLICACION DE MATRICES MEDIANTE EL ALGORITMO DE FOX*/4 /********************************************************************/5

7.7. IMPLEMENTACIÓN MULTIPLICACIÓN DE MATRICES DE FOX 115

6 /*TAMAÑO MAXIMO DE LA MATRIZ DE CADA PROCESO*/7 # define MAX_ORDEN_LOCAL 7008

9 # include < s t d i o . h>10 # include < s t d l i b . h>11 # include < math . h>12 # include " mpi . h "13

14 /*ESTRUCTURA QUE CONTIENE PARA CADA PROCESO LA INFORMACION RELEVANTE15 A LA TOPOLOGIA CARTESIANA QUE COMPONEMOS*/16 typedef struct {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 i n t f i l a ; /*NUMERO DE FILA*/23 i n t columna ; /*NUMERO DE COLUMNA*/24 i n t i d ; /*IDENTIFICADOR DENTRO DE LA TOPOLOGIA CREADA*/25 } I n f o _ c a r t ;26

27 /*TIPO MATRIZ DE CADA PROCESO*/28 typedef i n t Matr izLoca 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 Tipo_envio_matr iz ;32

33 /*DECLARACION DE LAS FUNCIONES UTILIZADAS*/34 i n t Conf ig_car t ( I n f o _ c a r t L pca r t ) ;35 void obtener_datos ( i n t minimo , i n t maximo , i n t L orden_global ) ;36 void d i s t r i b u i r _ d a t o s ( i n t L 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 ( Mat r i zLoca l loca lA ,38 Matr izLoca l loca lB ,39 Matr izLoca l loca lC ,40 i n t orden_ loca l ,41 i n t i d ) ;42 void Fox ( I n f o _ c a r t L pca r t ,43 Matr izLoca l mat r i z1 ,44 Matr izLoca l mat r i z2 ,45 Matr izLoca l r e s u l t ,46 i n t orden_ loca l ) ;47 i n t impresion_matr ices ( i n t i d , i n t numprocs ,48 Matr izLoca l mat r i z1 ,49 Matr izLoca l mat r i z2 ,50 Matr izLoca l r e s u l t ,51 i n t tamano ,52 i n t f i l a ,53 i n t columna ) ;54 void mult_matr ices ( Mat r i zLoca l mat r i z1 ,55 Matr izLoca l mat r i z2 ,56 Matr izLoca l r e s u l t ,57 i n t orden_ loca l ) ;58 void imp_matr iz ( Mat r i zLoca l mat r i z , i n t orden_ loca l , FILE L 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 */65 /*********************************************************************/66 i n t main ( i n t argc , char L8L argv ) {67 I n f o _ c a r t t op_ca r t ; /*ESTRUCTURA CON INFO SOBRE LA TOP.CARTESIANA*/68 Matr izLoca l L l oca lA ; /*MATRIZ LOCAL*/69 Matr izLoca l L l oca lB ; /*MATRIZ LOCAL*/70 Matr izLoca l L l oca lC ; /*MATRIZ LOCAL (SOLUCION)*/71 i n t orden_ loca l ; /*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*/78 char nombreproc [MPI_MAX_PROCESSOR_NAME] ;79 /*NOMBRE PROCESADOR*/80 i n t lnombreproc ; /*LONGITUD NOMBRE PROCESADOR*/81 double tmp in i c = 0 . 0 ; /*TIEMPO INICIO DE LA EJECUCION*/82 double tmpf in ; /*TIEMPO FINAL DE LA EJECUCION*/83 i n t e t i que ta =50; /*ETIQUETA MENSAJES DE PRUEBA*/84 MPI_Status s ta tus ; /*STATUS MENSAJES DE PRUEBA*/85 i n t or igen ; /*ORIGEN MENSAJES DE PRUEBA*/86

87

88

89 /*INICIALIZAMOS EL ENTORNO DE EJECUCION MPI*/90 MPI_In i t (& argc ,& argv ) ;91

92 /*ALMACENAMOS EL IDENTIFICADOR DEL PROCESO EN MPI_COMM_WORLD*/93 MPI_Comm_rank (MPI_COMM_WORLD,& id_comm_world ) ;94

95 /*ALMACENAMOS EL NUMERO DE PROCESOS*/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 tdout , " \ 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 ( s tdout , " debe t e n e r r a i z e n t e r a \ n \ n " ) ;104 }105 MPI_Final ize ( ) ;106 return 0 ;107 }108

109 /*E/S:NOMBRE DEL PROCESADOR,PROCESADOR 0*/110 MPI_Get_processor_name ( nombreproc,& lnombreproc ) ;111 i f ( id_comm_world ==0){112 f p r i n t f ( s tdout , " \ nProceso %d (MPI_COMM_WORLD) en %s " ,113 id_comm_world , nombreproc ) ;114 f p r i n t f ( s tdout , " Encargado de l a E / S \ n " ) ;115 }


116 /*E/S:NOMBRE DEL PROCESADOR,TODOS LOS PROCESOS (PRUEBAS)*/117 /*if(id_comm_world==0){118 * for (origen=1;origen<numprocs_comm_world;origen++){119 * MPI_Recv(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,origen,120 * etiqueta,MPI_COMM_WORLD,&status);121 * fprintf(stdout,"PROC %d (MPI_COMM_WORLD) en %s\n",122 * origen,nombreproc);123 * }124 *}125 *else{126 * MPI_Send(nombreproc,MPI_MAX_PROCESSOR_NAME,MPI_CHAR,0,127 * etiqueta,MPI_COMM_WORLD);128 *}129 *130 */131

132 /*RESERVAMOS ESPACIO PARA MATRICES LOCALES*/133 l oca lA =( Mat r i zLoca l L ) mal loc ( sizeof ( Mat r i zLoca l ) ) ;134 l oca lB =( Mat r i zLoca l L ) mal loc ( sizeof ( Mat r i zLoca l ) ) ;135 l oca lC =( Mat r i zLoca l L ) mal loc ( sizeof ( Mat r i zLoca l ) ) ;136

137 /*OBTENEMOS DATOS INTRODUCIDOS POR EL USUARIO*/138 i f ( id_comm_world ==0){139 minimo=raiz_numprocs ; /*MINIMO ORDEN GLOBAL*/140 maximo=raiz_numprocs L MAX_ORDEN_LOCAL; /*MAXIMO ORDEN GLOBAL*/141 obtener_datos ( minimo , maximo,& orden_global ) ; /*OBTENEMOS DATOS DEL USUARIO*/142 orden_ loca l=orden_global / raiz_numprocs ; /*CALCULAMOS ORDEN MATRIZ LOCAL*/143 orden_global=orden_ loca l L raiz_numprocs ; /*TRUNCAMOS ORDEN MATRIZ GLOBAL*/144 }145

146 /*TIEMPO INICIAL DE PROCESAMIENTO*/147 i f ( id_comm_world ==0){148 f p r i n t f ( s tdout , " \ n U t i l i z a n d o %d m a t r i c e s de orden %d cada una . \ n " ,149 numprocs_comm_world , o rden_ loca l ) ;150 f p r i n t f ( s tdout , " Orden M a t r i z Globa l : %d \ n " , orden_global ) ;151 f p r i n t f ( s tdout , " Procesando . . . \ n \ n " ) ;152 }153 tmp in i c=MPI_Wtime ( ) ;154

155 /*DISTRIBUIMOS DATOS INTRODUCIDOS POR EL USUARIO*/156 d i s t r i b u i r _ d a t o s (& orden_ loca l ) ;157

158 /*INICIALIZACION MATRICES*/159 i n i c i a l i z a c i o n _ m a t r i c e s ( L l oca lA , L l oca lB , L l oca lC , orden_ loca 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 rden_ loca l , o rden_ loca l ,MAX_ORDEN_LOCAL, MPI_INT ,166 &Tipo_envio_matr iz ) ;167 MPI_Type_commit(& Tipo_envio_matr iz ) ;168

169 /*CREACION Y CONFIGURACION DE LA TOPOLOGIA CARTESIANA170 SI LA SALIDA DE Config_cart ES ERRONEA,FINALIZAMOS EL PROCESO*/


171 i f ( Conf ig_car t (& top_ca r t ) ) {172 MPI_Final ize ( ) ;173 return 0 ;174 }175

176 /*LLAMADA MULTIPLICACION DE MATRICES MEDIANTE EL ALGORITMO DE FOX*/177 Fox(& top_ca r t , L l oca lA , L l oca lB , L l oca lC , orden_ loca l ) ;178

179 /*--------------------------------------------------------------------*/180

181

182

183 /*IMPRIMIMOS RESULTADO.UTILIZAMOS FILA Y COLUMNA DE LA TOP.CARTESIANA*/184 impresion_matr ices ( id_comm_world , numprocs_comm_world ,185 L l oca lA , L l oca lB , L l oca lC , orden_ loca l ,186 t op_ca r t . f i l a , t op_ca r t . columna ) ;187

188 /*IMPRIMIMOS TIEMPO FINAL DE PROCESAMIENTO*/189 tmpf in =MPI_Wtime ( ) ;190 i f ( id_comm_world ==0){191 f p r i n t f ( s tdout , " \ nNumero P r o c e s o s : %d \ n " , numprocs_comm_world ) ;192 f p r i n t f ( s tdout , " Tiempo P r o c e s a m i e n t o : %f \ n \ n " , tmpf in N tmp in i c ) ;193 }194

195 /*FINALIZAMOS EL ENTORNO DE EJECUCION MPI*/196 MPI_Final ize ( ) ;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 */205 /*************************************************************/206 void obtener_datos ( i n t minimo , i n t maximo , i n t L orden_global ) {207

208 i n t ok = 0 ; /*SEMAFORO PETICION DATOS*/209


212 while ( ok==0){213 f p r i n t f ( s tdout , " I n t r o d u z c a orden 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 tdout , " ( minimo= %d , maximo= %d ) \ n " , minimo , maximo ) ;215 scanf ( " %d " , orden_global ) ;216 i f ( minimo<=( L orden_global ) & & ( L orden_global )<=maximo ) { ok =1 ; }217 else { f p r i n t f ( s tdout , " Orden e r r o n e o . \ n " ) ; }218 }219

220

221 /*E/S SIN PETICION:UTILIZAR EN CASO DE PRUEBAS*/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 */229 /*********************************************************************/230 void d i s t r i b u i r _ d a t o s ( i n t L orden_ loca l ) {231

232 MPI_Bcast ( o rden_ loca 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 ( Mat r i zLoca l loca lA ,241 Matr izLoca l loca lB ,242 Matr izLoca l loca lC ,243 i n t orden_ loca l ,244 i n t i d ) {245

246 i n t i , j ; /*CONTADORES*/247


251 for ( i =0; i <orden_ loca l ; i ++){252 for ( j =0; j <orden_ loca l ; j ++){253 /*MATRICES LOCALES,ELEMENTOS PSEUDOALEATORIOS*/254 l oca lA [ i ] [ j ] = ( i n t ) (100.0 L rand ( ) / (RAND_MAX) ) ;255 l oca lB [ i ] [ j ] = ( i n t ) (100.0 L rand ( ) / (RAND_MAX) ) ;256 /*RESULTADO,ELEMENTOS=0*/257 l oca lC [ 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 */266 /************************************************************************/267 i n t Conf ig_car t ( I n f o _ c a r t L pca r t ) {268 i n t ant igua_ id ; /*ID DENTRO DEL COMUNICADOR INICIAL MPI_COMM_WORLD*/269 i n t dims [ 2 ] ; /*VECTOR QUE CONTIENE LA EXTENSION DE CADA DIMENSION*/270 i n t per iods [ 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

274 /*ALMACENAMOS EL NUM DE PROCESOS PERTENECIENTES A MPI_COMM_WORLD*/275 MPI_Comm_size (MPI_COMM_WORLD,&( pca r t N >numprocs ) ) ;276 /*IDENTIFICADOR DE CADA PROCESO DENTRO DE MPI_COMM_WORLD*/277 MPI_Comm_rank (MPI_COMM_WORLD,& ant igua_ id ) ;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 pca r t N >orden_cart =( i n t ) s q r t ( pca r t N >numprocs ) ;282

283 /*PREPARAMOS LA CREACION DE LA TOPOLOGIA CARTESIANA.DEFINIMOS LA EXTENSION284 Y PERIODICIDAD DE CADA UNA DE LAS DIMENSIONES,MEDIANTE SENDOS VECTORES*/285 dims [ 0 ] = dims [ 1 ] = pca r t N >orden_cart ;286 per iods [ 0 ] = per iods [ 1 ] = 1 ;287 /*CREACION DE LA TOPOLOGIA CARTESIANA.LA ALMACENAMOS EN pcart->comm_global*/288 MPI_Cart_create (MPI_COMM_WORLD, 2 , dims , per iods , 1 , & ( pca r t N >comm_global ) ) ;289

290 /*SI DICHO PROCESO NO ENCAJA EN LA TOPOLOGIA CARTESIANA,SALIDA ERRONEA*/291 i f ( ! pca r t N >comm_global ) return 1 ;292

293 /*IDENTIFICADOR DE CADA PROCESO DENTRO DE LA TOPOLOGIA CARTESIANA*/294 MPI_Comm_rank ( pca r t N >comm_global ,& ( pca r t N >i d ) ) ;295

296 /*COORDENADAS ASOCIADAS AL PROCESO,SU FILA Y COLUMNA*/297 MPI_Cart_coords ( pca r t N >comm_global , pca r t N >i d , 2 , coords ) ;298 pca r t N > f i l a =coords [ 0 ] ;299 pca r t N >columna=coords [ 1 ] ;300

301 /*CREAMOS UN COMUNICADOR ENTRE LOS PROCESOS DE LA MISMA FILA*/302 var_coords [ 0 ] = 0 ; var_coords [ 1 ] = 1 ;303 MPI_Cart_sub( pca r t N >comm_global , var_coords ,& ( pca r t N >comm_fila ) ) ;304 /*CREAMOS UN COMUNICADOR ENTRE LOS PROCESOS DE LA MISMA COLUMNA*/305 var_coords [ 0 ] = 1 ; var_coords [ 1 ] = 0 ;306 MPI_Cart_sub( pca r t N >comm_global , var_coords ,& ( pca r t N >comm_columna ) ) ;307

308 return 0 ;309

310 }/*Config_cart*/311

312

313 /**************************************************************************/314 /*FUNCION Fox:MULTIPLICACION DE MATRICES MEDIANTE EL ALGORITMO DE FOX */315 /**************************************************************************/316 void Fox ( I n f o _ c a r t L pca r t ,317 Matr izLoca l mat r i z1 ,318 Matr izLoca l mat r i z2 ,319 Matr izLoca l r e s u l t ,320 i n t orden_ loca l ) {321

322 i n t i ; /*CONTADOR*/323 i n t bcas t_ ra i z ; /*PROCESO ORIGEN QUE ENVIA MATRIZ LOCAL 1 HACIA324 LOS PROCESOS DE LA MISMA FILA*/325 i n t or igen , des t ino ; /*ORIGEN Y DESTINO DE MATRIZ LOCAL 2 ENTRE326 LOS PROCESOS DE LA MISMA COLUMNA*/327 i n t e t i que ta =50; /*ETIQUETA*/328 MPI_Status s ta tus ; /*STATUS RECEPCION*/329 Matr izLoca l L temp1 ; /*VBLE DONDE ALMACENAMOS LA MATRIZ330 ENVIADA POR bcast_raiz*/331

332

333 /*RESERVAMOS ESPACIO PARA MATRIZ LOCAL*/334 temp1=( Mat r i zLoca l L ) mal loc ( sizeof ( Mat r i zLoca l ) ) ;335


336 /*ESTABLECEMOS EL NUMERO DE FILA DE LOS PROCESOS ORIGEN Y DESTINO337 DE LA MATRIZ LOCAL 2*/338 or igen =( pca r t N > f i l a + 1 ) % pca r t N >orden_cart ;339 dest ino =( pca r t N > f i l a + pca r t N >orden_cart N 1) % pca r t N >orden_cart ;340

341 /*MIENTRAS QUEDEN PROCESOS EN LA FILA...*/342 for ( i =0; i <( pca r t N >orden_cart ) ; i ++){343 /*SE ELIGE EL PROCESO RAIZ*/344 bcas t_ ra i z =( pca r t N > f i l a + i ) %( pca r t N >orden_cart ) ;345 /*SI ES EL TURNO DEL PROPIO PROCESO EN EJECUCION,SE ENVIA MATRIZ LOCAL 1346 HACIA LOS PROCESOS DE LA MISMA FILA Y SE MULTIPLICA LOCALMENTE*/347 i f ( bcas t_ ra i z == pca r t N >columna ) {348 MPI_Bcast ( mat r i z1 , 1 , Tipo_envio_matr iz , bcas t_ ra i z , pca r t N >comm_fila ) ;349 mult_matr ices ( mat r i z1 , mat r i z2 , r e s u l t , o rden_ loca l ) ;350 }351 /*SI NO TOCA EL TURNO,SE RECIBE LA MATRIZ Y SE MULTIPLICA LOCALMENTE*/352 else {353 MPI_Bcast ( temp1 , 1 , Tipo_envio_matr iz , bcas t_ ra i z , pca r t N >comm_fila ) ;354 mult_matr ices ( L temp1 , mat r i z2 , r e s u l t , o rden_ loca l ) ;355 }356

357 /*POR ULTIMO SE ENVIA HACIA ARRIBA EN LA COLUMNA LA MATRIZ LOCAL 2*/358 MPI_Sendrecv_replace( mat r i z2 , 1 , Tipo_envio_matr iz ,359 dest ino , e t i que ta ,360 or igen , e t i que ta ,361 pca r t N >comm_columna,& s ta tus ) ;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 impresion_matr ices ( i n t i d , i n t numprocs ,372 Matr izLoca l matr izA ,373 Matr izLoca l matr izB ,374 Matr izLoca l mat r i zResu l t ,375 i n t orden_ loca l ,376 i n t f i l a ,377 i n t columna ) {378

379 i n t B u f f e r F i l a ; /*BUFFER RECEPCION FILA*/380 i n t BufferColumna ; /*BUFFER RECEPCION COLUMNA*/381 Matr izLoca l L Buf fe rMa t r i z ; /*BUFFER RECEPCION MATRIZ*/382 i n t or igen ; /*ORIGEN DE LOS DATOS*/383 MPI_Request requests [ 5 ] ; /*VECTOR DE PETICIONES*/384 MPI_Status s ta tus [ 5 ] ; /*VECTOR DE STATUS*/385 i n t e t i que ta =10; /*ETIQUETA DE LOS MENSAJES*/386 FILE L s a l i d a ; /*FICHERO SALIDA*/387

388

389 /*RESERVAMOS ESPACIO PARA MATRIZ LOCAL*/390 Buf fe rMa t r i z =( Mat r i zLoca l L ) mal loc ( sizeof ( Mat r i zLoca l ) ) ;


391

392 i f ( i d ==0){393 /*APERTURA FICHERO SALIDA*/394 /*UTILIZAR PREFERIBLEMENTE UN FICHERO LOCAL (EN LINUX395 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 tdout , " 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 : Coordenadas( %d, %d ) . M a t r i z A\ n " , i d ,405 f i l a , columna ) ;406 imp_matr iz ( matr izA , orden_ loca l , s a l i d a ) ;407 f p r i n t f ( s a l i d a , "PROC%d : Coordenadas( %d, %d ) . M a t r i z B\ n " , i d ,408 f i l a , columna ) ;409 imp_matr iz ( matr izB , orden_ loca l , s a l i d a ) ;410 f p r i n t f ( s a l i d a , "PROC%d : Coordenadas( %d, %d ) . M a t r i z R e s u l t a d o \ n " , i d ,411 f i l a , columna ) ;412 imp_matr iz ( mat r i zResu l t , o rden_ loca l , s a l i d a ) ;413 /*IMPRESION OTRAS MATRICES*/414 for ( o r igen =1; or igen<numprocs ; or igen ++){415 /*MATRIZ A*/416 MPI_Irecv(& B u f f e r F i l a , 1 , MPI_INT , or igen , e t i que ta L or igen +1,417 MPI_COMM_WORLD,& requests [ 0 ] ) ;418 MPI_Irecv(& BufferColumna , 1 , MPI_INT , or igen , e t i que ta L or igen +2,419 MPI_COMM_WORLD,& requests [ 1 ] ) ;420 MPI_Irecv ( Bu f fe rMa t r i z , 1 , Tipo_envio_matr iz , o r igen , e t i que ta L or igen +3,421 MPI_COMM_WORLD,& requests [ 2 ] ) ;422 MPI_Waita l l ( 3 , requests , s ta tus ) ;423 f p r i n t f ( s a l i d a , "PROC%d : Coordenadas( %d, %d ) . M a t r i z A\ n " , o r igen ,424 B u f f e r F i l a , BufferColumna ) ;425 imp_matr iz ( L Buf fe rMa t r i z , o rden_ loca l , s a l i d a ) ;426 /*MATRIZ B*/427 MPI_Irecv ( Bu f fe rMa t r i z , 1 , Tipo_envio_matr iz , o r igen , e t i que ta L or igen +4,428 MPI_COMM_WORLD,& requests [ 0 ] ) ;429 MPI_Wait(& requests [ 0 ] , & s ta tus [ 0 ] ) ;430 f p r i n t f ( s a l i d a , "PROC%d : Coordenadas( %d, %d ) . M a t r i z B \ n " , o r igen ,431 B u f f e r F i l a , BufferColumna ) ;432 imp_matr iz ( L Buf fe rMa t r i z , o rden_ loca l , s a l i d a ) ;433 /*MATRIZ Result*/434 MPI_Irecv ( Bu f fe rMa t r i z , 1 , Tipo_envio_matr iz , o r igen , e t i que ta L or igen +5,435 MPI_COMM_WORLD,& requests [ 0 ] ) ;436 MPI_Wait(& requests [ 0 ] , & s ta tus [ 0 ] ) ;437 f p r i n t f ( s a l i d a , "PROC%d : Coordenadas( %d, %d ) . M a t r i z R e s u l t \ n " , o r igen ,438 B u f f e r F i l a , BufferColumna ) ;439 imp_matr iz ( L Buf fe rMa t r i z , o rden_ loca l , s a l i d a ) ;440 }441 /*CIERRE FICHERO SALIDA*/442 f c l o s e ( s a l i d a ) ;443 }444 else {445 /*ENVIO DE DATOS*/


446 MPI_Isend(& f i l a , 1 , MPI_INT , 0 , e t i que ta L i d +1,447 MPI_COMM_WORLD,& requests [ 0 ] ) ;448 MPI_Isend(&columna , 1 , MPI_INT , 0 , e t i que ta L i d +2,449 MPI_COMM_WORLD,& requests [ 1 ] ) ;450 MPI_Isend ( matr izA , 1 , Tipo_envio_matr iz , 0 , e t i que ta L i d +3,451 MPI_COMM_WORLD,& requests [ 2 ] ) ;452 MPI_Isend ( matr izB , 1 , Tipo_envio_matr iz , 0 , e t i que ta L i d +4,453 MPI_COMM_WORLD,& requests [ 2 ] ) ;454 MPI_Isend ( mat r i zResu l t , 1 , T ipo_envio_matr iz , 0 , e t i que ta L i d +5,455 MPI_COMM_WORLD,& requests [ 2 ] ) ;456 }457

458 }/*impresion_matrices*/459

460

461 /**************************************************************/462 /*FUNCION mult_matrices:MULTIPLICACION DE MATRICES LOCALMENTE */463 /**************************************************************/464 void mult_matr ices ( Mat r i zLoca l mat r i z1 ,465 Matr izLoca l mat r i z2 ,466 Matr izLoca l r e s u l t ,467 i n t orden_ loca l ) {468

469 i n t i , j , k ; /*CONTADORES*/470

471 for ( i =0; i <orden_ loca l ; i ++){472 for ( j =0; j <orden_ loca l ; j ++){473 /*CALCULAMOS EL ELEMENTO i,j DE LA MATRIZ result*/474 for ( k =0;k<orden_ loca l ; k ++){475 ( r e s u l t ) [ i ] [ j ] + = ( mat r i z1 ) [ i ] [ k ] L ( mat r i z2 ) [ k ] [ j ] ;476 }477 }478 }479

480 }/*Mult_Matrices*/481

482

483 /*********************************************/484 /*FUNCION imp_matriz:IMPRESION DE UNA MATRIZ */485 /*********************************************/486 void imp_matr iz ( Mat r i zLoca l mat r i z , i n t orden_ loca l , FILE L s a l i d a ) {487

488 i n t i , j ; /*CONTADORES*/489

490 for ( i =0; i <orden_ loca l ; i ++){491 for ( j =0; j <orden_ loca l ; j ++)492 f p r i n t f ( s a l i d a , " %d " , mat r i z [ i ] [ j ] ) ;493 f p r i n t f ( s a l i d a , " \ n " ) ;494 }495 }

Parte III

Análisis del Rendimiento

125

Capítulo 8

Evaluación del Sistema

Para conseguir una cierta objetividad en el análisis de los algoritmos ejecutados en undeterminado sistema paralelo, lo primero que debemos hacer es medir el rendimiento de dichosistema. Además los distintos grupos de desarrolladores de software MPI tienen diferentesrazones 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 podrán elegirde manera acertada el tipo de operaciones a implementar en sus algoritmos y, si hayvarias disponibles, la implementación MPI a utilizar.� Los evaluadores encuentran la información sobre el rendimiento crítica a la hora dedecidir qué máquina adquirir para ejecutar sus aplicaciones y, si hay varias disponibles,qué implementación 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 medición del rendimiento se realiza a través de herramientas especializadasen el análisis, de modo que podemos saber fácilmente y con seguridad cuánto de apropiado esel sistema para la ejecución de determinados algoritmos paralelos.

8.1. Utilidad mpptest

Mpptest es un programa que mide el rendimiento de las funciones básicas MPI en unaamplia variedad de situaciones. Además del clásico test de comunicación entre dos procesos,mpptest puede realizar tests de comunicación con múltiples procesos implicados, exponiendoproblemas de escalabilidad. También podremos elegir el tamaño de los mensajes a enviar demanera que se puedan tratar de manera aislada los problemas imprevistos en el rendimientodel sistema.

Originalmente mpptest fué desarrollado antes de la aparición del estándar MPI, carac-terística que todavía se refleja en algunos de los nombres de las opciones (-force para ready-send, etc.). Mpptest se distribuye con la implementación MPICH aunque puede ser usada en

127

128 CAPÍTULO 8. EVALUACIÓN DEL SISTEMA

cualquier implementación MPI. Las versiones más actuales incluyen junto a mpptest una seriede programas (stress y goptest entre otros) que están adaptados específicamente a cierto tipode mediciones del rendimiento del sistema.

8.1.1. Compilación y Ejecución

La implementación MPICH incluye en su propia distribución la utilidad mpptest, porlo cual los usuarios de MPICH no necesitarán un complicado proceso de instalación. Paracompilar mpptest sólo tendremos que ejecutar :

$ cd directorio_mpich/examples/perftest$ make

Mpptest puede ser utilizado en otras implementaciones MPI; para realizar una instalaciónadecuada consulte la documentación.

Para ejecutar mpptest debemos utilizar el programa de arranque de procesos que gen-eralmente empleamos en la ejecución de programas MPI. Normalmente utilizaremos mpirun(sección A.6).

De este modo utilizando la siguiente orden realizaremos un test simple de comunicaciónbloqueante entre dos procesos:

$ mpirun -np 2 mpptest

Para conocer todas las opciones de mpptest ejecutaremos:

$ mpptest -help

También existe un script, llamado runmpptest, que facilita la realización de las pruebas derendimiento más 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 estándar los datos necesarios para visualizar elresultado con el programa CIt usaremos:

$ mpirun -np 2 mpptest

Sin embargo mpptest también puede generar datos para el programa gnuplot, utilizando laopción -gnuplot. De esta manera obtendremos por la salida estándar los comandos necesariospara 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 seránleídos por gnuplot, y agrega los datos del test al fichero ‘mppout.gpl’:

$ mpirun -np 2 mpptest -gnuplot > out.mpl

8.1. UTILIDAD MPPTEST 129

También podemos utilizar la opción -fname. Con la siguiente orden guardaremos en el fichero‘nombre.mpl’ los comandos que serán leídos por gnuplot, agregando los datos del test alfichero ‘nombre.gpl’:

$ mpirun -np 2 mpptest -gnuplot -fname nombre.mpl

8.1.3. Visualización

En la visualización del contenido de los tests utilizaremos el programa gnuplot. Lo primeroque 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í losdatos 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. Gráficos

Para generar gráficos en formato Encapsulated Postscript tenemos dos opciones. La primeraes utilizar la opción -gnuploteps en vez de -gnuplot para generar el fichero de comandos .mpl.La siguiente secuencia de órdenes genera el gráfico ‘out.eps’ en monocromo:

$ mpirun -np 2 mpptest -gnuploteps -fname out.mpl$ gnuplot out.mpl > out.eps

Otra posibilidad sería generar el fichero de comandos .mpl con la opción -gnuplot (comohacíamos 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 más precisa el formato del gráfico de salida. Con la siguienteserie de comandos conseguiremos obtener el gráfico 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 través de los argumentos asociados a la ejecución del programa enla línea de comandos, aunque también puede ser necesario el empleo de otros programas paraejecutarlos. La siguiente lista resume las opciones disponibles más interesantes:

Comunicación No Bloqueante. La comunicación no bloqueante es importante; en muchasaplicaciones usar funciones de comunicación no bloqueante es la manera más fácil deasegurar la fiabilidad evitando problemas relacionados con la capacidad finita del buffer.El rendimiento de las funciones no bloqueantes puede ser diferente al de las funcionesbloqueantes. Para utilizar este tipo de comunicación emplearemos la opción -async.

Número de Procesos. Cualquier número de procesos puede ser empleado. Por defecto só-lo dos de los procesos se comunican. Utilizando la opción -bisect todos los procesosparticipan en la comunicación.

Solapamiento entre comunicación y procesamiento. La opción -overlap realiza un simpletest que mide el solapamiento entre comunicación y procesamiento del sistema enviandomensajes con una longitud determinada y generando una carga variable de procesamien-to.

Patrones de Comunicación. Existen una gran variedad de patrones de comunicación. De estemodo, no sólo existe el modelo punto a punto; un modelo muy importante es el decomunicación colectiva, entre otros. La comunicación colectiva se mide con el programagoptest. Dicho programa utiliza muchas opciones similares a mpptest, y se maneja demanera muy similar. Para conocer su funcionamiento ejecutaremos :

$ goptest -help

Como ocurre con mpptest, también existe un script que facilita el manejo del programagoptest. Dicho script se denomina rungoptest. Podemos conocer sus opciones ejecu-tando:

$ rungoptest -help

Fiabilidad. La fiabilidad se comprueba mediante el programa stress. Este programa envíaconjuntos de bits en mensajes de varios tamaños, y luego chequea cada bit del mensajerecibido 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 trabajodedicadas a la realización de prácticas por parte de los alumnos de Ingeniería Técnica de

8.2. PRUEBAS REALIZADAS 131

Informática de Gestión de la Universidad de Cádiz. Dicho sistema se encuentra en el Aula deInformática II de la Escuela Superior de Ingeniería.

Las máquinas en las cuales ejecutaremos los algoritmos tienen las siguientes característi-cas: � Procesador AMD Duron a 1,2 Ghz� 256 Mb RAM� Distribución SUSE Linux 8.0

Todas las máquinas están conectadas a una red Ethernet (mediante una tarjeta Davicom Eth-ernet 100/10 Mbit) y comparten el sistema de ficheros ‘/home’ mediante NFS (“Network FileSystem”, Sistema de Ficheros en Red). El servidor de ficheros es un computador CompaqDEC 3000/800S Alpha, con el sistema operativo Tru64 UNIX (Digital UNIX) V4.0E . Laimplementación MPI utilizada es MPICH Versión 1.2.4 .

A continuación analizaremos el rendimiento y la fiabilidad de nuestro sistema al ejecutardistintos tipos de comunicación.

8.2.1. Comunicación Bloqueante

Este test analiza el comportamiento del sistema en la situación más habitual: el paso demensajes bloqueantes.

EJECUCIÓN

Ejecutaremos 16 procesos de los cuales dos de ellos se comunicarán. El tamaño de losmensajes variará entre 0 y 1024 bytes. Para ejecutarlo daremos la orden:

$ mpirun -np 16 mpptest -gnuplot -fname ComBloq.mpl

Como podemos observar el número de procesos lo fijamos mediante el programa mpirun. Pordefecto mpptest utiliza para las pruebas mensajes cuyo tamaño varía entre 0 y 1024 bytes, conun salto de 32 bytes entre un tamaño y el siguiente.

Con esta orden el fichero ‘ComBloq.gpl’ almacenará los datos para el gráfico, mientrasque ‘ComBloq.mpl’ contendrá los comandos gnuplot para visualizarlos. Modificaremos ésteúltimo para mejorar el aspecto del resultado:

set terminal postscript eps colorset 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 3exit

A continuación daremos la siguiente orden para generar el gráfico ‘ComBloq.eps’:


0

200

400

600

800

1000

1200

0 200 400 600 800 1000 1200

Tie

mpo

(m

icro

-seg

)

Tamano (bytes)

Comunicacion Bloqueante

Com.Bloqueante

Figura 8.1: Gráfico Comunicación Bloqueante

$ gnuplot ComBloq.mpl > ComBloq.eps

El gráfico que obtenemos como resultado lo tenemos en la figura 8.1. El eje T mide el tamañode los mensajes, mientras que el eje U mide el tiempo necesario para transmitirlos. La línearoja representa el rendimiento de la comunicación bloqueante.

ANÁLISIS DE LOS RESULTADOS

Como cabía esperar a medida que aumenta el tamaño del mensaje también lo hace el tiem-po requerido para transmitirlo. Debemos observar que el retardo mínimo en la comunicaciónbloqueante es de 200 <>=@?�A , tiempo requerido para transmitir un mensaje sin contenido (0bytes).

8.2.2. Comunicación No Bloqueante

Este test analiza el rendimiento de la comunicación no bloqueante en nuestro sistema.

EJECUCIÓN

Ejecutaremos 16 procesos de los cuales dos de ellos se comunicarán. El tamaño de losmensajes variará entre 0 y 1024 bytes. Utilizaremos comunicación no bloqueante. Para ejecu-tarlo daremos la orden:


$ mpirun -np 16 mpptest -async -gnuplot-fname ComNoBloq.mpl

La opción -async provoca la utilización de mensajes no bloqueantes en la comunicación.Con esta orden el fichero ‘ComNoBloq.gpl’ almacenará los datos para el gráfico, mientras

que ‘ComNoBloq.mpl’ contendrá los comandos gnuplot para visualizarlos. Modificaremoséste último para comparar el rendimiento de la comunicación bloqueante y el de la no blo-queante, relacionándolos en el mismo gráfico:

set terminal postscript eps colorset xlabel "Tamano (bytes)"set ylabel "Tiempo (micro-seg)"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" \



$ gnuplot ComNoBloq.mpl > ComNoBloq.eps

El gráfico que obtenemos como resultado lo tenemos en la figura 8.2. El eje T mide el tamañode los mensajes, mientras que el eje U mide el tiempo necesario para transmitirlo. La línearoja representa el rendimiento de la comunicación no bloqueante y la azul el rendimiento dela comunicación bloqueante.


En el gráfico observamos que los resultados son muy parecidos a los del test anterior. Lapequeña sobrecarga que genera el proceso de sincronización en este tipo de mensajes no afectacasi nada al rendimiento de la comunicación.

8.2.3. Participación Total de los Procesos

Este test analiza el rendimiento de la comunicación bloqueante cuando todos los procesosparticipan en la comunicación.

EJECUCIÓN

Ejecutaremos 16 procesos de manera que todos ellos participen en la comunicación. Lamitad de los procesos envían mensajes a la otra mitad. El tamaño de los mensajes variará entre0 y 1024 bytes. Para ejecutarlo daremos la orden:


0

200

400

600

800

1000

1200

0 200 400 600 800 1000 1200

Tie

mpo

(m

icro

-seg

)

Tamano (bytes)

Comparacion Comunicacion Bloqueante-No Bloqueante

Com.No BloqueanteCom.Bloqueante

Figura 8.2: Comparación Com.Bloqueante - No Bloqueante

$ mpirun -np 16 mpptest -bisect -gnuplot -fname Bisect.mpl

La opción -bisect provoca la participación de todos los procesos en la comunicación.Con esta orden el fichero ‘Bisect.gpl’ almacenará los datos para el gráfico, mientras que

‘Bisect.mpl’ contendrá los comandos gnuplot para visualizarlos. Modificaremos éste últimopara comparar el rendimiento de la comunicación participativa y el de la no participativa,relacionándolos en el mismo gráfico:

set terminal postscript eps colorset xlabel "Tamano (bytes)"set ylabel "Tiempo (micro-seg)"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" \



$ gnuplot Bisect.mpl > Bisect.eps


0

200

400

600

800

1000

1200

1400

1600

0 200 400 600 800 1000 1200

Tie

mpo

(m

icro

-seg

)

Tamano (bytes)

Comparacion Com.Participativa-No Participativa

Com.ParticipativaCom.No Participativa

Figura 8.3: Comparación Com. Participativa - No Participativa

El gráfico que obtenemos como resultado lo tenemos en la figura 8.3. El eje T mide el tamañode los mensajes, mientras que el eje U mide el tiempo necesario para transmitirlos. La línearoja representa el rendimiento de la comunicación participativa y la azul el rendimiento de lacomunicación no participativa.


En el gráfico observamos que los resultados son algo distintos a los obtenidos en la co-municación bloqueante convencional. La sobrecarga en la comunicación que genera la par-ticipación de todos los procesos queda reflejada en un aumento del tiempo requerido paratransmitir los mensajes. El retardo en la comunicación aumenta conforme crece el tamaño dela información a transmitir.

8.2.4. Solapamiento entre Comunicación y Procesamiento

Los algoritmos paralelos en general suelen solapar comunicación y procesamiento en susejecuciones. Este test analiza el impacto que tiene sobre el rendimiento del sistema dichosolapamiento.

EJECUCIÓN

Ejecutaremos 16 procesos de los cuales dos de ellos se comunicarán. Al mismo tiempo elsistema realizará un determinado procesamiento. El tamaño 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 opción -overlap realiza un simple test que mide el impacto que produce el solapamientoentre comunicación y procesamiento en el rendimiento del sistema. Este test se lleva a caboenviando mensajes no bloqueantes sin contenido a la vez que se genera una carga variable deprocesamiento.

Con esta orden el fichero ‘Overlap.gpl’ almacenará los datos para el gráfico, mientrasque ‘Overlap.mpl’ contendrá los comandos gnuplot para visualizarlos. Modificaremos ésteúltimo para comparar el rendimiento de la comunicación solapada y el de la no solapada,relacionándolos en el mismo gráfico:

set terminal postscript eps colorset xlabel "Carga de Procesamiento (bytes)"set ylabel "Tiempo (micro-seg)"set title "Impacto Solapamiento Comunicacion-Procesamiento"plot [] [182:194] ’Overlap.gpl’ using 4:5 title "Com.Solapada" \



$ gnuplot Overlap.mpl > Overlap.eps

El gráfico que obtenemos como resultado lo tenemos en la figura 8.4. El eje T representa lacarga de procesamiento medida en bytes, mientras que el eje U mide el tiempo necesario paratransmitir un mensaje con dicha carga. La línea roja representa el rendimiento de la comuni-cación solapada.


Como observamos en el gráfico la presencia de procesamiento no provoca una caída delrendimiento de la comunicación en nuestro sistema. Ésto es lógico debido a que contamos conequipos relativamente potentes. De este modo el tiempo requerido para transmitir un mensajede 0 bytes es prácticamente el mismo independientemente de la carga de trabajo del proce-sador.

Por otro lado observamos muchos “picos” en la línea de la comunicación solapada; ello sedebe a que la carga de procesamiento que genera este test es variable, por lo que la incidenciasobre el rendimiento también será variable.

8.2.5. Comunicación Colectiva

Este test analiza el rendimiento de la comunicación colectiva utilizando el programa goptest.


182

184

186

188

190

192

194

0 200 400 600 800 1000 1200

Tie

mpo

(m

icro

-seg

)

Carga de Procesamiento (bytes)

Impacto Solapamiento Comunicacion-Procesamiento

Com.Solapada

Figura 8.4: Comparación Com. Solapada - No Solapada

EJECUCIÓN

En el caso de las operaciones colectivas las mediciones no se deben basar sólo en el tamañode los mensajes, ya que no es la única variable determinante; también debemos analizar elnúmero de procesos que intervienen en su ejecución.

Goptest es el programa encargado de generar datos para gráficos basándose en el númerode procesos. La dificultad que entraña este tipo de mediciones es que no pueden ser realizadasen un solo paso; ello es debido a que el programa de arranque mpirun sólo puede seleccionarun número de procesos en la ejecución cada vez. Por lo tanto debemos realizar una ejecucióndel test para cada número de procesos que queramos incluir en el test.

Así pues realizaremos cuatro ejecuciones consecutivas para medir el comportamiento delsistema en una comunicación colectiva de 2, 4, 8 y 16 procesos. La operación se comunicacióncolectiva que realizaremos será una operación de reducción que sumará los valores de todoslos procesos. Dichos valores serán de tipo entero:

$ mpirun -np 2 goptest -isum -sizelist 32,256,512,1024-gnuplot -fname Goptest.mpl



$ mpirun -np 16 goptest -isum -sizelist 32,256,512,1024


-gnuplot -fname Goptest.mpl

Como podemos observar el tipo de operación colectiva se determina mediante una opción. Laopción isum indica la realización de una operación de reducción donde se suman los valores detodos los procesos, siendo dichos valores de tipo entero. La opción -sizelist indica los tamañosde mensajes a utilizar en las pruebas. En todo caso vemos que la ejecución de goptest es muysimilar a la de mpptest, coincidiendo en la mayoría 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 información al fichero ‘Goptest.gpl’.Tendremos que preparar dicho fichero para que pueda ser utilizado por el programa gnuplot.Con esta finalidad debemos agrupar la información para que el fichero quede sin líneas vacías,dejándolo de la siguiente manera:

#np time (us) for various sizes2 579.500000 2037.400000 3946.940000 7333.6800004 1606.820000 5923.540000 11683.560000 22859.7000008 4418.800000 14938.040000 30276.300000 60126.70000016 10821.880000 37237.340000 73761.080000 137344.780000

Ahora tenemos el fichero ‘Goptest.gpl’, que almacena los datos para el gráfico, y el fichero‘Goptest.mpl’, que contiene los comandos gnuplot para visualizarlos. Modificaremos ésteúltimo de manera que gnuplot genere un gráfico Encapsulated Postscript manteniendo unbuen aspecto:

set term postscript eps colorset xlabel "Num.Procesos"set ylabel "Tiempo (micro-seg)"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 continuación daremos la siguiente orden para generar el gráfico ‘Goptest.eps’:

$ gnuplot Goptest.mpl > Goptest.eps

El gráfico que obtenemos como resultado lo tenemos en la figura 8.5. El eje T representael número de procesos utilizados, mientras que el eje U mide el tiempo necesario realizar lacomunicación colectiva. La línea roja representa el rendimiento de la comunicación colectivautilizando los mensajes de 32 bytes, la azul los de 256 bytes, la morada los de 512 y la negralos de 1024 bytes.


0

20000

40000

60000

80000

100000

120000

140000

160000

0 2 4 6 8 10 12 14 16

Tie

mpo

(m

icro

-seg

)

Num.Procesos

Comunicacion Colectiva Op.Reduccion-Entero

32256512

1024

Figura 8.5: Gráfico Comunicación Colectiva


En el gráfico podemos observar la incidencia que tienen sobre el rendimiento de la comu-nicación tanto el número de procesos que toman parte en ella como el tamaño de los mensajesque se transmiten . Ésto lo vemos claramente analizando dos datos:� Una comunicación 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 reducción del 85 %.� Una comunicación colectiva de 16 procesos utilizando mensajes de 1024 bytes tardauno 140.000 <>=&?BA , mientras que utilizando mensajes de 256 bytes (una cuarta parte) eltiempo total es de 35.000 <>=@?�A aproximadamente. En este ejemplo sólo observamos unareducción del 75 %.

Con estos datos vemos que el número de procesos es una variable algo más determinanteque el tamaño de los mensajes, aunque esta última también reviste mucha importancia. Por lodemás vemos que el crecimiento de las funciones es similar en todos los tamaños de mensajes,y que este tipo de comunicación en general consume más tiempo que la comunicación puntoa punto.


8.2.6. Fiabilidad

Este test comprueba la fiabilidad de la comunicación en el sistema utilizando el programastress.

EJECUCIÓN

El programa stress realiza un test de fiabilidad sobre un determinado sistema. Este pro-grama envía conjuntos de bits en mensajes de varios tamaños, y luego chequea cada bit delmensaje recibido en el proceso receptor. Podemos utilizar el número de procesos que creamosconveniente. Con la siguiente orden realizaremos un test con 4 procesos:

$ mpirun -np 4 stress

Por defecto el tamaño de los mensajes que utiliza está comprendido entre 0 y 1024 bytes, conun salto de 32 bytes entre un tamaño y el siguiente. La comunicación es de tipo bloqueante,aunque ésto lo podemos cambiar con la opción -async.

A continuación 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 tests2.108621e+08 bytes sent

La primera línea , “Each to All”, indica que cada proceso enviará mensajes a todos losdemás. Cada una de las líneas de puntos representa una serie de mensajes que enviamos deun proceso a otro. Al utilizar la opción -verbose la línea de puntos es sustituida por unainformación para cada mensaje, que indica su tamaño y el patrón utilizado para generar elconjunto de bits que forma dicho mensaje; de esta manera cada línea de puntos representa losiguiente:


.Running size = 32 longs with pattern ffffffff































.Running size = 1024 longs with pattern ffffffff+


El hecho de no obtener un mensaje de error quiere decir que el test ha sido satisfactorio yque disponemos de un sistema fiable para la ejecución de programas MPI.

Capítulo 9

Evaluación de los Algoritmos

El presente documento aborda dos aspectos de los algoritmos paralelos: su diseño y suanálisis. El concepto de análisis se refiere al proceso de determinar cuánto de bueno es un al-goritmo, o lo que es lo mismo, cuánto de rápido y eficiente es en el uso que le da a los recursosdisponibles. En este capítulo hablaremos sobre las distintas herramientas de monitorizaciónque nos ayudan a estudiar la ejecución de los algoritmos, definiremos más formalmente loscriterios utilizados en la evaluación de su rendimiento y aplicaremos dicho análisis a los algo-ritmos implementados.

9.1. Herramientas de Monitorización

La extensión MPE (“Multi-Processing Environment”, Entorno de Multi-Procesamiento)(sección A.7) trata de proporcionar a los programadores un conjunto completo de herramientasde análisis del rendimiento para los programas MPI. Entre estas herramientas tenemos unconjunto de librerías de monitorización, un conjunto de programas de utilidad y un conjuntode herramientas gráficas.

Las librerías de monitorización proporcionan una colección de funciones que generan in-formación acerca de la ejecución de los programas MPI. Se pueden utilizar manualmentemediante la inserción de llamadas MPE en los programas MPI, o bien automáticamente, en-lazando el código MPI con las librerías MPE adecuadas. Normalmente se utiliza la segundaopción, como veremos más adelante. Las librerías de monitorización que actualmente estánincluidas, y que a continuación pasaremos a describir con más precisión, son las siguientes:� Librería de generación de ficheros de recorrido de la ejecución� Librería de representación del trazado de la ejecución� Librería de animación en tiempo real

Los programas de utilidad incluidos en MPE son básicamente utilidades para el manejo ytratamiento de ficheros de recorrido, y las herramientas gráficas se utilizan en su visualización.Todo ello se analiza con más detalle en la siguiente sección.

143

144 CAPÍTULO 9. EVALUACIÓN DE LOS ALGORITMOS

9.1.1. Ficheros de Recorrido

La librería para la generación de ficheros de recorrido es sin duda la más útil y ampliamenteusada en MPE. Dicha librería se utiliza para volcar información relativa a la ejecución de lasllamadas MPI en un fichero. Dichos ficheros representan el recorrido de la ejecución de losprogramas MPI, siendo generados durante su ejecución.

Actualmente existen tres formatos de fichero.

CLOG Es el formato por defecto. Básicamente es una colección de eventos asociados a eti-quetas temporales que representan el momento en que se produjeron. Almacena losdatos en formato binario.

ALOG Existe por motivos de compatibilidad hacia atrás. Almacena los eventos en formatode texto ASCII. Actualmente no es mantenido ni desarrollado.

SLOG Es el más potente. Proviene de “Scalable LOGfile”, Fichero de Recorrido Escalable.Almacena los datos como estados (esencialmente eventos con una duración) en un for-mato binario especial, diseñado para permitir el tratamiento de ficheros de recorridomuy grandes (del tamaño de varios Gigas).

9.1.1.1. Creación

Generalmente el método más sencillo y seguro para la utilización de las librerías MPE esmediante el enlace del código MPI con las librerías MPE adecuadas. Para ello sólo debemosproporcionar un argumento (-mpilog) al comando de compilación que usemos normalmente(sección A.5). En realidad ésto sólo debe hacerse en el momento de enlazar el código.

Por ejemplo, para crear una versión 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 también podemos compilar directamente:

$ mpicc -o RTrap -mpilog RTrap.c

Dado que el formato por defecto de salida es CLOG, el fichero de recorrido que obtendremosal ejecutar RTrap se llamará ‘RTrap.clog’.

Si queremos que el fichero tenga otro formato de salida debemos utilizar la variable deentorno MPE_LOG_FORMAT. Dicha variable determina el formato de salida de los ficherosde 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 ejecutaremoslo 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 MONITORIZACIÓN 145

9.1.1.2. Visualización

Para visualizar el contenido de los ficheros de recorrido, lo más recomendable es ejecu-tar el programa logviewer. Este script emplea el visualizador adecuado para tratar el ficherobasándose en su extensión. Dependiendo del formato que tenga el fichero, logviewer emplearáun visualizador u otro. Si queremos información 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 losficheros de recorrido:

upshot Utilizado para visualizar ficheros con el formato ALOG. Analiza eventos asociadosa etiquetas temporales que representan el momento en que se produjeron, almacenadosen formato de texto ASCII.

jumpshot-2 Utilizado para visualizar ficheros con el formato CLOG. Este visualizador es unaevolución de nupshot, el cual a su vez es una versión más rápida de upshot. Analiza losficheros en formato binario y está escrito en Java. Su inconveniente radica en el impactoque tiene sobre su rendimiento el tamaño del fichero a analizar. Cuando el fichero CLOGsobrepasa los 4MB su rendimiento se deteriora de manera significativa.

jumpshot-3 Utilizado para visualizar ficheros con el formato SLOG. Es la evolución naturalde jumpshot-2 y también está escrito en Java. Este visualizador es fruto del esfuer-zo de investigación desarrollado para solucionar los problemas de rendimiento de suantecesor. De este modo visualiza programas de una manera más escalable. Debido alformato de los ficheros que trata, este visualizador no analiza eventos convencionalessi no estados (esencialmente eventos con una duración) en un formato binario especial,diseñado para permitir el tratamiento de ficheros de recorrido muy grandes (del tamañode varios Gigas).

9.1.1.3. Conversión

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 quela generación directa del fichero SLOG no funciona debido mal comportamiento delprograma MPI. Además este conversor nos permite ajustar ciertos parámetros del ficherode recorrido, como el segmento del fichero a mostrar, etc. Para obtener más informaciónejecutaremos:

$ clog2slog -h

clog2alog Coversor de ficheros CLOG a ALOG. Se proporciona por motivos de compatibili-dad hacia atrás.


9.1.1.4. Impresión 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 estándar. Sirvepara chequear el contenido del fichero de recorrido. Si el fichero SLOG es demasiadogrande, puede no ser útil usar slog_print. Además cuando el fichero SLOG no estácompleto slog_print no funcionará. Por lo tanto servirá como un simple test para sabersi el fichero SLOG está generado completamente.

clog_print Programa que imprime ficheros CLOG en modo texto por la salida estándar.

9.1.2. Trazado de la Ejecución

La librería para la representación del trazado de la ejecución muestra todas las llamadas afunciones MPI.

Cada llamada a MPI imprime dos líneas 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 están precedidas por el identificador del proceso que la ejecuta en MPI_COMM_WORLD.Todo ésto se muestra por la salida estándar.

La mayoría de las funciones de envío y recepción de mensajes indican además los valoresde algunos de sus parámetros, como contador, etiqueta y compañero (proceso destino enenvíos y origen en recepciones).

El método más sencillo y seguro para la utilización de la librería de trazado MPE es me-diante el enlace del código MPI con las librerías MPE adecuadas. Para ello sólo debemos pro-porcionar un argumento (-mpitrace) al comando de compilación que usemos normalmente(sección A.5). Como ya dijimos, ésto sólo debe hacerse en el momento de enlazar el código.

Así, para crear una versión del programa HolaMundo (algoritmo ¡Hola Mundo!) quemuestre el trazado de su ejecución, 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 MONITORIZACIÓN 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

Proceso 0 en linux.local Encargado de la E/S

¡Hola Mundo!

Numero Procesos: 2Tiempo Procesamiento: 0.000087

[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. Animación en Tiempo Real

La librería gráfica MPE contiene funciones que permiten la compartición por parte de unconjunto de procesos de una ventana X, de manera que no esté asociada a ningún procesoespecífico.

La librería de animación en tiempo real utiliza esta capacidad para dibujar flechas querepresentan el tráfico de mensajes mientras el programa se ejecuta. Observemos que los pro-gramas MPI pueden generar eventos de comunicación mucho más rápidamente de lo que unservidor X11 puede mostrar dichos eventos.

Al igual que lo que ocurre con otras librerías, el método más sencillo y seguro para lautilización de la librería de animación en tiempo real es mediante el enlace del código MPIcon las librerías MPE adecuadas. Para ello debemos proporcionar un argumento (-mpianim)al comando de compilación que usemos normalmente (sección A.5). Como ya dijimos, éstosólo debe hacerse en el momento de enlazar el código.

Sin embargo la librería de animación requiere el uso de operaciones del sistema X Windowasí como operaciones de la librería matemática. De este modo para crear una versión delprograma RTrap (algoritmo Regla del Trapecio) que produzca una animación en tiempo realde su ejecución, 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: Animación en Tiempo Real


$ mpicc -o RTrap -L/usr/X11R6/lib -lX11 -lm-mpianim RTrap.c

Debido a que dicha librería utiliza operaciones del sistema XWindow, puede que tengamosproblemas con los permisos de acceso al servidor X. En ese caso utilizaremos la orden xhostpara permitir el acceso al servidor X. Si tiene problemas con la configuración de seguridadconsulte 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 Evaluación

Una vez que un nuevo algoritmo ha sido diseñado, normalmente es evaluado usando lossiguientes criterios: el tiempo de ejecución, el número de procesadores usados y el coste.Aparte de estas medidas estándar pueden utilizarse otras muchas medidas relacionadas con elhardware, aunque sólo deben ser empleadas cuando se conoce bien el entorno particular endonde dicho algoritmo es ejecutado.

9.2.1. Tiempo de Ejecución

Dado que la mejora en la velocidad computacional es la principal razón por la cual seconstruyen sistemas paralelos, podemos decir que la medida más importante en la evaluaciónde un algoritmo paralelo es su tiempo de ejecución. Se define como el tiempo empleado porun algoritmo para resolver un problema en un computador paralelo, desde el momento enque comienza hasta que acaba. Si los procesadores implicados en al ejecución no empiezan yterminan su procesamiento al mismo tiempo, el tiempo de ejecución será calculado desde elmomento en que el primer procesador comienza su ejecución, hasta que el último procesadortermina.

9.3. RESULTADOS OBTENIDOS 149

9.2.2. Número de Procesadores

El segundo criterio más importante en la evaluación de un algoritmo es el número deprocesadores que requiere para resolver un problema. Cuesta dinero comprar, mantener y hac-er que funcionen los computadores. Cuando varios procesadores están presentes el problemadel 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 número deprocesadores que utiliza un algoritmo para resolver un problema, más cara será la soluciónque obtendremos.

9.2.3. Coste

El coste de un algoritmo se obtiene de la multiplicación de las dos medidas anteriores; deesta manera

Coste = Tiempo de ejecución * Número de procesadores

Ésta es la medida más indicativa del rendimiento de un algoritmo paralelo. De hecho será laque utilicemos en la evaluación de nuestros algoritmos. Su precisión radica en que relacionael número de procesadores empleados con el tiempo de ejecución obtenido; por lo tanto, nosserá útil para conocer en qué proporción aumenta el rendimiento del sistema al incrementar elnúmero de procesadores.

9.3. Resultados Obtenidos

A continuación realizaremos un análisis del rendimiento alcanzado por los algoritmos de-sarrollados de manera objetiva, intentando eliminar las variables que entorpezcan dicha obje-tividad.

9.3.1. Algoritmo Cálculo de Áreas mediante Montecarlo Bloqueante

EJECUCIÓN

En la ejecución del presente algoritmo debemos tener en cuenta algunos asuntos para quelos tiempos arrojados por los tests realizados sean válidos. Lo primero que debemos hacer eseliminar el tiempo añadido por el usuario al introducir los datos. De esta manera fijaremos losdatos de entrada mediante operaciones de asignación en el código.

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 modointentaremos buscar el número PI calculando el área de una circunferencia de radio 1 . Paracomputarlo generaremos el número de muestras � �

200.000.000 .En la figura 9.2 observamos el modelo de ejecución del algoritmo regla del trapecio con 8

procesos.

150C

APÍT

UL

O9.

EV

AL

UA

CIÓ

ND

EL

OS

AL

GO

RIT

MO

S

Figura 9.2: Modelo Ejecución Cálculo de Áreas Bloqueante 8 Procesos


Número Procesadores Tiempo Coste

1 140,1 seg 140,12 71,3 seg 142,64 36,1 seg 144,48 19,4 seg 155,2

16 11,0 seg 176,0

Cuadro 9.1: Evaluación Cálculo de Áreas Bloqueante

El cuadro 9.1 contiene para cada número de procesadores empleado el tiempo de ejecu-ción medido en segundos y el coste obtenido. En el gráfico de la figura 9.3 exponemos larelación entre tiempo de ejecución y número de procesadores. La figura 9.4 contiene la curvade crecimiento del coste con respecto al número de procesadores.


El modelo de ejecución de este algoritmo puede ser interpretado fácilmente. En un princi-pio el proceso 0 distribuye los datos de entrada a los demás procesos enviando a cada uno unmensaje bloqueante. Si hubiéramos introducido los datos a través del terminal en vez de haberfijado variables en estas pruebas, este paso hubiera sido más largo debido a que el resto deprocesos tendrían 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 comunicación entre los procesos. Cuando los procesos culmi-nan el tiempo de procesamiento envían su resultado local al proceso 0 mediante un mensajebloqueante. El proceso 0 recoge dichos resultados locales, calcula la media de todos ellos eimprime el resultado global. Una vez hecho ésto el programa termina.

Como podíamos esperar, cuantos más procesadores intervienen en la ejecución menor esel tiempo de ejecución. Sin embargo el coste aumenta gradualmente con respecto al número deprocesadores. Por lo tanto deberíamos emplear más o menos procesadores dependiendo de lanecesidad 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 nuestrasnecesidades.

9.3.2. Algoritmo Cálculo de Áreas mediante Montecarlo No Bloqueante

EJECUCIÓN

En la ejecución del presente algoritmo debemos tener en cuenta algunos asuntos para quelos tiempos arrojados por los tests realizados sean válidos. Lo primero que debemos hacer eseliminar el tiempo añadido por el usuario al introducir los datos. De esta manera fijaremos losdatos de entrada mediante operaciones de asignación en el código.

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 modointentaremos buscar el número PI calculando el área de una circunferencia de radio 1 . Paracomputarlo generaremos el número de muestras � �

200.000.000 .


0

20

40

60

80

100

120

140

160

0 2 4 6 8 10 12 14 16

Tie

mpo

(se

g)

Numero de Procesadores

Calculo de Areas No Bloqueante: Tiempo Ejecucion

Tiempo Ejecucion

Figura 9.3: Gráfico Tiempo Ejecución Cálculo de Áreas Bloqueante

135

140

145

150

155

160

165

170

175

180

0 2 4 6 8 10 12 14 16

Cos

te


Calculo de Areas Bloqueante: Coste

Coste

Figura 9.4: Gráfico Coste Cálculo de Áreas Bloqueante

9.3.R

ESU

LTAD

OS

OB

TE

NID

OS

153

Figura 9.5: Modelo Ejecución Cálculo de Áreas No Bloqueante 8 Procesos



1 139,9 seg 139,92 71,3 seg 142,64 35,7 seg 142,88 18,8 seg 150,4

16 10,7 seg 171,2

Cuadro 9.2: Evaluación Cálculo de Áreas No Bloqueante

En la figura 9.5 observamos el modelo de ejecución del algoritmo regla del trapecio con 8procesos.

El cuadro 9.2 contiene para cada número de procesadores empleado el tiempo de ejecu-ción medido en segundos y el coste obtenido. En el gráfico de la figura 9.6 exponemos larelación entre tiempo de ejecución y número de procesadores. La figura 9.7 contiene la curvade crecimiento del coste con respecto al número de procesadores.


El modelo de ejecución de este algoritmo puede ser interpretado fácilmente. En un prin-cipio el proceso 0 distribuye los datos de entrada a los demás procesos enviando a cada unoun mensaje no bloqueante. Si hubiéramos introducido los datos a través del terminal en vez dehaber fijado variables en estas pruebas, este paso hubiera sido más largo debido a que el restode procesos tendrían 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 comunicación entre los procesos. Cuando los procesos culminanel tiempo de procesamiento envían su resultado local al proceso 0 mediante un mensaje nobloqueante. El proceso 0 recoge dichos resultados locales, calcula la media de todos ellos eimprime el resultado global. Una vez hecho ésto el programa termina.

Podemos observar que la versión no bloqueante de este algoritmo es un poco más eficienteque la versión bloqueante. Los tiempos de ejecución son algo menores, y por lo tanto el costetambién. De este modo nos percatamos de la mejora en el rendimiento que proporciona lacomunicación no bloqueante.

9.3.3. Algoritmo Regla del Trapecio

EJECUCIÓN

En la ejecución de este algoritmo debemos tener en cuenta algunos asuntos para que lostiempos arrojados por los tests realizados sean válidos. Lo primero que debemos hacer eseliminar el tiempo añadido por el usuario al introducir los datos. De esta manera fijaremos losdatos de entrada mediante operaciones de asignación en el código.


0

20

40

60

80

100

120

140

0 2 4 6 8 10 12 14 16

Tie

mpo

(se

g)



Tiempo Ejecucion

Figura 9.6: Gráfico Tiempo Ejecución Cálculo de Áreas No Bloqueante

135

140

145

150

155

160

165

170

175

0 2 4 6 8 10 12 14 16

Cos

te


Calculo de Areas No Bloqueante: Coste

Coste

Figura 9.7: Gráfico Coste Cálculo de Áreas No Bloqueante

156C

APÍT

UL

O9.

EV

AL

UA

CIÓ

ND

EL

OS

AL

GO

RIT

MO

S

Figura 9.8: Modelo Ejecución Regla del Trapecio 8 Procesos



1 124,4 seg 124,42 62,2 seg 124,44 31,8 seg 127,28 16,5 seg 132,0

16 8,5 seg 136,0

Cuadro 9.3: Evaluación Regla del Trapecio

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 modointentaremos buscar el número PI a través de la regla del trapecio. Para este propósito, y comoya explicamos en la sección 6.1, utilizaremos la función ^ ,.T\3 � �o qp n4r�s y el intervalo b DFE:1�d .Para computarlo utilizaremos el número de segmentos � �

1.000.000.000 .

En la figura 9.8 observamos el modelo de ejecución del algoritmo regla del trapecio con 8procesos.

El cuadro 9.3 contiene para cada número de procesadores empleado el tiempo de ejecuciónmedido en segundos y el coste obtenido. En el gráfico de la figura 9.9 exponemos la relaciónentre tiempo de ejecución y número de procesadores. La figura 9.10 contiene la curva decrecimiento del coste con respecto al número de procesadores.


El modelo de ejecución de este algoritmo puede ser interpretado fácilmente. En un princi-pio se produce una operación broadcast, con la cual distribuimos los datos de entrada desde elproceso 0 hacia los demás procesos. Si hubiéramos introducido los datos a través del terminalen vez de haber fijado variables en estas pruebas, este paso hubiera sido más largo debido aque el resto de procesos tendrían que esperar a que el proceso 0 terminara de consultar losdatos al usuario.

Una vez realizado este paso se produce el procesamiento interno en cada uno de los pro-cesos durante el cual no existe comunicación entre los procesos. Cuando cada proceso ha cul-minado su propio procesamiento el proceso 0 recoge los resultados de cada proceso a travésde una operación reduce. Luego el proceso 0 imprime los resultados y el programa termina.

Como podíamos esperar, cuantos más procesadores intervienen en la ejecución menor esel tiempo de ejecución. Sin embargo el coste aumenta gradualmente a partir de la utilizaciónde 4 procesadores. Por lo tanto deberíamos emplear más o menos procesadores dependiendode la necesidad que tengamos de acelerar el procesamiento y de los recursos que podamosutilizar, intentando llegar a un compromiso entre rendimiento y coste que sea óptimo paranuestras necesidades.


0

20

40

60

80

100

120

140

0 2 4 6 8 10 12 14 16

Tie

mpo

(se

g)


Regla del Trapecio: Tiempo Ejecucion

Tiempo Ejecucion

Figura 9.9: Gráfico Tiempo Ejecución Regla del Trapecio

122

124

126

128

130

132

134

136

138

0 2 4 6 8 10 12 14 16

Cos

te


Regla del Trapecio: Coste

Coste

Figura 9.10: Gráfico 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: Evaluación Multiplicación de Matrices de Fox

9.3.4. Algoritmo Multiplicación de Matrices de Fox

EJECUCIÓN

El algoritmo que presentamos ahora tiene una serie de características que lo diferenciandel resto. Para evaluarlo debemos tener en cuenta una serie de factores.

El primer factor es la sobrecarga en la comunicación. Para multiplicar matrices de orden6 utilizando Ç procesos, este algoritmo necesita hacer Ç operaciones de broadcast y Ç+*ÉÈ Çoperaciones simples de paso de mensajes. El tamaño de cada uno de estos mensajes tampocoes una cuestión a desconsiderar; cada uno de los mensajes deberá pasar una matriz de orden6�$ È Ç , 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 número de procesadores. Elnúmero de procesadores utilizado debe tener raiz entera para que una matriz cuadrada puedaser distribuida equitativamente entre los procesos.

En la figura 9.13 observamos el modelo de ejecución del algoritmo regla del trapecio con9 procesos.

El cuadro 9.4 muestra los tiempos obtenidos en la ejecución del algoritmo Multiplicaciónde Matrices de Fox. Contiene para cada cantidad de procesadores empleados los tiemposobtenidos en la multiplicación de matrices de distintos órdenes; los dos tiempos separadospor el carácter ’/’ 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 semiden en segundos. Para cada orden de matrices utilizado resaltaremos en negrita el tiempode multiplicación óptimo.

Los tiempos marcados con el carácter ’-’ son omitidos debido a que no son razonables;dichos cálculos tardan demasiado. De este modo comprendemos el carácter exponencial de lacurva de crecimiento del tiempo con respecto al tamaño de las matrices a multiplicar.

La figura 9.11 muestra la curva de crecimiento del tiempo de ejecución con respecto alorden de las matrices para cada una de las cantidades de procesos empleados. La figura 9.12hace lo propio con el coste.


0

500

1000

1500

2000

2500

500 1000 1500 2000 2500 3000 3500 4000 4500 5000

Tie

mpo

(se

g)

Orden Matriz

Comparacion Tiempo de distintas Cantidades de Procesos

16941

Figura 9.11: Comparación Tiempos de distintas Cantidades de Procesos

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

500 1000 1500 2000 2500 3000 3500 4000 4500 5000

Cos

te

Orden Matriz

Comparacion Coste de distintas Cantidades de Procesos

16941

Figura 9.12: Comparación Costes de distintas Cantidades de Procesos

9.3.R

ESU

LTAD

OS

OB

TE

NID

OS

161

Figura 9.13: Modelo Ejecución Algoritmo de Fox 9 Procesos



El modelo de ejecución de este algoritmo con 9 procesos demuestra la sobrecarga en la co-municación que genera. Cada uno de los procesos en ejecución realiza 3 operaciones de brad-cast y 6 de paso de mensajes bloqueantes (en realidad la función MPI_Sendrecv_replace()realiza un envío y una recepción por cada llamada). Cada una de los mensajes transmitidostendrá al menos el mismo tamaño que las matrices locales de los procesos. Una vez que losprocesos culminan el procesamiento de sus matrices locales, envían los resultados al proceso0 para generar la salida.

Como podemos observar en la figura 9.11 el crecimiento del tiempo de ejecución es ex-ponencial para todas las cantidades de procesos utilizadas; sin embargo dicho crecimiento esmás paulatino cuanto mayor es la cantidad de procesos empleados.

En la figura 9.12 observamos que el coste depende tanto del número de procesos emplead-os como del tamaño de las matrices a multiplicar. De hecho vemos que para matrices de ordenmayor a 2000 la utilización de 1 sólo procesador es la más costosa. Con este planteamientopodemos prever que para tamaños de matrices superiores a los empleados en las pruebas lautilización de 16 procesadores será la más rentable.

Apéndice A

Instalación, Configuración y Manejode MPICH

MPICH es una implementación del estándar MPI desarrollada por el Argonne NationalLaboratory que funciona en una amplia variedad de sistemas. MPICH contiene, además de lalibrería MPI, un entorno de programación para trabajar con programas MPI. El entorno de pro-gramación incluye un programa de arranque de procesos portable, librerías de monitorizacióndestinadas a analizar el rendimiento de los programas, y una interfaz gráfica para X Window.

Las características principales de MPICH son las siguientes:� Compatibilidad total con MPI-1.2, incluyendo cancelaciones de envíos.� Soporte para clusters heterogéneos.� Los enlaces con C++ incluidos en la especificación MPI-2 están disponibles para lasfunciones MPI-1.� Enlaces con Fortran 77 y Fortran 90.� Una versión de código abierto está disponible para Windows NT. La instalación, con-figuración y manejo de esta versión son diferentes a las explicadas en este apéndice, elcual cubre sólo la versión Unix de MPICH.� Soporte para una amplia variedad de entornos, incluyendo MPPs y clusters de SMPs.� Sigue la mayoría de las recomendaciones GNU acerca de la instalación y compilación,incluyendo VPATH.� Compatibilidad con algunas partes de la especificación MPI-2, de modo que incluye:; La mayoría de las funcionalidades de E/S paralela (MPI-IO) a través de la imple-

mentación ROMIO.; Algunas funcionalidades de administración de hilos (MPI_INIT_THREAD).; Nuevas funciones MPI_Info() y MPI_Datatype().

163

164 APÉNDICE A. INSTALACIÓN, CONFIGURACIÓN Y MANEJO DE MPICH� Incluye componentes pertenecientes al entorno de programación paralela, como son:; Herramientas de monitorización.; Herramientas para la visualización de los análisis 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 diseño en dos capas. La mayor parte del códigode 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 tambiéndispositivo, oculta la mayoría de los detalles específicos del hardware permitiendo que MPICHsea portado fácilmente a nuevas arquitecturas. La interfaz ADI (o dispositivo) se encarga defacilitar el acceso al hardware de una manera eficiente, mientras que el resto del código porencima de la ADI se encarga de la sintaxis y la semántica de MPI.

A continuación mostramos una lista con los dispositivos (ADIs) disponibles en MPICH.

Clusters, Beowulf y Estaciones de Trabajo Individuales. Los dispositivos más importantesson ch_p4 y ch_p4mpd. El dispositivo ch_p4 es el más general y soporta nodos SMP,programas MPMD y sistemas heterogéneos. El dispositivo ch_p4mpd (más rápido) so-porta sólo clusters homogéneos de uniprocesadores, pero proporciona un arranque másrápido y escalable.

Topologías de tipo Rejilla. El dispositivo globus2 utiliza Globus (URL 19) para proporcionaruna implementación diseñada para topologías de tipo rejilla. Este dispositivo es apropi-ado para sistemas en los que está instalado Globus.

Multiprocesadores Simétricos. El dispositivo ch_shmem es apropiado para sistemas basa-dos en memoria compartida. Utiliza la memoria compartida para pasar mensajes entrelos procesadores, y hace uso de las facilidades proporcionadas por el sistema operati-vo. El dispositivo ch_lfshmem es una versión de ch_shmem que no utiliza bloqueos,desarrollada para el NEC-SX4.

Procesadores Paralelos Masivos (MPPs). MPICH fue desarrollado originalmente para pro-porcionar una implementación MPI a la mayoría de los MPPs existentes, cada uno delos cuales tiene su propio sistema de paso de mensajes. De este modo se incluyen losdispositivos ch_meiko, ch_nx y ch_mpl en las distribuciones de MPICH.

Otros. MPICH ha sido diseñado para permitir que otros grupos lo usen cuando desarrollensus propias implementaciones MPI. Tanto las compañías privadas como los grupos deinvestigación han usado MPICH como base para sus implementaciones. Una imple-mentación importante desarrollada de esta manera es MPICH-GM, la cual se emplea enclusters Myrinet conectados mediante hubs dedicados.

A.2. OBTENCIÓN 165

A.2. Obtención

El primer paso para poder utilizar MPICH será descargarlo e instalar los parches necesar-ios:

1. Obtener MPICH. El camino más fácil para hacerlo es usar la sección de descargas desu página web (URL [10]). De esta manera podremos descargar fácilmente el fichero‘mpich.tar.gz’. Dicho fichero contiene la distribución MPICH completa.

2. Descomprimir el fichero ‘mpich.tar.gz’ en un directorio de trabajo. Se recomienda us-ar una partición montada localmente antes que usar una partición NFS (“Network FileSystem”, Sistema de Ficheros en Red). La mayoría de los sistemas tienen el directo-rio ‘/tmp’ o ‘/sandbox’ montado localmente. Asegúrese de que existe espacio sufi-ciente disponible (100MB debería ser más 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 sección de parches de la página web de MPICH (URL [11])para verificar la existencia de parches que pueda necesitar. Normalmente las versionesdisponibles de MPICH tienen ya aplicados dichos parches; ésto queda indicado porcuatro números en el nombre de la versión (p.ej. 1.2.2.3). En otros casos el parcheaislado se pone a disposición antes que la versión parcheada. Para aplicar estos parchessiga las instrucciones expuestas en la página indicada y en la documentación.

A.3. Compilación e Instalación

Antes de poder usar MPICH debemos configurarlo y compilarlo. El proceso de configu-ración analiza nuestro sistema y determina las opciones y ajustes correctos; además crea elfichero ‘Makefile’, utilizado para compilar MPICH.

1. Decida dónde quiere instalar MPICH. Este paso no es estrictamente necesario (excep-to en el caso del dispositivo ch_p4mpd); sin embargo la instalación de MPICH (quepuede realizarse sin necesidad de privilegios en un directorio de usuario) hace más fá-cil la aplicación de actualizaciones y permite una reducción del espacio en disco queMPICH necesita, ya que la versión instalada sólo contiene librerías, cabeceras, docu-mentación y algunos programas de soporte. Se recomienda una ruta de instalación quecontenga el número de versión de MPICH. Para instalar MPICH de manera que puedanusarlo otros usuarios podríamos escoger el directorio ‘/usr/local/mpich-1.2.4/’, aunquedebemos tener en cuenta los permisos necesarios para hacerlo. Si estamos instalandosólo para uso propio, podríamos usar algo como ‘/home/me/software/mpich-1.2.4’.

2. Invocar configure con el argumento -prefix adecuado:

166 APÉNDICE A. INSTALACIÓN, CONFIGURACIÓN Y MANEJO DE MPICH

$ ./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 elección 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 estándar . Si tenemos problemas en la configuración o la compilaciónel fichero ‘c.log’ nos servirá de ayuda para identificar los posibles problemas.

En la sección A.4.3 se explica cómo utilizar el programa ssh en vez de rsh para elarranque de procesos remotos.

3. Compilar MPICH:

$ make | tee make.log

Ésto puede llevar un tiempo dependiendo de la carga de nuestro sistema y de nuestroservidor de ficheros; puede durar desde algunos minutos hasta una hora o más.

4. (Opcional) Si queremos instalar MPICH en un lugar público de manera que los demásusuarios puedan usarlo, ejecutaremos:

$ make install

De este modo instalaremos MPICH en el directorio especificado por el argumento -prefix del comando configure. La instalación estará formada por los directorios ‘in-clude’, ‘lib’, ‘bin’, ‘sbin’, ‘www’ y ‘man’, además de un pequeño directorio con ejem-plos. Si queremos eliminar la instalación debemos usar el script ‘sbin/mpiuninstall’dentro del directorio de MPICH.

A.4. Configuración

A.4.1. El Fichero de Máquinas

Cuando utilizamos el dispositivo ch_p4 el programa mpirun utiliza un fichero llamadofichero de máquinas, el cual lista las máquinas o nodos que están disponibles para ejecutarprogramas MPICH.

La manera más fácil de crear un fichero de máquinas consiste en editar el fichero ‘mpich/u-til/machines/machines.xxxx’, el cual contiene los nombres de las máquinas pertenecientes ala arquitectura xxxx. Cuando mpirun es ejecutado, el número de hosts requerido por dicho co-mando es seleccionado del fichero de máquinas para su ejecución. No existe una planificacióncompleja para elegir qué máquina usar; las máquinas son seleccionadas desde el principio delfichero. Para ejecutar todos los procesos en una sola máquina, simplemente pondremos entodas las líneas del fichero la misma máquina.

Debemos advertir que el fichero de máquinas no puede contener líneas en blanco. En casode querer darle cierta estructura y para añadir comentarios utilizaremos el carácter ‘#’. Unejemplo del fichero ‘machines.LINUX’ podría ser:

A.4. CONFIGURACIÓN 167

#FICHERO MAQUINAS ARQ. LINUXgalbaneronoton#viteliovespasianotito#FINAL FICHERO MAQUINAS

Los nombres deben ser proporcionados con el mismo formato que la salida del comandohostname. Por ejemplo, si el resultado de hostname en galba fuera galba.aulas y lo mis-mo sucediera para los demás nombres, el fichero de máquinas sería entonces:

#FICHERO MAQUINAS ARQ. LINUXgalba.aulasneron.aulasoton.aulas#vitelio.aulasvespasiano.aulastito.aulas#FINAL FICHERO MAQUINAS

En el caso de que tengamos nodos con múltiples procesadores, debemos indicar su númerode procesadores tras su nombre y dos puntos. Por ejemplo, si en el ejemplo anterior viteliotuviera dos procesadores el fichero de máquinas sería:

#FICHERO MAQUINAS ARQ. LINUXgalbaneronoton#vitelio:2vespasianotito#FINAL FICHERO MAQUINAS

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 máquina para permitir el uso de rsh. Por motivos de seguridad sólo debemos hacerésto si somos un administrador del sistema y entendemos lo que estamos haciedo, o en el casode que utilicemos una red aislada. Por ejemplo, si estamos utilizando una red Linux en nuestracasa o en el trabajo, y estas máquinas no están conectadas a una red más grande, debemosseguir las siguientes instrucciones. Si por el contrario alguna de nuestras máquinas está conec-tada a otra red, debemos preguntarle a nuestro administrador del sistema acerca de la políticade utilización de rsh. Como alternativa podemos usar ssh.

Lo siguiente explica cómo configurar una máquina de manera que pueda usar rsh parainiciar un proceso en ella misma. Para ello debemos asegurarnos de que exista un fichero‘/etc/hosts.equiv’ que contenga al menos las siguientes líneas:

localhostnombre_maquina

donde nombre_maquina es el nombre que le damos a nuestra máquina en ‘/etc/hosts’. Paraeste propósito también podemos utilizar el fichero ‘.rhosts’ en el directorio de casa si quer-emos aplicarlo sólo a una cuenta de usuario. Por otro lado debemos asegurarnos de que losficheros ‘/etc/hosts.allow’ y ‘/etc/hosts.deny’ estén vacíos.

A.4.3. SSH

El mecanismo habitual para el arranque de procesos remotos al utilizar el dispositivoch_p4 en redes es rsh. El uso de rsh requiere ciertos permisos en las máquinas implicadas. Sinembargo en algunas redes no conviene establecer los permisos de esta manera. La alternativamás simple a rsh es el uso de ssh (“Secure Shell”, Shell Seguro). Éste puede ser utilizado comomecanismo seguro de procesamiento distribuido. Requiere cierta configuración que describire-mos seguidamente, aunque su utilización es muy sencilla. Dicha configuración depende de laversión de ssh que vayamos a utilizar.

Exponemos a continuación 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 versión. Si no está instalado podemos obtenerlo nosotros mismos(URL [12]).

2. Crear nuestra clave de autentificación.

a) Si utilizamos SSH Versión 1 ejecutaremos:

$ ssh-keygen

Ésto creará el par clave privada/pública. La clave privada se almacenará en

~/.ssh/identity

y la clave pública se guardará en

~/.ssh/identity.pub

b) Si utilizamos SSH Versión 2 ejecutaremos:

A.4. CONFIGURACIÓN 169

$ ssh-keygen -t dsa

Si no lo hacemos así, generaremos una clave rsa1 que no podrá ser usada con SSHVersión 2. Dicha orden creará el par clave privada/pública. La clave privada sealmacenará en

~/.ssh/id_dsa

y la clave pública se guardará en

~/.ssh/id_dsa.pub

3. Autorizar el acceso. Si estamos utilizando SSH Versión 1 añada su clave pública alfichero ‘/.ssh/authorized_keys’. Todas las claves de este fichero tendrán permitido elacceso:

$ cp ~/.ssh/identity.pub ~/.ssh/authorized_keys

Si la máquina 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 máquina a la que queremos conectarnos. Debemos ase-gurarnos de que el fichero ‘~/.ssh/authorized_keys’ no tenga permiso de escritura porparte de los miembros de nuestro grupo, de manera que tendremos que ejecutar:

$ chmod go-rwx ~/.ssh/authorized_keys

En caso de utilizar SSH Versión 2 copiaremos el fichero ‘id_dsa.pub’ sobre ‘autho-rized_keys2’ en vez de ‘authorized_keys’. Por lo demás 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 dosformas:� Ejecutar configure con la opción -rsh=ssh para que el dispositivo ch_p4 utilice ssh en

vez de rsh. De esta manera también los scripts serán modificados para hacer uso de ssh.Si MPICH ya había sido compilado antes debemos reconfigurar y recompilar utilizandolos siguientes comandos:

$ configure -rsh=ssh$ make

Si no es así utilizaremos las opciones -prefix para indicar el directorio de la instalación,y -rsh=ssh para elegir ssh como programa de arranque de procesos remotos. Luegocompilaremos:

$ ./configure -rsh=ssh -prefix=$HOME/mpich-1.2.4| tee c.log

$ make

170 APÉNDICE A. INSTALACIÓN, CONFIGURACIÓN Y MANEJO DE MPICH� 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:� Asegúrese de que las máquinas listadas en nuestro fichero de máquinas estén tambiénlistadas 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, conroot como dueño 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 acelerareste proceso. Este programa se llama “Secure Server” (Servidor Seguro) y se localiza en elfichero ‘bin/serv_p4’ dentro del directorio de instalación de MPICH.

El script ‘bin/chp4_servs’ puede ser utilizado para iniciar el servidor seguro en aquellasestaciones de trabajo en las que podamos ejecutar programas remotos mediante rsh, ssh o sim-ilar. También podemos iniciar el servidor a mano y permitir que se ejecute en segundo plano;ésto es apropiado en máquinas que no acepten conexiones remotas y sin embargo tengamosuna 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 unpassword, también lo requerirá el servidor seguro. De este modo el servidor seguro tiene dosimplicaciones bien diferenciadas en la seguridad:

1. Para ejecutarlo de manera remota en otras máquinas necesitamos tener conexión rsh,ssh o similar con ellas.

2. El servidor seguro utiliza el mismo procedimiento que rsh para comprobar los permisosde ejecución de los usuarios remotos.

Por lo tanto la manera más cómoda de utilizarlo es empleando rsh como programa de arranquede procesos remotos. Por otro lado también podemos usar ssh para ejecutar el servidor demanera remota, y establecer la configuración adecuada para poder ejecutar procesos medianteel servidor seguro (aunque ni siquiera esté instalado rsh). En este caso debemos tener en cuentaque los scripts generados por MPICH utilizan por defecto rsh para su ejecución; si queremosque dichos scripts hagan uso de ssh, tendremos que modificarlos o configurar MPICH con laopción -rsh=ssh.

A.5. COMPILACIÓN Y ENLACE DE PROGRAMAS 171

Debemos aclarar que tanto el fichero ‘serv_p4’ como ‘chp4_servs’ se encuentran en di-rectorios pertenecientes a la instalación de MPICH, generados por la ejecución del comando‘make install’ (sección A.3).

Antes de arrancar el servidor debemos comprobar si el servidor seguro ha sido inicializadoen nuestro sistema para uso general; si es así, el mismo servidor puede ser utilizado por todoslos usuarios. Para realizarlo de esta manera necesitamos acceder al sistema como root. Siel servidor seguro no ha sido inicializado, entonces podemos inicializarlo para nuestro usopersonal sin necesisdad de privilegios especiales con la orden:

$ chp4_servs -port=1234

Esta orden inicializa el servidor seguro en todas las máquinas listadas en el fichero de máquinas(sección A.4.1). El número de puerto proporcionado por la opción -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 número de puerto en el cual inicializamos el servi-dor seguro. Cuando estas variables de entorno están establecidas, mpirun intenta utilizar elservidor seguro para arrancar programas que usen el dispositivo ch_p4; si ésto no da resultadoutilizará el programa de arranque de procesos remotos que tengamos por defecto (normal-mente rsh o ssh). También podemos hacer que mpirun utilice el servidor seguro empleandola opción -p4ssport <num>, que indica el número de puerto donde el servidor seguro estáinstalado.

A.5. Compilación y Enlace de Programas

La implementación 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 compiladoresde C, Fortran 77, C++ y Fortran 90. Por ejemplo, para compilar utilizaríamos las siguientesórdenes:

mpicc -c foo.cmpif77 -c foo.fmpiCC -c foo.Cmpif90 -c foo.f

Mientras que para enlazar utilizaríamos:


mpicc -o foo foo.ompif77 -o foo foo.ompiCC -o foo foo.ompif90 -o foo foo.o

Las órdenes para enlazar código pueden requerir la inclusión de librerías adicionales. Porejemplo, para utilizar la librería de funciones matemáticas de C usaríamos la siguiente orden:

mpicc -o foo foo.o -lm

También podemos combinar la compilación y el enlace en una sola orden, como exponemos acontinuación:

mpicc -o foo foo.cmpif77 -o foo foo.fmpiCC -o foo foo.Cmpif90 -o foo foo.f

Notar que mientras los sufijos .c para los programas en C y .f para los programas en Fortran-77son estándar, 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 mayoría de lossistemas, aunque no todos. MPICH intenta determinar los sufijos aceptados, pero no es capazsiempre.

Podemos modificar la elección del compilador a utilizar por MPICH especificando las vari-ables de entorno MPICH_CC, MPICH_F77, MPICH_CCC y MPICH_F90. Sin embargo éstosólo funcionará si el compilador alternativo es compatible con el compilador por defecto (estoquiere decir que utilice los mismos tamaños para los tipos de datos y sus composiciones, y quegenere un código objeto que sea compatible con el utilizado en las librerías MPICH). Si lo quequeremos 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 utilizaría la orden de compilación sin ejecu-tarlos realmente emplearemos el argumento -show.

Las siguientes opciones nos ayudan a acceder a las librerías de monitorización del entornoMPE:

-mpilog Compila una versión que genera el fichero de recorrido de la ejecución.

-mpitrace Compila una versión que muestra el trazado de la ejecución.

-mpianim Compila una versión que genera animación en tiempo real.

A.6. Ejecución de Programas con mpirun

Para ejecutar programas MPI debemos utilizar el programa mpirun, localizado en el di-rectorio ‘bin/’ de MPICH. Bajo la mayoría de los sistemas podremos usar la orden

mpirun -np 4 a.out

A.7. EXTENSIÓN MPE 173

para ejecutar el programa ‘a.out’ en 4 procesadores. La orden ‘mpirun -help’ nos ofrece unalista completa de las opciones que tiene este programa.

Como salida mpirun retorna el status de uno de los procesos, usualmente el proceso conidentificador 0 en MPI_COMM_WORLD.

A.7. Extensión MPE

Como ya sabemos, MPI proporciona una base estable para la construcción de programasparalelos. Uno de los objetivos de su diseño es permitir la construcción de extensiones quecontengan librerías de software paralelo que ayuden en el desarrollo de aplicaciones paralelasextensas.

La extensión MPE (“Multi-Processing Environment”, Entorno de Multi-Procesamiento)explota las características de MPI para ofrecer una serie de facilidades útiles. Dicha extensiónfué desarrollada para la implementación MPICH (estando incluida en su distribución), aunquepuede ser usada por cualquier implementación MPI.

Actualmente los principales componentes de MPE son:� Librerías de monitorización utilizadas para generar información acerca del rendimientode los programas MPI, y herramientas para el estudio y visualización de dicha informa-ción.� Librería gráfica para la ejecución de programas paralelos en X Window.� Funciones para la secuencialización del código ejecutado en paralelo.� Funciones para la depuración de errores.

Apéndice B

Manual de Referencia

Este apéndice describe de manera resumida las funciones MPI utilizadas en los algoritmosimplementados. Pretendemos que sea una guía útil como manual de consulta. Para mayorcomodidad las funciones están expuestas en orden alfabético.

Para cada una de las funciones definimos su funcionalidad y su sintaxis, especificandocuáles son los parámetros de entrada y los de salida. Por último, en algunos casos haremos unbreve comentario acerca de su funcionamiento.

175

176 APÉNDICE B. MANUAL DE REFERENCIA

B.1. MPI_Bcast

FUNCIONALIDAD

Envía un mismo mensaje desde un proceso a todos los demás. Es una operación de comu-nicación colectiva.

SINTAXIS

int MPI_Bcast(void* mensaje, int contador,MPI_Datatype tipo_datos, int raiz,MPI_Comm com);

PARÁMETROS ENTRADA/SALIDA

mensaje Dirección inicial de memoria del mensaje a enviar/recibir

contador Número 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 envía el mensaje

com Comunicador en el cual se produce la comunicación

COMENTARIOS

Si el soporte hardware se hace responsable de la ejecución de esta función, generalmentese implementa mediante un algoritmo que estructura un modelo de comunicación en árbolentre los procesos. Para más información, léase la sección ??.

B.2. MPI_CART_COORDS 177

B.2. MPI_Cart_coords

FUNCIONALIDAD

Retorna las coordenadas de un proceso en un comunicador de topología cartesiana, dadosu identificador.

SINTAXIS

int MPI_Cart_coords(MPI_Comm cart_com, int id,int numero_dimensiones,int* coordenadas)

PARÁMETROS ENTRADA

cart_com Comunicador de topología cartesiana

id Identificador del proceso dentro del comunicador cart_com

numero_dimensiones Número de dimensiones del vector coordenadas

PARÁMETROS SALIDA

coordenadas Vector de enteros (de tamaño numero_dimensiones) que contiene las coorde-nadas cartesianas del proceso


B.3. MPI_Cart_create

FUNCIONALIDAD

Crea un nuevo comunicador de topología cartesiana (tipo rejilla).

SINTAXIS

int MPI_Cart_create(MPI_Comm antiguo_com,int numero_dimensiones,int* tam_dimensiones,int* periodicidades,int reordenamiento,MPI_Comm* com_cartesiano)

PARÁMETROS ENTRADA

antiguo_com Comunicador original a partir del cual creamos el nuevo comunicador de topologíacartesiana

numero_dimensiones Número de dimensiones de la rejilla cartesiana que queremos crear

tam_dimensiones Vector de enteros de tamaño numero_dimensiones que especifica el númerode procesos en cada dimensión

periodicidades Vector de booleanos de tamaño numero_dimensiones que especifica paracada dimensión si es periódica (verdadero) o no (falso)

reordenamiento Booleano que especifica si pueden ser reordenados los identificadores de losprocesos (verdadero) o no (falso). En muchos casos es apropiado para la optimizacióndel sistema, en otros no es significante.

PARÁMETROS SALIDA

com_cartesiano Nuevo comunicador de topología cartesiana

B.4. MPI_CART_RANK 179

B.4. MPI_Cart_rank

FUNCIONALIDAD

Retorna el identificador de un proceso en un comunicador de topología cartesiana, dadassus coordenadas.

SINTAXIS

int MPI_Cart_rank(MPI_Comm cart_com, int* coordenadas,int* id)

PARÁMETROS ENTRADA


coordenadas Vector de enteros (de tamaño numero_dimensiones, véase función B.3) queespecifica las coordenadas cartesianas del proceso

PARÁMETROS SALIDA

id Identificador del proceso especificado


B.5. MPI_Cart_sub

FUNCIONALIDAD

Divide un comunicador de tipo rejilla (topología cartesiana) en rejillas de menores dimen-siones.

SINTAXIS

int MPI_Cart_sub(MPI_Comm cart_com, int* var_coords,MPI_Comm nuevo_com)

PARÁMETROS ENTRADA


var_coords Vector de booleanos que especifica para cada dimensión de cart_com si pertenecea nuevo_com, dejando que la coordenada varíe (verdadero) o no (falso)

PARÁMETROS SALIDA

nuevo_com Nuevo comunicador de topología cartesiana con igual o menor número de di-mensiones que cart_com

B.6. MPI_COMM_CREATE 181

B.6. MPI_Comm_create

FUNCIONALIDAD

Crea un nuevo comunicador a partir de otro.

SINTAXIS

int MPI_Comm_create(MPI_Comm antiguo_com,MPI_Group nuevo_grupo,MPI_Comm* nuevo_com)

PARÁMETROS ENTRADA

antiguo_com Comunicador original a partir del cual generamos el nuevo comunicador

nuevo_com Grupo que contiene los procesos que formarán parte del nuevo comunicador.Debe ser un subconjunto del grupo asociado al comunicador original (antiguo_com).

PARÁMETROS SALIDA

nuevo_com Nuevo comunicador


B.7. MPI_Comm_group

FUNCIONALIDAD

Retorna el grupo asociado a un comunicador determinado.

SINTAXIS

int MPI_Comm_group(MPI_Comm com, MPI_Group* grupo)

PARÁMETROS ENTRADA

com Comunicador

PARÁMETROS SALIDA

grupo Grupo asociado al comunicador

B.8. MPI_COMM_RANK 183

B.8. MPI_Comm_rank

FUNCIONALIDAD

Retorna el identificador de un proceso dentro de un comunicador.

SINTAXIS

int MPI_Comm_rank(MPI_Comm com, int* id)

PARÁMETROS ENTRADA

com Comunicador dentro del cual el proceso tiene asociado el identificador

PARÁMETROS SALIDA

id Identificador del proceso dentro del comunicador com


B.9. MPI_Comm_size

FUNCIONALIDAD

Determina el número de procesos pertenecientes al grupo asociado a un comunicador.

SINTAXIS

int MPI_Comm_size(MPI_Comm com, int* numprocs)

PARÁMETROS ENTRADA

com Comunicador al cual está asociado el grupo cuyo tamaño queremos conocer

PARÁMETROS SALIDA

numprocs Número de procesos en el grupo del comunicador (entero)

B.10. MPI_COMM_SPLIT 185

B.10. MPI_Comm_split

FUNCIONALIDAD

Particiona un comunicador en varios subconjuntos de procesos y crea un nuevo comuni-cador para cada uno de ellos.

SINTAXIS

int MPI_Comm_split(MPI_Comm antiguo_com,int clave_particion,int clave_id, MPI_Comm* nuevo_com)

PARÁMETROS ENTRADA

antiguo_com Comunicador original a partir del cual creamos los nuevos comunicadores

clave_particion Número que representa el nuevo comunicador en el cual quedará englobadoel proceso

clave_id Identificador del proceso dentro del nuevo comunicador

PARÁMETROS SALIDA

nuevo_com Nuevo comunicador (leer comentarios)

COMENTARIOS

La llamada crea un comunicador para cada valor de clave_particion. Los procesos con elmismo valor en clave_particion quedan englobados en el mismo comunicador.

Sin embargo los comunicadores creados tendrán el mismo nombre para todos los proce-sos. Imaginemos que dividimos de manera escalonada un comunicador con 9 procesos en trescomunicadores 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, 4y 5 el grupo subyacente a nuevo_com será el formado por los procesos 3, 4 y 5; y lo mismoocurrirá con los procesos 6, 7 y 8.


B.11. MPI_Finalize

FUNCIONALIDAD

Finaliza el entorno de ejecución MPI. Después de que el programa haya acabado de utilizarla librería MPI, se debe hacer una llamada a MPI_Finalize. Esta función limpia todos lostrabajos no finalizados dejados por MPI (por ejemplo, envíos pendientes que no hayan sidocompletados, etc.).

SINTAXIS

int MPI_Finalize()

Esta función no tiene parámetros.

B.12. MPI_GET_PROCESSOR_NAME 187

B.12. MPI_Get_processor_name

FUNCIONALIDAD

Retorna el nombre del procesador donde está ubicado el proceso.

SINTAXIS

int MPI_Get_processor_name(char* nombre, int* longnombre)

PARÁMETROS SALIDA

nombre Vector de caracteres cuyo tamaño debe ser al menos igual a la constanteMPI_MAX_PROCESSOR_NAME destinado a contener el nombre del procesador

longname Longitud (en caracteres) de la cadena obtenida

COMENTARIOS

El nombre retornado debe identificar un elemento hardware específico; el formato exactoestará definido por la implementación.


B.13. MPI_Group_incl

FUNCIONALIDAD

Crea un nuevo grupo a partir de una lista de procesos pertenecientes a un grupo existente.

SINTAXIS

int MPI_Group_incl(MPI_Group antiguo_grupo,int tamano_nuevo_grupo,int* ids_antiguo_grupo,MPI_Group* nuevo_grupo)

PARÁMETROS ENTRADA

antiguo_grupo Grupo original a partir del cual generamos el nuevo grupo

tamano_nuevo_grupo Número de procesos que formarán el nuevo grupo

ids_antiguo_grupo Identificadores de los procesos que formarán parte del nuevo grupo (vec-tor de enteros)

PARÁMETROS SALIDA

nuevo_grupo Nuevo grupo derivado del existente, reordenado según el vector ids_antiguo_grupo.

B.14. MPI_INIT 189

B.14. MPI_Init

FUNCIONALIDAD

Inicializa el entorno de ejecución MPI. Antes de que podamos llamar a cualquier otrafunción MPI, debemos hacer una llamada a MPI_Init; esta función sólo debe ser llamadauna vez. Permite al sistema hacer todas la configuraciones necesarias para que la librería MPIpueda ser usada.

SINTAXIS

int MPI_Init(int *argc, char ***argv);

PARÁMETROS ENTRADA

argc Puntero al número de argumentos

argv Puntero a los vectores de argumentos


B.15. MPI_Irecv

FUNCIONALIDAD

Inicializa la recepción de un mensaje no bloqueante.

SINTAXIS

int MPI_Recv(void* mensaje, int contador,MPI_Datatype tipo_datos, int origen,int etiqueta, MPI_Comm com,MPI_Request* peticion)

PARÁMETROS ENTRADA

contador Número 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


PARÁMETROS SALIDA

mensaje Dirección inicial de memoria del mensaje a recibir

peticion Manejador de la petición

COMENTARIOS

Esta función recibe mensajes de tipo no bloqueante. Ello quiere decir que la ejecución delprograma no se bloquea con la llamada a esta función.

B.16. MPI_ISEND 191

B.16. MPI_Isend

FUNCIONALIDAD

Inicializa el envío de un mensaje no bloqueante a un proceso determinado.

SINTAXIS

int MPI_Isend(void* mensaje, int contador,MPI_Datatype tipo_datos, int destino,int etiq, MPI_Comm com,MPI_Request* peticion)

PARÁMETROS ENTRADA

mensaje Dirección inicial de memoria del mensaje a enviar

contador Número 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 comunicación

PARÁMETROS SALIDA


COMENTARIOS

Esta función envía mensajes de tipo no bloqueante. Ello quiere decir que la ejecución delprograma no se bloquea con la ejecución de la llamada.


B.17. MPI_Recv

FUNCIONALIDAD

Recibe un mensaje básico de un proceso.

SINTAXIS

int MPI_Recv(void* mensaje, int contador,MPI_Datatype tipo_datos, int origen,int etiqueta, MPI_Comm com,MPI_Status* status)

PARÁMETROS ENTRADA

contador Número 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)




PARÁMETROS SALIDA

mensaje Dirección inicial de memoria del mensaje a recibir

status Objeto que representa el estado de la recepción

COMENTARIOS

Esta función recibe mensajes de tipo bloqueante. Ello quiere decir que la ejecución delprograma se bloquea hasta que el mensaje ha sido recibido.

B.18. MPI_REDUCE 193

B.18. MPI_Reduce

FUNCIONALIDAD

Reduce valores en todos los procesos a un solo valor. Realiza una operación de reducción.

SINTAXIS

int MPI_Reduce(void* operando, void* resultado,int contador, MPI_Datatype tipo_datos,MPI_Op operacion, int raiz,MPI_Comm com);

PARÁMETROS ENTRADA

operando Dirección inicial de memoria de los valores a operar

contador Número de elementos del tipo tipo_datos que componen cada uno de los operandosy el resultado

tipo_datos Tipo de datos MPI de los valores a operar

operacion Operación de reducción a realizar (Cuadro 6.1)

raiz Identificador del proceso que recibe el valor calculado


PARÁMETROS SALIDA

resultado Dirección inicial de memoria del valor calculado a recibir (significante sólo en elproceso raiz)


B.19. MPI_Send

FUNCIONALIDAD

Envía un mensaje básico a un proceso determinado.

SINTAXIS

int MPI_Send(void* mensaje, int contador,MPI_Datatype tipo_datos, int destino,int etiq, MPI_Comm com)

PARÁMETROS ENTRADA

mensaje Dirección inicial de memoria del mensaje a enviar

contador Número 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)




COMENTARIOS

Esta función envía mensajes de tipo bloqueante. Ello quiere decir que la ejecución delprograma se bloquea hasta que el mensaje ha sido enviado.

B.20. MPI_SENDRECV_REPLACE 195

B.20. MPI_Sendrecv_replace

FUNCIONALIDAD

Envía y recibe un mensaje básico utilizando un sólo buffer.

SINTAXIS

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)

PARÁMETROS ENTRADA

mensaje Dirección inicial de memoria del mensaje a enviar y en la cual recibiremos el nuevomensaje

contador Número 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


COMENTARIOS

Esta función envía/recibe mensajes de tipo bloqueante. Ello quiere decir que la ejecucióndel programa se bloquea hasta que el mensaje ha sido enviado/recibido.


B.21. MPI_Type_commit

FUNCIONALIDAD

Acomete un tipo de datos MPI.

SINTAXIS

int MPI_Type_commit(MPI_Datatype* tipo_datos_MPI)

PARÁMETROS ENTRADA

tipo_datos_MPI Tipo de datos MPI

B.22. MPI_TYPE_STRUCT 197

B.22. MPI_Type_struct

FUNCIONALIDAD

Crea un tipo de datos MPI para estructuras.

SINTAXIS

int MPI_Type_struct(int contador,int longitudes_bloque[],MPI_Aint indices[],MPI_Datatype antiguos_tipos_datos,MPI_Datatype* nuevo_tipo)

PARÁMETROS ENTRADA

contador Número de bloques

longitud_bloque Número de elementos de tipo tipo_datos_elem de cada bloque

indices Dirección relativa de cada bloque

antigus_tipo_datos Tipos de datos de cada bloque

PARÁMETROS SALIDA

nuevo_tipo Nuevo tipo de datos MPI


B.23. MPI_Type_vector

FUNCIONALIDAD

Crea un tipo de datos MPI para vectores.

SINTAXIS

int MPI_Type_vector(int contador, int longitud_bloque,int salto, MPI_Datatype tipo_datos_elem,MPI_Datatype* nuevo_tipo)

PARÁMETROS ENTRADA

contador Número de bloques

longitud_bloque Número de elementos de tipo tipo_datos_elem en cada bloque

salto Número de elementos de tipo tipo_datos_elem que hay entre los sucesivos elementosde nuevo_tipo.

tipo_datos_elem Antiguo tipo de datos

PARÁMETROS SALIDA

nuevo_tipo Nuevo tipo de datos MPI

B.24. MPI_WAIT 199

B.24. MPI_Wait

FUNCIONALIDAD

Espera a que se complete un envío o una recepción de un mensaje.

SINTAXIS

int MPI_Wait(MPI_Request* peticion,MPI_Status* status)

PARÁMETROS ENTRADA


PARÁMETROS SALIDA

status Objeto que representa el estado del envío/recepción del mensaje


B.25. MPI_Waitall

FUNCIONALIDAD

Espera a que se completen todas las peticiones especificadas en un vector.

SINTAXIS

int MPI_Waitall(int contador,MPI_Request* vector_peticiones,MPI_Status* status)

PARÁMETROS ENTRADA

contador Longitud del vector de peticiones

vector_peticiones Vector de peticiones

PARÁMETROS SALIDA


B.26. MPI_WAITANY 201

B.26. MPI_Waitany

FUNCIONALIDAD

Espera a que se complete cualquiera de las peticiones especificadas en un vector.

SINTAXIS

int MPI_Waitany(int contador,MPI_Request* vector_peticiones,int* indice,MPI_Status* status)

PARÁMETROS ENTRADA

contador Longitud del vector de peticiones

vector_peticiones Vector de peticiones

PARÁMETROS SALIDA

indice Posición de la petición satisfecha en el vector de peticiones



B.27. MPI_Wtime

FUNCIONALIDAD

Retorna el tiempo transcurrido para un proceso.

SINTAXIS

double MPI_Wtime()

VALOR DE RETORNO

Tiempo en segundos desde que comenzó la ejecución del proceso.

Conclusiones

Para llegar a ciertas conclusiones en el estudio realizado lo primero que debemos hacer esanalizar los resultados obtenidos en las ejecuciones de los algoritmos paralelos. Sólo de estemodo podremos demostrar la utilidad y potencialidad del procesamiento paralelo ejecutado enredes bajo Linux.

Sumario de Resultados

Comenzaremos el análisis observando algunos gráficos ciertamente determinantes. Lafigura 1 muestra un gráfico que representa el tiempo de ejecución del algoritmo Cálculo deÁreas mediante Montecarlo utilizando paso de mensajes no bloqueantes.

0

20

40

60

80

100

120

140

0 2 4 6 8 10 12 14 16

Tie

mpo

(se

g)



Tiempo Ejecucion

Figura 1: Gráfico Tiempo Ejecución Cálculo de Áreas No Bloqueante

En el gráfico observamos una notoria reducción en el tiempo de ejecución de dicho algo-ritmo conforme incorporamos procesadores al cómputo. Ello es lógico debido a que se trata de

203

204 CONCLUSIONES

un algoritmo cuyo rendimiento depende básicamente de la capacidad de cómputo que tenga lamáquina en la cual lo ejecutamos. Además tenemos la gran ventaja de que si dividimos dichocómputo en varios elementos procesadores, el proceso de converger los resultados parcialesde cada uno de los elementos procesadores es bastante sencillo: sólo tenemos que hacer la me-dia de todos ellos. Así pues este algoritmo se muestra muy apropiado para el procesamientoparalelo. El rendimiento obtenido en la versión bloqueante de dicho algoritmo es sólo un pocoinferior al obtenido en la versión no bloqueante, aunque su comportamiento es similar.

En la misma línea se encuentra el algoritmo Regla del Trapecio. En la figura 2 tenemos elgráfico que muestra el rendimiento de dicho algoritmo. De nuevo observamos una importantereducción del tiempo necesario para su ejecución. 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 aproximacionesque hacemos en estos algoritmos dependerá del número de muestras aleatorias recogidas en elalgoritmo Cálculo de Áreas mediante Montecarlo, y del número de intervalos generados en elalgoritmo Regla del Trapecio. Por supuesto el nivel de detalle queda fijado de antemano antesde realizar las pruebas de rendimiento con distintas cantidades de procesadores.

0

20

40

60

80

100

120

140

0 2 4 6 8 10 12 14 16

Tie

mpo

(se

g)


Regla del Trapecio: Tiempo Ejecucion

Tiempo Ejecucion

Figura 2: Gráfico Tiempo Ejecución Regla del Trapecio

Por otro lado el algoritmo Multiplicación de Matrices de Fox tiene una serie de carac-terísticas que lo diferencian del resto. Una de ellas es la exactitud; aquí no tratamos de haceraproximaciones precisas, a diferencia de los algoritmos anteriormente expuestos. En este al-goritmo multiplicamos matrices cuadradas particionándolas en submatrices. Cada proceso eneste caso se encargará de calcular una submatriz de la matriz resultado.

La principal dificultad en este caso es la sobrecarga en la comunicación. El hecho de tenerque transmitir submatrices enteras entre los procesadores dificulta mucho el cálculo fluido.

205

Sin embargo obtenemos resultados muy interesantes en el cómputo de matrices de un ordenelevado. Como podemos observar en la figura 3 el crecimiento del tiempo de ejecución esexponencial para todas las cantidades de procesos utilizadas; sin embargo dicho crecimientoes más paulatino cuanto mayor es la cantidad de procesos empleados.

0

500

1000

1500

2000

2500

500 1000 1500 2000 2500 3000 3500 4000 4500 5000

Tie

mpo

(se

g)

Orden Matriz

Comparacion Tiempo de distintas Cantidades de Procesos

16941

Figura 3: Comparación Tiempo Distintas Cantidades de Procesos Fox

El cuadro 1 muestra los tiempos obtenidos en la ejecución del algoritmo Multiplicación deMatrices 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: Evaluación Multiplicación de Matrices de Fox

Contiene para cada cantidad de procesadores empleados los tiempos obtenidos en la mul-tiplicación de matrices de distintos órdenes; los dos tiempos separados por el carácter ’/’ rep-resentan el tiempo requerido para multiplicar las matrices por un lado, y por otro el tiemporequerido 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 multiplicación óp-timo.

Pero en el análisis de los algoritmos no sólo se deben medir sus tiempos de ejecución.Una variable importante a tener en cuesta es el coste. Dicha variable relaciona el número deprocesadores empleados con el tiempo de ejecución obtenido; de este modo nos permite sabersi es rentable el uso de una cantidad mayor de procesadores en la ejecución de un algoritmodado.

El coste normalmente aumenta en la mayoría de los algoritmos al emplear una cantidadmayor de procesadores en su ejecución. En la figura 4 mostramos el coste de ejecución delalgoritmo Cálculo de Áreas mediante Montecarlo. La curva de crecimiento del coste práctica-mente se repite en la mayoría de los algoritmos (figura 5).

135

140

145

150

155

160

165

170

175

0 2 4 6 8 10 12 14 16

Cos

te


Calculo de Areas No Bloqueante: Coste

Coste

Figura 4: Gráfico Coste Cálculo de Áreas No Bloqueante

Sin embargo en la comparación de costes del algoritmo de Fox (figura 6) observamos queel coste depende tanto del número de procesos empleados como del tamaño de las matricesa multiplicar. De hecho vemos que para matrices de orden mayor a 2000 la utilización de 1sólo procesador es la más costosa. Con este planteamiento podemos prever que para tamañosde matrices superiores a los empleados en las pruebas la utilización de 16 procesadores será lamás rentable.

207

122

124

126

128

130

132

134

136

138

0 2 4 6 8 10 12 14 16

Cos

te


Regla del Trapecio: Coste

Coste

Figura 5: Gráfico Coste Regla del Trapecio

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

500 1000 1500 2000 2500 3000 3500 4000 4500 5000

Cos

te

Orden Matriz

Comparacion Coste de distintas Cantidades de Procesos

16941

Figura 6: Comparación Costes Distintas Cantidades de Procesos Fox

208 CONCLUSIONES

Corolario

Las demostraciones de la sección anterior nos permiten argumentar que el procesamien-to paralelo es una técnica que arroja resultados muy satisfactorios para cierto tipo de com-putaciones. Ciertamente en todos los algoritmos desarrollados obtenemos una mejora delrendimiento al aumentar el número de procesadores utilizados.

Sin embargo debemos advertir de que no sólo debemos tener en cuenta el tiempo de ejecu-ción de los algoritmos para evaluarlos. En muchos ambientes la incorporación de una mayorcantidad de procesadores a la ejecución de un algoritmo realmente cuesta dinero. En estos ca-sos la variable coste nos permitirá medir la rentabilidad de la inclusión de nuevos procesadoresen la ejecución. Por lo tanto deberíamos emplear más o menos procesadores dependiendo dela 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 paranuestras necesidades.

Debemos insistir en que el paralelismo es un campo realmente extenso en el cual convergenuna amplia variedad de técnicas y tecnologías, como vimos en la primera parte del presentedocumento. Nosotros sólo hemos investigado sobre el paralelismo llevado a cabo mediante lautilización de clusters; no obstante el hacerlo conlleva el obtener una cierta perspectiva delamplio 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 técnica al alcance de todos. Losestándares como MPI no sólo ofrecen este tipo de facilidades, si no que además añaden porta-bilidad a los algoritmos implementados mediante su utilización.

Con todo lo expuesto anteriormente debemos darnos cuenta de que sólo necesitamos ungrupo 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 (oincluso 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 - Versión 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/>

Procesamiento Paralelo en Redes Linux Utilizando MPI · 2005-04-05 · Resumen El presente...

Documents

Transcript of Procesamiento Paralelo en Redes Linux Utilizando MPI · 2005-04-05 · Resumen El presente...