Simulación de Message Passing Interface sobre Open Virtual Platforms para aplicaciones dirigidas a Network on Chip

Texto completo

(1)Simulación de Message Passing Interface sobre Open Virtual Platforms para aplicaciones dirigidas a Network on Chip Por: Daniel Alberto Ortiz Yepes Asesor de Tesis: Mauricio Guerrero Coasesor de Tesis: Fernando Adolfo Escobar. Tesis presentada como requisito de obtener el título de:. Ingeniero electrónico. Universidad de los Andes Facultad de Ingeniería Departamento de Ingeniería elóctrica y electrónica Bogotá D.C., Colombia Junio de 2010.

(2) Simulación de Message Passing Interface sobre Open Virtual Platforms para aplicaciones dirigidas a Network on Chip Daniel Alberto Ortiz Yepes [email protected] Universidad de los Andes Facultad de Ingeniería, 2010 Asesor de Tesis: Mauricio Guerrero Coasesor de Tesis: Fernando Adolfo Escobar. Resumen A pesar de que la computación paralela ha sido un tema estudiado por muchos años solo hasta hace unos pocos se ha planteado la idea de producir circuitos integrados con varios procesadores en su interior lo cual requiere de modelos de programación que exploten el paralelismo que ofrece este hardware. Por otro lado en el diseño de plataformas embebidas se encuentra surgiendo una topología de diseño que busca contener los problemas de escalabilidad que presenta la integración por medio de un bus de datos conocida como "Network on chip". Este proyecto propone una aproximación que permite desarrollar software multiprocesador destinado a plataformas embebidas multiprocesador haciendo uso de la herramienta Open Virtual Platforms la cual permite verificar el comportamiento del software embebido sobre un entorno computacional que emula la plataforma física. Para hacer posible la comunicación entre procesadores se hace uso del estándar MPI que por años ha representado un estándar para desarrollo de aplicaciones paralelas de memoria distribuída, en la parte final se hacen las verificaciones de la aceleración obtenida al paralelizar los algoritmos de multiplicación de matrices y ordenamiento por selección.. 2.

(3) Índice general 1. Introducción 1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5 7 7 7. 2. Conceptos básicos de paralelismo 2.1. Ejemplos básicos de algoritmos paralelos . . . . . . . . . . . . . . . . . . . . . 2.2. La taxonomía de Flynn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Límites de la aceleración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Tipos de paralelismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1. Paralelismo por memoria compartida . . . . . . . . . . . . . . . . . . . 2.4.2. Paralelismo por memoria distribuída . . . . . . . . . . . . . . . . . . . . 2.4.3. Otras alternativas de implementación de paralelismo por memoria distribuída 2.5. Algoritmos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1. Multiplicación de matrices . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2. Ordenamiento por selección . . . . . . . . . . . . . . . . . . . . . . . .. 8 8 9 9 10 10 12 13 13 13 14. 3. Introducción a Networks on chip y Open Virtual Platforms 3.1. Network on chip . . . . . . . . . . . . . . . . . . . . . . . 3.2. Plataformas Virtuales . . . . . . . . . . . . . . . . . . . . 3.3. Open Virtual Platforms . . . . . . . . . . . . . . . . . . . 3.3.1. Un ejemplo de plataforma virtual . . . . . . . . . .. . . . .. 16 16 17 18 20. . . . . . . . . .. 23 23 24 25 25 25 26 26 26 26. 4. Especificación y desarrollo del diseño 4.0.2. Especificaciones . . . . . . . . . . . . 4.1. Justificación del modelo de paso de mensajes . 4.2. Trabajos relacionados . . . . . . . . . . . . . 4.3. Diseño de la solución . . . . . . . . . . . . . . 4.3.1. MPI_Send y MPI_Recv . . . . . . . . 4.3.2. MPI_Init y MPI_Recv . . . . . . . . . 4.3.3. MPI_Comm_rank y MPI_Comm_Size 4.3.4. MPI_Barrier . . . . . . . . . . . . . . 4.4. Implementación de la solución . . . . . . . . 3. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . ..

(4) 4.4.1. Almacenamiento de datos en el periférico . . . . . . . . . . . . . . . . . 4.4.2. Comunicación mediante registros . . . . . . . . . . . . . . . . . . . . . 5. Resultados y discusión 5.1. Mediciones de desempeño y análisis 5.1.1. Multiplicación de matrices . 5.1.2. Ordenamiento por selección, 5.1.3. Ordenamiento por selección,. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . crecimiento del arreglo. . . . . . . . . . crecimiento del número de procesadores.. . . . .. . . . .. 27 27 30 30 31 32 33. 6. Conclusiones y desarrollo futuro. 35. A. Diagramas de diseño de la plataforma A.1. Descripción algorítmica de las operaciones . . . . . . . . . . . . . . . . . . . . A.2. Descripción dinámica de las operaciones . . . . . . . . . . . . . . . . . . . . .. 36 36 36. 4.

(5) Capítulo 1 Introducción El desarrollo de este trabajo representa la intersección de 3 disciplinas: El estilo de diseño de circuitos integrados de Network on Chip, la creación de plataformas virtuales haciendo uso de Open Virtual Platforms y el estudio de la paralelización de algoritmos empleando la interfaz de paso de mensajes. Las plataformas virtuales son una herramienta que permite estudiar el comportamiento del software dirigido a una plataforma embebida multiprocesador antes de que se haya desarrollado por completo el hardware de la plataforma lo cual implica una ganancia en productividad y mitiga el riesgo de incurrir en retrasos debido a que los defectos en el software se pueden identificar y corregir en etapas más tempranas del proceso de desarrollo. OVP no solo busca ser un simulador de procesador si no tambien un simulador de sistema al simular los componentes con los que los procesadores interactúan y al soportar un ambiente multiprocesador facilita la detección de los defectos asociados con el software paralelo como condiciones de carrera o interbloqueos entre otros. La interfaz de paso de mensajes (MPI) es un estándar de computación paralela mediante memoria distribuida de gran reconocimiento y el cual se destaca por su amplia funcionalidad. Al ser un estándar de memoria distribuida cada procesador posee su memoria privada la cual no es visible por los demás y toda la comunicación se realiza mediante primitivas de send y receive las cuales se transmiten a través de una tecnología de comunicación de área local como Ethernet o InfiniBand, no obstante una de las ventajas de este estándar es que las primitivas de este estándar son independientes de la tecnología lo cual le ahorra al programador tener que conocer los detalles de esta. Uno de los mayores objetivos de la industria de la fabricación de procesadores es la obtención de un mayor desempeño lo cual históricamente se había logrado aumentado la frecuencia de reloj de los procesadores lo cual funcionó hasta que se llegó a la famosa “pared de la potencia", en donde la disipación de potencia de los procesadores alcanzaba límites no tolerables, entonces la respuesta a esta problemática se basó en incorporar varios elementos de procesamiento dentro de un mismo integrado lo cual hasta el momento se ha considerado una solución exitosa y se predice que con el paso del tiempo el número de procesadores dentro de un mismo integrado crecerá a un ritmo acelerado [11]. La necesidad de dos o más procesadores de compartir información plantea la necesidad de integrar facilidades de interconexión que les permita a los procesadores comunicarse lo cual hoy en día se logra mediante la inserción de buses de datos pero a medida 5.

(6) que el numero de procesadores dentro del chip aumenta los buses de comunicaciones no escalan de una manera aceptable haciéndo que se le plantee a la industria el reto de encontrar nuevas tecnologías de comunicación intra chip. Uno de los campos donde se dispone de tecnologías de comunicación escalables es el de las redes de telecomunicaciones donde estas están diseñadas para soportar el aumento del número de nodos y teniendo en cuenta este éxito la industria de la microelectrónica quiere trasladar los conceptos de redes a la interconexión de los bloques funcionales lo cual le ha dado surgimiento al campo de Network on chip. El objetivo de esta tesis es el de proponer la implementación de un modelo de programación paralela destinado a aplicaciones sobre network on chip. Teniendo en cuenta que los detalles completos del hardware del NoC hasta el momento no se conocen se empleará la herramienta Open Virtual Platforms para realizar las validaciones del modelo. Como modelo de programación se han decidido implementar las primitivas básicas del estándar MPI, la razón tras escogencia de este estándar se explica dentro del documento. Debido al desconocimiento de los detalles completos del hardware de la plataforma se ha decidido implementar una topología en donde todos los procesadores de la red se conectan a un periférico que abstrae la funcionalidad de la red y de esta manera se obtiene una aproximación de primer nivel a la conectividad de los elementos de procesamiento. Además de la implementación de la plataforma se implementaron dos programas auxiliares donde el primero busca generar automáticamente la plataforma de un número de procesadores determinado y el segundo se enfoca en permitirle al desarrollador hacer un análisis sobre el resultado de la ejecución de un algoritmo. Para comprobar el funcionamiento de la implementación y estudiar las ganancias obtenidas por el empleo de la aceleración se emplearon dos algoritmos distintos: el de multiplicación de matrices el cual es totalmente paralelizable y el ordenamiento por selección el cual cuenta con una parte paralela y otra secuencial. La organización de este documento es la siguiente: En el capítulo 2 se introduce el tema del paralelismo y se introducen los algoritmos a ser empleados durante el proceso de verificación. En el capítulo 3 se describen las tecnologías de Network on chip y Open Virtual platforms. En el capítulo 4 se describe el diseño de la plataforma que se implementó. En el capítulo 5 se discuten los resultados de la ejecución de los algoritmos de prueba sobre la plataforma implementada. En el anexo A se incluyen los diagramas de diseño de los componentes principales de la solución.. 6.

(7) 1.1.. Objetivos. 1.1.1.. Objetivo general. Sugerir y desarrollar una plataforma de procesamiento dirigida a aplicaciones NoC en donde se solucione la distribución de las tareas de procesamiento disponibles.. 1.1.2.. Objetivos específicos. Realizar una contribución al proyecto NoC/CMUA que despeje el camino para la composición de software sobre la plataforma haciendo uso eficiente de las capacidades multiprocesador. Evaluar la viabilidad de portar una herramienta ya existente a un ambiente NoC. Obtener métricas que permitan evaluar el comportamiento de la solución sobre la plataforma embebida propuesta.. 7.

(8) Capítulo 2 Conceptos básicos de paralelismo En su versión más simple un algoritmo es considerado un conjunto de instrucciones que se ejecutan una tras otra sobre un mismo procesador. Muchas veces se plantean tareas para las cuales el poder de un solo procesador no es suficiente, estos algoritmos se presentan en diversas áreas del conocimiento como la física, la ingeniería, la meteorología y las finanzas entre otros [1]. La solución natural a este tipo de algoritmos se encuentra en el empleo de múltiples unidades de procesamiento donde su uso puede hacer que se aumente la capacidad de ejecución de instrucciones por unidad de tiempo. A pesar de los incrementos del desempeño que se presentan el paralelismo también obliga a adoptar prácticas adicionales las cuales permiten que el programa se ejecute de manera correcta. Un sistema de cómputo paralelo tiene tres parámetros principales de interés: Número de elementos de procesamiento. Infraestructura de interconexión entre elementos. Organización de la memoria. En este capítulo se presentan los principales conceptos relacionados con la computación paralela, las mediciones y topologías computacionales relacionadas.. 2.1.. Ejemplos básicos de algoritmos paralelos. El siguiente ejemplo representa el algoritmo que realiza la sumatoria de los elementos del arreglo A. Las iteraciones de este algoritmo podrían repartirse sobre distintos procesadores, llevar una cuenta distinta por procesador y combinar los resultados de cada cuenta para obtener un resultado consolidado. Al paralelizar las iteraciones se logra una aceleración de N, donde N es el número de procesadores que participan en el cálculo, el cual se hace sin tener en cuenta el costo de combinar los resultados. int j ; i n t acum=0; 8.

(9) int A[500] f o r ( j =0; j <500; j ++){ accum+=a [ j ] ; } El siguiente ejemplo corresponde a un ejemplo de un algoritmo no paralelizable [1] debido a que cada iteración del ciclo depende de la anterior lo cual evita que las iteraciones se puedan ejecutar al tiempo como en el ejemplo anterior. Este ejemplo contiene una dependencia, la cual es uno de los mayores limitadores del paralelismo. int j ; int A[500] f o r ( j =0; j <500; j ++){ A [ j ]=A [ j − 1 ] ∗ 2 . 0 ; }. 2.2.. La taxonomía de Flynn. El modelo propuesto por el científico del mismo nombre representa una clasificación sencilla de los tipos de paralelismo que se pueden implementar en una arquitectura de computadores la cual posee cuatro tipos posibles [18]: Single instruction single data: Representa un computador secuencial con solo un procesador, este no explota ningún tipo de paralelismo. Single instruction multiple data: Existen múltiples elementos de procesamiento los cuales ejecutan la misma instrucción pero actúan sobre datos diferentes. Dentro de este conjunto se encuentran los aceleradores de gráficos y los procesadores digitales de señales. Multiple instruction single data: Sobre un mismo conjunto de datos se ejecutan múltiples operaciones, se considera la menos común de todas. Multiple instruction multiple data: Los procesadores ejecutan instrucciones independientes sobre datos distintos de manera simultánea, la mayoría de sistemas multiprocesador se clasifican dentro de esta categoría.. 2.3.. Límites de la aceleración. Una de las principales métricas para evaluar el desempeño de un algoritmo paralelo es la aceleración S la cual se define como: S=. T iempo de ejecucion paralelo T iempo de ejecucion secuencial 9.

(10) A simple vista si se busca ejecutar un algoritmo con X aceleración se deberían colocar X unidades de procesamiento pero esto no siempre se cumple debido a que la aceleración depende del algoritmo a ejecutar y que tanto influya la porción secuencial de este donde la porción secuencial se considera aquella que no puede ser ejecutada en paralelo. Este hecho es enunciado por la ley de Amdahl la cual establece los límites de la aceleración de un algoritmo paralelo frente al aumento de unidades de procesamiento [13]: S=. 1 f + 1−f p. Donde p es el número de procesadores empleados en la ejecución del algoritmo y f es la fracción de las operaciones que se deben ejecutar de manera secuencial.. 2.4.. Tipos de paralelismo. La comunicación entre los elementos de procesamiento es necesaria debido a que muchas veces estos operan sobre datos que otros procesadores han modificado o simplemente existe un almacén de datos común para todos los elementos. Se consideran dos tipos principales de comunicación: la de memoria compartida y la de paso de mensajes o memoria distribuida aunque en la práctica se encuentran implementaciones que reúnen conceptos de ambas [17]. El modelo de memoria compartida presenta rápidas velocidades de comunicación pero presenta restricciones de escalabilidad y su mayor obstáculo a combatir es la sincronización. Por otro lado el modelo de memoria distribuida basa su funcionamiento en el paso de mensajes usando directivas de send y receive el cual es bastante escalable y su mayor obstáculo es la comunicación.. 2.4.1.. Paralelismo por memoria compartida. Los procesadores conectados por un sistema de memoria compartida tienen acceso a una o varias memorias a las que pueden acceder mediante instrucciones convencionales de load and store y cualquier cambio que un elemento realice sobre la memoria se refleja en los demás procesadores cuando leen la misma posición de memoria. Si múltiples procesadores intentan leer una palabra de memoria y otros escriben la misma palabra al tiempo se puede presentar un comportamiento erróneo debido a que un procesador puede interferir con la ejecución de un algoritmo ejecutado sobre otro procesador de manera no intencional. Para evitar que este inconveniente se presente se deben disponer de mecanismos que permitan controlar el acceso a los recursos compartidos. El uso de estos mecanismos implica una disminución en el desempeño debido a que si un recurso está en uso por un procesador cualquier otro procesador que lo requiera debe esperar a que el recurso sea liberado. Otra problemática frecuente en los sistemas de memoria compartida se presenta cuando los procesadores tienen múltiples versiones de la misma variable lo cual se da por el uso de cachès con lo cual puede que la variable consultada no represente la versión más reciente o que al escribir una variable se demore en reflejar los cambios en la memoria original. Cuando esta situación se presenta se debe imponer un modelo de consistencia el cual representa un conjunto de normas 10.

(11) que el software debe seguir para que no se presenten inconsistencias en la información contenida en el hardware. Otra de las limitaciones de los sistemas de memoria compartida es la escalabilidad debido a que si se agregan muchos procesadores se presenta una baja considerable en el desempeño debido al ancho de banda limitado de las memorias, este problema se conoce como el fenómeno de contención de memoria. Paralelismo por memoria compartida con OpenMP OpenMP tiene como punto de partida el paralelismo que se puede presentar en los bucles de código como se mostró en la sección 2.1. Las directivas de OpenMP se le agregan a un programa secuencial a manera de anotaciones (pragmas). Al compilar el programa estas son reconocidas y se transforman en instrucciones de la librería de ejecución de OpenMP. Mediante este modelo de anotaciones se busca que el programador no tenga que especificar los detalles específicos del manejo de hilos a nivel del sistema operativo lo cual facilita la redacción del código. El siguiente es un ejemplo de un programa implementado con ayuda de OpenMP donde se realiza el cálculo de PI [3]: s t a t i c long num_rect = 1 0 0 0 0 0 ; double width , a r e a ; void main ( ) { int i ; double mid , h e i g h t ; w i d t h = 1 . 0 / ( double ) num_rect ; #pragma omp p a r a l l e l f o r p r i v a t e ( mid ) r e d u c t i o n (+: h e i g h t ) f o r ( i =0; i <num_rect ; i ++) { mid = ( i +0.5)∗ w i d t h ; h e i g h t += 4 . 0 / ( 1 . 0 + mid ∗ mid ) ; } area = width ∗ height ; p r i n t f ( P i = \ %f \n " , a r e a ) ; } La anotación pragma omp parallel for indica que se quiere hacer paralela la ejecución del bloque for, el modificador private indica que cada hilo maneja su propia copia de la variable mid sin importar que esta se haya declarado por fuera del for y reduction indica que el resultado en cada hilo de la variable height se suma para producir un consolidado. El componente clave de OpenMP es el compilador, el cual se encarga de encontrar las anotaciones que indican una región paralela y las transforma a llamados a la librería de ejecución de OpenMP la cual implementa las directivas anotadas. Dentro de las principales instrucciones de OpenMP se encuentran:. 11.

(12) Barrier: Solo pasa la instrucción hasta que todos los hilos han llegado a esta, sirve para hacer sincronización. Reducción: Aplica un operador binario y recoge los resultados. Secciones críticas, las cuales aseguran que un bloque de código se ejecuta solo una vez al tiempo. Otras alternativas de implementación de paralelismo por memoria compartida Una alternativa a OpenMP es el uso de las librerías de los sistemas operativos como Pthreads de Unix las cuales permiten controlar el ciclo de vida de los hilos y estas se emplean para implementar la librería de ejecución de OpenMP. Al usar este enfoque se gana un mayor control sobre la ejecución de los hilos pero se pierde la abstracción que OpenMP provee lo cual implica un mayor esfuerzo de desarrollo.. 2.4.2.. Paralelismo por memoria distribuída. El paralelismo de memoria distribuida considera un conjunto de procesadores cada uno con su propia memoria privada invisible para los demás lo cuales intercambian información mediante la implementación de las instrucciones send y receive. Los mecanismos por los cuales se transmiten estas instrucciones son más despaciosos que un acceso a memoria por lo cual se considera que las actividades de comunicación representan un cuello de botella. Interfaz de paso de mensajes Message passing interface también conocido como MPI representa un estándar [6] que le ofrece al programador mecanismos para ejecutar algoritmos paralelos de memoria distribuida, esta es una librería de funciones con las cuales cuenta un programador para poder escribir un programa paralelo. Dentro de las implementaciones más famosas de MPI se encuentran MPICH y OpenMPI. Un cluster MPI puede dividirse en varios grupos de nodos donde un nodo puede pertenecer a uno a más grupos. Dentro de cada grupo un nodo cuenta con un identificador único. Un grupo se representa mediante una estructura de datos llamada un communicator, existe un grupo por defecto que representa a todos los nodos representado por el communicator MPI_COMM_WORLD. En la actualidad el estándar MPI representa más de 100 instrucciones pero solo se necesitan 6 para construir un programa básico: MPI_Init(): Aplica la configuración necesaria en cada nodo y hace que los nodos se reconozcan unos a otros. Cualquier comando MPI antes de esta instrucción no es válido. MPI_Finalize(): Retira el nodo de la red y finaliza la sesión de MPI dentro del nodo, después de esta instrucción cualquier comando MPI es inválido a menos de que se reinicie el nodo.. 12.

(13) MPI_Comm_rank(Communicator): Devuelve el identificador del nodo dentro del grupo (communicator). MPI_ Comm_size(Communicator): Devuelve el numero de nodos dentro del grupo. MPI_Send(buf, count, datatype, dest, Communicator): Le envía un mensaje al nodo dest dentro del grupo communicator, el mensaje se encuentra en la posición de memoria buf, los datos son de tipo datatype y la longitud del mensaje es de count, la función no retorna hasta que se haya completado con éxito la operación. MPI_Recv(buf, count, datatype, source, Communicator): Recibe un mensaje proveniente de source dentro del grupo communicator, el mensaje se encuentra en la posición de memoria buf, los datos son de tipo datatype y la longitud del mensaje es de count. La función no retorna hasta que se haya completado con éxito la operación.. 2.4.3. Otras alternativas de implementación de paralelismo por memoria distribuída Parallel Virtual Machine (PVM) es una implementación de paralelismo por mensajería similar a MPI debido a que también consta de instrucciones de paso de mensajes, manejo de tareas y recursos [19] su filosofía de desarrollo se basa en presentarle al programador un recurso computacional coherente y flexible. PVM cuenta con instrucciones básicas pvm_send, pvm_recv y pvm_barrier de funcionalidad similar a sus análogas de MPI.. 2.5.. Algoritmos de prueba. En esta sección se describen los algoritmos que se van a usar para comprobar la funcionalidad de la plataforma, primero se hace la descripción del algoritmo básica y luego de su versión paralela.. 2.5.1.. Multiplicación de matrices. Dada una matriz A de m filas y x columnas y otra matriz B de x filas y n columnas, la multiplicación de A y B resultante es una matriz C de m filas y n columas donde el elemento Cij se define como: Cij =. x Ø. aik ∗ bkj. (2.1). k=0. Teniendo en cuenta lo anterior para una columna “y"(y<n) de la matriz c los elementos son x C1y =. Ø. k=0. 13. a1k ∗ bky.

(14) Figura 2.1: Muestra de 3 iteraciones del ordenamiento por selección C2y =. x Ø. a2k ∗ bky. k=0. hasta Cmy =. x Ø. amk ∗ bky. k=0. Con base en lo anterior para calcular una columna de la matriz C es necesario conocer toda la matriz A y los elementos de la columna “y"de la matriz B. Se propone paralelizar la ejecución de este algoritmo de la siguiente manera: • El nodo maestro le envía a cada nodo auxiliar los elementos de una matriz A y una columna de la matriz B. • El nodo auxiliar recibe la matriz A y la columna de la matriz B, computa la columna resultado y se la retorna al nodo maestro. • El nodo maestro recibe las columnas resultado. El número de nodos necesarios es de n + 1 aunque podría emplearse un nodo para multiplicar varias columnas resultado. La paralelización disminuye el tiempo de ejecución del algoritmo teniendo en cuenta que los elementos de la columna se calculan en paralelo. En el caso de una matriz cuadrada para calcular un elemento se hacen n multiplicaciones y como cada nodo calcula una columna resultado de longitud n entonces en total se realizan n*n multiplicaciones lo cual indica que la longitud de ejecución de este algoritmo crece de manera cuadrática frente al aumento de n.. 2.5.2.. Ordenamiento por selección. El ordenamiento por selección [7] se basa en el principio de que dado un conjunto de elementos se puede asegurar que un elemento es el menor después de haberlo comparado contra todos los demás del conjunto. Dado un conjunto de números representado por un arreglo se encuentra que el elemento menor es el k esimo elemento el cual se intercambia con el elemento que ocupa la primera posición, posteriormente se considera el subconjunto comprendido por los elementos a partir del segundo elemento y el menor se coloca en la segunda posición. Se procede de esta manera hasta que el subconjunto restante del arreglo original es el último elemento. La figura 2.1 ilustra el funcionamiento del algoritmo. 14.

(15) Figura 2.2: Ordenamiento por selección distribuido Para paralelizar este algoritmo se subdivide el arreglo original en cuantos nodos se quiere tener en la red entonces se le envía el subarreglo a cada nodo para que lo ordene y retorne sus resultados, a partir de estos resultados el nodo maestro tiene los subarreglos ordenados y el menor elemento es el menor de los elementos que se encuentre en la primera posición de cada subarreglo. La figura 2.2 ilustra el funcionamiento del algoritmo.. 15.

(16) Capítulo 3 Introducción a Networks on chip y Open Virtual Platforms En este capítulo se mencionan los conceptos fundamentales de Network on Chip el cual es el campo de aplicación final del proyecto y tambien se discute la tecnología de plataformas virtuales la cual representa el vehículo de implementación.. 3.1.. Network on chip. Los crecientes niveles de integración han llevado a que cada vez más se coloque un mayor grado de funcionalidad dentro de un mismo circuito integrado. Esta funcionalidad es de distintos tipos como video, comunicación, compresión entre otros. Hace pocos años se dió un salto fundamental en la industria de los microprocesadores cuando se llegó al límite del desempeño de los procesadores de un solo núcleo y se comenzaron a incluir múltiples núcleos dentro de un mismo integrado con el fin de aumentar la capacidad de procesamiento. Dentro de un circuito integrado multinúcleo existen múltiples unidades de procesamiento que necesitan comunicarse entre sí. Una de las maneras más comunes de comunicación es el bus de datos el cual ha sido ampliamente empleado, pero con el aumento de los núcleos de procesamiento dentro de un circuito integrado esta solución presenta problemas de escalabilidad. La introducción de los integrados multinúcleo ha logrado mejorar el desempeño de procesamiento pero ha planteado nuevos interrogantes relacionados con la comunicación de los módulos que se encuentran dentro de un circuito integrado debido a que al incluir más componentes las soluciones de interconexión ocupan un mayor área de chip y representan una de las mayores fuentes de disipación de potencia dentro del circuito. La problemática anterior le ha llevado a concluir a algunos expertos a que la industria de los microprocesadores se encuentra en la transición desde un modelo de diseño basado en el cómputo 16.

(17) Figura 3.1: Comparación entre las interconexiones de buses jerárquicos y la Network on Chip. Figura www.Arteris.com hasta uno basado en las comunicaciones [5]. Las redes de comunicaciones basadas en paquetes han demostrado por varios años sus beneficios en términos de escalabilidad lo cual ha llevado a proponer que la tecnología de redes puede emplearse para interconectar los módulos dentro de un chip [2], aunque se debe tener en cuenta las restricciones propias del diseño de integrados que no poseen las redes tradicionales tales como el consumo de potencia y el área de silicio entre otros. La anterior propuesta le ha dado nacimiento al término network on chip. A pesar de que originalmente se consideró el uso de redes de conmutación de paquetes hoy en día también se considera el uso de redes por conmutación de circuitos. Dentro de las ventajas de las topologías network on chip se encuentra su buen comportamiento ante un número creciente de nodos y el fuerte soporte de las técnicas de reuso de los bloques IP debido a que permite que los recursos funcionales se puedan diseñar de una manera independiente y posteriormente estos se pueden unir de una manera “plug and play"lo cual es un fuerte impulsor de la productividad de los diseñadores de sistemas basados en SoC [5].. 3.2.. Plataformas Virtuales. El entorno altamente competitivo de hoy le ha impuesto a los desarrolladores de sistemas embebidos un menor time to market lo cual implica menores tiempos de desarrollo. En el ciclo tradicional de diseño de sistemas embebidos la existencia de la plataforma hardware es un prerequisito para poder realizar las pruebas del software. La necesidad de evitar este prerequisito ha sido evidente por mucho tiempo lo cual ha llevado a adoptar prácticas como construir un prototipo de la plataforma sobre una o varias FPGAs o usar un emulador RTL del hardware. Estos métodos se consideran poco adecuados debido a que el primero provee poca observabilidad es decir es difícil de observar la ejecución del software 17.

(18) y su interacción con los componentes de la plataforma y el segundo es bastante costoso computacionalmente. Dentro de los factores que impulsan una creciente complejidad del software se encuentran el aumento de la cantidad de líneas de código que poseen los productos y la movida hacia los circuitos integrados multiprocesador, este último le agrega un factor de complejidad adicional debido a que el software paralelo introduce nuevos comportamientos erróneos como las condiciones de carrera y los interbloqueos. Algunas organizaciones de la industria han llegado a establecer que dentro de un proyecto de diseño con procesador el costo del software puede consumir un 80 % del presupuesto de desarrollo e incluso algunas veces este porcentaje puede ser más alto [15] lo cual le ha puesto a pensar a la industria y a la academia maneras de modificar el ciclo de diseño. Una plataforma o prototipo virtual se considera un prototipo del sistema que solo existe en software [14] mediante el uso de esta se busca emular la funcionalidad del hardware con el fin de que los desarrolladores del software puedan iniciar las pruebas del software sin tener la plataforma hardware definitiva con lo cual se independiza el desarrollo del software del hardware y se da la posibilidad de detectar potenciales defectos en el código en étapas más tempranas, la diferencia entre ambos procesos de desarrollo de muestra en la figura 3.2. La dependencia de una plataforma hardware ahora se traslada a una dependencia sobre el prototipo virtual el cual se considera mucho más fácil de desarrollar y a medida que se progresa en el desarrollo del hardware se elabora una nueva plataforma virtual y se vuelven a ejecutar las pruebas del código. Para crear una plataforma virtual se debe disponer de los modelos software de los componentes de la plataforma física los cuales emulan el comportamiento de sus equivalentes físicos. Uno de los estándares más famosos para el modelaje de hardware es SystemC/TLM el cual se presenta como una evolución de la simulación RTL al proveer mejores tiempos de respuesta. Uno de los factores de éxito de una plataforma es la abundancia de modelos lo cual depende de que tanto los fabricantes de componentes soportan la plataforma. Una de las metodologías más tradicionales de simulación de procesadores es la del instruction set simulator [9] pero esta se considera de poco desempeño y escalabilidad ante un aumento del número de procesadores lo cual lleva a la búsqueda de otras tecnologías como la traducción just in time la cual toma una instrucción en lenguaje de máquina del procesador que se simula como ARM o MIPS y se traduce a una instrucción x86 sobre la cual se ejecuta la plataforma virtual.. 3.3.. Open Virtual Platforms. OVP es una solución de prototipos virtuales la cual se diferencia de las demás soluciones del mercado al proveer su tecnología de manera gratuita y compartir muchos de los modelos de sus procesadores sin costo. El entorno de simulación de plataformas está basado en el 18.

(19) Figura 3.2: Comparación entre los procesos de desarrollo sin el uso de plataformas virtuales a la izquierda y a la derecha incuyendo su uso. Figura [8]. 19.

(20) método just in time y tiene una exactitud a nivel de instrucción (a diferencia del nivel de ciclo que tiene una simulación RTL) y dice soportar velocidades típicas de simulación de 200 MIPS, adicionalmente se han hecho pruebas sobre plataformas con más de 1000 procesadores [11]. OVP posee los modelos de procesadores de los fabricantes más importantes como ARM, MIPS y Tensilica. OVP también soporta la extensibilidad con SystemC/TLM 2.0 y la conexión de depuradores como GDB [9]. Para la descripción de los componentes de una plataforma y la plataforma completa OVP cuenta con tres librerías de modelaje en lenguaje C [10]: • ICM es la librería de creación de plataformas donde los componentes de esta se crean y unen, este también es el punto de unión con los componentes escritos en TLM. • VMI es la librería de creación de procesadores donde se hacen descripciones a nivel de comportamiento y permite la emulación de funcionalidades complejas como unidades de manejo de memoria, instrucciones privilegiadas y TLBs (Bufferes de traducción de búsqueda). Una de sus características más importantes es la del “semi hosting"la cual permite que los periféricos del computador anfitrión sean vistos como periféricos de los procesadores simulados permitiendo la adición de funcionalidades como la entrada/salida. • PPM/BHM Esta librería permite crear periféricos, consta de facilidades de manejo de tiempos, memoria y concurrencia lo cual permite emular de manera más cercana el funcionamiento del hardware. Esta es de vital importancia para el desarrollo del proyecto porque permite desarrollar el periférico MPIP el cual se explica en el siguiente capítulo. Para el programador un periférico es un archivo de código mediante el cual se describe la funcionalidad del periférico. Para la comunicación de un periférico con el procesador se disponen de registros y accesos al bus. Mediante los registros el procesador tiene mapeado en memoria el acceso a los registros es decir que al acceder a una posición de memoria desde el procesador se está teniendo acceso a la información de un registro. Cuando el procesador escribe o lee un registro se disponen de callbacks las cuales representan una llamada a una función en el código del periférico cada vez que se presenta una lectura o una escritura, también se ofrece la opción de vincular un registro a una variable de tal manera que al escribir el registro la variable se modifique o al modificar la variable este cambio se refleje al leer el registro. El acceso al bus permite leer o escribir posiciones de memoria conectadas al mismo bus que el procesador sin requerir de la intervención del procesador lo cual permite hacer grandes movimientos de datos.. 3.3.1.. Un ejemplo de plataforma virtual. A continuación se presenta un ejemplo de una plataforma con dos procesadores unidos mediante memoria compartida que está incluido dentro de los ejemplos de OVP, solo se 20.

(21) muestran las instrucciones más importantes: i c m I n i t (ICM_VERBOSE | ICM_ENABLE_IMPERAS_INTERCEPTS , 0 , 0 ) ; const char ∗ v l n v R o o t = NULL ; library const char ∗ model = icmGetVlnvString ( vlnvRoot , " o v p w o r l d . o r g " , " p r o c e s s o r " , " o r 1 k " , " 1 . 0 " , " model " ) ; const char ∗ s e m i h o s t i n g = i c m G e t V l n v S t r i n g ( v l n v R o o t , " ovpworld . org " , " semihosting " , " or1kNewlib " , " 1.0 " , " model " ) ; icmProcessorP processor0 = " cpu0 " , // " or1k " , // 0, // 0, // 32 , // model , // " modelAttrs " , // SIM_ATTRS , // 0, // semihosting , // " modelAttrs " // );. icmNewProcessor ( CPU name CPU t y p e CPU c p u I d CPU model f l a g s address bits model f i l e morpher a t t r i b u t e s simulation attributes u s e r −d e f i n e d a t t r i b u t e s semi−h o s t i n g f i l e semi−h o s t i n g a t t r i b u t e s. icmProcessorP p r o c e s s o r 1 = icmNewProcessor ( " cpu1 " , // CPU name " or1k " , // CPU t y p e 1, // CPU c p u I d 0, // CPU model f l a g s 32 , // a d d r e s s b i t s model , // model f i l e " modelAttrs " , // morpher a t t r i b u t e s SIM_ATTRS , // s i m u l a t i o n a t t r i b u t e s 0, // u s e r −d e f i n e d a t t r i b u t e s semihosting , // semi−h o s t i n g f i l e " modelAttrs " // semi−h o s t i n g a t t r i b u t e s ); icmBusP bus1 = icmNewBus ( " bus1 " , 3 2 ) ; icmBusP bus2 = icmNewBus ( " bus2 " , 3 2 ) ; i c m C o n n e c t P r o c e s s o r B u s s e s ( p r o c e s s o r 0 , bus1 , bus1 ) ; 21.

(22) i c m C o n n e c t P r o c e s s o r B u s s e s ( p r o c e s s o r 1 , bus2 , bus2 ) ; icmMemoryP 0x0fffffff icmMemoryP 0x0fffffff icmMemoryP 0xefffffff. l o c a l 1 = icmNewMemory ( " l o c a l 1 " , ICM_PRIV_RWX , ); l o c a l 2 = icmNewMemory ( " l o c a l 2 " , ICM_PRIV_RWX , ); s h a r e d = icmNewMemory ( " s h a r e d " , ICM_PRIV_RWX , );. icmConnectMemoryToBus ( bus1 icmConnectMemoryToBus ( bus2 icmConnectMemoryToBus ( bus1 icmConnectMemoryToBus ( bus2. , , , ,. "mp1" , "mp2" , "mp1" , "mp1" ,. shared shared local1 local2. , , , ,. 0 x00000000 ) ; 0 x00000000 ) ; 0 xf0000000 ) ; 0 xf0000000 ) ;. icmLoadProcessorMemory ( p r o c e s s o r 0 , a r g v [ 1 ] , F a l s e , F a l s e , True ) ; icmSimulatePlatform ( ) ; • Las instrucciones icmInit y icmSimulatePlatform marcan el inicio y el final de la descripción de la plataforma respectivamente. • La instrucción icmNewProcessor crea un procesador en la plataforma, en este caso ambos procesadores son de tipo openCores 1000. • La instrucción icmNewBus crea los buses necesarios dentro de la plataforma y la instrucción icmNewMemory crea las memorias, el último parámetro de estas instrucciones corresponde al tamaño de la memoria a emplear. • Las instrucciones icmConnectProcessorBusses e icmConnectMemoryToBus representan la integración de los componentes individuales dentro de la plataforma, en la última instrucción puede verse como se especifica el direccionamiento de las memorias dentro del bus.. 22.

(23) Capítulo 4 Especificación y desarrollo del diseño Durante este capítulo se explica el desarrollo principal del proyecto el cual consiste en la elaboración de una plataforma virtual sobre Open Virtual Platforms para verificar el correcto funcionamiento del estándar MPI para algoritmos dirigidos a Network on Chip (NoC). El principal factor que llevó a la escogencia de OVP se basa en su caracter gratuito y en el hecho de que los detalles de la plataforma hardware del Network on Chip a desarrollar aun no son conocidos en su totalidad. La plataforma OVP a desarrollar se ilustra en la figura 5.1, esta consta de los diferentes nodos de procesamiento los cuales cuentan con una cpu, una memoria RAM y un bus de datos. Cada nodo de procesamiento tiene un identificador entero único. La infraestructura de red que consta de los adaptadores de red de los nodos, los circuitos de conmutación y las vías de comunicación es abstraída mediante un periférico llamado MPIP. El periférico MPIP interactúa con los procesadores mediante un conjunto de registros que expone, adicionalmente MPIP está conectado al bus de datos de cada nodo como un maestro de bus con lo cual tiene la capacidad de copiar los mensajes que se envíen hacia o reciban desde el nodo según sea el caso directamente sin intervención del procesador. La idea detrás del desarrollo de esta plataforma es que el programador pueda hacer una validación de los algoritmos distribuidos sin que se tengan las especificaciones o el modelo concreto de la NoC. Cuando el procesador envía un mensaje este es copiado dentro de la memoria del periférico y al ser leído por el procesador destino es copiado desde el periférico hacia la memoria del procesador.. 4.0.2.. Especificaciones. Se han identificado los siguientes requerimientos para la plataforma: • El número de procesadores que posee la plataforma debe ser ajustable. • Se deben soportar procesadores de distintos fabricantes. 23.

(24) Figura 4.1: Diagrama de la plataforma a implementar • Debe ser posible hacer mediciones sobre el desempeño del procesador es decir cuánto se demora en ejecutar un determinado bloque de instrucciones.. 4.1.. Justificación del modelo de paso de mensajes. La razón por la que se escogió el paso de mensajes para emplearse como protocolo de comunicación se basa en que este es el modelo más usado en los trabajos realizados sobre el tema [4] [16] [12]. Adicionalmente Wolf [20] ha compilado una lista de razones por las cuales este modelo se considera más apropiado para operaciones sobre network on chip. • El software que hace explicita la comunicación entre tareas paralelas es más apropiado para sistemas en chip de aplicación específica. • El software basado en paso de mensajes permite alcanzar un mayor desempeño a costo de un mayor esfuerzo de desarrollo. • Al hacer la comunicación explícita en las directivas de paso de mensajes se destacan los mayores factores de no predictibilidad en la ejecución de un programa como la latencia y el throughput, entonces la adopción de un modelo de paso de mensajes hace que los programas se vuelvan más predecibles. • Es natural adoptar un estilo de programación que soporta el paralelismo a gran escala aun si el precio a pagar se adopta en mayores latencias de comunicación.. 24.

(25) 4.2.. Trabajos relacionados. La investigación sobre networks on chip en la actualidad se encuentra activa en varias universidades del mundo y parte de esta investigación ha sido dedicada a portar el estándar MPI a entornos embebidos. La propuesta de [12] consiste de un network on chip de 4 nodos sobre una FPGA, la plataforma software consta de las 6 instrucciones básicas de MPI (MPI_Send, MPI_Recv, MPI_Init, MPI_Finalize, MPI_Comm_rank y MPI_Comm_size). Dentro los resultados más destacados se halla una ocupación del 58 % de los recursos de la FPGA en la infraestructura de red y una implementación MPI de 1500 líneas de código que presenta una pequeña huella de memoria. El entorno TD-MPI [16] es una librería de intercambio de mensajes inter e intra FPGA, consta de 11 instrucciones además de las 6 básicas (Broadcast, Gather, Wtime, Reduce y Barrier ). Para el tráfico de mensajes se implementó un protocolo de tipo rendezvous el cual indica que para enviar un paquete se le debe hacer una solicitud al receptor y esperar una confirmación de que este está listo para recibir paquetes con lo que se busca proveer una implementación que premia el espacio en memoria sobre el desempeño, adicionalmente los diseñadores implementaron su propia suite de benchmarks. El sistema HSCale [4] es una implementación para NoCs donde los nodos corren el sistema operativo uCLinux y tienen la capacidad de cambiar de tareas de forma adaptativa. Para la comunicación se implementaron las instrucciones MPI_Send y MPI_Recv conformes al estándar MPI, los autores argumentan que con estas instrucciones también se puede realizar la sincronización ya que son bloqueantes. La mensajería consiste en un protocolo request-ack (acuse de recibo) y la validación de los algoritmos se realizó con un codificador MJPEG. Dentro de los trabajos encontrados sobre la implementación del software se encontró que el común denominador para el modelo de programación de un NoC era el de mensajería distribuida y poco se encontró sobre la elaboración de modelos sobre plataformas virtuales, lo cual es un punto clave de este trabajo debido a que se quiere examinar la exploración de la correcta ejecución de los programas antes de tener el diseño definitivo de la plataforma física.. 4.3.. Diseño de la solución. El primer paso para realizar la implementación de las instrucciones MPI es seleccionar cuales van a ser portadas y elaborar una estrategia de alto nivel para su implementación, la cual se describe en esta sección.. 4.3.1.. MPI_Send y MPI_Recv. La ejecución de send y receive se divide en tres etapas, como se muestra en la figura 4.2: 25.

(26) Figura 4.2: Etapas de la ejecución de las instrucciones send y receive • Solicitud: El procesador le solicita al periférico que ejecute la operación luego de haberle pasado los parámetros de esta y asegurarse de que el periférico está libre para realizarla. • Transferencia: El periférico toma el mensaje del procesador origen y lo copia en su memoria en caso del envío y en el caso de la recepción lo toma de la memoria del periférico y lo copia en la memoria del procesador destino. • Confirmación: El periférico le confirma al procesador que la operación se ha completado y que puede continuar su ejecución. Lo anterior sucede debido a que MPI especifica que las instrucciones Recv y Send son bloqueantes es decir que no pueden retornar hasta que se haya completado la operación.. 4.3.2.. MPI_Init y MPI_Recv. No existen pasos asociados a la inicialización de la plataforma embebida, no obstante se dejan en la librería con el fin de favorecer la compatibilidad con códigos existentes.. 4.3.3.. MPI_Comm_rank y MPI_Comm_Size. Estas instrucciones solo necesitan hacer uso del procesador. La primera hace uso de una función de OVP para consultar el id del procesador y la segunda devuelve una constante especificada en el archivo de descripción de la plataforma.. 4.3.4.. MPI_Barrier. Para esta instrucción cada procesador cuenta con un registro R que al ser escrito hace que se ejecute un callback en la plataforma que aumenta en uno la cuenta de los procesadores que han llegado a ese punto, posteriormente los procesadores leen otro registro S que cambia de valor cuando todos los demás procesadores han leído el registro R.. 4.4.. Implementación de la solución. El periférico cuenta con un conjunto de registros que le permiten gestionar la comunicación de control con los procesadores de la red. La transferencia de datos se lleva a cabo empleando acceso directo a memoria (DMA) al permitir que el periférico actúe como maestro de 26.

(27) bus. Cada procesador cuenta con un hilo de ejecución en el periférico que está pendiente de las solicitudes de escritura o lectura, el periférico solo puede ejecutar una operación al tiempo por canal. Para efectos de este documento por canal se comprende la representación de los datos de un procesador en el periférico.. 4.4.1.. Almacenamiento de datos en el periférico. La figura 4.3 muestra un ejemplo de la manera en que se almacenan los mensajes en el periférico, cada canal debe poder distinguir entre los mensajes que provienen de los distintos procesadores por lo cual cada canal replica esta estructura tantos procesadores existan en la plataforma de manera que si una plataforma cuenta con N procesadores en el periférico existen N*(N-1) estructuras de almacenamiento. Cada estructura posee dos buffers de tamaño programable: En el buffer de inbox se colocan los mensajes y se utiliza información adicional para controlar el almacenamiento de datos en inbox : • El apuntador WriteNext indica cual es el la siguiente posición de memoria donde se puede colocar el cuerpo de los mensajes en inbox, de igual manera nextRead indica la siguiente posición de lectura en inbox. • El buffer writeRecord se emplea para registrar la longitud de los mensajes que han ingresado a la red. Cada vez que ingresa un mensaje se registra su longitud en la posición writeOffset de writeRecord y la posición se avanza en uno. Cuando se lee un mensaje se utiliza la información de longitud ubicada en readOffset para saber cuántos bytes se deben leer. • Existe una variable llamada unread que indica cuantos mensajes se han almacenado en el periférico por canal provenientes de un remitente específico y no han sido leídos por el destinatario. Esta variable se emplea para evitar que si destinatario hace Recv y no ha recibido mensajes la función no retorne hasta que haya recibido un mensaje.. • Los buffers inboxes y writeRecord funcionan de manera circular es decir que si las variables de offset y next llegan al final de este son llevadas al inicio del buffer. Se puede dar la situación de que entren muchos mensajes a un inbox sin ser leídos lo cual lleva a que los nuevos mensajes que llegan sobrescriban la información de mensajes antiguos que aún no han sido leídos.. 4.4.2.. Comunicación mediante registros. Para la comunicación de información de control se disponen de varios registros: • CLR Barrier (R1): Solo existe un registro por plataforma. Después de haber completado un barrier todos los procesadores escriben este registro en donde se suma una variable contadora, cuando se llega a los n procesadores los registros CX_Barrier son 27.

(28) Figura 4.3: Estructura de datos empleada en el periférico para el almacenamiento de mensajes restaurados al valor BARRIER_NOT_REACHED. Para los demás registros existe uno por cada procesador: • Cx_Barrier(R2): Los procesadores lo usan para saber si todos los demás procesadores han pasado por el barrier. Al leer este registro se anota en el periférico que el procesador x ha llegado al barrier. Si no han pasado todos los procesadores por el barrier el periférico escribe el valor BARRIER_NOT_REACHED, cuando todos los procesadores han leído su registro respectivo el periférico escribe el valor BARRIER_REACHED. • ReadX_ACK(R3): Se usa para indicarle al procesador X que el periférico le ha terminado de transferir un mensaje entrante al retornarle el valor READ_ACK, si la transferencia no ha concluido y está en progreso el registro se coloca en el valor READ_NOT_ACK, este valor se coloca en READ_NOT_ACK cada vez que se inicia una solicitud de lectura. • WriteX_ACK(R4): Es el análogo de escritura de ReadX_ACK, maneja los valores READ_ACK y READ_NOT_ACK. • Cx_Dest (R5): Se emplea para indicar cuál es el procesador al que se le va a enviar un mensaje desde el procesador x. • Cx_SRC_Addr(R7): Se emplea para indicar donde está ubicado en memoria el mensaje que el procesador x va a enviar. • Cx_Tam(R8): Se emplea para especificar el tamaño del mensaje a enviar en bytes. • Cx_WR_RQ(R9): Se emplea para indicarle al periférico que puede ingresar un mensaje a la red (MPI_Send), al escribirse con cualquier valor el periférico reacciona. Este registro se debe escribir luego de haber fijado los registros R5, R7, R8. • Cx_BusyFlag(R10): Se emplea para indicar que el canal del periférico se encuentra ocupado en una transacción ya sea de lectura o escritura. Si el canal está ocupado se retorna el valor CH_BUSY de lo contrario se retorna CH_FREE. • Cx_ReadDest(R11): Para una operación de lectura se indica de que origen se quieren leer los mensajes.. 28.

(29) • Cx_Unread(R12): Indica el numero de mensajes sin leer provenientes del procesador especificado en Cx_ReadDest. • Cx_RD_REQ(R13): Le indica al periférico que puede iniciar una operación de lectura. El periférico inicia la transferencia al ser escrito el registro y el valor que se escribe es la posición de memoria donde se coloca el mensaje recibido. Antes de invocar esta acción se deben escribir los registros R12 y R13.. 29.

(30) Capítulo 5 Resultados y discusión 5.1.. Mediciones de desempeño y análisis. Para validar el funcionamiento de la plataforma y el modelo de mensajería se han ejecutado los algoritmos de prueba descritos en la sección 2.5 . Uno de los objetivos de la ejecución de estos algoritmos es el de comprobar que efectivamente se está experimentando una aceleración en la ejecución de la versión paralela con respecto a la secuencial. Como unidad de medición se usa el comando de conteo de instrucciones que provee OVP, el cual indica cuantas instrucciones a nivel de máquina se han ejecutado desde el inicio del procesador de manera que el costo de ejecución de un algoritmo se considera como la diferencia del contador de instrucciones después de finalizar el algoritmo y antes de iniciarlo, en esta sección se describen 3 tipos de pruebas que se realizaron: • Ejecución de la multiplicación de matrices de n*n sobre una plataforma de 4 procesadores variando el tamaño de n. • Ejecución del ordenamiento por selección sobre un arreglo de n posiciones sobre una plataforma de 4 procesadores variando el tamaño de n. • Ejecución del ordenamiento por selección sobre un arreglo de 1024 posiciones, variando el número de procesadores. Uno de los puntos clave de estas mediciones es que solo se tiene en cuenta el tiempo de procesamiento debido a que el tiempo empleado en comunicaciones no representa una información válida ya que las métricas de comunicaciones no describen las características de la red real al haberse hecho la simulación sobre un periférico que abstrae la funcionalidad del tráfico. Si se simularan las características de la red se deberían incluir factores como latencias, anchos de banda y escenarios de congestión.. 30.

(31) Figura 5.1: Comparación de la ejecución del algoritmo paralelo contra el secuencial ante un aumento del tamaño de la matriz. Tamaño matriz 4 8 16 32. Instrucciones secuencial 7.415 41.178 279.958 2’320.000. Instrucciones paralelo 1.503 10.065 68.712 588.453. Aceleración 4,933 4,0912 4,074 3,943. Tabla 5.1: Conteo de instrucciones de los algoritmos paralelos y secuenciales y aceleración obtenida para la multiplicación de matrices. 5.1.1.. Multiplicación de matrices. El problema de la multiplicación de matrices es uno de los ejemplos más comunes de la paralelización de un algoritmo debido a que este es totalmente paralelizable, es decir no posee una región serial si no se tiene en cuenta el envío y la recolección de los datos. Recordando los conceptos de la sección 2.5.1 para una multiplicación de dos matrices de N xN la matriz resultante será otra matriz de N xN . El desempeño de los algoritmos a medida que crece el tamaño N de la matriz se muestra en la figura 5.1 y la tabla 5.1.1. Para el algoritmo secuencial se deben calcular N columnas resultado, mientras que el algoritmo paralelo al contar con 4 elementos de procesamiento debe calcular N/4 columnas resultado por procesador lo cual justifica que la aceleración -la cual es la relación entre la duración del algoritmo paralelo y el secuencial- se mantenga alrededor de 4. Ambos algorit31.

(32) Figura 5.2: En la gráfica izquierda se muestra la comparación entre el crecimiento en tamaño de las partes secuenciales y paralelas del algoritmo semiparalelo, en la parte derecha se muestra la comparación del crecimiento en tiempo del algoritmo secuencial y semiparalelo . mos reflejan un ritmo de crecimiento cuadrático debido a que la obtención de una columna resultado es de complejidad O(n2 ), la única diferencia radica en el mencionado factor de 4.. 5.1.2.. Ordenamiento por selección, crecimiento del arreglo.. A diferencia del algoritmo de multiplicación de matrices, el algoritmo de ordenamiento por selección no es totalmente paralelizable debido a que cuenta con una parte secuencial después de haber organizado los subarreglos paralelos (ver sección 2.5). Las condiciones de la prueba son similares a las del punto anterior: se posee una plataforma con 4 procesadores esclavos y se varía el tamaño del arreglo con el fin de observar el comportamiento de los algoritmos. En la figura 5.2 y la tabla 5.1.2 se muestran los resultados. Contrastando los resultados con el algoritmo de multiplicación de matrices se puede observar que el crecimiento de la aceleración se estanca a medida que aumenta el tamaño del 32.

(33) Tamaño. Solo. arreglo 100 200 400 800. secuencial 287.729 1’125.557 4’451.648 17’704.603. Paralelo parte secuencial 20.459 75.246 287.833 1’425.661. Paralelo parte paralela 20.316 39.591 95.642 183.773. Paralelo. Aceleración. total 40.775 114.837 383.475 1’609.434. 7,05 9,8 11,6 11,0. Tabla 5.2: Comparación entre el tiempo de ejecución de la versión totalmente secuencial del ordenamiento por burbuja y la versión parcialmente paralela donde en este se discrimina la duración de la parte secuencial y la parte secuencial, la columna total representa la suma de estas partes. problema debido a que a pesar de que se está reduciendo el tamaño de la parte paralela del algoritmo el costo de ejecución del ordenamiento por selección crece de una manera cuadrática. Aun así la implementación semiparalela presenta una aceleración favorable comparada con la versión secuencial. Si se descompone el crecimiento de la parte semiparalela en sus componentes secuencial y paralela se ve que la parte paralela es la que presenta una mayor tasa de crecimiento (cuadrática) frente al crecimiento lineal de la región secuencial.. 5.1.3. Ordenamiento por selección, crecimiento del número de procesadores. Teniendo en cuenta el algoritmo de ordenamiento por selección ahora se quiere partir de un problema de tamaño fijo el cual es un arreglo de 1024 posiciones y encontrar el comportamiento frente a un crecimiento del número de procesadores, los resultados se muestran en la tabla 5.1.3 y la figura 5.3. A medida que se aumenta el número de procesadores el subarreglo a ordenar disminuye con lo cual la parte paralela se ejecuta de forma más rápida a diferencia de la parte secuencia la cual aumenta de manera lineal frente al número de procesadores debido a que esta se encarga de escoger el menor elemento ubicado en la primera posición de los subarreglos. El punto de intersección entre el desempeño de las partes secuenciales y paralelas representa la máxima aceleración que se pueda obtener. La forma de la gráfica de la aceleración es en U invertida, partiendo de un procesador la aceleración aumenta y llega un punto donde esta comienza a decrecer.. 33.

(34) Figura 5.3: En la gráfica izquierda se muestra el comportamiento del costo de ejecución de las partes paralela, secuencial y combinada ante un aumento en el número de núcleos. En la gráfica derecha se muestra el comportamiento de la aceleración relativa a un algoritmo secuencial ante la misma variación.. Número núcleos 2 4 8 16 32 64. parte secuencial 117.840 207.952 388.176 748.624 1469.520 2’911.312. parte paralela 7’275.727 1’835.237 466.903 120.763 32.211 9.051. total 7393.567 2043.189 855.079 269.387 1’501.731 2’920.363. Aceleración 3,91 14,17 33,87 33,32 19,29 9,91. Tabla 5.3: Resultados de la variación de los tiempos de ejcución y la aceleración del algoritmo de ordenamiento por selección ante la variación del número de procesadores.. 34.

(35) Capítulo 6 Conclusiones y desarrollo futuro A través de la ejecución de los algoritmos de prueba se ha mostrado que el portado a una plataforma embebida de la versión mínima de MPI es viable debido a que los recursos que requiere de un procesador son pocos. En futuros estudios deben incorporarse factores importantes como la latencia y el ancho de banda propios de la red los cuales representan factores que disminuyen el desempeño en la ejecución de los algoritmos y aumentan la exactitud de la simulación. En el momento de incorporar estos retrasos se podría evaluar la posibilidad de implementar un modelo de mensajería asíncrono con el fin de evitar que las instrucciones de comunicación se bloqueen mientras estas se ejecutan y se dedique el tiempo del procesador en actividades útiles. No obstante el modelo asíncrono implica la implementación de buffers y a la vez se aumenta la complejidad del hardware de manera que si se quiere adoptar la aproximación asíncrona se debe hacer un balance entre la liberación de tiempos del procesador y el tamaño de la implementación de un buffer. Otra aproximación posible para evitar el bloqueo del procesador es adoptar algún mecanismo de concurrencia como la gestión de interrupciones o la adopción de un sistema operativo en tiempo real. Otro de los logros del proyecto se basa en el haber podido demostrar la utilidad del desarrollo mediante plataformas virtuales debido a que en el momento de la redacción de este artículo los detalles finales de la implementación hardware del NoC en la universidad son desconocidos y el entorno virtual permitirá reaccionar fácilmente a los cambios que se presenten. Por otro lado los beneficios de la escogencia de algoritmos paralelos se pudieron estudiar lo cual en un futuro le facilitará a los implementadores tomar mejores decisiones frente al desarrollo de los algoritmos.. 35.

(36) Apéndice A Diagramas de diseño de la plataforma A.1.. Descripción algorítmica de las operaciones. Estos diagramas describen a alto nivel las operaciones principales implementadas en el periférico y las librerias de ejecución de las intrucciones MPI.. A.2.. Descripción dinámica de las operaciones. Los siguientes diagramas muestra como un llamado a una función MPI se propaga a la largo del procesador que hace la llamada y el periférico a lo largo del tiempo.. 36.

(37) Figura A.1: Implemetación de la barrera en el periférico. 37.

(38) Figura A.2: Implemetación de la entrada de38datos al periférico, invocada por MPI_Send..

(39) Figura A.3: Implemetación de la salida de datos desde el periférico, invocada por MPI_Recv. 39.

(40) Figura A.4: Implemetación de MPI_Recv.. 40.

(41) Figura A.5: Implemetación de MPI_Send.. 41.

(42) Figura A.6: Implemetación de MPI_Barrier.. Figura A.7: Convención de los diagramas dinámicos.. 42.

(43) Figura A.8: Diagrama dinámico de la ejecución de MPI_Recv.. 43.

(44) Figura A.9: Diagrama dinámico de la ejecución de MPI_Send.. 44.

(45) Figura A.10: Diagrama dinámico de la ejecución de MPI_Barrier.. 45.

(46) Bibliografía [1] Blaise Barney. Introduction to parallel computing. https://computing.llnl.gov/ tutorials/parallel_comp/. [2] L. Benini D. Bertozzi. Network-on-chip architectures and design methods. In IEE Proceedings: Computers and digital techniques, number 152, pages 261–272, 2005. [3] Max Domeika. Software development for embedded multi-core systems, chapter 4. Newnes Elsevier, 2008. [4] G. Marchesan et al. An adaptive message passing mpsoc framework. International Journal of Reconfigurable Computing, page 20, 2009. [5] Nicopoulos et al. Network on chip architectures, A hollistic design exploration., chapter 1. Springer, 2009. [6] MPI Forum. Estándar oficial de mpi 2.2. http://www.mpi-forum.org/docs/mpi-2. 2/mpi22-report.pdf. [7] Wikimedia foundation. Ordenamiento por selección. http://es.wikipedia.org/ wiki/Ordenamiento_por_seleccion. [8] Graham Hellerstrand. How virtual prototypes aid soc hardware design. http://www. embedded.com/columns/technicalinsights/20300463. [9] Imperas. About ovp. http://www.ovpworld2.org/aboutovp.php. [10] Imperas. Ovp apis. http://www.ovpworld.org/technology_apis.php. [11] Imperas. Ovp presentation. http://www.ovpworld.org/presentation.php?slide= OVPINTRO2. [12] D. Castells-Rufas J. Murillo and J. C. Bordoll. Hw-sw framework for distributed parallel computing on programmable chips. In Proceedings of the Conference on Design of Circuits and Integrated Systems (DCIS ’06), 2006. [13] Vincent P. Heuring Miles J. Murdocca. Principles of computer architecture, chapter 10. Prentice Hall, 2000. [14] Bill Neifert. Leveraging virtual hardware platforms for embedded software validation. http://www.embedded.com/design/208400911. [15] Katalin Popovivi and Ahmed Jerraya. Virtual platforms in system-on-chip design. DAC.COM knowledge center, 2009. 46.

(47) [16] M. Saldaña and Paul Chou. Td-mpi: an mpi implementation for multiple processors across multiple fpgas. In Proceedings of the International Conference on Field Programmable Logic and Applications (FPL ’06), pages 1–6, 2006. [17] Andrew Tannmbaum. Structured computer organization, chapter 8. Prentice hall, 1999. [18] Wikimedia. taxonomy.. Flyyn’s taxonomy.. http://en.wikipedia.org/wiki/Flynn%27s_. [19] Wikimedia. Parallel virtual machine. http://en.wikipedia.org/wiki/Parallel_ Virtual_Machine. [20] Wayne Wolf and Ahmed Jerraya. Multiprocessor systems on chip, chapter 3. Morgan Kauffman, 2005.. 47.

(48)