Actas JP2011 - Universidad de La Laguna

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011figuraciones, se obtiene un factor de rendimientocandidato.3. Evaluación del impacto de los factoresde rendimiento Para la evaluación del impactose mide empíricamente el tiempo de ejecuciónde las configuraciones posibles del factorde rendimiento, y se determina qué configuraciónobtiene mayor speedup y eficiencia. Severifica mediante simulación que es posible reproducirel problema de rendimiento obtenidoen el entorno real. Posteriormente, se analizamediante simulación el impacto del factor derendimiento para arquitecturas con gran númerode cores.4. Modelo de rendimiento o alternativade diseño y modelado Modelar el factorde rendimiento o proponer una alternativade diseño conjuntamente con su modelo derendimiento. Este proceso requiere la recopilaciónde las medidas y configuraciones para elfactor de rendimiento y buscar una relación quepermita predecir el comportamiento en un entornodinámico.5. Verificación del modelo de rendimientoIntegrar el modelo de rendimiento mediante lasherramientas de sitonización que permitan actuara nivel de la librería dinámica de OpenMP.Verificar mediante la sintonización dinámica sila predicción permite conseguir una mejora respectoa la ejecución sin sintonizar. Posteriormente,analizar el overhead debido a la instrumentacióny sintonización dinámica y verificar laprecisión del modelo generado. Posteriormente,se valida el modelo en un entorno de simulación,mediante la simulación del modelo sobre una arquitecturacon alto número de cores.IV. Casos de usoEn esta sección se muestran dos casos de uso de lametodología presentada anteriormente.A. Paralelismo de datosEn el modelo de paralelismo de datos existen factoresde rendimiento relacionados con la gestión delreparto de iteraciones en bucles paralelizados, primitivasde acceso concurrente a memoria y la asignaciónde threads sobre cores en base a datos afines paraminimizar fallos de cache.Respecto al reparto de iteraciones de bucles paralelizados,para una carga de trabajo desbalanceada,es posible en OpenMP aplicar tres estrategias de planificación:static, dynamic y guided.La estrategia de planificación estática reparte lasiteraciones en base al factor denominado chunksize.Previo al cómputo, se realiza la asignación de rangosde iteraciones para cada thread. La reparticiónde rangos altamente desbalanceados va a afectar alrendimiento de la aplicación.La planificación dinámica reparte iteraciones detamaño chunksize bajo demanda. Cuando un threadfinaliza la ejecución de las iteraciones asignadas, solicitanuevas iteraciones. Esta estrategia mejorael balanceo de carga. Sin embargo, tiene unpequeño overhead en los accesos concurrentes parala demanda de nuevas iteraciones, que afectará alrendimiento si los accesos son muy frecuentes o siintervienen un gran número de threads.El método guiado reparte bajo demanda grupos deiteraciones, empezando con tamaños grandes hastallegar a un tamaño chunksize definido por el usuario.Esta estrategia puede conseguir una mejora en el balanceoy pretende minimizar los problemas de las estrategiasanteriores.Por otro lado, existen factores de rendimiento enla utilización de las primitivas de acceso a memoria.Las diversas directivas OpenMP ofrecen diferentefuncionalidad y rendimiento en el acceso concurrente.Sin embargo, dependiendo de la aplicación no siempreserá posible utilizar la directiva con menor overhead.También existe en algunas implementaciones delmodelo de programación, aunque fuera del estándarde definición de OpenMP, la posibilidad de definirel orden de asignación de threads sobre los coresen base a la afinidad. Mediante esta definición, esposible asignar threads con regiones afines sobre mismosniveles de memoria para minimizar los fallos decache. Gracias a esta definición, también es posibleevitar problemas de falsa compartición. Éstos problemasocurren cuando threads en niveles diferentesde la jerarquía de memoria compiten por los mismosdatos, y aunque ejecutados de forma paralela, la disputaen el acceso concurrente a los datos serializa laejecución y además añade un alto overhead debido aconstantes fallos de cache y migración de datos.B. Paralelismo de tareasLos factores de rendimiento en este paradigmaestán relacionados con la gestión de tareas de la implementaciónOpenMP. Existen dos estrategias principalmente.El modelo centralizado dispone de unacola compartida que almacena las tareas, a dónde losthreads ociosos acceden de forma concurrente para laobtención de tareas. El otro modelo, está basado encolas descentralizadas. Cada thread cuenta con unacola local. Cuando un thread queda ocioso calculamediante una función (e.g. random) el identificadorde un thread sobre el que acceder a su cola localpara iniciar el robo de tareas, este thread es llamadovíctima.En el modelo de gestión centralizada, se presentaun problema de rendimiento en base al acceso concurrentea la cola. Este factor puede ser más significativocuantos más threads existan en el sistema.Por tanto, el tiempo de acceso concurrente limita elrendimiento.En la gestión descentralizada existen dos factoresde rendimiento principalmente. El primero consisteen la posible ineficiencia en identificar al threadvíctima con suficiente carga de trabajo. Las diferentesimplementaciones suelen utilizar una lógica simple.Por ejemplo, mediante una función aleatoria oJP2011-652