Actas JP2011 - Universidad de La Laguna

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011si se reduce el número de comunicaciones usandosolapamiento entre los subdominios.El número de comunicaciones de tipo send/receive sonmayores si se corta en dos direcciones, como se muestraen la Figura 2(c); aunque el total de datosintercambiados y el número de cálculo redundantepodría ser menor que alguna de las otras dosdistribuciones dependiendo de la geometría particular ydel número de subdominios. Con esta distribución unproceso envía y recibe de más de dos procesos. Losotros dos tipos de distribuciones, el corte estrecho yancho, presentan el mismo número de comunicacionesdel tipo send/receive. En estos dos casos un procesointercambiará datos con uno o dos procesos mientrasque en con la división de la Figura 8(c) un procesopuede intercambiar datos con más de dos procesos.En [15] se comparan las alternativas de la Figura 2(a)y 2(c) usando paso de mensajes (MPI) en un cluster de4 nodos AMD Opteron 2.2 GHz y dos cores cada unoconectados mediante Gigabit Ethernet. Los resultadospara diferentes tipos de simulaciones haciendo uso devarias cuadrículas mostraban un mejor rendimiento si ladescomposición estaba hecha usando el corte en anchoen vez del corte de dos direcciones. [8] compara lasalternativas de la Figura 2(b) y 2(c) usando también pasode mensajes con MPI en un CC-NUMA HP/ConvexExemplar X-Class (SPP2200) con 64 procesadoresdistribuidos en cuatro híper-nodos. Los ochos nodos deun híper-nodo están conectados en red (switch) de 960MB/s de ancho de banda en cada dirección [16]. Siendoesta una red basada en el estándar SCI. Los resultadosmuestran que el corte estrecho da mejores resultados queel de dos direcciones.La alternativa de la 2(c) presenta peor localidad dedatos que las otras dos alternativas. Esto afecta a lasprestaciones, especialmente en la implementación dememoria compartida. Teniendo en cuenta esto y locomentado más arriba, se ha descartado una comparativacon esta alternativa. En el trabajo que aquí se presentase comparan el corte ancho y estrecho tanto en laimplementación de paso de mensajes como la dememoria compartida. Para mejorar la localidad de losdatos, tanto para la distribución del corte en ancho yestrecho, los datos se almacenan en posiciones dememoria contiguas.TABLA IOPCIONES DE OPTIMIZACIÓN ( INTEL COMPILER 11.1 )O2: Expansión en línea, clonación de funciones, optimizaciones clásicas (desenrollado de bucles, copia y propagación deconstantes, renombrado de variables, liberación de memoria inútil) y vectorización (en el que se intentan generar instrucciones de tipoMMX, SSE, SSE2). O2 generalmente se recomienda como opción de optimización para mejorar el tiempo de comunicación.O3: Igual que O2 pero aplicado de una forma más agresiva, con técnicas como precaptación, reemplazamiento para reducirreferencias a memoria, transformaciones de bucles o del acceso a memoria.ipo: Multifile interprocedural optimization (esto, por ejemplo, permite la expansión y clonación de llamadas a funciones definidasen archivos distintos).openmp: Esta opción permite al compilador generar las hilos basándose en las directivas de OpenMP incluidas en el mismocompilador.xSSE4.2 (architecture-specific optimization): Intenta generar instrucciones del tipo MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 ySSE4.2 (vectorización) y puede optimizar la familia de procesadores de Intel Core i7.prof_gen and prof_use (Profile Guided Optimization or PGO): Permite optimizar teniendo en cuenta la referencia real de losdatos en vez de usar datos heurísticos.A. PlataformaV. RESULTADOSLos resultados han sido obtenidos en un pequeñocluster de tres nodos conectados mediante una switchGigabit Ethernet. Cada nodo tiene 6 GB de memoria yun Core i7 CPU920 (del último cuarto del 2008). CadaCore i7 920 se compone de cuatro cores de 2,667 GHz(2 hilos por core si está activado Hyperthreading). cacheL3 de 8 MB compartidos por todos los cores yQuickPath de 4,8 GT/s. El cluster tiene instalado unLinux Fedora 10 (kernel 2.6.27.41)Las comunicaciones del sistema han sido evaluadasmediante un benchmark ping-pong programado conMPI. El ancho de banda de la red obtenido con el testping-pong es de 115 MB/s, cerca de los teóricos 125MB/s.El ejecutable se ha generado con el compilador Fortrande Intel (versión 11) por lo que se ha usado la versiónOpenMP de este compilador. Para paso de mensajes seha usado MPICH 1.3. El código se ha compilado usandodistintas opciones de compilación orientadas a suoptimización y vectorización.En la Tabla I se resume las opciones de optimizaciónusadas. Los tiempos de ejecución obtenidos con O2 yO3 son muy similares, además cuando se añade lasopciones ipo o SSE4.2 a O2 u O3 no se presentancambios perceptibles en el rendimiento. De igual formaPGO no mejora el tiempo de ejecución con respecto auna versión que no usa PGO. Los ejecutables usados enla siguiente sección se han generado con las opciones decompilación O2 y openmp.B. Modelo de PruebaLa aplicación de prueba escogida se trata de unasimulación del lago Tahoe, la meta final de estasimulación es caracterizar las rutas de transporte de laslarvas de especies invasivas (el bivalve Corbiculafluminea, o almeja asiática) desde los puntos cercanos ala costa a otras zonas en el lago, y las condiciones medioambientales a las que podrían estar expuestas durante laruta.Simular un lago del tamaño del lago Tahoe, cuyasdimensiones son de 20x30 km, con un tamaño de lasceldas en la horizontal de O(10) m resulta un problemadesde el punto de vista computacional que sólo puedeser abordado mediante el uso de computadoresparalelos. Para hacerse una idea, la relación entre eltiempo real y el tiempo de ejecución secuencial (unJP2011-156