• No se han encontrado resultados

3. Motivaci´ on

5.2. Estudio previo a la optimizaci´ on

El prop´osito de esta secci´on es analizar la estructura del modelo de simulaci´on para detectar los puntos del sistema que son susceptibles de ser paralelizados. Se trata de un an´alisis prelimi- nar, ya que el definitivo tendr´a lugar sobre el sistema en su versi´on secuencial una vez que est´e implementado. Dicha tarea tendr´a mucho peso en el global del proyecto porque cuanto m´as exhaustivo sea dicho estudio, mejores decisiones podremos tomar acerca de la paralelizaci´on y mayores beneficios obtendremos a nivel de prestaciones.

De hecho, uno de los fundamentos del ´area HPC es conocer y analizar con detalle el algorit- mo para aplicar las metodolog´ıas adecuadas en los puntos adecuados. En otras palabras, ser´a necesario hacer un profiling de la implementaci´on secuencial para medir los tiempos de ejecu- ci´on. De esta manera podremos saber qu´e c´alculos tienen mayor coste y, por tanto, qu´e bloques

5.2. Estudio previo a la optimizaci´on 41

de c´odigo deben paralelizarse. Sabremos tambi´en si esos bloques ejecutan llamadas de c´odigo C++ puro desde la capa core, o se corresponden con paso de informaci´on por parte de la capa intermedia, o bien si se trata de llamadas a la propia API de Maya. Con toda esa informaci´on se podr´an tomar decisiones acertadas sobre la paralelizaci´on de los bucles o la reimplementaci´on de algunas partes del c´odigo para favorecer la optimizaci´on.

Como dec´ıamos, para poder completar este detallado estudio es necesario disponer de la implementaci´on del sistema en versi´on secuencial. Por ese motivo, de momento nos vamos a limitar a exponer el algoritmo del modelo y a plantear las hip´otesis de paralelizaci´on desde un punto de vista te´orico. En el Algoritmo 1 se muestra el bucle de simulaci´on del modelo MSXPBD, esto es, el conjunto de instrucciones que se ejecutan en cada fotograma.

Algorithm 1 Pseudoc´odigo del bucle de simulaci´on

1: Recoger datos globales de la escena

2: Enviar datos globales al solver

3: for all m´usculosm do

4: Recoger datos locales de m

5: Enviar datos locales de m al solver

6: Actualizar velocidades de los v´ertices de m

7: Actualizar posiciones de los v´ertices de m

8: for all iteraciones i do

9: for all m´usculos m do

10: Leer geometr´ıas de m´usculos vecinos a m

11: for all restricci´on r do

12: Computar r

13: Actualizar la geometr´ıa de m

14: for all m´usculosm do

15: Actualizar velocidad de los v´ertices de m

16: Enviar posiciones resultantes a la aplicaci´on

17: Actualizar v´ertices en la geometr´ıa de m para la visualizaci´on

Como introducci´on al an´alisis de la optimizaci´on del sistema, se adjunta la tabla 5.5 en la que se estudian los bucles presentes en el Algoritmo 1 para determinar las posibilidades de paralelizaci´on. La columna capa se refiere a la(s) capa(s) de abstracci´on encargada(s) de ejecutar cada bloque de instrucciones, a saber:coresi son c´alculos propios del modelo MSXPBD,

aplicaci´on si son operaciones a nivel de API de Maya, o intermedia si son instrucciones de comunicaci´on entre el core y la aplicaci´on.

Es necesario aclarar algunas cuestiones de la tabla5.5. Por un lado, vemos que los bucles 3-7 y 14-17 est´an indicados como paralelizables. Dichos bucles implican la participaci´on de las tres capas, incluyendo la capa de aplicaci´on. En estos casos, tendremos que asegurarnos previamente de que las llamadas a la API de Maya son compatibles con directivas de paralelizaci´on. Si esto

42 Metodolog´ıa y Gesti´on del Proyecto Capa Par. Comentarios

3-7

Aplicaci´on Intermedia

Core

S´ı

La recogida de par´ametros particulares de cada m´usculo es independiente una de otra. Tambi´en lo es la integraci´on de fuerzas y velocidades. 8-13 Aplicaci´on Intermedia Core No

El estado de la part´ıculas tras el c´omputo de una iteraci´on influye directamente en el c´omputo de la iteraci´on siguiente. La convergencia de MSXPB es posible gracias a ello.

9-13

Aplicaci´on Intermedia

Core

No

El c´omputo de un m´usculo depende del estado de la geometr´ıa de los m´usculos vecinos con los que se conecta. Se

necesita la informaci´on m´as actualizada posible.

11-12 Core S´ı Los m´etodos Jacobi y Coloreado de Grafos permiten calcular las restricciones de manera simult´anea.

14-17

Aplicaci´on Intermedia

Core

S´ı

La actualizaci´on de las velocidades de las part´ıculas de un m´usculo es independiente del resto de m´usculos. Ocurre lo mismo con la actualizaci´on de los v´ertices en la geometr´ıa. Tabla 5.5: Estudio de la paralelizaci´on del algoritmo. Cada columna refleja de izquierda a derecha: ´ındices de l´ınea en el algoritmo; capa(s) que ejecuta(n) las instrucciones; posibilidad de paralelizaci´on; y breve justificaci´on de la columna anterior.

no es posible, ser´a necesario dividir esos bucles en varias partes para poder optimizar, al menos, aquellas instrucciones que se ejecutan ´unicamente desde la capa core. Esta y otras cuestiones ser´an las que se ampl´ıen m´as adelante durante el dise˜no de la paralelizaci´on.

Por otro lado, el bucle 11-12 hace menci´on a los m´etodos de Jacobi y de Coloreado de Grafos. Tal y como se introdujo en el cap´ıtulo de Estado del Arte, el m´etodo Jacobi es una de las t´ecnicas de paralelizaci´on aplicables al modelo XPBD, el cual est´a basado en la acumulaci´on de las correctivas calculadas por cada restricci´on para aplicarlas de forma promediada s´olo una vez al t´ermino de cada iteraci´on, justo antes de procesar la siguiente iteraci´on. Por lo que respecta al Coloreado de Grafos, cabe recordar que consiste en la agrupaci´on de las restricciones aplicando un criterio independencia entre s´ı en lo que a compartici´on de v´ertices afectados se refiere. Con esta separaci´on se garantiza la convergencia del sistema y la atomicidad a nivel de escritura de los deltas de posici´on (consultar la subsecci´on 2.2.1).

Documento similar