{% extends "base.html" %} {% block content %}
Client
).
El cliente que se descarga de cada tablon está preparado
para trabajar por defecto contra ese servidor.
Para usarlo hay que disponer de Python 3. El cliente actual se ha probado con las versiones 3.6.8 a 3.8.4 de python.
Queues
del menú.
Supongamos que queremos ejecutar un programa con código OpenMP
que hemos guardado en el fichero test.c
. Nuestro tablon tiene una
cola denominada openmp que compila y ejecuta programas OpenMP con el compilador gcc 7.2.
Para ejecutar este programa debemos descargar el cliente (idealmente en el mismo
directorio o carpeta donde están los programas a enviar) y ejecutarlo desde una
ventana o interfaz de comandos como se indica más abajo.
El nombre de usuario, el nombre de la cola y el nombre del fichero con el código fuente del programa son parámetros obligatorios. La contraseña se puede introducir como parámetro, y sino el cliente te la pedirá.
ventana+R
,
y escribiendo cmd
.
Añadir al PATH la ruta donde están el programa de python (se puede fijar
de forma permanante en la configuración del sistema, para no tener que
repetir esta fase cada vez que se abre un cmd nuevo).
Ir al directorio donde se ha guardado el cliente y ejecutarlo.
PATH=C:\Python38;%PATH%
cd C:\ruta-hasta-la-carpeta-donde-esta-el-cliente-en-tu-maquina
py ./client -u USUARIO [-x PASSWORD] -q openmp test.c -- [ARGUMENTOS]
cd ruta-hasta-la-carpeta-donde-esta-el-cliente-en-tu-maquina
python3 ./client -u USUARIO [-x PASSWORD] -q openmp test.c -- [ARGUMENTOS]
También se pueden enviar argumentos de entrada para el programa. En el caso de la cola de OpenMP, los argumentos se pasarán al programa como si el usuario los estuviera tecleando en la línea de comando.
Conecting usuario@tablon.infor.uva.es:8080
Successful authentication
Sending request
Request sent successfully
Request id 17
http://tablon.infor.uva.es:8080/request?rid=17
Para escoger el número de hilos OpenMP, hay que especificar el parámetro -t del cliente ( -t <num_threads> ). Por defecto el número de hilos es 1. En tablon, la función omp_set_num_threads ya no tiene prioridad. Aunque se puede seguir utilizando para reducir el número de hilos que se usa en la región paralela.
Por ejemplo, el siguiente código selecciona manualmente 3 hilos pero sólo se hará efectivo cuando desde el cliente se envíe el programa con -t y un número de threads mayor o igual que 3.
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char *argv[]) {
int maxt = omp_get_max_threads();
printf("Max threads is: %d\n", maxt);
omp_set_num_threads(3);
int tid, tnum;
#pragma omp parallel private(tnum, tid)
{
tid = omp_get_thread_num();
tnum = omp_get_num_threads();
printf("Hello World from thread = %d/%d\n", tid, tnum);
}
return 0;
}
Existen unas colas especiales que evalúan el programa con una serie de entradas desconocidas para los usuarios, otorgándole a cada envío una puntuación. Estas colas mantienen un listado (leaderboard) con el ranking del mejor código enviado por cada usuario (grupo de alumnos).
Cuando se envía a una de estas colas, el servidor tablon ignora el número de procesos e hilos, así como los argumentos de entrada. El servidor prueba el programa varias veces con un conjunto de entradas desconocidas para el programador. El servidor va comparando la solución correcta con la salida del programa de los alumnos.
Un programa válido para un leaderboard debe realizar la tarea que se le pide e imprimir por la salida estándar: una linea con el tiempo y otra linea por cada resultado que se pida. Es aconsejable que los programas solo impriman por pantalla lo mínimo necesario ya que puede que el resultado no se considere cómo válido en el leaderboard si tiene caracteres o información extra. Además, existe una limitación en el número de caracteres que se recogen de la salida por defecto del programa.
Tablon lee también el tiempo de ejecución mostrado por el programa. En el caso de varias pruebas en un leaderboard acumula los tiempos de todas las pruebas. La parte del código donde se calcula o escribe el tiempo no debe ser alterada por los alumnos. Tablon almacena todos los códigos enviados, una vez que termine el concurso se comprobará los códigos y se descalificará a todos los alumnos que empleen medios no lícitos para mejorar su posición en el ranking.
Es aconsejable que los programas solo impriman por pantalla lo mínimo necesario ya que existe una limitación en el número de caracteres (ver sección siguiente) y porque puede ocurrir que el resultado no se considere cómo válido en el leaderboard.
Cuando un programa se envía a un leaderboard se compila con el macro CP_TABLON predefinidio. Los mensajes de debug que se utilizan para las ejecuciones en local se pueden imprimir usando compilación condicional, evitando así que estén activados en las ejecuciones del leaderboard.
#if !defined( CP_TABLON )
printf("Esto no se imprime en tablon\n");
#endif
También hay una limitación en el tamaño del buffer de salida (stdout). El número máximo de caracteres que se pueden imprimir desde el programa y que luego aparecen en la página es de 2000 caracteres. Si el usuario solicita al programa escribir más caracteres en la salida por defecto la salida se truncará, perdiéndose los caracteres más allá de los 2000 primeros.
Por seguridad, los programas se ejecutan en un sandbox (zona aislada) de forma que no pueden salir de una carpeta determinada para leer/escribir ficheros, o interferir por error con el resto del sistema de ejecución.
{# Frontendv es el frontend de un cluster de máquinas de memoria distribuida. Cada máquina tiene diferentes propiedades que se resumen en la siguiente tabla. #} Frontendv es un portal de acceso y lanzamiento de tareas a máquinas paralelas de docencia e investigación del grupo Trasgo. Estas máquinas están a disposición de los alumnos gracias a la financiación del Departamento de Informática, la Escuela de Ingeniería Informática y la empresa Nvidia, a través de los programas GPU Education Center y GPU Research Center.
Máquina | CPU | GPU |
---|---|---|
Heracles | 4 AMD Opteron 6376 (total 64 cores) @ 2.3Ghz | - |
Hydra | 2 Xeon E5 (total 12 cores) @ 1.9Ghz | 2 GTX Titan Black 2880 cores @ 980 Mhz
2 GTX K40c 2880 cores @ 745 Mhz |
Medusa | 2 Xeon Silver 4208 CPU @ 2.10GHz (total 16 cores con hyperthreading, 32 procesos) @ 1.4Ghz | 3 GTX Titan Black 2880 cores @ 980 Mhz
1 GTX Titan X 3072 cores @ 1000 Mhz |
Thunderbird | i5-3330 (4cores) @ 3Ghz | Tesla K40c 2880 @ 745 Mhz |
Phoenix | Qcore (4cores) @ 2.4Ghz | Tesla K40c 2880 @ 745 Mhz |
Titan01 | Qcore (4cores) @ 2.33Ghz | GTX Titan Black 2880 @ 980 Mhz |
Titan02 | Qcore (4cores) @ 2.4Ghz | GTX Titan Black 2880 @ 980 Mhz |
Titan03 | Qcore (4cores) @ 2.5Ghz | GTX Titan Black 2880 @ 980 Mhz |
Cuando se envía un programa a una cola MPI de frontendv, se reservan máquinas hasta que el número de cores sea igual o mayor al número de procesos MPI. Hasta 4 procesos se ejecutan todos en una misma máquina. Para más de 4 se necesitan varias. Por ejemplo, para 6 procesos se reservan 2 máquinas. El sistema de gestión de colas coloca los procesos en las máquinas reservadas. En el caso de 6 procesos, al reservar 2 máquinas, colocará 3 procesos en cada máquina.
Cuando se envía un trabajo MPI no es posible elegir la máquina en la que se ejecuta, sino que se ejecuta en las primeras máquinas que se encuentren libres. Es posible que dos ejecuciones con los mismos parámetros obtengan un tiempo diferente porque se estén ejecutando sitios diferentes.
La siguiente gráfica muestra el tiempo de ejecución de una solución al problema de búsqueda de cadenas con MPI en las diferentes máquinas de frontendv. El tiempo de ejecución disminuye según aumenta la velocidad de la máquina.