Actas JP2011 - Universidad de La Laguna

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011MPJ ApplicationsF−MPJ Librarydevice layeromxdevibvdevniodev/iodevsmpdevJVMJNIJava SocketsJava Threadsnative commsOpen−MXIBVTCP/IPMyrinet/EthernetInfiniBandEthernetShared MemoryFig. 2.F-MPJ communication devices on shared memory and cluster networksel método Class.forName(). Para que esta aproximaciónfuncione, es necesario tener en cuenta quela ejecución de la deserialización tiene que llevarsea cabo en el thread local, es decir, en el receptor.Esto es relevante para las comunicaciones no bloqueantes,en las que cualquiera de los threads queestá esperando a que se complete puede hacer la comunicaciónefectiva.IV. Evaluación del RendimientoA. Configuración ExperimentalEn esta evaluación se han utilizado dos máquinas.La primera de ellas (“Nehalem”) cuenta con 2 procesadoresIntel Xeon E5520 quad-core Nehalem y 8Gbytes de RAM, con Sistema Operativo Linux CentOS5.3 y la JVM Sun JDK 1.6.0 23. La segunda(“Magny Cours”) es una máquina con 4 procesadoresAMD “Magny Cours”, cada uno con 12 núcleos (48núcleos en total) y 128 Gbytes de RAM. El SistemaOperativo es Linux CentOS 5.5, y la JVM Sun JDK1.6.0 05.Las implementaciones MPJ evaluadas son F-MPJ(release interna) y MPJ Express versión 0.38, ademásde las bibliotecas Intel MPI v.4.0.0.028 (usado enmáquina “Magny Cours”), OpenMPI v1.4.2 (en“Magny Cours”) y v1.3.3 (en “Nehalem”), y MVA-PICH2 r3510 (en “Nehalem”). Para OpenMP se hausado el compilador gcc v.4.3.4.B. Micro-benchmarking de Primitivas Punto aPuntoEl micro-benchmarking en Java se ha llevado acabo con nuestra propia suite, similar a los Intel MPIBenchmarks (IMB) utilizados para bibliotecas MPI,debido a la falta de una suite de benchmarking adecuadapara MPJ.La Figura 4 presenta el rendimiento de un benchmarkde PingPong entre dos procesos/threads dentrode un mismo nodo mostrando la latencia para mensajesde tamaño inferior a un Kbyte y el ancho debanda para mensajes mayores. Para la transferenciade datos se han utilizado arrays de bytes evitando elcoste de la serialización de objetos. Las opciones medidasson F-MPJ y MPJ Express con sus respectivosdispositivos smpdev y las distintas implementacionesMPI utilizando su soporte para memoria compartida.Tal y como se ve en las gráficas, la latencia deMPJ Express es bastante superior a la de las demásopciones, todas por debajo de los 5 µs. En cuantoal ancho de banda, también se queda por debajo,Latency (µs)Point-to-Point Java Communication Performance (Nehalem)8024F-MPJ (smpdev)MPJE (smpdev)7522MVAPICH27020OpenMPI6560185516501445124035103082562041510201 4 16 64 256 1K 4K 16K 64K 256K 1M 4M516M 0Message Size (Bytes)Point-to-point Java Communication Performance (Magny Cours)Latency (µs)4540F-MPJ (smpdev)MPJE (smpdev)IntelMPI 435242230201825162014121510810654204 16 64 256 1K 4K 16K 64K 256K 1M 4M 16M 0Message size (Bytes)Fig. 4. Message-passing point-to-point performance on sharedmemory.302826mientras que el dispositivo de memoria compartidapresentado en este artículo supera ampliamente elrendimiento de todas las demás. Esto es así porqueestá optimizado para que el intercambio de mensajesentre threads se realice mediante copias de arrays,aprovechando de este modo la arquitectura de memoriacompartida. La diferencia de ancho de banda entrediferentes procesadores se debe a la arquitecturadel procesador y a la asignación de threads a cores,ya que hay una probabilidad bastante elevada de quese ejecuten en núcleos de distintos procesadores dentrodel mismo nodo. La pérdida de rendimiento apartir de 1 Mbyte con 8 núcleos, o de 256 Kbytescon 48, se puede superar mediante la segmentaciónde mensajes lo cual permite incrementar la localidadde los datos.C. Micro-benchmarking de Primitivas ColectivasLa Figura 5 presenta el ancho de banda agregadode una operación collectiva representativa (broadcast)utilizando todos los núcleos disponibles en “Nehalem”(8) y “Magny Cours” (48). La selección delBandwidth (Gbps)Bandwidth (Gbps)JP2011-442