Conceptos básicos de la Computación de Altas Prestaciones tic.ec 2018 21 de noviembre de 2018

Índice La Computación de Altas Prestaciones Problema Justificación Soluciones Algunos resultados Bibliografía

Índice La Computación de Altas Prestaciones Problema Justificación Soluciones Algunos resultados

Computación de Altas Prestaciones Los computadores han servido para hacer simulaciones numéricas de fenómenos físicos, químicos, socioeconómicos, de tratamiento de datos, etc. Estas simulaciones sirven para realizar modelos, prever comportamientos, encontrar soluciones… Han cambiado el modelo en el que se corroboraban teoría y experimentos Diseño de nuevas instalaciones, predicción de proteínas, confirmación experimental de modelos complejos, etc.

Computación de Altas Prestaciones La Computación de Altas Prestaciones se divide en Computación de Alta Productividad High Throughput Computing (HTC) Computación de Alto Rendimiento High Performance Computing (HPC)

Computación de Alta Productividad La Computación de Alta Productividad (HTC) Su objetivo es aumentar el número de ejecuciones por unidad de tiempo Su rendimiento se mide en número de trabajos ejecutados por segundo Áreas de aplicación Códigos Monte Carlo, Barrido de parámetros… Es decir, problemas en los que se hacen muchos cálculos independientes unos de otros Radiofísica, Economía, Finanzas, Medioambiente, Física de Altas Energías, Ingeniería, Estadística, Física de Plasmas, Química, Técnicas de optimización, etc.

Computación de Alta Productividad Ejemplos de Computación de Alta Productividad (HTC) HTC síncrono HTC asíncrono Maestro–Esclavo

Computación de Alta Productividad Ejemplo “tonto” de Computación de Alta Productividad (HTC) Calcular la media aritmética de los resultados de estas operaciones 19+21 19+22 18+21 18+22 40 18+23 17+22 17+23 Estos cálculos se pueden hacer todos a la vez independientemente unos de otros

Computación de Alto Rendimiento La Computación de Alto Rendimiento (HPC) Su objetivo es reducir el tiempo de ejecución de una única aplicación paralela Su rendimiento se mide en número de operaciones en punto flotante por segundo Áreas de aplicación: Estudio de fenómenos a escala microscópica (dinámica de partículas) Resolución limitada por la potencia de cálculo del computador Cuantos más grados de libertad (puntos), mejor reflejo de la realidad Estudio de fenómenos a escala macroscópica (sistemas descritos por ecuaciones diferenciales fundamentales) Precisión limitada por la potencia de cálculo del computador Cuantos más puntos, más se acerca la solución discreta a la continua

Computación de Alto Rendimiento Ejemplo de Computación de Alto Rendimiento (HPC) Ecuación no lineal de Schrödinger Ecuaciones de Maxwell-Bloch Esquemas numéricos

Computación de Alto Rendimiento Ejemplo “tonto” de Computación de Alto Rendimiento (HPC) (1+5*3+6*7)/2 + 4 5*3 (15+42) + 1 6*7 (58)/2 (29)+4 33 Estos cálculos no se pueden hacer hasta que termine el anterior

Computación de Altas Prestaciones Con un mayor número de procesadores, se aumenta algunos de los parámetros que definen una simulación numérica Resolución de problemas en menor tiempo de ejecución, usando mas procesadores (crítico en T) Resolución de problemas con mayor precisión, usando mas memoria (crítico en P) Resolución de problemas más ambiciosos, usando modelos matemáticos más complejos (crítico en C)

Computación de Altas Prestaciones Algunos ejemplos de la necesidad de la potencia de cálculo en ámbitos científicos Nº de operaciones = Rendimiento * Tiempo

Computación de Altas Prestaciones En qué órdenes nos estamos moviendo… Leyenda de los granos de trigo y del tablero de ajedrez T = 1+2+4+ … +9.223.372.036.854.780.000 T = 20+21+22+ … + 263 T = = 264–1 = 18.446.744.073.709.551.615 ~ 18,5·1018 Por curiosidad, esta suma es ~ 15,4·1012 Tm ~ 22.000 veces la producción anual mundial de trigo

Computación de Altas Prestaciones Un ejemplo más actual… Predicción meteorológica

Computación de Altas Prestaciones Predicción meteorológica El clima es una función de la longitud, latitud, altura y tiempo Para cada uno de estos puntos se debe calcular temperatura, presión, humedad y velocidad del viento (3 componentes) Conocida la función clima(i,j,k,t), el simulador debe proporcionar el valor clima(i,j,k,t+∆t) Predicción 1 Minuto Celdas de 1 Km2 y 10 celdas en altura Europa  5·109 celdas (0,1 TB) ∆t = 1 minuto: 100 flops por celda (estimación optimista) 100*5*109 operaciones en menos de un minuto

Computación de Altas Prestaciones Infraestructuras Memoria Compartida (UMA – SMP) Uniform Memory Access Symmetric Multi-Processing Memoria Distribuida (MPP) Massively Multi-Processing NUMA (Memoria virtualmente compartida y físicamente distribuida)

Computación de Altas Prestaciones NUMA Cada procesador tiene su propia memoria local pero también tiene acceso a la memoria de otros (de forma más lenta) Ofrece la "escalabilidad" de MPP y la programación simple de SMP CC-NUMA (Cache Coherent NUMA) Extensión de SMP para soportar capacidades MPP Con acceso por hardware a la memoria de otros procesadores mediantes canales de conexión de componentes (buses) El acceso también se puede hacer a través del Sistema Operativo La memoria caché es la memoria de acceso rápido Guarda temporalmente los datos procesados recientemente Más pequeña que la principal

Computación de Altas Prestaciones Infraestructuras HPC (SMP o MPP) Supercomputadores, Clústeres locales Hospedados en un único CPD Cores  Procesadores  Nodos  Servidores/Chasis (CPU) Aceleradores (co-procesadores) GPU (cálculo vectorial – son MPP en modo local) Xeon Phi (multithreading, paralelización dentro del procesador) Recursos comunicados por Infiniband

Computación de Altas Prestaciones Infraestructuras HTC (MPP) Federación de sitios (sites) heterogéneos Grid Recursos permanentes Cloud Recursos bajo demanda Públicas y privadas Distribuidos geográficamente Misma arquitectura que HPC, pero en menor número Se salen del dominio de administración de la institución (no son clústeres locales) Conectados por fibra óptica o redes de datos (Ethernet)

Computación de Altas Prestaciones Infraestructuras actuales Top500 (HPC) Nº 1: Summit (EE.UU.) con ~122 Pflops reales CPU + NVIDIA GPU Nº 2: Sunway TaihuLight (China) con ~93 Pflops reales … Quinde I (Ecuador) con ~232 Tflops EGI (HTC) Grid: 4,7·109 horas KSI2K FedCloud: 700.000 Máquinas virtuales, 9·106 horas de CPU

Índice La Computación de Altas Prestaciones Problema Justificación Soluciones Algunos resultados

¿Cómo se divide ese problema? Se dispone de Una mayor potencia de cálculo y almacenamiento Redes de interconexión cada vez más rápidas Problemas que se pueden dividir en partes más pequeñas de tal forma que cada una de ellas se ejecute en un sitio distinto de la infraestructura computacional ¿Cómo se divide ese problema? Paralelización o distribución de las tareas que lo componen… ¿Cómo se ejecutan esas tareas distribuidas? Ha de hacerse de tal forma que se optimice la eficiencia computacional

Problema El quid de la cuestión es saber qué tipo de infraestructura sirve para resolver el problema de interés No todo sirve para todo No es bueno matar moscas a cañonazos A veces una solución aproximada con un pequeño margen de error es más que suficiente No es imprescindible la solución exacta en caso de que ésta sea posible Hay que tener la infraestructura computacional ocupada, pero con problemas que realmente lo requieran El mayor supercomputador se puede llenar fácilmente con códigos que buscan soluciones por “fuerza bruta”

Problema Algunas leyes que han regido el desarrollo de la Computación de Altas Prestaciones Ley de Moore (1965 / 1975) La densidad de circuitos en un chip se dobla cada 12 / 24 meses Ley de Amdahl (1967) La eficiencia obtenida en una implementación paralela viene limitada por la parte secuencial, por ello el límite superior de mejora obtenida es independiente del número de procesadores Respuesta de Gustafson (1988) En la práctica, la mayoría de las aplicaciones son críticas en precisión, por lo que el tamaño de problema crece con el número de procesadores

Mejoras obtenidas hasta el momento Problema Mejoras obtenidas hasta el momento A partir de las metodologías computacionales (SW) Ganancia de un factor ~80 cada 10 años A partir de la arquitectura (HW) Ganancia de un factor ~50 cada 10 años Estas ganancias se van estancando poco a poco También la Ley de Moore, lógicamente…

Análisis previo a la paralelización Problema Análisis previo a la paralelización Complejidad numérica del código/algoritmo Escalabilidad y recursos que serán necesarios Grado de paralelismo del código/algoritmo Ley de Amdahl Granularidad de la implementación paralela Grado de acoplamiento requerido en la arquitectura subyacente Análisis del código ¿Por qué? ¿Dónde? ¿Cómo? Último análisis: ¿Qué ganancia (speedup) final se espera?

Índice La Computación de Altas Prestaciones Problema Justificación Soluciones Algunos resultados

Justificación Un código científico se compone básicamente de una parte de entrada (prólogo), una parte principal de ejecución y una parte de salida (epílogo) Se mide El tiempo de ejecución (wall-time) de la parte del programa que se va a paralelizar (código potencialmente paralelo) usando las rutinas de tiempos que nos aporte el S. Operativo Se quitan las partes secuenciales, como las sumas globales y entrada/salida de datos El tiempo del programa entero, desde la primera sentencia hasta la última

Se calcula el contenido paralelo c Justificación Se calcula el contenido paralelo c p = número de CPU c =

Justificación Nº de CPU Speedup teórico 1 1,00 2 1,94 3 2,82 4 3,65 5 4,43 6 5,17 7 5,86 8 6,52 9 7,15 10 7,75 Speedup Nº de CPU La diferencia creciente entre el speedup ideal y el teórico es debida al tanto por ciento secuencial que cada vez se hace más dominante El speedup real se debe al tiempo consumido en creación, sincronización y comunicación, la competencia por recursos y la desigualdad en la carga de los procesadores

Índice La Computación de Altas Prestaciones Problema Justificación Soluciones Algunos resultados

Define la arquitectura óptima Soluciones Para paralelizar una aplicación científica acoplada (sus partes no son independientes), hay que definir la granularidad de la división (cuán pequeñas hacemos las particiones) En un cálculo HTC, la división es de todas y cada una de las partes del cálculo independientes La granularidad es una medida de la cantidad de computación de un proceso software Se considera como el segmento de código escogido para su procesamiento paralelo Define la arquitectura óptima

Soluciones Ejemplo de granularidad

El siguiente paso es analizar cómo reducir el tiempo de ejecución Soluciones El siguiente paso es analizar cómo reducir el tiempo de ejecución ¿Por qué no se ejecuta eficientemente? ¿Dónde se encuentran los puntos críticos del código? Principio de Pareto o Regla 80/20 Paralelizar aquellas partes idóneas para ellas Optimización

La optimización se produce a partir de varios factores Soluciones La optimización se produce a partir de varios factores Tipo de procesador Procesos de Entrada / Salida en el código Uso y acceso a la memoria de la infraestructura Llamadas al sistema Conocimiento del código Es muy común el uso de herramientas para saber cómo se comporta el código (profiling) Indican qué partes del código consume más recursos

Algunos ejemplos de técnicas a tener en cuenta Soluciones Algunos ejemplos de técnicas a tener en cuenta Procesador Opciones de compilación para optimización secuencial y paralelización automática Técnicas de optimización para mejorar la explotación de la arquitectura y de la memoria caché Inclusión de directivas de paralelización en el código Entrada/Salida Reorganizar E/S para evitar muchas peticiones cortas Funciones para mapear ficheros en memoria Funciones para indicar al sistema el uso de las páginas de fichero en memoria

Algunos ejemplos de técnicas a tener en cuenta Soluciones Algunos ejemplos de técnicas a tener en cuenta Memoria virtual Técnicas de optimización para mejorar la explotación de la memoria virtual Funciones para indicar al sistema el uso de las páginas de fichero en memoria Conocimiento del código Aplicación de distintos modelos para un mismo dato de entrada Bucles Cálculos más pesados

Soluciones Ya se dispone de Una infraestructura paralela o distribuida Un código adaptado para su ejecución en esa infraestructura ¿Se pueden usar todos los procesadores de los que dispone la infraestructura?

Las infraestructuras computacionales a partir de cierto tamaño están Soluciones Las infraestructuras computacionales a partir de cierto tamaño están Compartidas por varios usuarios Gestionadas por administradores Con permisos para el uso de los recursos superiores a los de los usuarios Los administradores implementan reglas de uso (AUP) que delimitan El software que está instalado El nº de recursos al que cada usuario puede acceder El empleo de esos recursos para que la máquina esté operativa de la forma más eficiente posible

Soluciones Se instalan programas destinados a la gestión de los recursos computacionales y una buena calidad de servicio (QoS) Sistemas de colas batch Las peticiones de trabajos a ejecutarse (con un nº de recursos solicitados) se encolan para irles dando prioridad Portable Batch System (PBS, Slurm) que provee una serie de comandos con los que se ejecuta el envío de trabajos Sistema de gestión de carga para entornos distribuidos HTC Librerías que permiten la coordinación e intercomunicación de los trabajos paralelos o distribuidos MPI, OpenMP, DRMAA… Herramientas de monitorización de recursos y sistemas de información de sites

Algunas de estas labores las puede hacer también el usuario Soluciones Para conseguir esa optimización del uso de la infraestructura, es conveniente realizar labores de Configuración y mantenimiento de los recursos Planificación de qué recursos se asignan a qué cálculo/usuario Aprovisionamiento de recursos Algunas de estas labores las puede hacer también el usuario Implementación de herramientas que permiten definir cómo se va a ejecutar el trabajo Estas labores pueden ser Manuales, automáticas o semiautomáticas Estáticas o dinámicas

Soluciones (HPC) Planificación y gestión en HPC

Ejemplos típicos de políticas de uso de un supercomputador Soluciones (HPC) Ejemplos típicos de políticas de uso de un supercomputador Nº máximo de procesadores permitidos a un único usuario Nª máximo de trabajos permitidos a un único usuario Nº máximo de procesadores y trabajos permitidos a un grupo de usuarios Tiempo máximo que puede durar un trabajo ejecutándose Porcentaje reservado para la ejecución de trabajos paralelos Los gestores de recursos disponen de algoritmos de planificación que gestionan la carga del supercomputador acorde a las políticas anteriores Estos algoritmos también se pueden diseñar e implementar para que actúen sobre el gestor de recursos

Para ello, se necesita de Soluciones (HPC) Para mejorar la eficiencia o resolver fallos de ejecución, se realiza la migración de tareas Secuenciales Paralelas Contendores Para ello, se necesita de Gestor de recursos LRMS (Slurm, PBS…) Librería de puntos de chequeo (DMTCP, BLCR…) Librería de paso de mensajes MPI (MPICH3, MVAPICH2…) Hipervisores de entornos virtualizados (KVM, Xen) Gestores de entornos virtualizados (OpenNebula, OpenStack…)

Puede ser útil la compactación de tareas Soluciones (HPC) Puede ser útil la compactación de tareas Para liberar recursos que requieran de trabajos paralelos Para dejar parte del supercomputador libre con el fin de realizar trabajos de configuración, actualización, apagado… Aumentar la localidad para reducir el tiempo empleado en la gestión de los recursos (overhead), por ejemplo, el ancho de banda de procesos con pasos de mensajes MPI

Soluciones (HPC) A veces, por el contrario, se aumentará el rendimiento planificando tareas en distintos nodos Cuando se migran tareas, también ha de tenerse en cuenta cuáles son las más demandantes de recursos (en uso de memoria, por ejemplo) para ver cuáles van antes y cuáles van después

Soluciones (HPC) ¿Qué pasa si tenemos un cálculo paralelo de 1 millón de tareas y una falla? ¿Hemos de empezar de nuevo con el coste energético y computacional que eso origina? Relacionado con la migración de tareas se encuentra la tolerancia a fallos El código y el sistema están preparados para responder a posibles errores imprevistos Se hace mediante metodologías de puntos de chequeo (checkpointing) y detección proactiva de errores (SW y HW) Dan robustez al sistema, lo que redunda principalmente en que las ejecuciones sean desatendidas

Planificación, aprovisionamiento y gestión en HTC Soluciones (HTC) Planificación, aprovisionamiento y gestión en HTC Algunos de los conceptos anteriormente citados son válidos, pero el escenario es distinto Sites heterogéneos distribuidos geográficamente Distintos recursos (potencia de cálculo, memoria, etc.) Distintas configuraciones Distinto ancho de banda para acceder a ellos Mover volúmenes de datos más o menos grandes Mayor posibilidad de fallos El problema de ajustar carga de trabajo y recursos disponibles es por definición es NP-Completo Nondeterministic Polynomial time Únicamente se pueden hallar soluciones sub-óptimas

Soluciones (HTC) El mayor problema en este tipo de infraestructuras es que los Sistemas de Información (IS) no publican información real Nº de trabajos que se aceptan o Máquinas Virtuales (MV) que se pueden levantar Por usuario Por Organización Virtual Estado en el que se encuentran los recursos Las infraestructuras HTC son mucho más dinámicas ¿Cómo hago la división de mi cálculo para que se ejecute de forma eficiente? ¿Qué posibilidades existen de provisionar (“reservar”) recursos por anticipado?

Soluciones (HTC) La planificación de tareas en entornos HTC es objeto de varias líneas de investigación Replicación de tareas M/N (con M>N) La proporción M/N se obtiene a través de la tasa media de finalización de tareas en el sistema Bolsa de tareas (Bag of tasks) Agrupamiento de tareas Se determina el tamaño del chunk ≡ nº de samples Pero en general… No se ha tenido en cuenta el carácter dinámico de la infraestructura No se ha estimado el overhead Las soluciones se han probado en simuladores

Soluciones (HTC) Pending Prolog Execution Epilog Infraestructura física Computación Grid Gestión de trabajos computacionales Infraestructura virtualizada Computación en la nube Gestión de MM.VV y trabajos

DINÁMICO Soluciones (HTC) Pending Prolog Execution Epilog Estatus de la infraestructura Dinámico Número de tareas a ejecutar

DINÁMICO DINÁMICO Soluciones (HTC) Pending Prolog Execution Epilog Tamaño de los ficheros de entrada/salida Puede conocerse antes de la ejecución Conexión de red local y remota Aproximadamente constante para cada site

DINÁMICO Soluciones (HTC) Pending Prolog Execution Epilog Rendimiento del sitio remoto Aproximadamente constante para cada site Fluctuaciones dependiendo del uso

Posibilidades para la planificación y aprovisionamiento de recursos Soluciones (HTC) Posibilidades para la planificación y aprovisionamiento de recursos Pending Prolog Execution Epilog Métodos vinculantes iniciales (early-binding): la carga se planifica antes de que se asignen los recursos Métodos vinculantes finales (late-binding): se actúa sobre la asignación de recursos (provisioning)

Posibilidades para la planificación y aprovisionamiento de recursos Soluciones (HTC) Posibilidades para la planificación y aprovisionamiento de recursos Pending Prolog Execution Epilog Métodos vinculantes iniciales (early-binding): la carga se planifica antes de que se asignen los recursos Métodos vinculantes finales (late-binding): se actúa sobre la asignación de recursos (provisioning)

Soluciones (HTC) El punto de partida es que hay que modelar problemas complejos que generalmente siguen un patrón (Muchas) Simulaciones + Matemáticas Números aleatorios para inicializar simulaciones Tareas simples e independientes Estadística u operaciones diversas para unir los resultados Inicialización (I): tiempo constante y/o variable Simulación (S): tiempo variable Análisis de los resultados (R): tiempo constante y/o variable Tejec = Ic + Iv· N + Sv· N + Rc + Rv· N ~ a· N + b (con N = número de samples)

Soluciones (HTC) Se hace un estudio de cómo se ejecuta el código de interés en cada site (profiling) Realizar 1, 10, 100, 1.000… simulaciones (u otra serie) Obtener a y b (recordemos que Tejec ~ a· N + b) Ejecutar el benchmark Whetstone en el mismo site Adecuado para monoprocesadores Normalizar Repetir este proceso en varios sites para evitar distorsiones

Se actualiza la información de cada site Soluciones (HTC) Se actualiza la información de cada site Cada vez que cambia algo en él (memoria, CPU…) o aparece uno nuevo Globus Monitoring & Discovering System Después de cada ejecución Rendimiento Eficiencia, tareas fallidas, slots disponibles Tiempo de cola Ancho de banda Los resultados tras cada ejecución se ponderan Fórmula de Biessel Las ejecuciones nuevas cuentan más que las viejas

Soluciones (HTC) Con toda esa información, se diseña un algoritmo que decide cómo y dónde se ejecuta el código Para tener una eficiencia optimizada Para alcanzar una política de tiempo máximo de espera de resultados Se implementa una herramienta que con ese algoritmo (u otro, ha de ser modular) sirva como interfaz para el usuario Utiliza información estática y dinámica Actúa en 2 niveles: recurso local y remoto Produzca un overhead lo menor posible

Posibilidades para la planificación y aprovisionamiento de recursos Soluciones (HTC) Posibilidades para la planificación y aprovisionamiento de recursos Pending Prolog Execution Epilog Métodos vinculantes iniciales (early-binding): la carga se planifica antes de que se asignen los recursos Métodos vinculantes finales (late-binding): se actúa sobre la asignación de recursos (provisioning)

La planificación se desarrolla para mejorar el rendimiento de Soluciones (HTC) El objetivo es implementar metodologías que actúen directamente sobre los recursos remotos más allá de una obtención precisa de su información Se sigue una estrategia de caballo de Troya (trabajos pilotos o pilot jobs) Aprovisionamiento de recursos La planificación se desarrolla para mejorar el rendimiento de La ejecución del código cumpliendo los requisitos computacionales del mismo Las MM.VV. que se hayan iniciado (si estamos en la nube) La localización de los datos para la distribución de trabajos

Aunque no únicamente, se desarrolla sobre infraestructuras federadas Soluciones (HTC) Aunque no únicamente, se desarrolla sobre infraestructuras federadas En la nube, se actúa sobre IaaS (Infrastructure-as-a-Service) Correo-e, Escritorio remoto, Aplicaciones… Entorno de desarrollo, BBDD, Serv. Web MV, Servidores, Almacenamiento, Red…

Los sistemas de pilotos (pilot systems) han de Soluciones (HTC) Los sistemas de pilotos (pilot systems) han de Ser capaces de gestionar grid y cloud E incluso clústeres locales y computación voluntaria Ser compatibles con aplicaciones ya portadas a HTC Mejorar la productividad y rendimiento previo Ser interoperables con estándares ya desarrollados para distintas infraestructuras Ser configurables por el usuario para adaptarse a las necesidades del código Gestionar adecuadamente trabajos de corta duración Peor escenario para pilot systems

Legacy Application GWpilot Factory GWcloud Execution Driver Server CLI task launching applications Launching applications GWpilot Factory pilots GWcloud Execution Driver Server task CLI DRMAA BES Scheduler GridWay Core OCCI GWcloud Information Driver task HTTPS pull IaaS Federation abstraction LDAP Top BDII Provider A Provider B Federated IaaS Cloud task

Soluciones (HTC) Como en el caso anterior, se diseña un algoritmo que decide cómo y dónde se ejecuta el código y se implementa una herramienta que sirva como interfaz para el usuario Para reducir el overhead en la nube, lo ideal es levantar una MV para cada trabajo Si estamos en la nube y estamos accediendo a una infraestructura privada, hay que tener en cuenta el coste económico además Es posible acoplar herramientas de early- y late-binding para maximizar el uso de la infraestructura (stacking)

Índice La Computación de Altas Prestaciones Problema Justificación Soluciones Algunos resultados

Resultados (HTC) Existe una variedad de herramientas que implementan las metodologías explicadas anteriormente Algunas de ellas son módulos integrados en los gestores de recursos (LRMS) Aquí se mostrarán algunos resultados de las herramientas desarrolladas en el CIEMAT Early-binding  Montera Late-binding  GWpilot

Montera (HTC)

Montera es una aplicación Phyton residente en el área de usuario Montera (HTC) Montera es una aplicación Phyton residente en el área de usuario API para la creación de chunks y controlar la ejecución local Plantilla name=isdep.sh num_samples=5000 input_files=isdep.sh, lgv_LHD_ion_2species. files.tar.gz, crea_input, config_mag_LHD.ini output_files=output${TASK_ID}.tar.gz scheduling_policy=dytss max_profiling time (optional) environment_variables (optional Comando final run.montera template.mt

Dynamic Trapezoidal Self Scheduling Montera (HTC) Dynamic Trapezoidal Self Scheduling Algoritmo implementado para Montera Asymptotic performance Half performance length Necesita Profiling de los Monte Carlo (o códigos muy desacoplados) Profiling de los Recursos Funcionamiento (simplificado) Más samples a los recursos más potentes (chunk) Replicación de tareas para evitar cuellos de botella en tiempo real, no sólo al principio

Deadline Policy (Entorno real de producción EGI) Montera (HTC) Deadline Policy (Entorno real de producción EGI) Ejecución de tantas tareas de FAFNER2 como sea posible en 2.000 s

Montera (HTC) Adaptación a slots libres (ce01-tic.ciemat.es)

DyTSS (Entorno real de producción EGI) Montera (HTC) DyTSS (Entorno real de producción EGI) 5.000 partículas (~ 10% de un caso real de estudio de FastDEP) UMD es el planificador más usado en EGI GridWay es el planificador en el que está basado Montera   Montera Scheduler/Montera [hh:mm] GridWay UMD Walltime 60:26 1,16 1,62

Walltime GW / Walltime Montera Montera (HTC) DyTSS (Entorno real de producción EGI) 4·108 partículas (caso real de estudio de BeamNRC) Simulated samples Walltime GW / Walltime Montera   50 tasks 100 tasks 250 tasks 10 4 0,7 0,9 4,6 10 6 1,1 1,4 2,4 10 8 1,8 1,5 1,3

GWpilot (HTC) Comparativa de sistemas de pilotos

GWpilot ( DKEsG – Entorno real de producción EGI) GWpilot (HTC) GWpilot ( DKEsG – Entorno real de producción EGI) 5·105 tareas independientes (configuración estándar del TJ-II)

GWpilot (Entorno real de producción EGI FedCloud) GWcloud (HTC) GWpilot (Entorno real de producción EGI FedCloud) 4·108 partículas (caso real de estudio de BeamNRC)

GWcloud acoplado (HTC) GWcloud + DyTSS (Entorno real de producción EGI FedCloud) 2·107 partículas (caso real de estudio de Nagano)

¡¡GRACIAS!! Red Iberoamericana de Computación de Altas Prestaciones (RICAP) http://www.red-ricap.org RICAP is partially funded by the Ibero-American Program of Science and Technology for Development (CYTED), Ref. 517RT0529.