I have become comfortably numb

Creo que sobra decir que, si no me he ido de vacaciones ni he escrito uno de estos "Flying Circus" es porque he estado bastante ocupado. A diferencia de Ion que está por Mongolia comiendo entrañas de cabra.

Ya que no puedo dedicarme a las nuevas experiencias gastronómicas de Asia Central me dedico a pasar el rato haciendo chorradas que tienen que ver con mi trabajo. Es equivalente a masturbarse cuando tus amigos se están cepillando a la novia de Cristiano Ronaldo.

Cosas que he hecho durante este triste tiempo y aún no he contado:

• Montar un servidor público de SAGE aprovechando que tenemos un pc viejo muerto de asco y un nombre en el DNS de la politécnica que no usamos. Podéis cacharrear todo lo que queráis, de hecho está hecho para cacharrear. Ha costado como un poquito y he tenido que parchear los scripts de instalación pero os presento el primer servidor sage público de la Politécnica de Madrid

• Un talón de aquiles jodido de nuestros códigos es la lectura y escritura de datos. Como si fuera un locutor de los 40 principales voy a llamarlo I/O a partir de ahora. Actualmente leemos y escribimos en paralelo pero lo hacemos sin formato. Aunque conseguimos transferencias de hasta 26 BGi/s (un blu-ray por segundo) lo hacemos a un coste muy elevado. El archivo queda fragmentado y sólo puede utilizarse como restart file. Si necesitamos post procesar nuestros resultados tenemos que escribir en serie.

  Para resolver este problema me he pillado MPI, HDF5, un poco de Fortran 2003 (sí, habéis leído bien) y he creado VSIO. Es una librería tremendamente simple para leer y escribir archivos HDF5 en serie y en paralelo asumiendo una descomposición de dominios trivial. Supongamos que el dominio computacional es un cubo. Tendremos tres tamaños: NX, NY y NZ. La manera más habitual de descomponer el dominio es asignar a cada nodo los índices correspondientes de la última dimensión, en este caso NX. Así, cada nodo irá de un nx_beg a un nx_end.

  Lo que hace VSIO es juntar las variables para escribir los datos en el archivo y generar un dataset de tamaño NX x NY x NZ.

  La gracia es que la librería está programada en C y Fortran la llama a través de wrappers escritos con el módulo ISO_C_BINDING. Esto significa que necesitáis un compilador de Fortran de putísima madre para compilarlo. Con el GCC, nada por debajo del 4.4 va a poder con ello. Si usáis el de Intel más os vale pasar del 11.0

  Yo aún no he podido encontrar ningún bug así que espero que alguna alma caritativa mejore los tests que he diseñado (más bien pocos). Si quieréis un ejemplo podéis mirar los programas main.c y main.f90. Son el mismo programa y escriben los mismos archivos sólo que uno está escrito en C y el otro en Fortran.

Más cuando tenga algo de tiempo para respirar.

Hay relativamente pocas diferencias entre un cluster de pequeño tamaño como el que tenemos en el laboratorio y los monstruos en los que corremos las grandes simulaciones. El primer gran escollo, la escalabilidad, depende en gran medida del algoritmo. Por norma general, si funciona bien en 8000 nodos, funcionará en 32. En nuestro caso el cálculo en un BG/P o en un Xeon no tiene ninguna diferencia. Cuando ejecutamos la versión de BG/P en nuestro cluster las comunicaciones funcionan mejor mientras que el cálculo es un poco más lento debido a la pobre escalabilidad en OpenMP del Xeon 5450.

Sí hay algo que es completamente distinto: el I/O. Escribir en un BG/P no tiene nada que ver con escribir en un cluster de 32 nodos. El motivo principal es que, en el momento en el que lo que tienes que grabar en disco más de 100 GBi, es una mala idea hacerlo en serie.

Escribir en serie es fácil. Da igual cómo lo hagas y el formato que uses. Sólo hay un procesador escribiendo a la vez y el sistema de ficheros no se puede liar. En resumen: hay un único identificador de archivo. Incluso en superordenadores con sistemas de ficheros paralelos, como el Mare nostrum, la mayoría de códigos escriben sólo con el nodo maestro.

Esto nos enfrenta a un serio problema. El ancho de banda de un sistema RAID no suele pasar el GBi/s, que es lo que te da un interfaz Fibre Channel. Pero difícilmente eres el único usando el disco así que lo más normal es que nunca llegues a ver el pico de ancho de banda. Dejémoslo en que vemos 0.5 GBi/s. Supongamos que tenemos que leer 300 GBi, algo bastante habitual cuando pasas de los 1024 nodos, con lo que tardamos 600 s en leer y 600 s más en escribir. Esto hace 20 minutos, 0.36 horas, que puede parecer poco. Cuando tienes que multiplicar esta cifra por el número de cores ya no te parece tan poco. Así, un proceso que no era intensivo en I/O se convierte en un devorador de horas de cálculo que podrías perfectamente gastar haciendo ciencia.

Hoy todo el mundo le dedica una gran atención a cómo escalar en superordenadores, cómo sacarles el máximo rendimiento a las horas de cálculo, como si lo único que se hiciera en ellas fuera calcular. En cambio el I/O siempre se soluciona con la misma receta: hacerlo asíncrono. Sin embargo no puedes hacer asíncrona la lectura inicial ni la escritura final.

Esta es la manera en la que estamos solucionando el problema:

1. El nodo maestro abre el archivo con un

    posix_open 

   .
2. Manda el identificador de archivo al resto de nodos.
3. Cada nodo hace un

    fseek 

   y pone el puntero de escritura donde debe.
4. Cuando se escribe se hace en bloques del mismo tamaño que el bloque del sistema de ficheros para aumentar la velocidad. En el caso de gpfs 2MBi.

Este método nos permite conseguir prácticamente el ancho de banda pico del sistema de ficheros. Nuestro récord son 26GBi/s -un blue ray por segundo- con 8096 nodos. Pero presenta el problema de tener un formato de archivo fragmentado. Si la variable se corta antes de los 2MBi nos queda una zona llena de mierda.

Los sistemas de ficheros distribuidos irán consolidándose a medida que el número de procesadores aumente. No necesariamente para conseguir más ancho de banda -el ancho de banda de cualquier red de altas prestaciones es un orden de magnitud mayor que el de un controlador de disco- sino para conseguir que más nodos accedan a un disco que no tienen de manera concurrente. Demasiadas infraestructuras utilizan NFS para este tipo de concurrencia cuando nunca se diseñó para ello. Leer y escribir en paralelo en un formato portable será cada vez más una necesidad de modo que, si la brecha de la supercomputación es un problema cultural, más nos vale que empecemos a ver cursos sobre HDF5 por ahí.

Parece que si la comunidad científica ya ha escogido HDF5, Linus ha apostado por Ceph como sistema de ficheros. Por otro lado, PVFS2 sigue siendo una incógnita, Lustre puede tener un futuro muy negro e IBM sigue vendiendo como churros GPFS a precio de oro.

La Ingeniería Española tiene un problema de productividad. Probablemente no sólo la Ingeniería tiene este mismo problema pero sólo hablo de lo que conozco.

Gracias a seguir cediendo mi tiempo libre a Englobe tengo la suerte de conocer a la mayoría de los representantes de software de simulación en España. Todos se quejan de lo mismo: su facturación en España es entre cinco y diez veces menor de lo esperado. Antes que pensar que somos un polo mundial de piratería de software de cálculo me inclino hacia la idea que nuestras empresas de ingeniería dedican muchos menos recursos a la simulación que sus competidores europeos.

Esto es un problema.

Y de los gordos.

La competitividad se debe a dos factores: la experiencia previa y los recursos disponibles. España ha sido la fábrica low cost de Europa durante muchos años, tantos que nos hemos pensado que alemanes y franceses jamás iban a cerrar las fábricas. Muchos años. Demasiados. Cuando han empezado a cerrarlas resulta que no eramos tan listos. Hemos aprendido tarde y mal que lo de "la letra con sangre entra" no sirve para formar ingenieros. Los tiempos del lápiz y papel han pasado y somos cuatro los que nos hemos dado cuenta de ello.

Todos los proveedores me dicen lo mismo. Si monto seminarios, cursos, eventos; acudirán a la llamada. Creen, como yo, que se trata de un problema de formación junto con una endémica falta de recursos.

En España jamás haremos aerogeneradores de 10 MW offshore porque la ingeniería necesaria para ello cuesta 100 millones de Euros. Aquí nos creemos capaces de hacerlo con cien veces menos. Y somos necios felices por sabernos tan listos. Sólo somos listillos. Ahora que todas las cabezas pensantes de Gamesa huyen a Vestas como las ratas que abandonan el barco que se hunde lo entendemos un poco mejor. Nunca quisimos hacer Ingeniería de verdad. Por lo menos en Airbus Military se atrevieron a equivocarse con el A400M y les llamamos incompetentes por ello.

La lección es sencilla. Nos ponemos a hacer Ingeniería de verdad o más vale que empecemos a comprar terrenos para construir hoteles en Namibia. A lo mejor sólo del ladrillo vivimos.

Puedo montar un sarao para que todos los proveedores de software de cálculo cuenten lo que hacen. Una semana en la que todos los suministradores de software y de hardware muestren sus productos para que por fin los españolitos sepan quién es Mister Marshall. Y puedo hacerlo en seis meses y a lo grande. Estoy convencido de ello. Pero me queda una duda.

¿Las empresas acudirían a la cita?

Éste es otro post con peligro de muerte por aburrimiento. Si queréis diversión siempre podéis leer a Tyler.

Tener saraos en el campus de Diagonal de la UPC es una putada. Obviamente con mis padres en Calella no me voy a pillar un hotel. Tardo aproximadamente dos horas y cuarto, puerta a puerta, de mi casa al BSC. Esto significa que si lo que sea empieza a las nueve, mi despertador suena a las 6.

Para los muy profanos que no conozcan el BSC, se trata de un centro de investigación de nivel mundial en temas de supercomputación y calculo en paralelo. Han pasado en sólo cuatro años de tener 50 empleados a 300. Tienen una fuerte relación con IBM aunque hoy en día también hacen cosas con Intel y Microsoft. Ser un centro grande les hace fuertes y lo saben. Alardean con razón que si algún fabricante les intenta vender hardware su primera respuesta es: ¿Y cuánto nos pagáis para que lo usemos?

He ido a aprender sobre GPGPU. Aunque hayamos comprobado que en nuestros códigos que usan algoritmos de orden N no sirva, esto no significa que no estemos interesados en aprender sobre cómo se usan.

Una GPU es un procesador con centenares de cores y una memoria local pequeña y rápida. La manera de programarlas se basa en paralelismo masivo gracias a que los threads, que son llevados por un runtime, son muy baratos. Esto hace que sea frecuente tener ejecutando millares de threads en una única tarjeta. El gran problema es la transferencia de datos entre la memoria de la CPU y la de la tarjeta que hay que hacer a mano y se presta a centenares de técnicas de optimización. Hay cuatro niveles de memoria y cada uno tiene su gracia.

Quiero enfatizar lo de hacer las cosas a mano porque la mayoría del curso iba sobre cómo conseguir buenos speedups a base de aplicar decenas de técnicas de optimización manual tanto al escribir los kernels (las minitareas que se ejecutan en la tarjeta) como en el código CPU. Pinned memory, double buffering, uso de los registros, tiling... Repito que la mayoría de los benchmarks que presentaron eran operaciones > O(N²) como multiplicaciones matriciales o resolución de sistemas lineales de gran tamaño.

Es precisamente en el tema de los runtime, aún muy verde, donde los del BSC se han puesto a trabajar. Isaac Gelado presentó GMAT, un runtime alternativo para CUDA que permite utilizar un único espacio de memoria para la CPU y las tarjetas de las que se dispongan. Tiene tan buena pinta que uno no entiende cómo no Nvidia les compra el trabajo y lo convierten en CUDA 4.0. Tiempo al tiempo.

Xavi Martorell presentó la modificación que han hecho del runtime de sus compiladores Superscalar para las GPU. Los compiladores superscalar utilizan una serie de pragmas parecidos a los de OpenMP para anotar el código y dejar que el runtime paralelice utilizando los recursos disponibles del nodo. Siempre han demostrado buenos rendimientos en todas las plataformas a las que lo han portado pero nunca he tenido tiempo de utilizarlos como es debido. ¿Quizás para el post proceso de la capa límite? Presentaron también una modificación al estándar OpenMP llamado OpenMPT que añade una colección de pragmas más para explicitar el target de una región paralela.

Da la casualidad que Xavi estuvo en IBM Watson trabajando en la red del BG/P. Red de la que podemos decir sin miedo a equivocarnos que es una puta pasada. Así que le estreché la mano y le di las gracias. Por lo que me contó el proceso de optimización de la implementación de MPI del BG/P era esencialmente artesanal. Corrían casos, obtenían trazas completas de las comunicaciones e iban eliminando cuellos de botella gradualmente.

Probablemente tenga que volver en septiembre. Al ritmo al que los visito van acabar pensando que trabajo ahí.

En el Último ISC hubo una sesión sobre cómo mejorar la eficiencia energética de las grandes infraestructuras de cálculo, tanto de los propios ordenadores como de los centros. Esto implica también mejorar los sistemas de disipación de calor de los procesadores.

El ordenador de 100 Petaflops, el próximo Blue Waters, contará ya con refrigeración líquida. Es la única manera de evacuar unos 2 KW de menos de una décima de metro cúbico. Un poco más y estos bichos tendrán la densidad energética de una central térmica.

Sí, esto de lo que veis muchos en línea son DIMMS de memoria DDR 3

Lo más curioso es que se enfatiza en la eficiencia de la disipación energética cuando lo que a mi me parece es un problema de regeneración. Cualquier tipo de energía, incluso la térmica, puede ser utilizada para otro fin; normalmente producir más energía.

Este fin de semana le he estado dando vueltas a lo siguiente.

Un procesador es, en realidad, un punto caliente. El objetivo es mantener este punto a una temperatura de diseño mientras se consigue transportar el exceso de energía a un punto lejano. Esto es exactamente lo que sucede en un evaporador.

No debería ser difícil, teniendo en cuenta que la refrigeración líquida ya funciona, convertir el disipador de cada procesador en un pequeño evaporador en el que ocurra un cambio de fase del fluido de trabajo. A una presión de trabajo el cambio de fase se hace a una temperatura fija de modo que conseguiríamos mantener el procesador a dicha temperatura mientras que el exceso de calor se aleja en forma de gas.

La ventaja de disipar en forma de gas es que este sobrante se puede utilizar del mismo modo que en una central se realiza un ciclo de potencia de vapor. Entonces sólo necesitaríamos una turbina, una bomba y un condensador para producir un ciclo de potencia que aproveche esa energía térmica.

Si la energía que se obtiene de la turbina es suficiente como para mover un ciclo criogénico o un motor Stirling habríamos reducido la potencia necesaria para el enfriamiento de la plataforma de cálculo a cero.

¿Alguien más lo cree posible?

Segunda vez en Hamburgo. Mismo motivo. International Supercomputer Conference. Este año fuimos invitados por Microsoft e incluso teníamos un expositor para que la gente nos mirara como a los chimpancés del zoo.

Si el año pasado fuimos a ver qué se cocía por ahí, este año incluso fuimos invitados a la fiesta de Microsoft y Fernando se coló en la orgía de alcohol que por lo que se ve fue la fiesta de t-systems.

Las ciudades alemanas están bien siempre que no tengas un tiempo de mierda. Nos encontramos un tiempo de mierda la mayoría de los días. Los congresos están bien siempre que las conferencias sean interesantes. Las sesiones científicas fueron una mierda.

No hice fotos porque no merecía la pena. Ahora, para los que les aburra leer, esas frases cortas sobre mis viajes que tanto molan.

El logo de la cerveza Astra tiene pinta de tatuaje de marinero gay.

Fernando se bebió dos botellas de Astra el primer día así que me estuve metiendo con él durante todo el viaje por beber cerveza de marinero gay.

La fiesta de Microsoft fue en una terraza en el puerto y estuvo bien hasta que empezó a hacer un frío helador y tuvimos todos ganas de pirarnos.

En la fiesta de los rusos de t-systems había chupitos de vodka gratis.

La frase del congreso me la dijo un jefe de nVidia: "el 80% de los trabajadores de las empresas son unos incompetentes. Si sabes lo que haces puedes considerarte de los buenos".

Seguía sin haber españoles a parte de los del BSC y nosotros. Sigue siendo una mala noticia teniendo en cuenta que en ese congreso todo el mundo se conoce.

A sgi españa no se le ocurrió otra cosa que organizar una presentación en Madrid durante el ISC. sgi tenía uno de los mayores booths del ISC. Da una medida de lo aislados que estamos tecnológicamente.

Tuve que llevar un polo de Microsoft durante un día. Me he traído dos y uno es para Ion.

Muy probablemente será el último ISC al que vaya.