Anterior: Me hizo gracia |  Siguiente: Guillem Borrell's Flying Circus: Bologna


Estamos todos locos

Supercomputación



High Performance Computing es diseñar un algoritmo de traspuesta en OpenMP que sobreescala cuando tu código usa más de 1024 nodos.




Guillem Borrell, completamente enfermo.

  • Tags: Ingeniería
Por guillem  |  en: jue 04 Mar 2010  |  Comentar...

Comentarios

¡Pega el código, pega el código!

¿Te refieres a un algoritmo para calcular una matriz traspuesta? ¿La tenéis que trasponer explícitamente por huevos?

Pregunta tonta: ¿más de 1024 nodos con memoria compartida (OpenMP)?



@jgpallero

Para trasponer algo que es 100 más largo que ancho no te vale con un simple transpose

1024 nodos, 4 cores cada uno. MPI+OpenMP. Somos ya de los pocos grupos en España que hacemos híbrido.



Más preguntas tontas

Más preguntas tontas, que estoy empezando a mirar en ratos libres el tema de OpemMP.

Aunque parezca una chorrada, hay una cosa que no acabo de entender. Imagínate que utilizas OpenMP (o cualquier otro entorno de paralelización, ya sea de memoria compartida o distribuida) para paralelizar una función que hace una determinada tarea (copiar un vector, por ejemplo). Ahora imagínate que paralelizamos en otra función un bucle dentro del cual se llama a la función anterior; y, así, ad infinitum. ¿Sigue siendo eficiente la función final?, ¿de qué depende? Por ejemplo, si paralelizas BLAS con OpenMP y también LAPACK, ¿qué rendimiento tiene eso?

Por otra parte, he estado echando un vistazo por internete a ver si hay alguna implementación de BLAS para OpenMP, pero no he encontrado nada (a lo mejor no he sabido buscar) ¿Te suena alguna?



@jgpallero

Hay cuatro niveles de granularidad en los ordenadores modernos. El primero es la vectorización, que intenta utilizar las unidades vectoriales (SSE, VMX) de los procesadores o las múltiples unidades de proceso en coma flotante. El segundo es el uso optimo del caché y el ancho de banda de memoria que se suele hacer utilizando blocking y variables intermedias. El tercero es utilizar múltiples hilos para aprovechar los threads virtuales y el multiple core. El cuarto es, si es una arquitectura de memoria compartida, NUMA o si es de memoria distribuida, el uso optimo de las comunicaciones.

Duplicar uno de los niveles es perjudicial, olvidarte uno también. Nosotros hacemos los tres últimos a manopla, del primero se suele encargar el compilador; pero hay que ayudarle un poquito con memoria alineada y contigua (algo esencial con las fft).

Hay dos versiones de blas, una que hace los dos primeros niveles (la de netlib de toda la vida) y la que hace los tres primeros (threaded atlas, intel MKL). Luego tienes versiones paralelas de lapack como scalapack que usa la blas que le proporciones por debajo.

Las versiones multithread de blas utilizan posix threads y no OpenMP. Esto es una discusión a parte y ha generado toneladas de literatura a parte que he tenido la desagradable experiencia de haber leído.

Todo lo que haces con OpenMP lo puedes hacer con posix threads (que es lo que lleva OpenMP por debajo), pero hacer algoritmos data parallel (fácilmente vectorizables) con pthreads es matar moscas a cañonazos puesto que pthreads es una librería para programar cosas task parallel.



El rey del mambo

O sea, que la cosa no es tan fácil como: "me cojo una implementación de CBLAS (como la de GSL, por ejemplo), le pongo los #pragma omp correspondientes delante de los bucles for a todas las funciones, y ya soy el rey del mambo con mi multicore", ¿no?



@jgpallero

Hacer que OMP escale no es trivial en absoluto. Pero como el mundo está lleno de genios siempre te encuentras quien le echa la culpa cuando hace las cosas mal.

Con lo nuestro es más fácil porque nuestras matrices son rematadamente grandes.

Mi experiencia es que blas y fft es de lo más optimizado que existe. Seguro que hay alguien que lo hace mejor que yo así que no lo hago y busco por ahí.



Es un coñazo escoger un título para los comentarios

Lógico, lógico, yo tampoco me voy a poner a reprogramar BLAS o LAPACK con OpenMP. Pero bueno, aunque no se vaya a trabajar en supercomputación siempre queda el gusanillo de intentar usar OpenMP en todo elcódigo que se genere para tratar de aprovechar en lo posible los multicores.

Otra cosa es que, como el tema de paralelizar con OpenMP, en líneas generales, es tan fácil como colocar sentencias #pragma en los lugares adecuados, no cuesta nada ir preparando todo el código según se escribe. Luego lo compilas con OpenMP o no, según convenga. O quizás no he entendido nada.

Una cosa está clara, el Kazushige Goto es un frikazo como un piano:

www.ncsa.illinois.edu/UserInfo/Perf/BLAS/