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.

- Y vosotros... ¿Os operaríais el rabo para tenerlo de 30 centímetros?

- Yo no me lo sajo diez centímetros por nada del mundo..

Ayer hubo otras frases memorables durante las fiestas de La Virgen de La Paloma, que por cierto era un campo de nabos. Cuando pasábamos por delante de una caseta en la que estaban haciendo panceta a la plancha...

- Por una vez que mi mujer me deja salir en vez de oler a sexo voy a volver oliendo a grasa quemada.

- Tú no le des ascos, lo importante es volver oliendo a carne.

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.

JC, en vez de grabarme a mi mismo diciendo OJETEEEEEEEEEE, he encontrado algo mejor.

After almost five years using gentoo I decided, about one year ago, to switch to OpenSUSE. I am a KDE user and I don't have enough time to take care of my computer as it was a pet (this was the feeling I had dealing with gentoo).

One of the lessons learned with gentoo was that, most of times, fixing build scripts is not that difficult. It takes some time and research, but configuration scripts are just scripts at the end.

If you try to compile SAGE in either OpenSUSE 11.2 or 11.3 you will get a weird bash error. This is due to the fact that bash is dynamically linked with libreadline in some modern distributions (Arch linux has this issue too). The readline configuration script for the SAGE's local readline version has an exception for OpenSUSE 11.1, and only 11.1.

You only have to go to the spkg folder where the readline spkg is. In SAGE, a spkg is only a tarball of the source directory. Untar the spkg and change the following block in the build and install script (spkg-install)

if [ -f /etc/SuSE-release ]; then
    if [ `grep 11.3 /etc/SuSE-release > /dev/null; echo $?` -eq 0 ]; then
        echo "OpenSUSE 11.3 detected"
        if [ -d /usr/include/readline/ ]; then
            echo "The development version of libreadline is installed -> copying"
            if [ `uname -p` = "x86_64" ]; then
                cp /lib64/libreadline.so.* "$SAGE_LOCAL"/lib
            else
                cp /lib/libreadline.so.* "$SAGE_LOCAL"/lib
            fi
            cp -r /usr/include/readline  "$SAGE_LOCAL"/include
            exit 0
        else
            echo "No headers found, building library."
            # # This variable is only set to "true" on openSUSE 11.1.                                     
            # OVERWRITE_READLINE="true"; export OVERWRITE_READLINE                                        
        fi
    fi
fi

Now tar the folder to get the spkg again and you are good to go.