Ing. Patricia Morales Calvo
71
Pruebas de desempeño para la evaluación de clústeres de alto rendimiento Yasmanis Basulto Castañeda Ing. Patricia Morales Calvo , junio de 2018
Transcript of Ing. Patricia Morales Calvo
Pruebas de desempeño para la evaluación de clústeres de alto rendimiento
Yasmanis Basulto Castañeda
Ing. Patricia Morales Calvo
, junio de 2018
Autor: Yasmanis Basulto Castañeda
Email: [email protected]
Tutor: Ing. Patricia Morales Calvo
Email: [email protected]
Cotutor: Ing. Sergio Chirino Tejeda
Email: [email protected]
, junio de 2018
Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu” de
Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria “Chiqui
Gómez Lubian” subordinada a la Dirección de Información Científico Técnica de la
mencionada casa de altos estudios.
Se autoriza su utilización bajo la licencia siguiente:
Atribución- No Comercial- Compartir Igual
Para cualquier información contacte con:
Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de Las
Villas. Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830
Teléfonos.: +53 01 42281503-1419´
i
PENSAMIENTO
“Nos sentimos libres al escapar, aunque sea del sartén al
fuego”.
Eric Hoffer
ii
DEDICATORIA
Dedico esta tesis a mis padres, por darme la vida, su amor, comprensión y
apoyo, porque gracias a ellos hoy estoy aquí.
iii
AGRADECIMIENTOS
A mis padres, por impulsarme a seguir hacia delante siempre y confiar en mí.
A toda mi familia, por brindarme su amor y apoyo en todo momento.
A mi tutor, por su ayuda y comprensión.
A mis amigos, por apoyarme y ayudarme siempre.
A aquellos profesores que han contribuido en mi formación profesional.
A todos los que han contribuido de una forma u otra en la realización de este
trabajo, a ellos que sin haberlos mencionado tendrán siempre mi eterna
gratitud.
A todos, muchas gracias
iv
TAREA TÉCNICA
Evaluar el comportamiento del clúster de alto rendimiento de la Universidad Central
“Marta Abreu” de Las Villas según las métricas de desempeño empleadas en
tecnologías de computación paralela.
Para llegar a cumplir dicha tarea se proponen las siguientes Tareas de
investigación:
1. La búsqueda de información sobre implementación y funcionamiento de
clústeres de alto rendimiento.
2. La caracterización del estado actual del clúster de alto rendimiento de la
UCLV.
3. La realización de un estudio de las principales métricas empleadas para
evaluar el desempeño de un clúster.
4. La selección de los programas o herramientas a utilizar para obtener las
métricas a evaluar.
5. La configuración de varios escenarios teniendo en cuenta los parámetros que
puedan variar los resultados.
6. La aplicación de las herramientas en los diferentes escenarios para la
obtención de los valores de las métricas.
7. La comparación de los resultados obtenidos.
8. La elaboración del informe.
v
RESUMEN
Los clústeres HPC ofrecen una capacidad computacional para solventar
requerimientos de alto costo computacional. Su beneficio radica en que, al realizar
procesamiento de manera distribuida y paralela, logran acortar los tiempos de
espera en la obtención de los resultados y de esta forma posibilitan una toma
decisiones con mayor anticipación. Sin embargo, para tener un rendimiento óptimo
de las aplicaciones que están instaladas en el clúster, es necesario utilizar
herramientas que simulen el uso intenso de sus recursos, lo que permite conocer
su comportamiento cuando se enfrenta a este tipo de situación.
En el presente trabajo se describen las principales herramientas que miden el
comportamiento del clúster cuando alguno de sus recursos es utilizado
intensamente. Con el objetivo de medir el rendimiento computacional del clúster de
la UCLV se realizan pruebas de rendimiento utilizando la herramienta HPL y
pruebas de escalabilidad con la aplicación NAMD.
.
vi
TABLA DE CONTENIDOS
PENSAMIENTO .................................................................................................................... i
DEDICATORIA .................................................................................................................... ii
AGRADECIMIENTOS ....................................................................................................... iii
TAREA TÉCNICA ............................................................................................................... iv
RESUMEN ............................................................................................................................ v
INTRODUCCIÓN ................................................................................................................. 1
CAPÍTULO 1. Métricas de desempeño en clústeres HPC ........................................ 4
1.1 Parametrización de una aplicación ..................................................................... 4
1.2 Medidas de Rendimiento...................................................................................... 7
1.3 MPI (Message Passing Interface) ....................................................................... 9
1.4 Benchmark............................................................................................................ 10
1.4.1 Versiones de los Benchmark...................................................................... 11
1.4.2 Herramientas de Benchmarking ................................................................ 12
1.5 Conclusiones parciales ....................................................................................... 18
CAPÍTULO 2. Métricas de desempeño con el empleo de la herramienta HPL ... 20
2.1 Etapas de las pruebas ........................................................................................ 21
2.2 Jerarquía de Caché y Memoria Principal ........................................................ 22
2.2.1 Localidad de referencia de los programas ............................................... 23
2.2.2 Jerarquía de memoria ................................................................................. 24
2.3 LINPACK Benchmark ......................................................................................... 26
2.3.1 HPL ................................................................................................................. 26
2.3.2 Configuración de HPL.dat ........................................................................... 28
vii
2.4 Conexión y transferencia de archivos al clúster ............................................. 29
2.5 Corridas de HPL y de NAMD ............................................................................. 31
2.6 Análisis de los escenarios .................................................................................. 33
2.7 Conclusiones parciales ....................................................................................... 38
CAPÍTULO 3. Análisis de los resultados .................................................................... 39
3.1 Resultados de las pruebas en el primer escenario ........................................ 39
3.2 Resultados de las pruebas en el segundo escenario .................................... 43
3.3 Resultado de las pruebas del tercer escenario .............................................. 46
3.4 Conclusiones parciales ....................................................................................... 49
CONCLUSIONES Y RECOMENDACIONES ................................................................ 50
Conclusiones .................................................................................................................. 50
Recomendaciones ......................................................................................................... 51
REFERENCIAS BIBLIOGRÁFICAS................................................................................ 52
Glosario ................................................................................................................................ 55
ANEXOS .............................................................................................................................. 56
Anexo I Ficheros de salidas en las pruebas a la aplicación NAMD ................... 56
INTRODUCCIÓN 1
INTRODUCCIÓN
En la actualidad, el uso de supercomputadoras se ha convertido en una necesidad
para resolver problemas que demanden grandes velocidades de procesamiento de
cálculo. La importancia de su uso en el campo de la investigación es invaluable, ya
que al utilizar técnicas de programación paralela se pueden simular y modelar
problemas científicos en un plazo de tiempo aceptable.
El surgimiento de los clústeres se remonta a los años 40 con la creación del ENIAC
(Electronica Numeral Integrator and Computer), el cual fue un computador
electrónico digital desarrollado por John Mauchly y John Presper Eckert. Su
desarrollo estuvo motivado por la ineficiencia detectada a la hora de resolver
problemas basados en algoritmos secuenciales. En esta misma década se dieron
los primeros pasos del procesamiento paralelo, cuando se lograron sincronizar un
grupo de microprocesadores que podían resolver problemas utilizando técnicas de
paralelismo. Pero no fue hasta los años 90, que aparecen los clústeres de
ordenadores, cuando varios proyectos llevaron a cabo la utilización de una red de
alta velocidad para interconectar un grupo de máquinas y hacerlas funcionar como
una sola[1],[2].
Los clústeres hoy en día se clasifican en base al uso que se les dé y a los servicios
que ofrecen en clústeres de alto rendimiento (HPC – High Performance
Computing)[3], clústeres de alta disponibilidad (HA – High Availability)[4] o clústeres
de alta eficiencia (HT - High Throughput)[5]. La necesidad de contar con una
plataforma de cómputo estable que funcione de manera eficiente hace que los
administradores de estos dispositivos utilicen herramientas que muestren su
comportamiento según las diversas tareas que enfrenten. Existen diversas formas
INTRODUCCIÓN 2
de medir el uso de los recursos del clúster siendo el más común los benchmark
(puntos de referencia del desempeño) estándar que son técnicas de medición para
monitorear su desempeño frente a diversas aplicaciones[6],[7].
La Universidad Central Marta Abreu de Las Villas (UCLV) cuenta con un clúster de
cálculo de alta disponibilidad y con un clúster de Big Data que poseen un
rendimiento teórico de 3,90 TFlops y 2,16 TFlops de operaciones en CPU
respectivamente. Su rendimiento real frente a las diferentes aplicaciones científicas
instaladas (NAMD, GROMACS, OpenFOAM, Matlab, Yade, Gaussian, etc) no se
conoce y es necesario el uso de herramientas para comprobar si estas funcionan
de la mejor manera posible.
Cuando la configuración de este tipo de ordenadores no es óptima se genera un
gasto energético innecesario y, además, disminuye la cantidad de usuarios que
pueden utilizar el servicio. Por ello se propone la siguiente interrogante científica:
¿Cuán eficiente es el comportamiento del clúster de la UCLV según las métricas de
desempeño empleadas en tecnologías de computación paralela y distribuida?
Para dar respuesta a esta interrogante se hace necesario tener en cuenta las
siguientes interrogantes de investigación:
¿Cuáles son las herramientas existentes que muestran el desempeño del
clúster cuando el uso de los recursos es crítico?
¿Cuál es la mejor forma de utilizar los benchmarks para obtener datos
objetivos del desempeño del clúster?
¿Cómo evaluar la efectividad de las técnicas empleadas para los distintos
escenarios de operación?
El objetivo principal de este trabajo es evaluar el comportamiento del clúster de alto
rendimiento de la Universidad Central “Marta Abreu” de Las Villas según las
métricas de desempeño empleadas en tecnologías de computación paralela. Del
mismo se derivan los siguientes objetivos específicos:
Definir los parámetros y las métricas de desempeño que mejor caracterizan
el rendimiento del clúster durante la ejecución de las aplicaciones.
INTRODUCCIÓN 3
Definir las herramientas a utilizar y sus configuraciones en los distintos
escenarios de experimentación.
Comparar los resultados obtenidos en los distintos escenarios y arribar a
conclusiones.
Organización del informe
El informe está estructurado de la siguiente forma: introducción, capitulario,
conclusiones, recomendaciones, referencias bibliográficas, glosario de términos y
anexos. A continuación, se resume el contenido de los capítulos:
Capítulo 1: Análisis crítico del estado del arte de las técnicas y tecnologías que se
utilizan para evaluar el desempeño en los clústeres HPC. Se realiza una
caracterización de un grupo de métricas empleadas para comprobar el
funcionamiento de un clúster basado en CPU y se seleccionarán las más adecuadas
para su implementación en el presente trabajo.
Capítulo 2: Se desarrollan los materiales y métodos para la experimentación.
Además, se describirá el procedimiento utilizado para su implementación, y el
diseño de los experimentos a realizar. Se abordarán las herramientas de softwares
empleadas y los escenarios de las pruebas a realizar.
Capítulo 3: Se describirán los resultados obtenidos comparando el valor teórico
proporcionado por el fabricante con los valores obtenidos en las pruebas realizadas
con los benchmarks disponibles para mostrar cuán eficiente es la implementación.
Se identificarán problemas de funcionamiento, se trabajará en su solución y se
realizarán propuestas para mejorar el rendimiento actual del clúster de la UCLV y
su funcionamiento.
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 4
CAPÍTULO 1. Métricas de desempeño en clústeres HPC
El uso optimizado de los recursos computacionales que ofrecen los clústeres, se
obtiene tras un proceso de ajuste y configuración, que implica la medición del
comportamiento de aplicaciones durante su ejecución. Para esto se monitorean los
tiempos de CPU para diferentes magnitudes de problemas ejecutados en un mismo
clúster o en diferentes clústeres. Cuando se comparan estas estimaciones es
posible establecer mejoras reajustando el número de nodos a emplear según el
tamaño de la tarea. El uso de recursos innecesarios puede llegar a empobrecer el
desempeño de la aplicación.
Con el objetivo de utilizar herramientas que permitan evaluar el rendimiento de
clústeres HPC, en este capítulo se caracterizan los diferentes parámetros que utiliza
una aplicación para interactuar con el clúster, las principales métricas de
rendimiento existentes y los programas que comprueban el funcionamiento del
clúster cuando algunos de sus recursos se utilizan de manera intensiva.
1.1 Parametrización de una aplicación
Para explicar como ocurre la interacción entre el clúster y la aplicación, se supone
que, al ser ejecutada la tarea, esta es separada en diferentes componentes
pudiendo considerarse a cada uno de ellos como un programa paralelo. Estos
componentes pueden ser caracterizados por:
Nj: Parámetro de entrada de la aplicación requerido para predecir su
complejidad.
O: Número de operaciones realizadas por la CPU en Flops.
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 5
W: Número de “palabras” (operando de 64 bits) accedidas desde la memoria
principal o escritas en la memoria principal.
Z: Número de mensajes enviados sobre la red de comunicación.
S: Número de “palabras” enviadas sobre la red de comunicación.
𝜎: Media o promedio del tamaño de mensaje.
𝑛𝑠𝑑: Número de tareas en que la aplicación puede ser desglosada.
En arquitecturas paralelas se utilizan las operaciones de punto flotante (Flop) como
medida del número de operaciones de 64 bits de adición o multiplicación que puede
realizar el clúster por segundo. Según los parámetros anteriores se pueden definir
expresiones para mostrar como la aplicación utilizará los recursos disponibles.
El tamaño promedio de los mensajes determina el ancho de banda real utilizado en
la red de comunicación y está definida por la siguiente expresión:
𝜎 =𝑆
𝑍
El acceso a la memoria principal se comporta según el valor de 𝑉𝑎 [Flops/w] donde
una aplicación programada para funcionar de forma optimizada en el clúster, se
caracterizará por un alto valor de 𝑉𝑎 acercando el rendimiento del procesador a su
pico teórico mientras que un valor pequeño mostrará un alto uso de los
componentes del ancho de banda de la memoria principal. La siguiente expresión
muestra las variables de las que depende el comportamiento descrito:
𝑉𝑎 =𝑂
𝑊
La comunicación de la red se comporta según el valor de 𝛾𝑎 [Flops/w] el cual debe
ser lo mayor posible para alcanzar la comunicación deseada. Es un parámetro
definido por la siguiente expresión:
𝛾𝑎 =𝑂
𝑆
Al ser la latencia un recurso importante, el número de mensajes enviados sobre la
red de comunicación debe ser pequeño, por lo que cada mensaje debe tener la
mayor cantidad posible de operandos de 64 bits. De esta forma serán enviados solo
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 6
el número de mensajes necesarios, teniendo estos el mayor tamaño posible
admitido por la red de comunicación.
Para una aplicación que se ejecuta en varios nodos, donde se hace necesaria la
comunicación entre los mismos, se tienen en cuenta los siguientes parámetros:
𝑟𝑎: Rendimiento teórico por nodo para la aplicación. Se expresa en GFlops.
𝑅𝑎: Rendimiento real por nodo para la aplicación. Se expresa en GFlops.
𝑔𝑝: Eficiencia de un núcleo.
𝑀𝑚: Ancho de banda real de la memoria principal. Se expresa en GFlops.
𝑔𝑚: Eficiencia de la memoria principal.
T: Tiempo total de ejecución. Se expresa en segundos.
𝑡𝑐𝑜𝑚𝑝: Tiempo empleado por la CPU. Se expresa en segundos.
𝑡𝑐𝑜𝑚𝑚: Tiempo empleado en la comunicación. Se expresa en segundos.
𝑡𝑏: Tiempo empleado en transferir datos. Se expresa en segundos.
𝑡𝐿: Latencia. Se expresa en segundos.
𝑡𝑠: Tiempo en que empieza la ejecución de la aplicación. Se expresa en
segundos.
𝑡𝑒: Tiempo en que termina la ejecución de la aplicación Se expresa en
segundo.
Para conocer si la red en la que se ejecuta la aplicación es idónea se emplea el
modelo Γ que está definido por la siguiente expresión matemática:
𝛤 =𝛾𝑎
𝛾𝑚
Donde 𝛾𝑎 expresa el tiempo de comunicación de red requerido por la aplicación y
𝛾𝑚 define la comunicación de red disponible. Si 𝛤 = 1 el tiempo de CPU y el tiempo
de comunicación son iguales, si 𝛤 = 0 la comunicación toma el máximo tiempo
posible y si 𝛤 = ∞ indica que no hay comunicación entre los nodos.
El objetivo de tener un clúster funcionando en óptimas condiciones es poder usar
sus recursos para ejecutar el mayor número de aplicaciones paralelas en el menor
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 7
tiempo posible. Las aplicaciones paralelas tienen diferentes necesidades de
comunicación y atendiendo a este parámetro existen tres tipos:
Aplicaciones embarrassingly parallel: Estas aplicaciones no presentan
comunicaciones entre nodos esclavos, por lo que no existe intercambio de
datos entre los mismos. El nodo master distribuye en los nodos esclavos las
tareas y es el encargado de integrar el resultado. En este caso 𝑡𝑐𝑜𝑚𝑝 >>
𝑡𝑐𝑜𝑚𝑚.
Aplicaciones con comunicación punto a punto: Este tipo de comunicación
aparece en métodos de elementos o volúmenes finitos cuando un dominio
es descompuesto en subdominios o al resolver matrices. El número de
operaciones por paso se relaciona directamente con el número de variables
en un subdominio.
Aplicaciones que necesitan comunicación multicast: El algoritmo de la
transformada discreta de fourier (FFT) es un ejemplo típico que necesita de
este tipo de comunicación.
Al saber que parámetros determinan el comportamiento de las aplicaciones se
introduce a continuación las medidas de rendimiento para poder caracterizar el
empleo correcto de los recursos del clúster[3], [8], [9].
1.2 Medidas de Rendimiento
Al medir la eficiencia de un sistema paralelo se observan generalmente dos
parámetros fundamentales:
1- Tiempo de ejecución (o respuesta) de una aplicación.
2- Productividad (Throughput) o número de aplicaciones que es capaz de
procesar por unidad de tiempo.
Las arquitecturas paralelas también tienen en cuenta otras medidas como el
rendimiento real respecto al teórico, aceleración o speed-up y la eficiencia paralela
para caracterizar su estado funcional.
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 8
Pico Teórico
El rendimiento teórico de los nodos de un clúster está determinado por el número
de instrucciones de doble precisión que ejecuta por segundo, la frecuencia a la que
trabaja el procesador y su número de núcleos. La siguiente expresión permite
determinar este valor:
𝑅𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜𝑇𝑒ó𝑟𝑖𝑐𝑜 = 𝐷𝑃 ∗ 𝑓 ∗ #_𝑑𝑒_𝑛ú𝑐𝑙𝑒𝑜𝑠
Establecer una comparación de este resultado con el rendimiento real permite
conocer el poder de cómputo del sistema.
Speed-Up
El speed-up es la mejora en velocidad de una tarea tomando como base la ejecución
secuencial y relacionándola con el resto de ejecuciones incrementando el número
de procesadores. Es definida por la siguiente expresión matemática:
𝑆𝑝𝑒𝑒𝑑𝑈𝑝 =𝑇1
𝑇𝑝
Donde T1 es el tiempo de ejecución secuencial base y Tp es el tiempo de ejecución
teniendo en cuenta los procesadores que participen[10].
La aplicación de la definición anterior permite conocer la aceleración alcanzada en
la resolución de un problema altamente paralelizable y determinar si esta es
eficiente, ya que el incremento de nodos en la ejecución de una tarea aumenta el
gasto energético e imposibilita el uso de estos recursos por otras personas.
Eficiencia Paralela
La eficiencia paralela es la relación entre el speed-up (Sp) y el número de
procesadores (P) utilizados en la aplicación. Es definida por la siguiente expresión
matemática[11]:
𝐸𝑓𝑓𝑝 =𝑆𝑝
𝑃
Como en el rendimiento de la ejecución de un programa influyen la comunicación
interproceso, la coherencia de la caché, la jerarquía de memoria y otros elementos,
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 9
la expresión permite conocer, despreciando estos factores, el grado de paralelismo
de la tarea ejecutada según la cantidad de procesadores a utilizar en la resolución
del problema.
1.3 MPI (Message Passing Interface)
Los sistemas de procesamiento en paralelo mejoran el rendimiento de las
aplicaciones al utilizar más de un procesador para su ejecución. Para lograr esto se
necesita una manera de fragmentar una aplicación en ejecuciones paralelas. El
estándar de pasos de mensajes (MPI) resuelve el problema al contener un grupo de
funciones diseñadas para usarse en programas que exploten la existencia de
múltiples procesadores. Sus rutinas están escritas en C o FORTRAN, es portable,
eficiente, flexible y soporta arquitecturas de memoria distribuida, compartida e
híbrida[12].
Características de un programa MPI
Un programa MPI está basado en el modelo de programación de paso de mensajes,
donde al iniciarse una aplicación lanza en paralelo N copias del mismo programa
(procesos). Estos procesos no avanzan sincronizados instrucción a instrucción, por
lo que debe hacerse explícita la sincronización cuando sea necesaria. Además, el
intercambio de información, así como la sincronización, se hacen mediante paso de
mensajes.
Dispone de funciones de comunicación punto a punto (que involucran sólo a dos
procesos), y de funciones u operaciones colectivas (que involucran a múltiples
procesos). Los procesos pueden agruparse y formar comunicadores, lo que permite
una definición del ámbito de las operaciones colectivas, así como un diseño
modular.
La estructura típica de un programa MPI escrita C es el siguiente:
# include "mpi.h"
main (int argc, char **argv) {
int nproc; /* Número de procesos */
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 10
int yo; /* Mi dirección: 0<=yo<=(nproc-1) */
MPI_Init(&argc, &argv);
MPI_Comm_size(MPI_COMM_WORLD, &nproc);
MPI_Comm_rank(MPI_COMM_WORLD, &yo);
/* CUERPO DEL PROGRAMA */
MPI_Finalize();
}
Este segmento de código presenta cuatro de las funciones más utilizadas de
MPI[13]:
MPI_Init(): Para iniciar la aplicación paralela.
MPI_Comm_size(): Para averiguar el número de procesos que participan en
la aplicación.
MPI_Comm_rank(), para que cada proceso conozca su dirección
(identificador) dentro de la colección de procesos que componen la
aplicación.
MPI_Finalize() para dar por finalizada la aplicación.
La mayor fuente de información sobre MPI es la página web mantenida por Argonne
National Laboratory en http://www.mcs.anl.gov/mpi/index.html/. En ella se puede
encontrar enlaces al texto del estándar, así como diferentes recursos para
aprendizaje de MPI. Además, están disponibles implementaciones de dominio
público de MPI. Una de las más conocidas es MPICH, desarrollada por Argonne
National Laboratory y Mississippi State University, con versiones para múltiples
sistemas paralelos (SGI, IBM, Intel, Cray, etc.) y para diferentes redes de
ordenadores (IBM, HP, Sun, etc.).
1.4 Benchmark
En términos informáticos un benchmark es una aplicación destinada a medir el
rendimiento de un ordenador o de algún elemento del mismo. Para esto se somete
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 11
a un grupo de pruebas con la intención de medir su respuesta ante las mismas.
Existen tres tipos de fuentes de benchmark[14]:
Benchmark especificados por vendedores de supercomputadoras como es
el caso de iCOMP[15].
Organizaciones que comparten sus benchmark como es el caso de Linpack,
NAS[16] y SPLASH[17].
Organizaciones industriales como es el caso de SPEC[18].
Hay diferentes tipos de benchmark que van desde los simples (que contienen 100
líneas de código) hasta los complejos (que contienen más de 100 000 líneas de
código). Para poder escoger un benchmark que se aproxime a las aplicaciones que
se utilizan mayormente en el clúster de la UCLV es necesario entender que los
diferentes benchmark miden el comportamiento de diferentes recursos.
1.4.1 Versiones de los Benchmark
Existen versiones distintas de los benchmark, que según los escenarios
uniprocesador, multiprocesador y multinodo, son utilizados para evaluar la
escalabilidad de las aplicaciones, la eficiencia paralela a nivel de nodo o a nivel de
clúster y el rendimiento de la red de comunicación entre nodos.
La tabla 1.1 muestra las versiones disponibles para algunos de los benchmark que
serán descritos:
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 12
Benchmark Uniprocesador Multiprocesador Multinodo
DGEMM X X
STREAM X X
PTRANS X
RandomAccess X X X
FFT X X X
HPL X
Tabla 1.1. Versiones disponibles de los benchmarks[19].
1.4.2 Herramientas de Benchmarking
La computación de alto rendimiento se vio influenciada en sus inicios por
benchmarks desarrollados por usuarios, siendo estos la primera fuente de
información del rendimiento del dispositivo. El primero de los benchmark fue el
Unpack benchmark escrito por Jack Dongarra en el Laboratorio Nacional de
Tennessee. Su objetivo no fue desarrollar un benchmark, sino rutinas que
resolvieran sistemas de álgebras lineales. Para comprobar su funcionamiento en los
clústeres, los resultados se publicaron y comenzaron a adoptarse como una medida
de rendimiento de la CPU.
A continuación se presentan los benchamark DGEMM[20], STREAM[21],
PATRANS[22], RandomAccess[23], FFT[24], HPL[25], la suite HPC Challenge
Benchmark (HPCC)[26], que incluye mediciones de latencia y ancho de banda de
la comunicación (Communication Bandwidth and Latency), y el benchmark
PEAK[27] que pertenece a la suite PMAC (Performance Modelling and
Characterization)[28]. Además, se caracteriza el software NAMD[29], que es un
software de dinámica molecular para procesamiento en paralelo. En algunos casos
se hará referencia a las expresiones matemáticas que utilizan las pruebas para
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 13
medir los siguientes recursos computaciones: memoria principal, ancho de banda
de red disponible y capacidad de procesamiento.
DGEMM (Double-precision GEneral Matrix-Multiply): Multiplica matrices en
doble precisión utilizando un algoritmo de partición en bloques para reutilizar datos
y minimizar el acceso a memoria principal, tanto para versiones secuenciales como
para multiprocesador. Para esto utiliza por defecto una subrutina de la biblioteca
cBLAS (Basic Linear Algebra Subprograms, versión en el lenguaje C), que realiza
la siguiente operación:
𝐶 = 𝛼 ∗ 𝐴 ∗ 𝐵 + 𝛽 ∗ 𝐶
Donde: 𝐴, 𝐵, 𝐶 𝜖 𝑅𝑛𝑥𝑛 𝑦 𝛼, 𝛽 𝜖 𝑅.
La complejidad de la región a evaluar es 2𝑛3 siendo los registros de caché el recurso
más utilizado. Existen dos versiones: SingleDGEMM que se ejecuta en un único
procesador y StarDGEMM que se ejecuta en varios procesadores a la vez. Al no
existir comunicación entre los procesos (excepto a la hora de dar los resultados)
ambas versiones son similares y permiten evaluar el desempeño del procesador.
STREAM: Es un benchmark que evalúa la eficiencia de acceso a memoria principal
mediante operaciones sobre vectores y matrices de gran tamaño. Se compone de
4 pruebas como se muestra en la tabla 1.2:
Nombre Kernel Bytes/iteración Flops/iteración
COPY 𝑎(𝑖) = 𝑏(𝑖) 16 0
SCALE 𝑎(𝑖) = 𝑞 ∗ 𝑏(𝑖) 16 1
SUM 𝑎(𝑖) = 𝑏(𝑖) + 𝑐(𝑖) 24 1
TRIAD 𝑎(𝑖) = 𝑏(𝑖) + 𝑞 ∗ 𝑐(𝑖) 24 2
Tabla 1.2. Pruebas de STREAM [21]
El código STREAM se ejecuta y multiplica por varios ciclos. En estas operaciones
no hay reaprovechamiento de datos, pero los accesos son secuenciales, así que se
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 14
aprovecha al máximo la localidad espacial. Los bucles acceden a estructuras de
datos lo suficientemente grandes como para que los datos sobrepasen la memoria
caché. Cada una se mide en regiones de tiempo diferentes, pero se repiten al menos
10 veces dentro de cada región para obtener una mejor muestra. El tamaño de datos
para vectores de m elementos es 16*m bytes para COPY y SCALE y 24*m bytes
para ADD y TRIAD, con complejidad 2*n y 3*n respectivamente. La medida de
rendimiento obtenida se expresa en GB/s que representa el ancho de banda
sostenido de acceso a la memoria RAM de un nodo.
Además de estos valores se calcula otro número denominado saldo de máquina
(machine balance). El mismo captura el rendimiento relativo de los cálculos de coma
flotante frente al ancho de banda de la memoria. Valores grandes de saldo de
máquina se traducirá en un intenso uso del caché. Si bien el índice de referencia de
STREAM no dice exactamente qué tan bien funcionará su computadora, puede
indicar algunas fortalezas y debilidades básicas del desempeño para ayudar a
diseñar puntos de referencia que prueben esas fortalezas y debilidades con mayor
precisión. Los proveedores de computadoras a menudo usan el benchmark
STREAM en sus propias pruebas internas, y los proveedores de computadoras los
citan cada vez más en su documentación externa.
PTRANS (Parallel TRANSposition): Evalúa la comunicación entre dos procesos
que intercambian mensajes de gran dimensión en un algoritmo distribuido para
multiplicación de matrices densas. PTRANS permite determinar la capacidad de la
red de interconexión, y es un programa útil para medir el desempeño de las
comunicaciones cuando se transfieren grandes volúmenes de datos. La operación
matemática realizada es:
𝐴 = 𝐴𝑇 + 𝐵
Siendo A y B matrices aleatorias donde 𝐴, 𝐵 𝜖 𝑅𝑛𝑥𝑛. La tasa de transferencia de
datos se determina por el cociente entre los 𝑛2 elementos de cada matriz y el tiempo
necesario para llevar a cabo la transposición. Para transponer la matriz se asigna
un bloque de datos a cada proceso MPI y entre ellos se comunican por parejas.
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 15
Los resultados se presentan en Gigabytes por segundo y como incluye un
mecanismo de verificación (test), permite evaluar la precisión del procesador al
trabajar en aritmética de punto flotante.
RandomAccess: Evalúa la velocidad con que el sistema es capaz de actualizar las
direcciones de memoria aleatoria y se expresa en Giga UPdates per Second
(GUPS). GUPS es calculado identificando el número de localizaciones de memoria
que pueden ser actualizadas aleatoriamente en un segundo. El término aleatorio se
debe a que existe muy poca relación entre una dirección a ser actualizada y la
siguiente, solo que esto ocurre en un espacio equivalente a la mitad de la memoria
total del sistema. La actualización se traduce en operaciones de lectura,
modificación y escritura.
Dado un vector de tamaño fijo, se crea una tabla T de tamaño 2𝑛 y una secuencia
Ai de enteros de 64 bits de longitud 2𝑛+2 generados con la función 𝑥2 + 𝑥 + 1. Lo
anterior ocurre cuando una dirección es generada, siendo este valor leído desde la
memoria y modificado por una operación (add, and, or, xor), que será el nuevo valor
escrito en la memoria.
En la implementación MPI cada procesador genera una parte de la secuencia de
índices y realiza sus propias actualizaciones de memoria, en consecuencia, se
generan gran cantidad de mensajes de poco tamaño por lo que es necesario
comunicación todos con todos. De este modo se permite analizar el impacto de la
latencia introducida en el paso de mensajes.
Los accesos aleatorios provocan que no exista ningún tipo de localidad, evitando
aprovechar la jerarquía de memoria (especialmente los niveles de caché) y así
poder determinar el costo con máxima penalización de acceder a memoria
compartida en el sistema.
FFT (Fast Fourier Transformation): Es un benchmark que se basa en la ejecución
de transformadas de Fourier discretas y uni-dimensionales sobre aritmética
compleja de punto flotante de doble precisión. Al igual que en los benchmarks
descritos anteriormente, tiene sus versiones secuenciales, de ejecución simultánea
sobre varios procesadores, y de ejecución distribuida (en las cuales el vector de
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 16
entrada se dispersa en bloques para varios procesos, utilizando MPI). Es un kernel
habitualmente utilizado en aplicaciones reales descrito por la siguiente expresión
matemática:
𝑍𝑘 = ∑ 𝑥𝑗𝑒−2𝑖𝜋𝑗𝑘/𝑛𝑛−1𝑗=0 para 1 ≤ 𝑘 ≤ 𝑛
FFT permite evaluar la eficiencia del procesador y también la precisión del sistema
de representación de punto flotante utilizado, ya que incluye una rutina de
verificación que aplica una implementación de referencia de la transformada de
Fourier inversa a la salida del benchmark. Los valores se expresan en GFlops, que
se calculan en base al tiempo y a la complejidad del algoritmo (5𝑛𝑙𝑜𝑔2𝑛). Durante la
ejecución hay un gran volumen de intercambio de grandes mensajes entre los
procesadores que participan.
Ancho de banda y latencia de la comunicación: Es un grupo de pruebas para
evaluar el ancho de banda efectivo y la latencia de la red de interconexión del clúster
mediante mensajes MPI punto a punto. No se realizan cálculos adicionales al
evaluar los nodos.
Basados en diferentes patrones de comunicación MPI, se obtienen medidas de
latencia y ancho de banda utilizando. Algunos ejemplos de patrones son ping-pong,
natural ring y random ring.
A continuación, se muestran la figura 1.1 y la figura 1.2 algunos ejemplos de
conexión MPI en natural ring y en random ring[30].
Figura 1.1 Conexiones que realiza MPI en Natural ring [26]
Figura 1.2 Posible patrón que realiza MPI en random ring [26]
HPL (High-Performance LINPACK): Es una implementación del famoso
benchmark LINPACK. El software se basa en un enfoque descompositivo del
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 17
álgebra lineal numérica y su idea general es que dado un problema que involucra
una matriz, uno descompone la matriz en un producto de matrices simples y bien
estructuradas que pueden manipularse fácilmente para resolver el problema
original. El paquete tiene la capacidad de manejar muchos tipos diferentes de
matrices y diferentes tipos de datos, y proporciona una amplia gama de opciones.
Utiliza el método de factorización Lower-Upper (LU) y luego resuelve el sistema
𝑈𝑥 = 𝑦. La complejidad del método es igual a la expresión: 2
3𝑛3 + 2𝑛2 extrayendo
de ahí la fórmula que utiliza HPL para medir el rendimiento en GFlops y teniendo
este un valor equivalente a la expresión matemática siguiente:
𝑃𝐻𝑃𝐿 =
23 𝑛3 + 2𝑛2
𝑡𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠10−9
HPL nos da una medida de rendimiento del microprocesador en un margen del 70%
al 80% del pico teórico (PP) y al ser una herramienta de código abierto es muy
utilizada por universidades e instituciones sin ánimos de lucro.
PEAK (Performance Evaluation Application Kernel): Consiste en una prueba
que evalúa la eficiencia del procesador mediante un ciclo de operaciones que
incluye divisiones, productos y evaluación de un polinomio de quinto grado. Los
detalles de las operaciones de PEAK, sus instrucciones y el número de Flops y de
operaciones de memoria involucradas se presentan en la tabla 1.3.
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 18
Operación Instrucciones Flops Op. en
memoria.
División 𝑠 =𝑠
𝑎(𝑖) 1 1
producto daxPy 𝑎(𝑖) = 𝑎(𝑖) + 𝑠 ∗ 𝑏(𝑖) 2 3
producto dot 𝑠 = 𝑠 + 𝑠(𝑖) ∗ 𝑏(𝑖) 2 2
evaluación
del polinomio
𝑎(𝑖) = ((((𝑐5 ∗ 𝑏(𝑖) + 𝑐4) ∗ 𝑏(𝑖) + 𝑐3)
∗ 𝑏(𝑖) + 𝑐2) ∗ 𝑏(𝑖) + 𝑐1)
∗ 𝑏(𝑖) + 𝑐3)
10 2
Tabla 1.3. Operaciones del benchmark PEAK [27].
NAMD (Not (just) Another Molecular Dynamics program): es un software para
dinámica molecular en paralelo, diseñado para simulaciones de alto desempeño de
sistemas biomoleculares. Las simulaciones de dinámica molecular computan las
trayectorias atómicas de forma tal que resuelven las ecuaciones del movimiento
numéricamente utilizando campos de fuerza empíricos, como el campo CHARMM,
que aproxima la fuerza atómica real en sistemas de biopolímeros. Está basado en
objetos paralelos Charm++ y es escalable a decenas de procesadores en clusters
usando ethernet o gigabit. Es un software gratis, con código fuente en C++ y portátil
que puede ser utilizado en cuanlquier plataforma con ethernet o MPI.
1.5 Conclusiones parciales
Las aplicaciones que se ejecutan en un clúster adquieren un grupo de parámetros
que permiten determinar si estas funcionan de manera eficiente. Cada programa
utilizará diferentes recursos y su posible comportamiento se puede saber mediante
herramientas que simulan estas necesidades.
El benchmarking es la base cuantitativa de la investigación de Arquitectura de
Computadores Paralelas ya que se utiliza para determinar experimentalmente el
CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA 19
comportamiento de los softwares científicas instalados en el clúster. Se
seleccionará el benchmark HPL ya que es una herramienta que dispone de amplia
bibliografía, es de código abierto y mide el rendimiento del procesador siendo este
recurso el de mayor demanda por parte de los investigadores de la UCLV. Además,
sus versiones recientes permiten evaluar supercomputadores con más potencia y
nuevas arquitecturas (memoria distribuida). El uso del software de dinámica
molecular NAMD permitirá conocer si una aplicación escalable utiliza de forma
correcta los recursos del clúster.
CAPÍTULO 2. MATERIALES Y MÉTODOS 20
CAPÍTULO 2. Métricas de desempeño con el empleo de la
herramienta HPL
Al utilizar herramientas de pruebas de desempeño se realizan operaciones simples
con el fin de utilizar los componentes del hardware a su máxima capacidad y de esta
forma obtener una medida de su rendimiento. Es importante conocer el significado
de estas operaciones de forma tal que permitan utilizar los resultados obtenidos en
función de alcanzar un mejor rendimiento o funcionamiento del clúster.
Obtener un buen rendimiento al ejecutar una aplicación concreta que se encuentra
en producción (aplicación instalada en clúster y utilizada por los investigadores) no
significa que otras aplicaciones disponibles se comportarán de forma similar, ya que
en gran medida esto va a depender de sus necesidades computacionales. Esto
puede deberse a diversas causas: diferente patrón de accesos a memoria, número
de llamadas a sistema, insuficiente balance de carga, etc.
Por ejemplo, si se desea hacer una estimación del rendimiento que se obtendrá en
un tipo de aplicación que hace cálculo intensivo con operaciones en coma flotante,
se puede prever el rendimiento según los resultados obtenidos con la herramienta
HPL. El uso de este tipo de prueba de desempeño se ha hecho frecuente al permitir
a los administradores solucionar problemas de instalación y configuración de un
clúster de alto rendimiento.
En este capítulo se explica la diferencia entre el acceso a la memoria caché y el
acceso a la memoria principal para entender cómo influye su uso en las pruebas de
desempeño que se realizan. También, se describe el proceso que se realizó a la
hora de validar los resultados, el procedimiento para conectarse al clúster de la
CAPÍTULO 2. MATERIALES Y MÉTODOS 21
UCLV, los requisitos de funcionamiento de la herramienta HPL, así como la
instalación y configuración de la herramienta, y como estructurar un script de
SLURM (Simple Linux Utility for Resource Management) para ejecutar las
prueba[31] de esta herramienta y de la aplicación NAMD.
2.1 Etapas de las pruebas
La figura 2.1 muestra a grandes rasgos las etapas del proceso realizado a la hora
de ejecutar las diferentes pruebas. Como no se conoce el comportamiento base del
sistema, se comienza configurando en el archivo HPL.dat que contiene los valores
para realizar una prueba inicial. Luego se procede a trabajar en etapas iterativas
asegurando en cada paso la estabilidad de los resultados, una correcta utilización
de los recursos y tamaños de problemas que permitan determinar el rendimiento
real de los nodos evaluados. Luego de optimizar y comprobar la mejora, se vuelve
a empezar el ciclo.
Figura 2.1 Procedimiento de Análisis
CAPÍTULO 2. MATERIALES Y MÉTODOS 22
2.2 Jerarquía de Caché y Memoria Principal
La elevada latencia de los accesos a memoria fuera del chip supone una limitante
considerable en el rendimiento de los sistemas multiprocesador. Esto se debe a que
la velocidad de la CPU ha ido aumentando a un ritmo superior al que lo hacía la
memoria principal. En las gráficas 1 y 2 se observa la enorme diferencia entre la
velocidad en que la CPU ejecuta instrucciones y velocidad en que la memoria
principal (tecnología DRAM) las suministra[32], [33].
Gráfica 1. Velocidad de ejecución de instrucciones del procesador [33].
0
2000
4000
6000
8000
10000
12000
1975 1980 1985 1990 1995 2000 2005 2010 2015 2020
ejec
uci
ón
de
inst
rucc
ion
es
año
Procesador
CAPÍTULO 2. MATERIALES Y MÉTODOS 23
Gráfica 2. Velocidad en que la memoria principal suministra instrucciones del
procesador [33].
La memoria caché es una solución estructural a este problema de diferencia de
velocidades, y consiste en interponer una memoria más rápida (tecnología SRAM)
y más pequeña entre la principal y la CPU. Un mecanismo específico fundamentado
es la localidad de referencia de los programas el cual hace posible que las palabras
de memoria se encuentren en la caché cuando son referenciados por la CPU[34].
2.2.1 Localidad de referencia de los programas
Los programas manifiestan una propiedad nombrada localidad de referencia,
también conocida como el principio de localidad, que es un fenómeno según el cual
basándose en el pasado reciente de un programa se puede predecir con una
precisión razonable qué instrucciones y datos utilizará en un futuro próximo.
Los casos más importantes de localidad son la espacial, la secuencial y la temporal,
las cuales se explican a continuación:
Localidad temporal: si en un momento una posición de memoria particular es
referenciada, entonces es muy probable que la misma ubicación vuelva a ser
referenciada en un futuro cercano. Existe proximidad temporal entre las referencias
adyacentes a la misma posición de memoria. En este caso es común almacenar
0
2
4
6
8
10
12
1975 1980 1985 1990 1995 2000 2005 2010 2015 2020
sum
inis
tro
de
inst
rucc
ion
es
año
Memoria
CAPÍTULO 2. MATERIALES Y MÉTODOS 24
una copia de los datos referenciados en caché para lograr un acceso más rápido a
ellos. Está motivada por la existencia de bucles, subrutinas y acceso a la pila de
variables locales.
Localidad espacial: si una localización de memoria es referenciada en un momento
concreto, es probable que las localizaciones cercanas a ella sean también
referenciadas pronto. Existe localidad espacial entre las posiciones de memoria que
son referenciadas en momentos cercanos. En este caso es común estimar las
posiciones cercanas para que estas tengan un acceso más rápido. Está motivada
fundamentalmente por la linealidad de los programas y el acceso a las estructuras
de datos regulares.
Localidad secuencial: Las direcciones de memoria que se están utilizando suelen
ser continuas. Esto ocurre porque las instrucciones se ejecutan secuencialmente.
Para obtener beneficios de la gran frecuencia con la que ocurren los casos de
localidad espacial o temporal, muchos sistemas de memoria utilizan una jerarquía
de niveles de memoria. La utilización de estas dos localidades sucede de la
siguiente manera:
Cada vez que se accede a la memoria principal se copia la palabra accedida
en la memoria caché, más pequeña y rápida (SRAM). El tiempo utilizado para
realizar este proceso es amortiguado porque los accesos sucesivos a esa
palabra se realizarán sobre la memoria caché que es mucho más rápida.
Cada vez que se accede a una dirección de memoria se copia en la caché la
palabra accedida y las palabras próximas (bloque). El tiempo utilizado para
acceder al primer elemento de un arreglo es amortiguado cuando se accede
a los restantes elementos del mismo[35]–[37].
2.2.2 Jerarquía de memoria
Las distintas memorias presentes en un computador pueden ser representadas por
el esquema que se muestra en la figura 2.2. Estas se organizan jerárquicamente de
la siguiente forma:
Registros de la CPU
CAPÍTULO 2. MATERIALES Y MÉTODOS 25
Memoria Caché
Memoria Principal
Memoria Secundaria (discos)
Memoria flash y CD-ROMs
Figura 2.2. Jerarquía de memoria [38].
Propiedades de la jerarquía:
1. Inclusión: la información almacenada en el nivel 𝑀𝑖 debe encontrarse
también en los niveles 𝑀𝑖+1, 𝑀𝑖+2 y 𝑀𝑖+𝑛.
2. Coherencia: si un bloque de información se modifica en el nivel 𝑀𝑖, deben
actualizarse los niveles desde 𝑀𝑖+1hasta 𝑀𝑖+𝑛.
Los objetivos de utilizar la jerarquía de memoria son el uso optimizado de la
memoria, haciendo que el usuario tenga la ilusión de que dispone de una memoria
con tiempo de acceso similar al del sistema más rápido y permitir que el acceso a
un bloque de información se encuentre en los niveles más bajos de la jerarquía[38],
[39].
CAPÍTULO 2. MATERIALES Y MÉTODOS 26
2.3 LINPACK Benchmark
LINPACK es una librería de álgebra lineal escrita en 1980 en Fortran 66 y su
propósito era el de ser utilizada en supercomputadores. Basándose en esa librería,
se crearon una serie de benchmarks con el propósito de medir la potencia
computacional en Flops de un sistema. Estos benchmarks se conocen como
LINPACK Benchmarks.
Los LINPACK Benchmarks generan y calculan la solución de un sistema de
ecuaciones denso del tipo 𝐴 ∗ 𝑥 = 𝐵 y de tamaño 𝑁𝑥𝑁, como se muestra en la
siguente expresión matemática que multiplica una matriz A por una matriz x:
[
𝑎1,1 𝑎1,2 𝑎1,𝑎
𝑎2,1 𝑎2.2 𝑎2,𝑛
𝑎𝑛,1 𝑎𝑛,2 𝑎𝑛,𝑛
] ∗ [
𝑥1
𝑥2
𝑥𝑛
] = [
𝑏1
𝑏2
𝑏𝑛
]
El primero fue LINPACK 100, que como indica el nombre, ofrecía medidas de
rendimiento resolviendo sistemas de tamaño N = 100. Las siguientes versiones,
LINPACK 1000 y HPLinpack, se crean para poder evaluar supercomputadores con
más potencia y nuevas arquitecturas (memoria distribuida)[40].
2.3.1 HPL
HPL es la implementación de los LINPACK Benchmark más relevante. Es una
versión escalable y paralela que utiliza aritmética de 64 bits de doble precisión para
resolver un sistema de ecuaciones lineales de orden N y así probar el poder de
cálculo de un sistema. Generalmente se ejecuta en las computadoras de memoria
distribuida para determinar el rendimiento de punto flotante de doble precisión del
sistema. El programa posee un fichero de entrada llamado HPL.dat que puede ser
ajustado para mejorar el rendimiento de acuerdo al sistema en que el benchmark
es ejecutado y de la topología de la red utilizada para interconectar los nodos. Está
diseñada para correr en cientos de nodos por lo que su empleo en pocos nodos trae
consigo cierto impacto en la ineficiencia producto a las cabeceras de control que
genera MPI. Una ejecución de HPL optimizada suele encontrarse en el margen de
70 a 80 por ciento del pico teórico (Peak Performance - PP) del rendimiento del
procesador.
CAPÍTULO 2. MATERIALES Y MÉTODOS 27
Requisitos de Implementación
La instalación HPL requiere un sistema de memoria distribuida con una
implementación de la librería BLAS compilada sobre la arquitectura y una
implementación del estándar de MPI para la comunicación entre nodos.
El proceso de instalación del software se puede realizar manualmente o de manera
automática utilizando el paquete de software Easybuild. Ambas formas se describen
a continuación[41].
Instalación manual del software
Para el proceso de instalación manual se deben seguir los siguientes pasos:
1- Descargar el archivo que se encuentra en la siguiente dirección:
http://www.netlib.org/benchmark/hpl/hpl-2.2.tar.gz y ejecutar la siguiente
línea de comando para descomprimir el archivo descargado tar -xvf hpl-
2.1.tar.
2- Luego crear un archivo Make que contiene los compiladores, las bibliotecas
y las rutas para usar en el sistema.
3- Escribir en la línea de comandos make arch=nombre_del_clúster, que creará
en el directorio bin/nombre_del_clúster/ el binario xhpl.
4- Utilizar mpirun -np 4 xhpl para correr las pruebas.
Este proceso se encuentra descrito en el sitio web:
http://www.netlib.org/benchmark/hpl/software.html.
Instalación mediante el paquete de software EasyBuild
EasyBuild es una herramienta para la construcción e instalación de software, cuyo
objetivo es disminuir la carga de trabajo en la instalación, configuración y
administración de software científico. Brinda soporte a un gran número de paquetes
de softwares dentro de los que se encuentra HPL.
Para instalar el paquete HPL se ejecuta el siguiente comando
$ eb HPL-2.2-foss-2017a.eb –robot
El argumento --robot habilita la resolución automática de las dependencias.
CAPÍTULO 2. MATERIALES Y MÉTODOS 28
Para cargar el software y comenzar a usarlo solamente es necesario cargar el
módulo y ejecutar el comando de inicialización del software.
$ module load HPL
Una vez cargado los módulos se utiliza el comando mpirun -np número_procesos
xhpl para realizar las pruebas.
2.3.2 Configuración de HPL.dat
HPL utiliza un archivo de configuración con el nombre HPL.dat donde se escriben
algunos parámetros que la herramienta solicita para poder iniciar las pruebas en los
nodos. Tiene un total de 31 líneas donde las más importantes son las que equivalen
a los números 6,8,10 y 11.
Complejidad del Problema
El espacio ocupado durante la ejecución depende de la matriz A, siendo esta de
tamaño 𝑛 ∗ 𝑛. Los datos que componen la matriz se obtienen a partir de un
generador pseudo-aleatorio de números decimales.
Tamaño del Problema (N)
La línea 6 especifica los tamaños de problema que se desean ejecutar. Para calcular
el máximo tamaño de problema en memoria de debe utilizar la siguiente expresión:
𝑁 = √𝑅𝐴𝑀𝑠𝑖𝑠𝑡𝑒𝑚𝑎
8
Una manera más sencilla es utilizar el sitio web: http://hpl-
calculator.sourceforge.net/hpl-calculations.php y llenar los campos requeridos.
Tamaño del Bloque (NB)
La línea 8 especifica los tamaños de bloque (NB) que es utilizado por HPL para la
distribución de datos, así como para la granularidad computacional. Desde el punto
de vista de distribución de datos cuando el NB es más pequeño mejora el equilibrio
de carga. Desde un punto de vista de computación, un valor demasiado pequeño
de NB puede limitar el rendimiento computacional porque disminuye la reutilización
CAPÍTULO 2. MATERIALES Y MÉTODOS 29
de datos en el nivel más alto de la jerarquía de memoria y la cantidad de mensajes
también aumentará. Los tamaños de bloques aconsejados están en el intervalo [32
a 256]. Los mejores valores dependen de la relación entre el rendimiento
computacional y la comunicación del sistema. Este campo depende del tamaño de
la caché del procesador.
Interconexión Física (PxQ)
Las líneas 10 y 11 dependen de la red de interconexión física. Son el número de
filas y columnas de proceso por cuadrícula. La multiplicación de los parámetros de
entrada P y Q determinar el número de procesos utilizados por la herramienta. Se
deben escoger valor donde Q sea ligeramente mayor que P[41].
2.4 Conexión y transferencia de archivos al clúster
La conexión al clúster se puede realizar utilizando los protocolos SSH, HTTP y FTP
en los que se garantiza el cifrado de los datos adicionando la capa SSL/TLS y desde
Windows o Linux, utilizando los pasos que se describen a continuación.
Al conectarse desde una máquina que utilice Linux se abrirá una consola de
comandos y se ejecutará la siguiente línea de comando:
$ ssh <nombre_de_usuario>@login.uclv.hpc.cu -p 2222
Una vez introducida la contraseña que pertenece al usuario se establecerá una
sesión de trabajo.
Al conectarse desde una máquina con sistema operativo Windows puede utilizarse
la herramienta Putty disponible en el sitio web:
http://www.chiark.greenend.org.uk/~sgtatham/putty/ y luego se debe llenar los
campos como se muestra en la figura 2.3. Se utiliza el nombre de dominio
login.uclv.hpc.cu y el puerto 2222, luego se presiona open para abrir la consola y
una vez introducidos los campos de usuario y la contraseña se estará utilizando la
partición asignada en clúster.
CAPÍTULO 2. MATERIALES Y MÉTODOS 30
Figura 2.3 Uso de la herramienta Putty para conectarse al clúster.
La transferencia de archivos siempre debe ser realizada desde la computadora que
se conecta al clúster, pues las comunicaciones desde el servidor hacia
computadoras remotas están bloqueadas por razones de seguridad. Para acceder
vía FTP se debe utilizar Filezilla que se encuentra disponible en el sitio web:
https://filezilla-project.org/download.php y llenar los campos como se muestra en la
figura 2.4. Primero se introduce el nombre de dominio login.uclv.hpc.cu, seguido del
usuario y la contraseña y al presionar la tecla enter se podrá enviar al clúster los
archivos que se necesiten.
CAPÍTULO 2. MATERIALES Y MÉTODOS 31
Figura 2.4 Uso de la herramienta Filezilla para transferencia de archivos con el
clúster.
2.5 Corridas de HPL y de NAMD
El clúster de la UCLV actualmente brinda servicio a varios investigadores de la
institución por lo que se utiliza SLURM que es un gestor de recursos que es lo que
necesitan los usuarios para organizar la administración y distribución de los mismos.
Además, este planificador de tareas es utilizado por el sistema para mantener en
espera los trabajos que requieran el uso de nodos ocupados. La herramienta incluye
funcionalidades para monitorear los recursos disponibles en el HPC y de esta forma
asignarlos según los requerimientos de la corrida del trabajo lanzado.
Parámetros necesarios para la corrida de pruebas
Para correr las pruebas HPL en el clúster es necesario crear un script con la
extensión sh que es utilizado por SLURM para asignar los recursos requeridos por
CAPÍTULO 2. MATERIALES Y MÉTODOS 32
la herramienta cuando estos se encuentren disponibles. Este archivo debe
especificar los parámetros siguientes:
#SBATCH --job-name: para especificar el nombre del trabajo a ejecutar.
#SBATCH --partition: para especificar la partición que tenemos asignada
para correr los trabajo.
#SBATCH --ntasks: para especificar el número de tareas, procesos o hilos
que se utilizarán en la prueba.
#SBATCH --output: para especificar el archivo que mostrará los resultados
de la prueba.
#SBATCH --error: para especificar el nombre del archivo que contiene los
errores de la prueba.
#SBATCH --mail-user: para especificar el correo al que se notificará cuando
comience y termine la prueba.
Además, debe contener los siguientes comandos para ejecutar las pruebas con la
herramienta HPL:
$ module load HPL/2.2-foss-2017a para establecer las variables de entornos
apropiadas y poder ejecutar HPL.
$ cd $SLURM_SUBMIT_DIR que especifica el directorio actual que es el que debe
contener el archivo de configuración HPL.dat.
$ mpirun -np número_de_procesos xhpl que indica cuántas instancias del programa
se ejecutarán pasándole como parámetros la cantidad de procesos y el binario que
utiliza cada uno.
El script descrito anteriormente se ejecuta con la siguiente instrucción en la línea de
comando: sbatch nombre_del_script.sh.
Para ejecutar NAMD se deben cargar las variables de entorno mediante el módulo
correspondiente con la instrucción: module load NAMD/2.12-foss-2017a-mpi. A
continuación, se utiliza la instrucción mpirun y se especifica el número de
procesadores, el nombre del ejecutable y el fichero de entrada: mpirun -np
número_de_procesadores apoad1.namd.
CAPÍTULO 2. MATERIALES Y MÉTODOS 33
2.6 Análisis de los escenarios
El diseño de escenarios se realiza para planificar puntos críticos del clúster que se
desean evaluar como su escalabilidad, eficiencia y rendimiento frente aplicaciones
que demanden alto coste computacional. Para estos se plantean tres escenarios
que son descritos a continuación.
Escenario 1
En el primer escenario se realizan tres grupos de pruebas para comprobar si se
introducen mejoras al utilizar más núcleos en la resolución de un mismo tamaño de
problema. Para esto la herramienta HPL se configura con los valores que se
muestran en las tablas 2.1, 2.2 y 2.3.
Parámetros Prueba 1 Prueba 2
N 8000 8000
NB 220 220
P 1 1
Q 1 2
Memoria del sistema 16 GB 16 GB
Memoria utilizada 0.5 GB 0.5 GB
# de núcleos 1 2
# de nodos físicos 1 1
Tabla 2.1. Parámetros de entrada en el primer grupo de pruebas escenario 1.
CAPÍTULO 2. MATERIALES Y MÉTODOS 34
Parámetros Prueba 3 Prueba 4 Prueba 5
N 10000 10000 10000
NB 220 220 220
P 1 1 2
Q 2 4 4
Memoria del sistema 16 GB 16 GB 16 GB
Memoria utilizada 0.8 GB 0.8 GB 0.8 GB
# de núcleos 2 4 8
# de nodos físicos 1 1 1
Tabla 2.2. Parámetros de entrada en el segundo grupo de pruebas escenario 1.
Parámetros Prueba 6 Prueba 7 Prueba 8
N 40720 40720 40720
NB 220 220 220
P 1 1 2
Q 2 4 4
Memoria del sistema 16 GB 16 GB 16 GB
Memoria utilizada 13.26 GB 13.26 GB 13.26 GB
# de núcleos 2 4 8
# de nodos físicos 1 1 1
Tabla 2.3 Parámetros de entrada en el tercer grupo de pruebas escenario 1.
CAPÍTULO 2. MATERIALES Y MÉTODOS 35
Con el fin de medir el tiempo en segundos que demora la aplicación para ejecutar
las pruebas se definen en estas tablas parámetros tales como: tamaño del
problema, tamaño de bloque, número de filas y columnas de proceso por cuadrícula,
memoria utilizada por el sistema y el número de núcleos. Estos parámetros
permitirán observar las mejoras en tiempo de ejecución contra número de núcleos
empleados para ejecutar la aplicación.
Escenario 2
En el segundo escenario se realizan también dos grupos de pruebas. El primero,
permite determinar el rendimiento en GFlops con la utilización de 1, 3 y 7 nodos
respectivamente al configurar el máximo tamaño de problema que se puede calcular
para cada caso. El segundo grupo establece una comparación del rendimiento
cuando se utilizan 7 nodos con 16 Gb y 64 Gb de memoria RAM respectivamente.
Para esto la herramienta HPL es configurada con los parámetros descritos en las
tablas 2.4 y 2.5.
CAPÍTULO 2. MATERIALES Y MÉTODOS 36
Parámetros Prueba 6 Prueba 7 Prueba 8 Prueba 9
N 40720 40720 70656 108240
NB 220 220 220 220
P 1 2 4 7
Q 2 4 6 8
Memoria del sistema 16 GB 16 GB 48 GB 112 GB
Memoria utilizada 13.26 GB 13.26 GB 39.9 GB 93.7 GB
Frecuecia del procesador 2.26 GHz 2.26 GHz 2.26 GHz 2.26 GHz
# de núcleos 2 8 24 56
# de nodos físicos 1 1 3 7
Tabla 2.4. Parámetros de entrada en el primer grupo de pruebas escenario 2.
CAPÍTULO 2. MATERIALES Y MÉTODOS 37
Parámetros Prueba 10 Prueba 11
N 108240 216480
NB 220 220
P 7 7
Q 8 8
Memoria del sistema 112 GB 448 GB
Memoria utilizada 93.7 GB 374.9 GB
Frecuecia del procesador 2.26 GHz 2.26 GHz
# de núcleos 56 56
# de nodos físicos 7 7
Tabla 2.5. Parámetros de entrada en el segundo grupo de pruebas escenario 2.
Los parámetros definidos en estas tablas son iguales a los definidos en el primer
escenario de pruebas con la diferencia, de que en este caso se deben tomar en
consideración la frecuencia del procesador y la memoria total del sistema, para
poder establecer una comparación entre el rendimiento real y el teórico que se debe
alcanzar.
Escenario 3
En el tercer escenario se ejecutan un grupo de pruebas en la aplicación NAMD para
medir su comportamiento con respecto a su escalabilidad, aceleración y eficiencia
paralela. Para esto, las pruebas se realizan variando el número de nodos que se
utilizan para ejecutar la aplicación como se aprecia en la tabla 2.6.
CAPÍTULO 2. MATERIALES Y MÉTODOS 38
# de las pruebas
realizadas con
NAMD
# de núcleos que
participan
# de nodos físicos
que participan
Memoria del
sistema
1 2 1 16 GB
2 4 1 16 GB
3 8 1 16 GB
4 16 2 32 GB
5 24 3 48 GB
6 56 7 112 GB
Tabla 2.6. Parámetros de entrada de las pruebas en el tercer escenario.
Con el uso de esta tabla se podrá medir la escalabilidad de la aplicación con el
aumento del número de nodos. Esto se evidenciará en un aumento de la velocidad
de resolución del problema de dinámica molecular y una disminución de la eficiencia
paralela.
2.7 Conclusiones parciales
Dentro de las jeraquías de memoria caché, HPL utiliza el tamaño de L1 para definir
el tamaño de bloque y de esta manera explotar eficientemente las localidades
espaciales y temporales. Además, para obtener el máximo rendimiento del sistema
se debe elegir un tamaño de problema que represente el uso del 80 o 90% de la
memoria total del sistema.
Los dos primeros están destinados a medir el rendimiento real del clúster con
respecto al teórico frente a aplicaciones que demanden grandes capacidades de
cómputo. El tercer escenario comprueba la escalabilidad, speed-up y eficiencia
paralela de la aplicación NAMD con el fin de conocer el comportamiento de
aplicaciones altamente paralelizables en el clúster de la UCLV.
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 39
CAPÍTULO 3. Análisis de los resultados
En este capítulo se analizan los diferentes escenarios descritos en el capítulo 2 para
las mediciones objetivas de desempeño y las pruebas de escalabilidad con la
herramienta HPL y la aplicación NAMD, respectivamente. Además, se establece
una comparación entre los resultados obtenidos en términos de aceleración o
speed-up y la eficiencia paralela.
3.1 Resultados de las pruebas en el primer escenario
Al ejecutar las pruebas definidas en el escenario 1 se pretende demostrar que las
aplicaciones paralelizables disminuyen su tiempo de ejecución según aumenta el
número de núcleos utilizados. Los resultados de dichas pruebas se muestran en las
siguientes figuras:
Figura 3.1. Pruebas de tiempo de ejecución con la herramienta HPL.
44
28
0 10 20 30 40 50
1
2
Tiempo en segundos
# d
e n
úcl
eo
s
HPL
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 40
Figura 3.2. Contenido del fichero de salida de las pruebas de HPL.
En la figura 3.1 se aprecia una disminución del tiempo de ejecución de la tarea
debido al uso de dos núcleos en lugar de uno. El archivo de salida de la prueba se
ilustra en la figura 3.2 donde además se evidencia una mejora de rendimiento
debido al uso de múltiples hilos de procesamiento.
Si se cuenta con una tarea de poca complejidad operacional, el hecho de aumentar
la cantidad de núcleos para su solución influirá negativamente en el tiempo que
demora la solución del problema, debido a que existirá un sobredimensionamiento
de los recursos. Esto se muestra en las figuras 3.3 y 3.4.
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 41
Figura 3.3 Pruebas de tiempo de ejecución con la herramienta HPL.
Figura 3.4 Contenido del fichero de salida de las pruebas de HPL.
29.59
30.91
39.54
0 5 10 15 20 25 30 35 40 45
2
4
8
tiempo en segundos
# d
e n
úcl
eo
s
HPL
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 42
Como se observa, al desglosar un problema pequeño en partes, el comportamiento
no será el deseado debido al aumento del número de mensajes que viajan a través
del bus de direcciones del procesador para sincronizar los resultados, lo que
provoca un incremento del tiempo al tener que sincronizar las respuestas de cada
núcleo.
Sin embargo, un problema grande y paralelizable, hace un mejor uso de los recursos
disponibles disminuyendo el tiempo de ejecución de la tarea como se muestra en la
figuras 3.5 y 3.6.
Figura 3.5 Pruebas de tiempo de ejecución con la herramienta HPL.
1397.24
1364.61
1209.55
1100 1150 1200 1250 1300 1350 1400 1450
2
4
8
tiempo en segundos
# d
e n
úcl
eo
s
HPL
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 43
Figura 3.6 Contenido del fichero de salida de las pruebas de HPL.
En la imagen se muestra la mejora del tiempo de ejecución; esta no es significativa
debido a que la herramienta utilizada está programada para medir el rendimiento
del sistema, cuestión que se abordará en el próximo escenario.
3.2 Resultados de las pruebas en el segundo escenario
En este escenario se realizan dos grupos de pruebas. En la primera se observa el
rendimiento real que pueden alcanzar 1,3 y 7 nodos donde cada uno cuenta con 16
Gb de memoria RAM como se muestra en la figuras 3.7 y 3.8. Para esto las pruebas
se configuraron utilizando el mayor tamaño de problema que puede resolver el
sistema.
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 44
Figura 3.7 Pruebas de rendimiento en GFlops con la herramienta HPL.
15.1
31.75
72.15
131.9
18.08
72.32
216.96
506.24
0 100 200 300 400 500 600
2
8
24
56
Rendimiento en Gflops
# d
e n
úcl
eo
s
Prueba de HPL
Pico Teórico
Rendimiento en Gflops
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 45
Figura 3.8 Contenido del fichero de salida de las pruebas de HPL.
En un segundo grupo de pruebas se ilustra la mejora alcanzada por el sistema
cuando se utiliza mayor capacidad de memoria RAM fijando el número de nodos en
7 como se muestra en las figuras 3.9 y 3.10. La comparación se estableció entre 7
nodos de 16 y 64 Gb de memoria RAM respectivamente.
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 46
Figura 3.9 Pruebas de rendimiento en GFlops con la herramienta HPL.
Figura 3.10 Contenido del fichero de salida de las pruebas de HPL.
3.3 Resultado de las pruebas del tercer escenario
Los resultados alcanzados por las pruebas del escenario 3 evidencian que una
aplicación que escale correctamente disminuye su tiempo de ejecución
proporcionalmente al aumento del número de núcleos utilizados. En las figuras 3.11
y 3.12 se muestra lo descrito anteriormente. En el Anexo I se pueden encontrar
todos los ficheros de salida resultante de las pruebas en este escenario.
131.9
213.2
506.24
506.24
0 100 200 300 400 500 600
112GB
448GB
Rendimiento e Gflops
Me
mo
ria
de
l sis
tem
a
Pico Teórico
Rendimiento en Gflops
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 47
Figura 3.11 Pruebas de escalabilidad con la aplicación NAMD.
Figura 3.12 Contenido del fichero de salida de las pruebas de NAMD en 1 núcleo.
669
369
200
115
65
47
26
0 100 200 300 400 500 600 700 800
1
2
4
8
16
24
56
tiempo en segundos
# d
e n
úcl
eo
s
NAMD
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 48
En términos de speed-up se observa que al aumentar el número de procesadores
aumenta la rapidez de resolución del problema. En la Figura 3.7 se muestra la
aceleración alcanzada al utilizar de 2 a 56 núcleos desde 1.81 hasta 25.73.
Figura 3.13 Análisis de speed-up en la aplicación NAMD.
En la siguiente figura se muestra cómo la eficiencia paralela disminuye de 0.9
cuando se utilizan 2 núcleos de un mismo nodo a 0.46 cuando se emplean 56
núcleos de 7 nodos. Esta disminución se debe a que se genera más información
para el sincronismo de las tareas a medida que aumenta el número de nodos, es
decir, incrementa el número de mensajes para la comunicación entre procesos lo
que genera información de control adicional. Toda esta información debe ser
encapsulada para ser enviada a través de la red que interconecta los nodos, lo cual
genera un aumento del tiempo de ejecución.
0
5
10
15
20
25
30
2 4 8 16 24 56
spe
ed
-up
# DE NÚCLEOS
speed-up
CAPÍTULO 3. RESULTADOS Y DISCUSIÓN 49
Figura 3.13 Análisis de la eficiencia paralela en la aplicación NAMD.
3.4 Conclusiones parciales
A partir de los escenarios analizados se puede concluir que el aumento del número
de nodos está determinado por los recursos que requiera la aplicación. Además, el
rendimiento medido por la herramienta HPL mejora cuando se utiliza la mayor
cantidad de memoria disponible en el sistema. Esto se debe a que un aumento del
tamaño del problema hace más eficiente el uso de los recursos disponibles.
La utilización de una mayor cantidad de nodos en una aplicación escalable mejora
el tiempo de resolución del problema y disminuye la eficiencia paralela debido a los
mensajes adicionales generados para el sincronismo.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
2 4 8 16 24 56
efic
ien
cia
par
alel
a
# de procesadores
eficiencia paralela
CONCLUSIONES Y RECOMENDACIONES 50
CONCLUSIONES Y RECOMENDACIONES
Conclusiones
A partir del cumplimiento de la tarea técnica y los objetivos específicos se concluye
que:
1. Los parámetros y las métricas de desempeño que mejor caracterizan el
rendimiento del clúster durante la ejecución de las aplicaciones son el pico
teórico que permite establecer una comparación respecto al rendimiento real
de los procesadores, el speed-up que muestra la mejora en velocidad con
respecto a una ejecución secuencial, y la eficiencia paralela referida al grado
de paralelismo.
2. HPL es una herramienta de código abierto, que permite determinar la
eficiencia paralela a nivel de clúster y su rendimiento real respecto al teórico
expresado en GFLOPS; el rendimiento medido por la misma mejora cuando
se utiliza la mayor cantidad de memoria disponible en el sistema.
3. NAMD es un software para dinámica molecular en paralelo, diseñado para
simulaciones de alto desempeño de sistemas biomoleculares que demuestra
que una aplicación escalable emplea los recursos del clúster de forma
eficiente.
4. Los escenarios muestran que la cantidad de nodos a utilizar está
determinado por los recursos que requiera una aplicación y que al
incrementar su número en una aplicación escalable, mejora el tiempo de
resolución del problema y disminuye su eficiencia paralela debido a los
mensajes adicionales generados para el sincronismo.
CONCLUSIONES Y RECOMENDACIONES 51
Recomendaciones
Se proponen como recomendaciones:
Realizar pruebas que midan el uso de la red en la ejecución de aplicaciones
que requieran más de un nodo.
Comprobar el rendimiento de los nodos GPU respecto al pico teórico.
REFERENCIA BIBLIOGRÁFICA
52
REFERENCIAS BIBLIOGRÁFICAS
[1] «What is ENIAC (Electronic Numerical Integrator and Calculator)?» [En línea]. Disponible en: https://www.computerhope.com/jargon/e/eniac.htm. [Accedido: 28-feb-2018].
[2] Kevin Santiago, «El proyecto eniac fin 1», 16:37:48 UTC.
[3] «High Performance Computing». [En línea]. Disponible en: https://www.hpc.cam.ac.uk/. [Accedido: 3-mar-2018].
[4] «What is High Availability?», DigitalOcean. [En línea]. Disponible en: https://www.digitalocean.com/community/tutorials/what-is-high-availability. [Accedido: 3-mar-2018].
[5] «High-Throughput». [En línea]. Disponible en: http://www.mdpi.com/journal/high-throughput. [Accedido: 10-mar-2018].
[6] «What are tools available for benchmarking an HPC cluster? - Quora». [En línea]. Disponible en: https://www.quora.com/What-are-tools-available-for-benchmarking-an-HPC-cluster. [Accedido: 18-mar-2018].
[7] «High-Performance Computing (HPC) - European Commission». [En línea]. Disponible en: https://ec.europa.eu/programmes/horizon2020/en/h2020-section/high-performance-computing-hpc. [Accedido: 18-mar-2018].
[8] A. E. Helal, W. Feng, C. Jung, y Y. Y. Hanafy, «AutoMatch: An automated framework for relative performance estimation and workload distribution on heterogeneous HPC systems», en Workload Characterization (IISWC), 2017 IEEE International Symposium on, 2017, pp. 32-42.
[9] P. V. Sukharev, N. P. Vasilyev, M. M. Rovnyagin, y M. A. Durnov, «Benchmarking of high performance computing clusters with heterogeneous CPU/GPU architecture», en Young Researchers in Electrical and Electronic Engineering (EIConRus), 2017 IEEE Conference of Russian, 2017, pp. 574-577.
[10] S. Ristov, R. Prodan, M. Gusev, y K. Skala, «Superlinear speedup in HPC systems: Why and when?», en 2016 Federated Conference on Computer Science and Information Systems (FedCSIS), 2016, pp. 889-898.
[11] «Speedup Ratio and Parallel Efficiency : TechWeb : Boston University». [En línea]. Disponible en: https://www.bu.edu/tech/support/research/training-consulting/online-tutorials/matlab-pct/scalability/. [Accedido: 3-abr-2018].
REFERENCIA BIBLIOGRÁFICA
53
[12] «Message Passing Interface (MPI) | HPC | USC». [En línea]. Disponible en: https://hpcc.usc.edu/support/documentation/message-passing-interface/. [Accedido: 5-abr-2018].
[13] «MPI Hello World · MPI Tutorial». [En línea]. Disponible en: http://mpitutorial.com/tutorials/mpi-hello-world/. [Accedido: 10-abr-2018].
[14] R. Miguel Crespo, «Análisis del benchmark PARSEC en arquitecturas multicore», 2015.
[15] «What is ICOMP (Intel Comparative Microprocessor Performance)?» [En línea]. Disponible en: https://www.computerhope.com/jargon/i/icomp.htm. [Accedido: 12-abr-2018].
[16] «NAS Parallel Benchmarks». [En línea]. Disponible en: https://www.nas.nasa.gov/publications/npb.html. [Accedido: 15-abr-2018].
[17] C. Sakalis, The Splash-3 benchmark suite. 2018.
[18] M. S. Müller et al., «SPEC MPI2007—an application benchmark suite for parallel systems using MPI», Concurrency and Computation: Practice and Experience, vol. 22, n.o 2, pp. 191-205.
[19] C. Ortega Carrasco, «Diseño y evaluación de un clúster HPC: software de sistema», Universitat Politècnica de Catalunya, 2014.
[20] P. Luszczek et al., «Introduction to the HPC challenge benchmark suite», Ernest Orlando Lawrence Berkeley NationalLaboratory, Berkeley, CA (US), 2005.
[21] «MEMORY BANDWIDTH: STREAM BENCHMARK PERFORMANCE RESULTS». [En línea]. Disponible en: http://www.cs.virginia.edu/stream/. [Accedido: 28-abr-2018].
[22] «PARKBENCH MATRIX KERNEL BENCHMARKS». [En línea]. Disponible en: http://www.netlib.org/parkbench/html/matrix-kernels.html. [Accedido: 29-abr-2018].
[23] «RandomAccess Rules». [En línea]. Disponible en: http://icl.cs.utk.edu/projectsfiles/hpcc/RandomAccess/. [Accedido: 2-may-2018].
[24] «FFTE: A Fast Fourier Transform Package». [En línea]. Disponible en: http://www.ffte.jp/. [Accedido: 2-may-2018].
[25] «HPL - A Portable Implementation of the High-Performance Linpack Benchmark for Distributed-Memory Computers». [En línea]. Disponible en: http://www.netlib.org/benchmark/hpl/. [Accedido: 6-may-2018].
[26] «HPC Challenge». [En línea]. Disponible en: http://icl.cs.utk.edu/hpcc/. [Accedido: 7-may-2018].
[27] H. Shan, K. Antypas, y J. Shalf, «Characterizing and predicting the I/O performance of HPC applications using a parameterized synthetic benchmark», en Proceedings of the 2008 ACM/IEEE conference on Supercomputing, 2008, p. 42.
REFERENCIA BIBLIOGRÁFICA
54
[28] P. Worley et al., «Performance analysis of GYRO: a tool evaluation», en Journal of Physics: Conference Series, 2005, vol. 16, p. 551.
[29] J. C. Phillips et al., «Scalable molecular dynamics with NAMD», Journal of computational chemistry, vol. 26, n.o 16, pp. 1781-1802, 2005.
[30] L. Youseff, R. Wolski, B. Gorda, y C. Krintz, «Evaluating the performance impact of Xen on MPI and process execution for HPC systems», Lawrence Livermore National Laboratory (LLNL), Livermore, CA, 2006.
[31] A. B. Yoo, M. A. Jette, y M. Grondona, «SLURM: Simple Linux Utility for Resource Management», en Job Scheduling Strategies for Parallel Processing, 2003, pp. 44-60.
[32] L. M. Censier y P. Feautrier, «A New Solution to Coherence Problems in Multicache Systems», IEEE Transactions on Computers, vol. C-27, n.o 12, pp. 1112-1118, dic. 1978.
[33] P. Conway, N. Kalyanasundharam, G. Donley, K. Lepak, y B. Hughes, «Cache Hierarchy and Memory Subsystem of the AMD Opteron Processor», IEEE Micro, vol. 30, n.o 2, pp. 16-29, mar. 2010.
[34] A. W. Wilson Jr., «Hierarchical Cache/Bus Architecture for Shared Memory Multiprocessors», en Proceedings of the 14th Annual International Symposium on Computer Architecture, New York, NY, USA, 1987, pp. 244–252.
[35] C. R. D. ÁLVAREZ, P. Y. E. QUE, y P. E. EL EVENTO, «PONENCIA: PROCESADORES MULTINÚCLEO: REALIDADES Y FALACIAS.»
[36] O. Camacho Nieto, L. A. Villa Vargas, J. L. Díaz de León Santiago, y C. Yáñez Márquez, «Diseño de Sistemas de Memoria Cache de Alto Rendimiento aplicando Algoritmos de Acceso Seudo-Especulativo», Computación y Sistemas, vol. 7, n.o 2, pp. 130-147, 2003.
[37] F. Y. Leibovich, F. Chichizola, L. C. De Giusti, M. Naiouf, y F. Tirado Fernández, «Programación híbrida en clusters de multicore», en XVIII Congreso Argentino de Ciencias de la Computación, 2012.
[38] G. Ortega et al., «Procesadores de bajo coste y su aplicación en la docencia de Ingeniería de Computadores», en Actas de las XXII Jenui, 2016, pp. 343-349.
[39] M. Barrionuevo, M. Lopresti, N. C. Miranda, y M. F. Piccoli, «Un enfoque para la detección de anomalías en el tráfico de red usando imágenes y técnicas de Computación de Alto Desempeño», en XXII Congreso Argentino de Ciencias de la Computación (CACIC 2016), 2016.
[40] «The Linpack Benchmark | TOP500 Supercomputer Sites». [En línea]. Disponible en: https://www.top500.org/project/linpack/. [Accedido: 17-may-2018].
[41] «HPL Frequently Asked Questions». [En línea]. Disponible en: http://www.netlib.org/benchmark/hpl/faqs.html. [Accedido: 17-may-2018].
REFERENCIA BIBLIOGRÁFICA
55
Glosario
Big Data: Grandes volúmenes de datos, tanto estructurados como no
estructurados.
Bucle: Ciclo de repeticiones.
Caché: Componente de hardware o software que almacena datos para que las
solicitudes futuras de esos datos se puedan atender con mayor rapidez.
Clúster: Conjuntos o conglomerados de computadoras construidos mediante la
utilización de hardware comunes y que se comportan como si fuesen una única
computadora.
CPU: Central processing unit.
DRAM: Dynamic Random Access Memory.
FLOP: Floating point operations per second.
GFLOP: GigaFlops.
HA: High Availability.
HPC: High Performance Computing.
HT: High Throughput.
Latencia: Suma de retardos temporales dentro de una red.
MPICH: Biblioteca de desarrollo de libre disposición implementación portable de
MPI.
RAM: Random Access Memory.
SRAM: Static Random Access Memory.
TFLOP: TeraFlops.
ANEXOS 56
ANEXOS
Anexo I Ficheros de salidas en las pruebas a la aplicación NAMD
Anexo 1.1 Fichero de salida de prueba NAMD utilizando 2 núcleos.
ANEXOS 57
Anexo 1.2 Fichero de salida de prueba NAMD utilizando 4 núcleos.
ANEXOS 58
Anexo 1.3 Fichero de salida de prueba NAMD utilizando 8 núcleos.
ANEXOS 59
Anexo 1.4 Fichero de salida de prueba NAMD utilizando 16 núcleos.
ANEXOS 60
Anexo 1.5 Fichero de salida de prueba NAMD utilizando 24 núcleos.
ANEXOS 61
Anexo 1.6 Fichero de salida de prueba NAMD utilizando 56 núcleos.
