Dise˜no y evaluación de un clúster HPC: Aplicaciones

Diseño y evaluación de un clúster HPC: Aplicaciones
Autor:
Constantino Gómez Crespo
Grado en Ingenierı́a Informática
Especialidad en Ingenierı́a de Computadores
26 de Junio de 2014
Director:
Agustı́n Fernández Jiménez, Arquitectura de computadores
Facultad de Informática de Barcelona
Universidad Politécnica de Cataluña (UPC) - BarcelonaTech
2
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
3
Resumen
En este trabajo se presenta un análisis de las aplicaciones utilizadas de manera habitual en el área de la informática conocida como High Performance Computing
(HPC).
También se hace un inciso en técnicas de optimización para tales aplicaciones mediante el uso de herramientas de profiling, librerı́as y configuración de parámetros.
Por último, se realiza la evaluación de rendimiento de un clúster HPC basado en
procesadores móviles de bajo consumo.
El trabajo tiene como objetivo aprender a construir y optimizar un clúster HPC,
acorde con el conjunto de aplicaciones a ejecutar y con la mirada puesta en la eficiencia energética (Energy-to-solution).
A destacar, que para la parte final del trabajo se ha montado un clúster con procesadores de bajo consumo, en concreto, System-on-Chip con arquitectura ARMv7
para móviles de Samsung, Exynos 5420.
Resum
En aquest treball es presenta un anàlisi de les aplicacions utilitzades de manera habitual a l’àrea de l’informàtica coneguda com HPC.
També es fa un incı́s en les técniques d’optimització per aquestes aplicacions mitjançant l’ús d’eines de profiling, llibrerı́es i configuració de paràmetres.
Per acabar, es realitza la evaluació de rendiment d’un clúster HPC basat en procesadors mòbils de baix consum.
Aquest treball té com objectiu aprendre a construir i optimitzar un clúster HPC,
concorde amb el conjunt d’aplicacions a executar y amb la mirada posada en la
eficiencia energética (Energy-to-solution).
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
4
A destacar, que per la part final del treball s’ha muntat un clúster amb processadors de baix consum, en concret, System-on-Chip amb arquitectura ARMv7 per
mòbils de Samsung, Exynos 5420.
Abstract
This project presents an analysis of the applications commonly used in the area of
the computer sciences known as HPC.
Also, an introduction in optimization techniques is made for those applications with
the use of profiling tools, libraries and parameter configuration.
On the last part, a performance evaluation of the HPC cluster based in mobile
processors is made.
This project has as objective to learn to build and optimize a cluster HPC, according to the set of applications to execute while keeping the energy efficiency in
consideration (Energy-to-Solution).
As a highlight, for the last part of the project a cluster with low-power mobile processors has been built, in particular, with Samsung’s System-on-Chip with ARMv7
architecture for cellphones Exynos 5420.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
5
Índice general
Resumen
4
Prefacio
17
1. Introducción
19
1.1. Orı́genes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.2. Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.3. Student Cluster Challenge . . . . . . . . . . . . . . . . . . . . . . . .
20
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.4.1. Objetivos Generales . . . . . . . . . . . . . . . . . . . . . . .
21
1.4.2. Objetivos individuales . . . . . . . . . . . . . . . . . . . . . .
22
2. Planificación y presupuesto
25
2.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.1.1. Estudio Teórico . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.1.2. Aplicación Práctica . . . . . . . . . . . . . . . . . . . . . . . .
25
2.2. Estimación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.2.1. Listado de Tareas
. . . . . . . . . . . . . . . . . . . . . . . .
28
2.2.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . .
29
2.2.3. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.3. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.3.1. Recursos humanos . . . . . . . . . . . . . . . . . . . . . . . .
31
2.3.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.3.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
2.3.4. Gastos generales . . . . . . . . . . . . . . . . . . . . . . . . .
32
2.3.5. Presupuesto total . . . . . . . . . . . . . . . . . . . . . . . . .
33
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
6
Índice general
3. Sumario del Hardware
35
3.1. Sumario del Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2. Clúster de Arndale Octa . . . . . . . . . . . . . . . . . . . . . . . . .
36
4. Análisis de aplicaciones
39
4.1. Aplicaciones de producción . . . . . . . . . . . . . . . . . . . . . . .
39
4.2. Herramientas de benchmarking . . . . . . . . . . . . . . . . . . . . .
40
4.3. LINPACK Benchmarks
. . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3.1. HPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.4. HPCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.4.1. DGEMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.4.2. STREAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.4.3. PTRANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.4.4. RandomAccess . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.4.5. FTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.4.6. Comunications latency and bandwidth . . . . . . . . . . . . .
47
4.5. GROMACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.6. Microkernels
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.6.1. Patrones de acceso a memoria . . . . . . . . . . . . . . . . . .
49
4.6.2. Float-Point peak performance . . . . . . . . . . . . . . . . . .
49
4.6.3. Overhead al paralelizar . . . . . . . . . . . . . . . . . . . . .
49
4.7. Aplicaciones del SCC’14 . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.8. En resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5. Optimización de aplicaciones
51
5.1. Medidas de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.1. Speed Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.2. Eficiencia paralela . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.3. Ley de amdahl . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.2. Herramientas de análisis . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.2.1. EXTRAE y Paraver . . . . . . . . . . . . . . . . . . . . . . .
53
5.3. Instalación y configuración de programas . . . . . . . . . . . . . . . .
53
5.4. Optimizando el fichero de configuración de HPL y HPCC . . . . . .
56
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
6. Evaluación del clúster
7
59
6.1. Benchmarking single node . . . . . . . . . . . . . . . . . . . . . . . .
59
6.1.1. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.1.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.2. Benchmarking multi nodo . . . . . . . . . . . . . . . . . . . . . . . .
66
6.2.1. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.2.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
7. Sostenibilidad
71
7.1. Sostenibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1. Viabilidad económica
71
. . . . . . . . . . . . . . . . . . . . . .
71
7.1.2. Impacto Social . . . . . . . . . . . . . . . . . . . . . . . . . .
71
7.1.3. Impacto Ambiental . . . . . . . . . . . . . . . . . . . . . . . .
72
8. Conclusiones individuales
73
8.1. Evaluación global . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9. Conclusiones de equipo
75
9.1. Conclusiones de cara a la competición . . . . . . . . . . . . . . . . .
75
9.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Agradecimientos
77
Bibliografı́a
80
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
8
Facultat d’Informàtica de Barcelona
Índice general
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
9
Índice de figuras
2.1. Listado de Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.3. Estado del Laboratorio C6-103 al llegar. . . . . . . . . . . . . . . . .
32
3.1. Vista del clúster (cerveza para comparar la escala) . . . . . . . . . .
36
3.2. Vista del clúster (cerveza para comparar la escala) . . . . . . . . . .
36
3.3. Vista cercana del clúster . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4. Vista del switch de interconexión . . . . . . . . . . . . . . . . . . . .
37
3.5. Vista general del clúster . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.1. Patrón de acceso a datos según aplicación . . . . . . . . . . . . . . .
44
4.2. Esquema de comunicaciones según la versión de benchmark. . . . . .
44
4.3. Conexiones que realiza MPI en Natural ring . . . . . . . . . . . . . .
47
4.4. Un posible patrón de conexiones que realiza MPI en Random ring .
48
6.1. Ejemplo de fichero de resultados del microkernel N-Body OpenMP .
60
6.2. Speed Up con precisión de 32-bits. . . . . . . . . . . . . . . . . . . .
61
6.3. Speed Up con precisión de 64-bits. . . . . . . . . . . . . . . . . . . .
61
6.4. Comparativa de la eficiencia paralela de simple y doble precisión con
4 threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
6.5. Rendimiento y efficiencia paralela con HPL (single node). . . . . . .
63
6.6. Eficiencia respecto al PP de las primeras posiciones del top500. . . .
64
6.7. Eficiencia energética comparada con las primeras posiciones de Green500. 66
6.8. Gráfica de speed up del cluster ejecutando HPL de 1 a 24 procesadores. 68
6.9. Eficiencia paralela del clúster ejecutando HPL de 1 a 24 procesadores. 69
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
10
Facultat d’Informàtica de Barcelona
Índice de figuras
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
11
Índice de cuadros
2.1. Distribución de horas de trabajo según rol. . . . . . . . . . . . . . .
27
2.2. Costes asociados a recursos humanos.
. . . . . . . . . . . . . . . . .
31
2.3. Costes derivados de la compra de Hardware. . . . . . . . . . . . . . .
31
2.4. Desglose de los gastos generales. . . . . . . . . . . . . . . . . . . . .
33
2.5. Resumen presupuesto total. . . . . . . . . . . . . . . . . . . . . . . .
33
4.1. Operación y medida de rendimiento de los benchmarks de HPCC.
.
43
4.2. Versiones disponibles para cada benchmark. . . . . . . . . . . . . . .
45
6.1. Resumen de resultados de HPCC. . . . . . . . . . . . . . . . . . . . .
70
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
12
Facultat d’Informàtica de Barcelona
Índice de cuadros
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
13
Abreviaciones
BLAS Basic Linear Algebra Subprograms. 42, 49
BSC Barcelona Supercomputing Center. 30, 48
CPU Central Processing Unit. 35, 48
DGEMM Double-precision GEneral Matrix Multiply. 45
eMMC embeded MultiMediaCard. 35
EP Embarrassingly Parallel. 43, 69
FFT Fast Fourier Transformation. 47, 49
GB Gigabyte. 35
GFLOPS Gigaflops. 42, 47, 59, 60
GPU Graphics Processing Unit. 35
GROMACS GROningen MAchine for Chemical Simulations. 39, 40, 48
GUPS Giga UPdates per Second. 46
HPC High Performance Computing. 3, 4, 17, 20, 22, 25, 30, 71, 72
HPCC High Performance Computing Challenge. 39, 41
HPL High-Performance Linpack. 20, 39, 41, 59, 60, 63, 64
ISC International Supercomputing Conference. 17, 19, 20
LU Lower-Upper. 42
Mbps Mega Bits Por Segundo. 35
MHz Gigahercios. 35
MPI Message Passing Interface. 42, 60
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
14
Abreviaciones
PP Peak Performance. 42
SCC Student Cluster Challenge. 17, 19, 20, 22, 25, 39
SD Secure Digital. 35
SIMD Single Instruction Multiple Data. 48
SoC System On Chip. 35, 59, 62, 69
W Vatios. 20, 65, 69, 72
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
15
Glosario
Green500 Ránking de los 500 supercomputadores más potentes del mundo ordenados por eficiencia energética. 59
Top500 Ránking de los 500 supercomputadores más potentes del mundo ordenados
por rendimiento. 41
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
16
Facultat d’Informàtica de Barcelona
Glosario
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
17
Prefacio
Este trabajo forma parte de un proyecto colaborativo de investigación entre estudiantes que se ubica en el área de la informática conocida como HPC. Comparte
tı́tulo y se complementa con el trabajo de tres compañeros de proyecto: David Trilla
en el ámbito del hardware, Cristóbal Ortega en el de software de sistema y Constantino Gómez por el apartado de aplicaciones. Por tanto, los siguientes capı́tulos
son compartidos a nivel de proyecto: este prefacio, introducción, planificación y presupuestos, sostenibilidad y por último conclusiones de equipo. Estos capı́tulos son
compartidos porque aportan información esencial común a todo el proyecto, ası́ como una descripción del trabajo conjunto que ha realizado el equipo.
Hoy en dı́a el HPC es una de las herramientas principales para el desarrollo de
la ciencia. Por norma general las aplicaciones HPC comparten una caracterı́stica
común, se pueden desmenuzar en subtareas para poder ası́ ejecutarse de manera
paralela en gran cantidad de procesadores.
El principal exponente de este tipo de investigación son los supercomputadores,
máquinas con capacidades de cómputo muy por encima de la mayorı́a de ordenadores, y que son imprescindibles para casi cualquier campo cientı́fico e investigación.
El HPC se encarga de que estas máquinas sigan evolucionando para permitir que la
ciencia siga avanzando a pasos cada vez mayores.
Una de las conferencias más importantes en materia HPC es la International Supercomputing Conference (ISC). Los asistentes, mayoritariamente profesionales del
sector, participan en charlas técnicas, conferencias y talleres entre otros. Para este
trabajo, no es el evento principal el que resulta de interés, sino la competición HPC:
Student Cluster Challenge (SCC). En esta competición, que participan universidades de todo el mundo, equipos de estudiantes compiten por conseguir los mejores
resultados de rendimiento.
La creación del grupo responde a dos necesidades: la de dar cabida a los tres aspectos
técnicos más importantes de la tecnologı́a HPC en un proyecto común, y segundo,
la de formar un equipo y las opciones que se tendrı́an para ganar una competición
como la Student Cluster.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
18
Facultat d’Informàtica de Barcelona
Glosario
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
19
Capı́tulo 1
Introducción
1.1.
Orı́genes
A principios de septiembre de 2013, Álex Ramı́rez reúne a 7 estudiantes de la especialidad de ingenierı́a de computadores, entre ellos los 3 integrantes del grupo, y nos
propone formar un equipo con intención de participar en la ISC ‘14 que se celebra
en Leipzig del 21 al 25 de Junio en 2014
A lo largo de septiembre y octubre se estudian los requerimientos de la competición y elaboramos el documento de inscripción con información de los participantes
y un primer planteamiento del clúster.
A principios de diciembre la organización nos comunica que no hemos sido admitidos
en la competición sin aportar mayor explicación.
En enero de 2014 acordamos seguir con el proyecto a modo de TFG pese a no
estar admitido. El grupo se reduce a 3 personas: Constan Gómez, David Trilla y
Cristobal Ortega.
1.2.
Problemática
Por un lado la problemática que se plantea es la siguiente: en caso de querer competir en el futuro en una competición como el SCC, qué competencias de equipo y
conocimientos técnicos deberı́amos desarrollar.
Por otro lado, nos encontramos otro problema, más general y de más alcance, como
es el consumo de los supercomputadores hoy en dı́a. Actualmente, el mantenimiento
de los centros de computación tiene un coste muy elevado. Gran parte del coste se
debe al consumo eléctrico de sus equipos y la refrigeración necesaria para mantenerlos funcionando. Este problema es atacado de forma indirecta en el SCC por la
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
20
Capı́tulo 1. Introducción
limitación de consumo a 3.000 Vatios (W), y en el clúster que construiremos con
hardware de bajo consumo.
Para ayudarnos a definir los objetivos del trabajo, veamos primero en detalle en
que consiste la competición.
1.3.
Student Cluster Challenge
El SCC es una competición que se celebra en el ámbito del ISC, el escaparate sobre HPC en Europa. El evento ISC ‘14 tiene lugar entre los dı́as 21 y 25 de Junio
en Liepzig, Alemania. Esta competición será nuestro marco de referencia, dirigiendo nuestro proyecto como si fuéramos a participar en ella, usando sus directrices y
parámetros. El evento consiste en reunir a varios equipos, de hasta 6 estudiantes
sin graduar, que junto con un pequeño sistema para supercomputación y a lo largo
de 4 dı́as, compitan entre ellos en diferentes categorı́as para determinar el sistema
ganador, mediante el montaje y la optimización de los parámetros de las aplicaciones.
Existen 3 categorı́as a las cuales se opta a premio, la de mejor resultado con HighPerformance Linpack (HPL), que es la versión para HPC del software de benchmarking LINPACK, la de votación a favorito, y la categorı́a general donde cuenta la
puntuación total de todos los benchmarks.
La caracterı́stica de la competición de premiar al eficiencia da lugar a la principal restricción que se impone en la competición, que limita el “presupuesto para el
consumo”. Esto limita el consumo de cualquier clúster en competición, incluyendo
sus elementos para interconexión, a un total de 3.000W. [2]
Debido a todas las anteriores normas, nuestra intención es diseñar dos clústeres
pensados para presentar al concurso. Un clúster teórico, que cumpla los requisitos
anteriores, y que nos permitirá liberarnos de la necesidad de depender del coste de
su creación, y posteriormente, con el hardware disponible, crear un clúster que pueda ejecutar eficientemente los benchmarks del concurso, con especial atención en el
HPL, y que también cumpla la restricción de consumo.
1.4.
Objetivos
A continuación se desglosan los objetivos generales del proyecto y los objetivos individuales de cada uno de los tres trabajos.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
1.4.1.
21
Objetivos Generales
Basándonos en los requerimientos vistos en la sección anterior se establecen los siguientes objetivos generales y su justificación. Hemos dividido el proyecto en dos
fases.
Objetivos de la primera fase
Estudio del estado del arte HPC
Diseñar y montar un clúster con un consumo inferior a los 3kW.
Para poder diseñar adecuadamente un clúster necesitamos realizar previamente un
estudio del estado del arte. De esta manera podremos extraer cuales son los elementos
indispensables para su montaje, y además, adquirir otros conocimientos relacionados
que nos ayudarán durante todo el desarrollo del proyecto.
El segundo objetivo se aborda de dos maneras diferentes. Por un lado se realiza
el diseño teórico de un clúster con procesadores y aceleradores convencionales. Por
otro, el diseño y montaje de un prototipo de clúster con procesadores móviles de
bajo consumo.
Dada la necesidad de asistir con un clúster propio a la competición, es necesario
trabajar de primera mano con el hardware y el software de sistema para ser más
competitivos.
Objetivos de la segunda fase
Evaluación del clúster basado en procesadores de bajo consumo.
En este momento, mediante benchmarks y aplicaciones, realizaremos las pruebas
empı́ricas que demostrarán que nuestra solución al problema está a la altura de la
competición. En caso de que no estarlo, se buscará poder señalar de manera precisa
la causa de las deficiencias de rendimiento (cuellos de botella) ya sean de diseño, de
configuración o de uso incorrecto de las herramientas de evaluación.
Dado que ningún integrante del grupo ha participado en algún proyecto similar
anteriormente, el proceso de evaluación servirá también para el desarrollo de las habilidades de equipo necesarias en la competición, ya que, gran parte de las técnicas
y los test aplicados con el fin de optimizar la máquina y las aplicaciones de este
trabajo son extrapolables a otras configuraciones de hardware y otros programas.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
22
Capı́tulo 1. Introducción
1.4.2.
Objetivos individuales
Objetivos de la sección de hardware
Fase 1
Investigación sobre el estado del arte del hardware en el mundo de HPC, cuáles
son las tecnologı́as más usadas y los componentes necesarios para construir un
clúster.
Crear un clúster para HPC de manera conceptual para poder competir en el
SCC, sin limitación económica.
Evaluar la tecnologı́a usada en el SCC y las capacidades del clúster teórico
diseñado.
Fase 2
Analizar el hardware a nuestro alcance, disponible para construir un clúster
para HPC.
Montar y configurar el hardware para tener una plataforma funcional con
múltiples nodos sobre la que poder ejecutar software
Evaluar el rendimiento del hardware, las diferencias entre los resultados esperados y los reales, y comparar con el clúster conceptual de la primera fase y
otros sistemas con tecnologı́as distintas.
Objetivos de la sección de software de sistema
Fase 1
Investigar que software de sistema es necesario habitualmente para correr aplicaciones del tipo HPC.
Estudiar el estado actual en los sistemas de supercomputación para saber que
stack de software usan.
Seleccionar el software de sistema que necesitemos y elegir el que mejor se nos
adapte a nosotros, ya sea por compatibilidad con el hardware o aplicaciones a
correr, por documentación existente o requisitos diversos.
Fase 2
Basado en la fase 1, instalar y configurar todo el stack de software para crear
un clúster totalmente funcional. Es posible que haya que seleccionar otro tipo
de software por la plataforma usada.
Experimentar con distintas versiones de paso de mensajes MPI para saber
realmente cuál se adapta a nuestro sistema
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
23
Objetivos de la sección de aplicaciones
Fase 1
Investigar las aplicaciones en el estado del arte actual y analizar las más relevantes para nuestro proyecto.
Averiguar que opciones existen de cara a optimizar las aplicaciones que se
ejecutarán en el clúster.
Fase 2
Evaluar el rendimiento de las aplicaciones descritas a nivel de nodo y a nivel
de clúster.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
24
Facultat d’Informàtica de Barcelona
Capı́tulo 1. Introducción
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
25
Capı́tulo 2
Planificación y presupuesto
2.1.
2.1.1.
Planificación
Estudio Teórico
La primera fase, es de investigación activa, sobre HPC y el SCC, e información sobre todo lo necesario para la instalación y preparación de un clúster. Esto incluye
hardware, software de sistema y aplicaciones. Esta parte del proyecto recabará la
información necesaria para elaborar un clúster teórico con el que ir a competir en el
SCC.
No se esperan grandes contratiempos durante esta fase. Los problemas que puedan
surgir serán derivados de la poca información disponible sobre algunos componentes
del clúster.
2.1.2.
Aplicación Práctica
La segunda fase, basada en la experimentación, es en la cual usamos la información
recogida en la fase anterior para crear un clúster totalmente funcional. En esta fase
es donde es más probable que surjan dificultades técnicas, ya que al ser un mundo
casi nuevo, como por ejemplo, que la información recogida en la fase anterior no se
ajuste a nuestra arquitectura o software escogido.
Los posibles retrasos de ponernos a montar el clúster, instalación de software y
benchmarks deberemos tenerlos en cuenta y aplazar el resto de tareas que tengamos,
como es la optimización de software y aplicaciones, esto implica que obtendremos
peores rendimientos de los que realmente podrı́amos conseguir. Ya que para poder
obtener las métricas de rendimiento necesitamos un clúster funcionando. Y aunque
no sea un clúster optimizado todo lo posible, el objetivo de tener un clúster de HPC
estará conseguido. Los posibles retrasos que aparezcan en esta sección puede aparecer de errores e incompatibilidades en la fase de instalación del clúster, el tiempo
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
26
Capı́tulo 2. Planificación y presupuesto
adicional será recortado de las tareas más opcionales dispuestas al final del proyecto, correspondientes a la parte de optimización, lo que implicará que obtendremos
peores rendimientos de los que realmente podemos conseguir, ya que la instalación
y puesta en marcha del clúster es esencial, sin embargo el proyecto estará finalizado
ya que tendremos un clúster totalmente funcional.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
2.2.
27
Estimación temporal
La temporización en este proyecto toma especial importancia por dos motivos: hay
un gran volumen de tareas a realizar que requieren un esfuerzo conjunto y la alta
incertidumbre que albergan algunas de ellas. Debido a las fuertes dependencias entre
tareas es imprescindible tener en mente las fechas comprometidas para garantizar
que todo el grupo cumple con sus objetivos.
Desde el principio se acuerdan unas horas fijas de dedicación semanal en grupo.
Por un lado, nos ayudará a empezar con buen ritmo con la parte teórica y a funcionar como un equipo, y por otro, tener margen de reacción de cara al final del
proyecto donde se prevén más problemas.
Tarea
Estudio previo
Montaje y configuración
Benchmarking
Análisis de resultados
Dedicación por persona
125h
155h
35h
60h
Cuadro 2.1: Distribución de horas de trabajo según rol.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
28
Capı́tulo 2. Planificación y presupuesto
2.2.1.
Listado de Tareas
Figura 2.1: Listado de Tareas
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
2.2.2.
Diagrama de Gantt
29
Figura 2.2: Diagrama de Gantt
30
Capı́tulo 2. Planificación y presupuesto
2.2.3.
Recursos
Los recursos que tendremos para este proyecto serán principalmente humanos, tendrán
un papel importante para el estudio teórico, el montaje y configuración del clúster.
Para la parte de estudio, nos apoyaremos en publicaciones cientı́ficas, revistas y
papers, además de sitios online especializados de este tipo de hardware y software.
También se hará uso de libros que puedan tratar los temas de HPC o clústeres, pese
a que estos se prevén en menor medida.
Para la parte práctica del montaje del clúster dispondremos principalmente del
hardware que nos ofrezca el departamento de computadores y el sitio en el que nos
permita colocarlo. Para realizar las medidas de consumo energético se ha dispuesto
de un medidor de potencia Yokogawa cedido por el Barcelona Supercomputing Center (BSC).
Finalmente, otros recursos utilizados son los ordenadores personales para la redacción de la memoria y conectar en remoto al hardware de desarrollo.
2.3.
Presupuesto
El proyecto se basa en montar un clúster y configurarlo de manera correcta para
poder ejecutar aplicaciones HPC en él. En este documento se hace una estimación
del precio de los recursos que se usarán a lo largo del trabajo. Las amortizaciones se
calcularán respecto a 6 meses.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
2.3.1.
31
Recursos humanos
Se necesitan técnicos que se encarguen de diseñar, instalar y configurar dicho clúster.
Siendo 3 personas en este proyecto, repartiremos las mismas horas para todos. Dentro de cada bloque de horas, cada uno se centrará en una de las divisiones lógicas
que hemos establecido: hardware, software de sistema y aplicaciones.
Para las decisiones de elección de componentes se han considerado horas de Director
de proyecto. Para el montaje e instalación del clúster se necesitarán competencias
de Administrador de Sistema. Para realizar los benchmarks adecuados e interpretar
resultados se han considerado horas de Analista. Los datos que utilizamos están
basados en portales online de ofertas laborales.
Rol
Director de proyecto
Administrador de sistema
Analista
Total
Horas
estimadas
Precio
por hora
Total
por persona
Total
grupo
125h
155h
95h
375h
50e/h
26e/h
30e/h
6250e
4030e
2850e
18750e
12090e
8550e
39390e
Cuadro 2.2: Costes asociados a recursos humanos.
2.3.2.
Hardware
Para la segunda parte del proyecto será esencial el hardware que adquiramos para
poder trabajar con él. Datos obtenidos de tiendas online.
Producto
Arndale Octa(Exynos 5420)
Fuentes de alimentacion
Tarjetas SD
Power meter Yokogawa
Switch Netgear 100-Mbit
1TB Hard Drive Storage
125M cat 5E FTP
Total
Precio
unitario
Unidades
150e
5e
7.5e
1830e
89e
70e
68e
6
6
12
1
1
1
1
Vida
útil
5
5
5
15
10
7
20
Amortización
total
años
años
años
años
años
años
años
90e
3e
9e
61e
4.45e
5e
1.7e
174.15e
Cuadro 2.3: Costes derivados de la compra de Hardware.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
32
Capı́tulo 2. Planificación y presupuesto
Tanto las placas Arndale Octa como las fuentes de alimentación y el medidor de potencia Yokogawa han sido cedidos por el BSC. El resto del material ha sido cedido
por el departamento de Arquitectura de Computadores. Al final de la realización
del proyecto se espera deshacer el montaje y retornar ı́ntegro todo el material para
su posterior reutilización en otras actividades de investigación o proyectos.
2.3.3.
Software
El software requerido para la instalación, benchmarking y análisis de la máquina
es de acceso gratuito. Gran parte de de los programas tienen licencias de Software Libre, y las que no, disponen de versiones gratuitas con propósito no comercial.
Necesitaremos distinto software de sistema para gestionar la máquina como aplicaciones para medir su rendimiento.
2.3.4.
Gastos generales
Necesitaremos un sitio donde instalar el clúster fı́sicamente, para ello necesitaremos
un sitio con espacio y una instalación eléctrica adecuada además de Internet para
tener acceso a los sistemas desde fuera.
El laboratorio C6-103 cedido también por el departamento de AC cuenta con todo
lo necesario para la realización del proyecto. Se ha hecho una estimación del coste
que supondrı́a disponer de un espacio similar.
Figura 2.3: Estado del Laboratorio C6-103 al llegar.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
Concepto
Espacio fı́sico
Electricidad
Internet
Total
33
Coste
hora
Coste
total
0.368e
0.083e
0.07e
1590e
358e
300e
2248e
Cuadro 2.4: Desglose de los gastos generales.
2.3.5.
Presupuesto total
Concepto
Recursos humanos
Hardware
Software
Gastos generales
Total
Coste estimado
+ Impuestos
39390e
174.15e
625e
2248e
42437.15e
51600.9e(31 % S.S.)
210.7e(21 % IVA)
300e(21 % IVA)
2720.08e(21 % IVA)
54831.68e
Cuadro 2.5: Resumen presupuesto total.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
34
Facultat d’Informàtica de Barcelona
Capı́tulo 2. Planificación y presupuesto
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
35
Capı́tulo 3
Sumario del Hardware
3.1.
Sumario del Hardware
En resumen el hardware usado que constituye al clúster es el siguiente:
Nodo: Arndale Octa (x6)
• System On Chip (SoC): Samsung Eynos 5420
◦ Central Processing Unit (CPU): ARM Cortex-A15 (x4) + ARM
Cortex-A7 (x4)
◦ Graphics Processing Unit (GPU): Mali T-628
◦ Memoria: 2 Gigabyte (GB) 933 Gigahercios (MHz)
• 100 Mega Bits Por Segundo (Mbps) Interfaz Ethernet
• Almacenamiento:
◦ 4 GB embeded MultiMediaCard (eMMC)
◦ 16 GB Secure Digital (SD)
Switch: NetGear FS524
Cables Ethernet Cobre (x6)
Transformadores (x6)
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
36
Capı́tulo 3. Sumario del Hardware
3.2.
Clúster de Arndale Octa
Figura 3.1: Vista del clúster (cerveza para comparar la escala)
Figura 3.2: Vista del clúster (cerveza para comparar la escala)
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
37
Figura 3.3: Vista cercana del clúster
Figura 3.4: Vista del switch de interconexión
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
38
Capı́tulo 3. Sumario del Hardware
Figura 3.5: Vista general del clúster
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
39
Capı́tulo 4
Análisis de aplicaciones
En esta sección tiene como propósito presentar y analizar las aplicaciones con las
que se trabajará a lo largo del proyecto. Algunas de estas aplicaciones tienen especial
relevancia, ya sea por su papel en el estado del arte actual o en la competición SCC.
En concreto veremos:
Los benchmarks HPL y High Performance Computing Challenge (HPCC), en
ellos centraremos la mayor atención, ya que son dos aplicaciones a las que se
deben enfrentar cada año los equipos de la SCC, y además son utilizadas para
confeccionar los ránkings oficiales de rendimiento de clústers.
GROningen MAchine for Chemical Simulations (GROMACS) nos servirá como ejemplo para ver que tipo de aplicaciones cientı́ficas se ejecutan en los
supercomputadores.
Finalmente listamos y describimos los microkernels que han sido utilizados en
la evaluación del clúster final y que implementan algoritmos de uso recurrente
en HPC.
Se ha decidido dejar fuera del análisis las aplicaciones especı́ficas para esta edición
del SCC por el tiempo que llevarı́a trabajar con ellas. Al final veremos una lista y
una breve descripción de cuáles son.
En el estado del arte actual podemos agrupar entonces en dos grupos, aplicaciones de producción y las de benchmarking.
4.1.
Aplicaciones de producción
Usaremos el término aplicación de producción para referirnos a aquellas aplicaciones que tienen un uso directo en la investigación o industria. Principalmente, estas
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
40
Capı́tulo 4. Análisis de aplicaciones
aplicaciones implementan modelos matemáticos y permiten simular experimentos
o fenómenos fı́sicos. Una manera general de determinar la calidad de este tipo de
aplicaciones es la relación entre el volumen de datos de entrada, la precisión y el
tiempo en obtener los resultados. Generalmente, el volumen de datos a procesar de
estas aplicaciones es enorme, ası́ que para poder obtener resultados en un espacio
de tiempo razonable, es necesario utilizar ordenadores con gran capacidad de cálculo.
Es por tanto que cuando se diseña un clúster HPC el principal objetivo es el de
conseguir una configuración de hardware que ofrezca buenos resultados en la aplicación o conjuntos de aplicaciones que queremos ejecutar en él.
Las aplicaciones de producción pueden ser usadas, entre otros, en la simulación
de dinámica de fluidos, que permite observar el comportamiento fı́sico de materiales
o elementos fluidos. Un ejemplo concreto puede ser la simulación de la aerodinámica de un coche dentro de un túnel de viento. Otro uso es en dinámica molecular,
permitiendo realizar pruebas con fármacos sin necesidad de usar personas u otros
animales. Un ejemplo de este tipo de aplicaciones es GROMACS, explicado un poco
más adelante.
4.2.
Herramientas de benchmarking
Comúnmente, los benchmarks realizan operaciones simples con el fin de estresar
partes del hardware y obtener una medida de rendimiento de éstas. Estas medidas
de rendimiento las compararemos a su vez con otras obtenidas en otras condiciones,
ya sea porque hemos modificado algún parámetro de ejecución o porque han sido
obtenidas en otro clúster. Es importante conocer en que consisten dichas operaciones
para poder hacer un uso inteligente de estas herramientas.
Obtener buen rendimiento al ejecutar una aplicación de producción concreta no
implica que el resto de aplicaciones vayan a obtener también buen rendimiento. A
bajo nivel esto puede ser debido a muchas causas: diferente patrón de accesos a
memoria, número de llamadas a sistema, mal balanceo de carga, etc. En resumen
diremos que cada aplicación tiene necesidades computacionales diferentes.
Es por eso que nos interesa poder evaluar de manera consistente los recursos hardware del clúster. Por consistente nos referimos a obtener valores que representen las
capacidades de la máquina en todos sus niveles. Capacidades de cómputo, comunicaciones, memoria y la escalabilidad al ejecutar aplicaciones.
Por ejemplo, supongamos que queremos hacer una estimación del rendimiento que
se obtendrá en un tipo de aplicación que hace cálculo intensivo con operaciones de
coma flotante, y cuyos accesos a datos son mayoritariamente a vectores en orden secuencial . Podemos prever el rendimiento basándonos en los resultados obtenidos en
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
41
la ejecución en el mismo clúster de un benchmark que tenga caracterı́sticas similares.
Hemos seleccionado los benchmark HPL y HPCC, para determinar en qué nos pueden ayudar, y que más tarde nos permitirá hacer una evaluación lo más completa
posible del clúster que se ha montado.
4.3.
LINPACK Benchmarks
LINPACK es una librerı́a de álgebra linear. Originalmente fue escrita en Fortran 66
en 1980 y su propósito era el de ser utilizada en supercomputadores.[22]
Basándose en esa librerı́a, se crearon una serie de benchmarks con el propósito
de medir la potencia computacional en FLOPS (de doble precisión) 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 Ax = b y de tamaño N xN [23].

a1,1
 a2,1

 ..
 .
a1,2
a2,2
..
.
an,1 an,2
   
. . . a1,n
x1
b1




. . . a2,n   x2   b2 

..   ..  =  .. 
..




.
.
.
.
. . . an,n
xn
bn
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).[13]
4.3.1.
HPL
HPL website: http://www.netlib.org/benchmark/hpl/
HPL es la implementación de HPLinpack Benchmark más relevante. Es una versión
paralela y escalable preparado para ejecutarse con un modelo de memoria distribuida. Es el benchmark utilizado para elaborar la lista Top500 de supercomputadores
www.top500.org.
Está implementación es mantenida por la Universidad de Tenesse y actualmente
se encuentra en la versión 2.1 de Octubre 2012, está escrita en C para facilitar su
portabilidad. Para su ejecución HPL requiere tener instaladas en el sistema librerı́as
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
42
Capı́tulo 4. Análisis de aplicaciones
que implementen Message Passing Interface (MPI) y Basic Linear Algebra Subprograms (BLAS).[1]
Complejidad y tamaño del problema
Para resolver el sistema de ecuaciones, HPL utiliza el método de factorización LowerUpper (LU) y luego resuelve el sistema triangular superior (U) U x = y.
La complejidad de este método es 32 n3 + 2n2 , es decir, necesitamos esa cantidad
de operaciones de coma flotante (64-bits) para obtener la solución al sistema. De
ahı́ extraemos la fórmula que utiliza HPL para medir el rendimiento en Gigaflops
(GFLOPS).
PHP L =
2 3
3n
+ 2n2
tsegundos
10−9
(4.1)
Cabe decir que en caso de querer optimizar la implementación, queda excluido cualquier método que varie la complejidad del algoritmo (p.ej: algoritmo de Strassen),
ya que se deberı́a modificar también la fórmula del rendimiento. Serı́a utilizar un
benchmark diferente.
El espacio en memoria durante la ejecución depende de la matriz A, siendo la matriz
A de tamaño n por n, esta ocupará 8n2 bytes.
Los datos que componen la matriz A y el vector b se obtienen a partir de un generador pseudo-aleatorio de números decimales con una media esperada de cero[9].
Eficiencia paralela
Con el fin de balancear el volumen de trabajo a realizar en cada nodo, HPL divide en
bloques de tamaño BSxBS y los distribuye de manera cı́clica entre procesos[9]. El
número de operaciones a realizar es proporcional al tamaño de los datos de entrada.
Debido al blocking, el patrón de acceso a memoria explota la localidad espacial
y temporal de la cache. Si bien en algún momento se requiere comunicación entre
procesos todos-con-todos, el mayor estrés lo sufren las unidades de coma flotante y
la conexión de los registros a la caché de cada procesador.
Al final de la ejecución se obtiene una medida del rendimiento en GFLOPS. Una
ejecución de HPL optimizada suele moverse en el margen de 70-80 % del Peak Performance (PP).
Hemos dicho que HPL nos da una medida de rendimiento, sin embargo esta medida solo se puede extrapolar a aplicaciones que hagan un uso similar de los recursos
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
43
de la máquina. ¿Qué pasa con el resto de aplicaciones que usan diferentes de recursos? Hay que seguir haciendo benchmarking.
4.4.
HPCC
HPCC website: http://icl.cs.utk.edu/hpcc/
HPCC (High Performance Computing Challenge) es una colección de benchmarks
confeccionada con el propósito es el de ofrecer medidas de rendimiento de un sistema
HPC más completas que las que ofrece HPL, para ello, utiliza variedad de aplicaciones con diferentes tipos de operaciones y patrones de acceso a memoria. HPCC
es desarrollado por la Universidad de Tenesse bajo el programa DARPA HPCS[5].
Los desarrolladores de HPCC mantienen además un ránking propio en la sección
results de su página web. Anualmente se celebra una competición, que tiene lugar
en la Supercomputer Conference, llamada HPC Challenge Awards Competition, y
dónde se premia al mejor resultado del ránking y a la mejor implementación de una
lista de kernels seleccionados[7].
El listado de benchmarks que componen HPCC, una breve descripción de la operación que realizan y la medida de rendimiento obtenida en cada uno de ellos se puede
ver en la tabla 4.2.
Benchmark
Operación
Medida
HPL
DGEMM
STREAM
PTRANS
RandomAccess
FFT
b eff
Resuelve un sistema de ecuaciones
Multiplicación de matrices (64-bit)
Conjunto de operaciones con vectores
Transposición de matrices
Acceso aleatorio a datos enteros
Transformada discreta de Fourier
Varios patrones de comunicación MPI
GFLOPS
GFLOPS
GB/s
GUP/s
GUP/s
GFLOPS
GB/s
Cuadro 4.1: Operación y medida de rendimiento de los benchmarks de HPCC.
Una representación gráfica del grado y tipo de localidad de los accesos a memoria
se puede ver en la figura 4.1.
De cada benchmark podemos encontrar hasta tres versiones: Single, Embarrassingly
Parallel (EP) y Global. Estas versiones pretenden estresar diferentes partes del hardware suponiendo varios escenarios: uniprocesador, multiprocesador y multinodo.
En las versiones single el benchmark se ejecutará utilizando de manera aislada los
cores de nuestro clúster, por tanto, no hay comunicación de ningún tipo ni entre
procesadores ni entre nodos. Sirve como medida base para evaluar la escalabilidad
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
44
Capı́tulo 4. Análisis de aplicaciones
Figura 4.1: Patrón de acceso a datos según aplicación
de la aplicación en nuestro sistema.
Las versiones Embarrasingly Parallel solo se permiten la comunicación entre cores del procesador de un mismo nodo. Ejecutan el benchmark una vez por nodo y
se quedan con la mejor. Permite determinar la eficiencia paralela a nivel de nodo.
Las Global apuntan a hacer un uso completo del clúster, durante la ejecución
habrá comunicación entre procesadores de diferentes nodos para obtener datos de
la memoria. Permite determinar la eficiencia paralela a nivel de clúster y evaluar el
rendimiento de la red de comunicación entre nodos.
Nota: Los nombres que reciben estas versiones en los informes de resultados son
Single, Star y MPI.
Una representación gráfica del comportamiento de las versiones descritas puede verse
en la figura 4.2
Figura 4.2: Esquema de comunicaciones según la versión de benchmark.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
45
Las versiones disponibles para cada uno de los benchmarks en la tabla ??
Benchmark
HPL
DGEMM
STREAM
PTRANS
RandomAccess
FFT
Single
EP
X
X
X
X
X
X
X
X
Global
X
X
X
X
Cuadro 4.2: Versiones disponibles para cada benchmark.
A continuación un pequeño análisis individual de las aplicaciones. Se excluye HPL
por que ya ha sido explicada anteriormente.
4.4.1.
DGEMM
Double-precision GEneral Matrix Multiply (DGEMM), se define como una operación
de multiplicación de matrices A y B tal que C ← αAB + βC donde A, B, C ∈ Rn×n
, α, β ∈ R y n ∈ N.
La complejidad de la región a evaluar es de 2n3 operaciones de coma flotante . Como
en HPL, no se puede aplicar ninguna optimización que reduzca la complejidad del
algoritmo.
Por defecto en esta implementación, resuelve la multiplicación con una llamada a
la correspondiente rutina CBLAS. El uso de recursos hardware del multiprocesador
dependerá de las optimizaciones en la librerı́a instalada(multithreading, vectorización, etc). De todos modos, como HPL, en DGEMM el mayor estrés lo sufre el canal
de registros a caché[4].
4.4.2.
STREAM
STREAM permite medir el ancho de banda entre el procesador y la memoria principal haciendo operaciones simples con vectores de gran tamaño.
Se compone de 4 test u operaciones. Supongamos los vectores a, b, c ∈ Rn y los
escalares α, β ∈ R :
COPY, c ← a
SCALE, b ← αc
ADD, c ← a + b
TRIAD, a ← b + αc
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
46
Capı́tulo 4. Análisis de aplicaciones
En estas operaciones no hay reaprovechamiento de datos, pero los accesos son secuenciales, ası́ que se aprovecha al máximo la localidad espacial. Cada una se mide
en regiones de tiempo diferentes pero se repiten almenos 10 veces dentro de cada
región para obtener una mejor muestra.
El tamaño de datos para vectores de m elementos es 16m bytes para COPY y
SCALE, y 24m bytes para ADD y TRIAD, con complejidad 2n y 3n 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[4].
4.4.3.
PTRANS
Los benchmarks explicados a partir de ahora están pensados para testear la capacidad de comunicaciones de la red.
PTRANS, Parallel TRANSposition, realiza la transposición de una matriz A y le
suma una matriz B. Descripción de la operación: A = AT + B donde A, B ∈ Rn×n .
Para transponer la matriz se asigna un bloque de datos a cada proceso MPI y
entre ellos se comunican por parejas. El rendimiento y el tamaño son O(n2 ), y los
datos que contienen las matrices se generan de manera aleatoria.
4.4.4.
RandomAccess
RandomAccess mide la tasa de actualizaciones aleatorias de memoria con enteros,
esta medida se expresa en Giga UPdates per Second (GUPS). Este benchmark tiene
implementaciones de las tres versiones.
Se crea una tabla T de tamaño 2n y una secuencia Ai de de enteros de 64 bits
de longitud 2n+2 generados con la función x2 + x + 1. La secuencia pseudo-aleatoria
nos servirá para indicar a que posición de la tabla se deben hacer las actualizaciones
de 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 siendo necesario comunicación todos con
todos. De este modo se permite analizar el impacto la latencia introducida en el paso
de mensajes. La comunicación ser realiza todos-con-todos.
Los accesos aleatorios provocan que no exista ningún tipo de localidad y poder
evitar el aprovechamiento de la jerarquı́a de memoria (especialmente los niveles de
cache) y poder determinar el coste con máxima penalización de acceder a memoria
compartida en nuestro sistema [8].
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
4.4.5.
47
FTT
Fast Fourier Transformation (FFT), calcula la transformada de fourier de un vector
unidimensional de gran tamaño. Este kernel es habitualmente utilizado en aplicaciones reales.
Siendo N es el numero de datos (tamaño del vector) y x, z ∈ Cn .
Zk =
n−1
X
xj e−2iπjk/n ;
1≤k≤n
(4.2)
j=0
Los resultados de este benchmark se expresan en GFLOPS, es calculado en base al
tiempo y la complejidad del algoritmo 5n log2 n. Durante la ejecución hay un gran
volumen de intercambio de mensajes largos entre procesadores[4].
4.4.6.
Comunications latency and bandwidth
Sirve para medir el ancho de banda efectivo y la latencia de la red de interconexión
del clúster mediante mensajes punto a punto MPI. No se realizan cálculos de ningún
tipo dentro de la región evaluada.
Basado en b eff pero con cambios en los patrones de comunicaciones, el número
de operaciones que ejecuta es directamente proporcional al numero de procesadores
[5].
En concreto, obtiene medidas de latencia y ancho de banda con 3 patrones: Pingpong, Natural Ring y Random ring.
1
2
3
4
5
6
Figura 4.3: Conexiones que realiza MPI en Natural ring
Para medir latencia cada nodo intercambia mensajes de 8 bytes de tamaño, para
medir el ancho de banda los mensajes son de 2 MB. Se realizan conexiones en los
dos sentidos. La latencia se expresa en milisegundos y en ancho de banda en GB/s
como es habitual.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
48
Capı́tulo 4. Análisis de aplicaciones
1
4
3
6
2
5
Figura 4.4: Un posible patrón de conexiones que realiza MPI en Random ring
4.5.
GROMACS
GROMACS es un paquete de software de dinámica molecular que permite hacer
simulaciones con sistemas de cientos de millones de partı́culas. Fue desarrollado
originalmente por la Universidad de Groningen y hoy en dı́a es mantenido por la
comunidad cientı́fica y universidades de todo el mundo.
Una de sus particularidades es que implementa gran cantidad de optimizaciones
para mejorar su rendimiento. Entre ellas, el uso de librerı́as matemáticas optimizadas, inclusión en el código soporte hasta la última versión Single Instruction Multiple
Data (SIMD) x86 y soporte para CUDA 2.0 en adelante[10].
Un caso de uso de esta aplicación es la plataforma de computación distribuida folding@home de la Universidad de Stanford, esta plataforma permite a los usuarios
colaborar en proyectos de investigación cientı́fica, principalmente relacionadas con
al cura de enfermedades, cediendo tiempo de CPU de sus ordenadores domésticos.
El procedimiento es el siguiente: un proveedor central, servidores de la Universidad de Stanford, despacha unidades de tareas a los ordenadores que tienen el cliente
de la plataforma instalado. En baja prioridad, para no interferir con las tareas que
este realizando el usuario, mediante el uso de la CPU y/o GPU se ejecutan programas como GROMACS. Como entrada de datos se utiliza la unidad de trabajo
asignada en ese momento. Al terminar los cálculos, el cliente envı́a los resultados a
los servidores centrales y vuelta a empezar[19] [21].
4.6.
Microkernels
Usaremos el término microkernel para referirnos a pequeños programas que implementan algoritmos usados habitualmente en software de investigación cientı́fica. Los
microkernels aquı́ descritos forman parte de un conjunto de benchmarks desarrollados en el BSC y utilizados en el proyecto Mont-blanc para obtener mediciones de
rendimiento de sus plataformas [16] [12]. Cada microkernel pone a prueba diferentes
partes de la microarquitectura del SoC/máquina a evaluar; se han agrupado por este
criterio. A continuación una breve descripción de cada uno [11].
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
4.6.1.
49
Patrones de acceso a memoria
Vector operation. Toma dos vectores de un tamaño N y genera el resultado de un
tercero de tamaño N. Realiza sumas uno a uno entre los dos vectores. Permite evaluar el acceso a datos secuencial (localidad espacial).
2D Convolution y 3D stencil. Toman como entrada una matriz 2D de tamaño N xN
y una 3D de tamaño N xN xN respectivamente. Ambos generan resultados del mismo tamaño que sus entradas y calculan cada posición de la matriz resultado a partir
de la entrada como una combinación lineal del mismo punto y sus adjacentes. Estos
benchmarks permiten evaluar el rendimiento de las GPU cuando se realizan accesos
a memoria de tipo strided y cuando son intercalados con accesos secuenciales.
N-Body. Simula la interacción gravitacional entre una serie de partı́culas con velocidad, masa y posición propias. Evalúa el rendimiento frente a un patrón de accesos
a memoria irregular.
4.6.2.
Float-Point peak performance
FFT y DMMM, son implementaciones de las conocidas rutinas de multiplicación de
matrices y transformada de Fourier. Ya han sido explicados en la sección HPCC. Se
pueden optimizar mediante el uso de BLAS y FFTW.
Atomic Monte-Carlo Dynamics . Su caracterı́stica principal es que al realizar simulaciones independientes, durante su ejecución paralela, no necesita comunicación
entre entre threads permitiendo obtener medidas de rendimiento pico.
4.6.3.
Overhead al paralelizar
La ejecución en paralelo de un programa siempre introduce un overhead respecto
a su versión serie. Según el tipo de aplicación el sincronismo entre threads y la serialización al reducir puede suponer una caı́da en el rendimiento importante. Los
siguientes tres microkernels nos ayudarán a evaluar el rendimiento que ofrece nuestro multiprocesador en estos casos.
Reduction. A partir de un vector de entrada calcula un único valor escalar resultado
de la suma por etapas de los elementos del vector. Útil para evaluar como las GPUs
pasan progresivamente de el calculo masivo en paralelo a secuencial.
Histogram. Calcula el histograma de un vector, como en el caso de reduction evalúa
el rendimiento al reducir operaciones con mucho paralelismo.
Merge Sort. Evalúa los posibles cuellos de botella derivados del uso de barreras
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
50
Capı́tulo 4. Análisis de aplicaciones
de sincronización.
4.7.
Aplicaciones del SCC’14
En este apartado mencionamos el conjunto de aplicaciones especificas para la edición
de este año del SCC.
Quantum ESPRESSO es un paquete de software que integra diversos programas
para cálculos eléctrico-estructurales y modelado de materiales. Totalmente Open
Source se puede descargar y obtener mucha documentación de su página web. [15]
OpenFOAM (Open Field Operation and Manipulation) también Open Source es
un paquete de software que permite realizar un gran rango de simulaciones: desde
dinámica de fluı́dos hasta transferencia de calor. [14]
Por último, GADGET software para simulaciones N-body/SPH (Smoothed-particle
Hydrodinamics) [18].
4.8.
En resumen
De cara a evaluar de manera completa nuestro clúster serı́a conveniente ejecutar al
menos HPL y HPCC.
En concreto, la potencia de cálculo la mediremos con HPL, DGEMM y FFT. El
ancho de banda a memoria RAM con STREAM. Finalmente las capacidades de la
red de interconexión se pueden medir con los test de conectividad de HPCC y el acceso a memoria distribuida de manera más aplicada con PTRANS y RandomAccess.
Los microkernels, por la implementación de la que disponemos, solo se usarán para
evaluar el rendimiento en modo nodo único (Single Node).
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
51
Capı́tulo 5
Optimización de aplicaciones
Una vez se consigue la ejecución correcta de una aplicación, es el momento de analizar
el rendimiento obtenido y a partir de ahı́ pensar que optimizaciones se pueden aplicar
para mejorar tales resultados.
5.1.
Medidas de rendimiento
A continuación se comentan las principales medidas de rendimiento utilizadas para
evaluar el rendimiento de un clúster y el impacto de las optimizaciones.
5.1.1.
Speed Up
Speed Up indica la mejora de rendimiento obtenida relativa a una ejecución base. En
paralelismo, se toma como base la ejecución secuencial (T1 ) y con ella se relacionan
el resto de ejecuciones incrementando el número de procesadores (Tp donde p es el
número de procesadores)[6].
SpeedU p =
5.1.2.
T1
Tp
(5.1)
Eficiencia paralela
La eficiencia paralela es la relación entre el Speed Up y el número de procesadores
utilizados en la aplicación.
Ef fp =
Sp
P
(5.2)
De manera ideal, el tiempo de ejecución de un programa se reduce de manera proporcional al número de procesadores que utilizamos, es decir, respecto a un procesador,
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
52
Capı́tulo 5. Optimización de aplicaciones
si usamos 4 procesadores va 4 veces más rápido (Speed Up 4x). El valor de la eficiencia en estos casos es 1 (el máximo).
En la práctica esto no sucede, hay mucha maneras de perder eficiencia: creación
de threads (overhead llamadas a sistema), dependencias (barreras de sincronismo),
granularidad de tareas o scheduling inadecuado provocando problemas de desbalanceo de carga, uso de un algoritmo con insuficiente grado de paralelismo respecto al
número de procesadores, false sharing, mala red de interconexión, etc.
Existen dos tipos de escalabilidad: strong scaling se define como la variación de
tiempo con en base a un número de procesadores variable y un tamaño de problema
fijos, y weak scaling que es el caso inverso, mismo número de procesadores y tamaño
de problema variable.
5.1.3.
Ley de amdahl
La ley de amdahl se utiliza para obtener el valor de mejora máxima alcanzable por
un programa cuando únicamente se mejora una parte. La ley de amdahl aplicada
a un programa paralelo es la siguiente (γ es la región paralela del programa y p el
número de procesadores):
Sp =
1
(1 − γ) +
γ
p
(5.3)
La metodologı́a para la optimización de rendimiento basada en la ley de amdahl
consiste en lo siguiente, se localizan las funciones del programa donde se invierte el
mayor tiempo y es ahı́ donde se concentran los esfuerzos de optimización. Esto es
exactamente lo que se pretende mediante el uso de HPC, utilizar muchos procesadores para reducir el tiempo de ejecución de la región paralela de la aplicación. Con
este propósito usaremos herramientas de análisis de rendimiento paralelo.
5.2.
Herramientas de análisis
Mediante el uso de herramientas de análisis de rendimiento se pretende obtener la
información relevante asociada a la ejecución de una aplicación, de esta manera
encontraremos los cuellos de botella causantes del mal rendimiento. Estos análisis
sirven para indicar qué optimizaciones darán mayor Speed Up, y es más, tratar de
optimizar una aplicación sin realizar análisis puede suponer grandes pérdidas de
tiempo.
Para hacer mediciones en un clúster multinodo se requieren aplicaciones capaces
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
53
de recopilar información, en forma de trazas, de la ejecución de todos los procesos
de la aplicación distribuidos por el clúster. Una de estas herramientas es EXTRAE.
5.2.1.
EXTRAE y Paraver
EXTRAE es una herramienta software que permite generar trazas de aplicaciones
paralelas mediante instrumentación. En estas trazas se recopila información de los
contadores de sistema, numero de accesos a funciones y su temporización. Es capaz
de instrumentar aplicaciones programadas con MPI, OpenMP, pthreads, OpenCL y
StarSS. EXTRAE también ofrece una API que nos permite instrumentar el código
manualmente.
La herramienta dispone de varios métodos mediante los cuales es capaz de instrumentar y obtener trazas. Ofrece soporte para DynINST, una librerı́a que permite
inyectar instrucciones en binarios de manera dinámica y estática. Otra manera de
instrumentar es inyectando librerı́as compartidas durante la precarga de un ejecutable. Esto se consigue editando la variable de entorno en Linux LD PRELOAD.
Durante la precarga se comprueba si el binario a ejecutar tiene llamadas a sı́mbolos que coinciden con las librerı́as indicadas en la variable de entorno, de darse tal
caso, el sistema operativo redirecciona las llamadas hacia la librerı́a compartida.
EXTRAE aprovecha esta caracterı́stica para introducir wrappers instrumentados a
la funciones.
Algunas caracterı́sticas a destacar de la información que recopila. El timestamp
de se hace utilizando funciones de baja latencia que permiten precisión de nanosegundos. Utiliza la librerı́a PAPI que además de los contadores de sistema permite
obtener información sobre el consumo y la temperatura del procesador. Por último
destacar que es capaz de referenciar el código fuente permitiendo encontrar fácilmente las funciones a optimizar.
Una vez tengamos las trazas es necesario usar una herramienta que permita visualizar de manera gráfica los datos para un análisis profundos, Paraver es una de
ellas.
Es flexible y permite guardar vistas de las trazas para retomar o compartir el análisis
en cualquier momento. Además de analizar el rendimiento individualmente permite
comparar varias trazas a la vez y también establecer nuestras propias métricas.
5.3.
Instalación y configuración de programas
Se ha decidido incluir esta sección en este capı́tulo porque en él se muestra como
habilitar el uso de librerı́as de álgebra optimizadas como ATLAS. En ella se detallan
los pasos de instalación y configuración de los 3 paquetes de aplicaciones que se han
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
54
Capı́tulo 5. Optimización de aplicaciones
ejecutado en el clúster.
HPL
Para instalar este programa hemos instalado previamente ATLAS y OpenMPI. HPL
se puede descargar de la página oficial: http://www.netlib.org/benchmark/hpl/
Una vez descargado ejecutaremos:
//Descomprimimos el paquete
$ tar xf hpl-2.1.tar.gz
$ cd hpl-2.1
//Copiamos un makefile predefinido
$ cp Make.ubuntuARM setup/Make.PII_CBLAS
Entonces editaremos diferentes regiones del fichero Make.ubuntuARM de la siguiente manera. A destacar la configuración de la última región donde hemos habilitado
el uso de la versión optimizada de CBLAS del paquete ATLAS.
#Platform identifier
ARCH
= ubuntuARM
[...]
#HPL Directory Structure / HPL library
TOPdir
= /media/ancient/benchmarks/hpl
[...]
#Message Passing library (MPI)
MPdir
= /usr/local/openmpi1.8.1
MPinc
=
MPlib
=
[...]
#Linear Algebra library (BLAS or VSIPL)
LAdir
= /usr/local/atlas
LAinc
=
LAlib
= $(LAdir)/lib/libatlas.a $(LAdir)/lib/libcblas.a
[...]
#Compilers /linkers
CC
= $(OPENMPI)/bin/mpicc
LINKER
= $(OPENMPI)/bin/mpif77
Ahora, HPL ya está listo para compilar.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
55
$ make arch=ubuntuARM
// El anterior comando crea la carpeta bin/ubuntuARM con el
ejecutable
$ cd bin/ubuntuARM/
Antes de ejecutar hará falta configurar HPL.dat de manera adecuada y crear el
hostfile con las direcciones IP de los nodos donde queremos ejecutar el benchmark.
Una vez tengamos eso estamos listos para lanzar la aplicación mediante los siguientes
comandos.
$ mpirun -np <#procesadores> -hostfile <hostfile> xhpl
HPCC
Por suerte para nosotros el benchmark HPCC requiere exactamente los mismos
pasos a excepción de uno. Durante la configuración del fichero Make.ubuntuARM
antes de compilar el benchmark habrá que editar el parámetro TOPdir.
#HPL Directory Structure / HPL library
TOPdir
= ../../..
También encontramos que el fichero de configuración para ejecutar los benchmarks
HPL.dat tiene otro nombre: hpccinf.txt.
Microkernels
Para la instalación y configuración de los microkernels hemos seguido estos pasos:
$ ./setup.sh
$ mkdir build
$ cd build
//Indicamos el path de la libreria ATLAS en los flags de compilacion
$ CPPFLAGS=-I/usr/local/atlas/include
LDFLAGS=-L/usr/local/atlas/lib ./configure --prefix=‘pwd‘/../
//Si lo hemos configurado correctamente al finalizar del script
configure obtendremos un mensaje indicando que se hara uso de
CBLAS.
$ make
$ make install
Ahora ya podemos elegir entre ejecutar uno por uno los diferentes microkernels o
lanzar una ejecución de todos ellos con los comandos:
$ cd ..
$ ./benchmark.py
En caso de querer editar el número de iteraciones a ejecutar o el tamaño del problema
deberemos editar el fichero benchmark.py.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
56
Capı́tulo 5. Optimización de aplicaciones
5.4.
Optimizando el fichero de configuración de HPL y
HPCC
Como hemos mencionado, el benchmark HPL dispone de un fichero de configuración
HPL.dat que permite definir más de 20 parámetros que hacen referencia a aspectos
de la ejecución. Veamos cuales son:
A cada parámetro le corresponde una lı́nea del fichero.
Lı́neas 1-2: sin utilizar, permiten al usuario escribir comentarios
Lı́nea 3: Permite especificar el nombre del fichero de salida
Lı́nea 4: Permite especificar hacia donde redireccionar la salida.
Lı́nea 5: Número de tamaños de problema a ejecutar.
Lı́nea 6: Tamaños de problema, es decir, dimensiones de la matriz del sistema
de ecuaciones.
Lı́nea 7: Numero de tamaños de bloque a ejecutar.
Lı́nea 8: Tamaños de bloque en los que se dividirá la matriz
Lı́nea 9: Como se distribuyen los procesos MPI entre nodos.
Lı́nea 10: Número de grids (PxQ) de procesos a ejecutar.
Lı́nea 11: Valores de P
Lı́nea 12: Valores de Q
Lı́nea 13: Threshold
Lı́neas 14-21: Tipo de subdivisión en paneles de la matriz.
Lı́nea 22: Número de tipos de broadcast a ejecutar.
Lı́nea 23: Permite elegir diferentes patrones de comunicación de mensajes MPI.
Lı́nea 24: Profundidad lookahead.
Lı́nea 25: Valor de la profundidad.
Lı́nea 26: SWAP.
Lı́nea 27: Umbral de SWAP.
Lı́nea 28: Permite transponer o no la matriz L1.
Lı́nea 29: Permite transponer o no la matriz U.
Lı́nea 30: Equilibrado
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
57
Lı́nea 31: Alineamiento de memoria para doble precisión
Con la información conocida sobre los parámetros y una serie de pruebas empı́ricas
se ha optimizado el fichero de configuración para obtener los mejores resultados en
la medida de lo posible. A continuación veremos la justificación de los valores que
más impacto han tenido sobre el rendimiento de HPL.
Tamaño de problema. La documentación de HPL recomienda utilizar alrededor
de un 80 % de la memoria fı́sica disponible. En nuestras pruebas sobre un único nodo
a partir de 12K elementos (51 % del total de memoria) la mejora es inapreciable. En
multinodo el impacto del tamaño de problema es mucho mayor y si se recomiendo
ocupar el máximo (en nuestro caso 32K elementos, casi 8 GB).
Tamaño de bloque. Utilizar blocking aumenta el rendimiento debido a que se
explota la localidad espacial y temporal de datos. En las pruebas hemos obtenido
64 ya que se ajusta al tamaño de la caché L1 (32KB).
Factorización y recursividad de paneles Estos parámetros varı́an la manera
en que HPL resuelve el sistema de ecuaciones. No se ha podido analizar en detalle
por el coste y la complejidad del algoritmo. Lo que si se ha podido observar que
combinaciones de valores ofrecı́an los mejores resultados. Estos son: R2R2, C2C2 y
R2C2.
Alineamiento, equilibrado y transposición. En alineamiento debemos especificar 8, ya que es el tamaño de bytes de una palabra en doble precisión, activaremos
el equilibrado con valor 1 y habilitaremos la transposición de las matrices L1 y U
dejando el valor a 0. La transposición de matrices permite explotar la temporalidad
local de los accesos a memoria durante las operaciones entre matrices donde la segunda matriz se recorre por columnas.
Nota: HPCC utiliza el mismo tipo de fichero de configuración con algunas opciones
más que no hemos precisado describir. Únicamente tener en cuenta que el tamaño
de problema de los diferentes test dentro de HPCC se calcula en base al valor especificado en la lı́nea 6.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
58
Facultat d’Informàtica de Barcelona
Capı́tulo 5. Optimización de aplicaciones
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
59
Capı́tulo 6
Evaluación del clúster
6.1.
Benchmarking single node
Inicialmente, se han realizado una serie de pruebas para conocer la potencia de la
unidad básica de nuestro clúster, el nodo. Para evaluar el SoC Exynos 5 Octa se
han seleccionado el conjunto de microkernels descritos en el capı́tulo de análisis de
aplicaciones y HPL.
El conjuntos de pruebas que se llevará a cabo es el siguiente:
Primero, se ejecutará la versión OpenMP de los microkernels con 1, 2 y 4 threads
en simple y doble precisión con el propósito de evaluar la eficiencia paralela del SoC
en variedad de situaciones.
Segundo, se ejecutará el benchmark HPL con 1, 2 y 4 procesos MPI. Compararemos
la eficiencia computacional conseguida en HPL con la de los 9 primeros supercomputadores más MareNostrum del Top500. La eficiencia computacional se obtiene de la
relación entre GFLOPS obtenidos en HPL y pico teórico de GFLOPS del SoC.
Finalmente, de las mediciones de consumo eléctrico con un medidor de potencia,
se hace una comparación en este caso con los primeros 9 primeros supercomputadores más MareNostrum del ránking Green500.
Los benchmarks con peores resultados en escalabilidad indicarán los puntos débiles
(cuellos de botella) de nuestro SoC. Además podremos estudiar el comportamiento
frente a diferentes patrones de acceso a memoria.
6.1.1.
Metodologı́a
Los microkernels se ejecutan con el script Python subministrado con el paquete:
Benchmark.py. En él se pueden especificar parámetros para configurar la ejecución
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
60
Capı́tulo 6. Evaluación del clúster
de los diferentes test: volumen de datos, número de iteraciones, versiones, tipos de
datos (single, double), etc. Para conseguir muestras fiables se han especificado un
números de iteraciones suficiente para conseguir tiempos de ejecución serie superiores a los 40 segundos en cada benchmark.
Los resultados obtenidos se vuelcan en ficheros de texto; un fichero por cada versión
y microkernel.
dataType,numIterations,numThreads,n,totalTime,avgTime,stdDev,gflops,validated
float,25,1,8192,195.82830200,7.83313208,0.00576846,0.17134618,n/a
Figura 6.1: Ejemplo de fichero de resultados del microkernel N-Body OpenMP
En la figura 6.1.1 vemos un ejemplo de fichero CSV de resultados. En los resultados
se especifica los parámetros usados durante la ejecución, medidas de tiempo medias
y totales con su desviación estándar y la una medida de rendimiento (GFLOPS) en
base al tiempo de ejecución medio.
Los resultados de la ejecución de HPL se han obtenido con el set de parámetros
optimizado descrito en el capı́tulo anterior, y aparte del uso de ATLAS no se han
hecho más optimizaciones. El comando utilizado ha sido: $ > sudompirun − np <
1, 2, 4 > −hostf ile < HF SingleN ode > ./xhpl donde < 1, 2, 4 > corresponde al
número de procesos MPI para cada una de las 3 muestras y < HF SingleN ode >
es un fichero de Hosts MPI con una única lı́nea con la dirección de la tarjeta de
loopback.
La metodologı́a para la medición de consumo eléctrico y resultados está detallada en la sección del trabajo de hardware ??.
6.1.2.
Resultados
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
61
Figura 6.2: Speed Up con precisión de 32-bits.
Figura 6.3: Speed Up con precisión de 64-bits.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
62
Capı́tulo 6. Evaluación del clúster
Figura 6.4: Comparativa de la eficiencia paralela de simple y doble precisión con 4
threads .
Los resultados de escalabilidad vistos en las figuras 6.2 y 6.3 son bastante buenos.
En precisión simple, la eficiencia paralela con 4 threads ronda el 90 %+ excepto en
VecOP. Montecarlo demuestra que en caso de no compartir datos entre threads se
alcanza una eficiencia del 99 %. Sobre el detrimento de eficiencia de doble precisión
frente a simple observado en la figura 6.4, se debe a que cada procesador tiene más
tiempo ocupado el bus de memoria para traerse datos de 64 bits, y siendo la memoria un recurso compartido entre procesadores, implica que el resto de threads deben
esperar hasta que el bus esté disponible. Los benchmarks que hacen un uso importante del ancho de banda a memoria como VecOP y 3D stencil son los más afectados.
Como nota, sorprende la mejora de N-body en doble respecto a simple precisión,
harı́a falta estudiar en detalle que operaciones se realizan para obtener esos resultados.
HPL
En la figura 6.5 vemos la eficiencia computacional obtenida con 1, 2 y 4 procesos
MPI en un mismo SoC.
A partir del rendimiento pico de un núcleo Cortex-A15 @ 800MHz (1.6 GFLOPS)
calculamos el rendimiento pico del SoC, en total 6.4 GFLOPS.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
63
Figura 6.5: Rendimiento y efficiencia paralela con HPL (single node).
Con el resultado de ejecutar HPL con 4 procesos MPI en un mismo nodo 4,27 GF LOP S
(precisión doble) calculamos la eficiencia computacional.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
64
Capı́tulo 6. Evaluación del clúster
Ef f.comp. =
4,27
= 0,667187
6,4
(6.1)
Tomamos un 67 % de eficiencia. Veamos como de bueno es este resultado respecto a
máquinas del TOP 500.
En la figura 6.6 se aprecia como la eficiencia conseguida (linea horizontal) hasta
el momento entra en unos márgenes aceptables. A nuestro favor decir que los cálculos en HPL son de doble precisión, la operación en coma flotante tarda lo mismo
pero los accesos a memoria requieren más tiempo. En nuestra contra, los valores obtenidos no se ven afectados por el overhead introducido por la red de interconexión
para realizar el paso de mensajes. En la siguiente sección ’Evaluación multinodo’ se
verá el impacto que tiene el uso de la red.
Figura 6.6: Eficiencia respecto al PP de las primeras posiciones del top500.
Como nota, destacar que Supercomputadores como el Tiahne, Titan y Stampede
muestran peor eficiencia siendo 3 de los 4 supercomputadores, entre las 10 primeras
posiciones, que hacen uso de aceleradores (Xeon Phi y NVidia K20). Sabiendo que
hay una máquina con aceleradores que ofrece un 80 % de eficiencia como es el Piz
Daint, se entiende que se pueden desarrollar implementaciones de HPL que saquen
un mejor partido a estos componentes.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
65
Al final de la evaluación de rendimiento paralelo y de cálculo quedan varios puntos
claros. Primero, pese a disponer de unidad de coma flotante capaz de hacer operaciones de 64-bits, en las versiones de doble precisión existe una pérdida de rendimiento
relativa a la versión de simple precisión que va de un 3 a un 30 %. Segundo, la
escalabilidad del SoC a nivel de nodo es buena, en muchos de los benchmarks se
observa un >90 %. Por último, los valores obtenidos en DGEMM Single Precisión,
demuestran que el SoC Exynos 5 es capaz de ofrecer un rendimiento bueno del 80 %
respecto a su máximo teórico en aplicaciones reales.
Eficiencia energética
Hemos hecho mediciones de consumo energético con los nuestros dos test mejor optimizados, HPL y DGEMM precisión simple. Durante la ejecución de HPL con 4
threads hemos obtenido un consumo medio de 7.73W, mientras que en DGEMM-SP
observamos 6.59W.
Dividiendo el rendimiento obtenido en los anteriores apartados con el consumo nos da
como resultado una eficiencia energética de 552.2 MFLOPS/W en HPL, y 792.5 en
DGEMM-SP. En la figura 6.7 hemos indicado la supuesta posición que ocuparı́amos
en la tabla Green500, la linea horizontal marca nuestro récord (DGEMM-SP) conseguido en los test.
Teniendo en cuenta el estado del arte actual, y a simple vista, los resultados resultan
un tanto flojos. Sin embargo hay muchos factores jugando en contra como la baja
frecuencia de la CPU y el consumo de componentes como la tarjeta gráfica y de red
que podrı́an estar apagados.
Con esto damos por finalizado el estudio Single node, de nuestra máquina. Los
datos obtenidos en esta sección nos permiten establecer el valor de rendimiento base
a partir del cual estudiaremos la escalabilidad multinodo de la siguiente sección.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
66
Capı́tulo 6. Evaluación del clúster
Figura 6.7: Eficiencia energética comparada con las primeras posiciones de Green500.
6.2.
Benchmarking multi nodo
En esta sección se muestran los resultados obtenidos al evaluar el clúster al completo, es decir, hasta 24 procesadores en paralelo.
El propósito de estos test es obtener, ahora sı́, una medida realista del rendimiento
que ofrece la configuración que hemos montado. En cualquier clúster HPC la red
de comunicación entre nodos para acceder a la memoria distribuida es el nivel que
ofrece mayor latencia con diferencia, si a eso sumamos las bajas prestaciones que
ofrece el puerto de comunicaciones Ethernet presente en las placas Arndale Octa,
cabe anticipar una caı́da de rendimiento considerable respecto a los resultados del
apartado anterior.
Para comparar con los resultados anteriores se ejecutará HPL con hasta 24 procesadores. Esto nos permitirá evaluar dos cosas: la pérdida de eficiencia paralela al
introducir la red de interconexión y una idea del máximo rendimiento que podemos
conseguir con el clúster funcionando al máximo de sus capacidades.
Seguidamente, volveremos a evaluar la relación GFLOPS/W con la nueva medida de rendimiento obtenida con HPL y el consumo total del cluster.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
67
Por último mostraremos los resultados que obtenemos con HPCC.
6.2.1.
Metodologı́a
Empezando con HPL, introducimos varios cambios en los parámetros de ejecución.
Primero aumentamos el tamaño de problema a 20K elementos. Esto hace un tamaño
de problema de:
P roblemSize =
200002 × 8
= 3051,87M Bytes
220
(6.2)
Es necesario este incremento en el tamaño de problema para intentar disminuir en
la medida de lo posible el impacto de paso de mensajes. Con un mayor tamaño de
problema, cada procesador deberá realizar más cálculos antes propagar los resultados en la memoria compartida. El máximo tamaño de problema que soporta nuestro
clúster ronda los 32K elementos, pero por problemas de inestabilidad y sobrecalentamiento de las placas solo disponemos datos para hacer las gráficas de hasta 20K.
Ha sido necesario ajustar el tamaño del problema a medida que se aumentaba el
tamaño de problema para tratar de que sea proporcional.
El tipo de broadcast de mensajes, que hasta el momento no importaba, será de
tipo mixed ring. El grid de procesos que mejor resultados ofrece en las pruebas se
obtiene fijando P = 2 e incrementando Q = 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.
El fichero hostfile utilizado en este caso contiene las direcciones IP de cada una
de las placas en la red. Y se utiliza el mismo comando que en el apartado anterior,
pero ahora con el parámetro −np 24 para indicar al runtime de MPI que cree tantos
procesos como procesadores Cortex A-15. Se muestra a continuación el contenido
del hostfile usado para la evaluación multinodo.
administrador@127.0.0.1 slots=4
administrador@192.168.0.82 slots=4
administrador@192.168.0.83 slots=4
administrador@192.168.0.84 slots=4
administrador@192.168.0.85 slots=4
administrador@192.168.0.86 slots=4
Para HPCC hemos utilizado un fichero de configuración con parámetros similares, y
para ejecutar, el mismo fichero hostfile y un comando equivalente mpirun también
con 24 procesos MPI.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
68
Capı́tulo 6. Evaluación del clúster
6.2.2.
Resultados
HPL
Figura 6.8: Gráfica de speed up del cluster ejecutando HPL de 1 a 24 procesadores.
En la gráfica 6.8 se aprecia como HPL escala con un factor mucho menor que 1, siendo 1 el factor de escala lineal ideal. La deceleración de crecimiento que se observa en
el paso de Single Node (1-4 procesadores) a Multinode (4-24 procesadores) muestra
el impacto negativo de la red de interconexión en el rendimiento de la máquina. Por
tanto, si continuáramos añadiendo nodos en nuestro clúster, esperamos seguir perdiendo eficiencia paralela como se puede ver en la figura 6.9. En esta última figura
podemos ver que con 10 procesadores (3 nodos) se irrumpe por debajo del 50 % de
eficiencia, a partir de este punto ya se pueden considerar ’malos’ los resultados.
Como ya hemos dicho, debido a lo inestable del sistema y el tiempo disponible
para hacer las pruebas, no se ha podido obtener una muestra de datos muy grande,
pero en este caso, las suficiente para poder sacar conclusiones (que es al fin y al cabo
lo que buscamos) ya que las variaciones son muy acentuadas.
En cuanto al valor máximo de rendimiento se ha obtenido con un test de 32K
elementos que duró alrededor de 20 minutos, este test se ha repetido 3 veces. El
resultado medio fue de 14.38 GFLOPS una eficiencia computacional del 37 % resFacultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
69
Figura 6.9: Eficiencia paralela del clúster ejecutando HPL de 1 a 24 procesadores.
pecto al PP teórico de 38.4 GFLOPS. Ası́ mismo también se tomaron mediciones de
consumo durante las pruebas donde obtuvimos una media 62.58W, ofreciendo una
eficiencia energética de 229.78 MFLOPS/W. En el Green500 caerı́amos a la posición
317.
HPCC
Resumen de los resultados obtenidos en el benchmark HPCC con parámetro N =
20000 y 24 procesadores.
Hemos tomado los resultados del supercomputador Jaguar y hemos podido observar
valores de rendimiento reales más allá de la potencia de coma flotante.
Su red de interconexión tiene 15.98 µs de latencia, casi 20 veces menos que la nuestra
y su ancho de banda es de 1.52 GB/s en el peor caso, al menos 140 veces mejor.
Lo único que no parece estar como mı́nimo un orden de magnitud por detrás es el
ancho de banda de la memoria donde Jaguar puntúa 3.31 GB/s en su versión EP,
en este test nuestro SoC ofrece 1.48 GB/s [20].
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
70
Capı́tulo 6. Evaluación del clúster
Benchmark
MPIRandomAccess
StarRandomAccess
PTRANS WALL
PTRANS CPU
StarDGEMM
StarSTREAM (Scale)
SingleSTREAM (Scale)
MPIFFT
StarFFT
Net Latency ping-pong
Net Bandwidth ping-pong
Resultado
0.0004309 GUP/s
0.006904 GUP/s
15.59 s. @ 0.051 GB/s
2.34 s. @ 0.343 GB/s
1.23 GFLOP/s
1.48 GB/s
2.85 GB/s
0.11 GFLOP/s
0.22 GFLOP/s
315.68 µs
11.657 MB/s
Cuadro 6.1: Resumen de resultados de HPCC.
No es posible comparar directamente otros test como MPIRandomAcces o MPIFFT
ya que los resultados varian en base al número de nodos. Si podemos comparar StarRandomAccess donde Jaguar ofrece un poco menos del doble de ancho de banda.
StarFFT en este caso ha sido fuertemente optimizado y el rendimiento es hasta 50
veces mejor que el nuestro.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
71
Capı́tulo 7
Sostenibilidad
7.1.
Sostenibilidad
Los aspectos sobre la sostenibilidad del proyecto se tratarán en tres categorı́as distintas: viabilidad económica, impacto social e impacto ambiental.
7.1.1.
Viabilidad económica
La viabilidad económica de un supercomputador que obtenga un buen rendimiento
con un consumo muy reducido está prácticamente asegurada. La necesidad que existe
actualmente de procesar grandes cantidades de datos hace imprescindible disponer
de máquinas de este tipo, sin embargo, su alto consumo, añadido a la gran inversión
inicial necesaria, hace que el mantenimiento de dichas infraestructuras resulte un
esfuerzo muy costoso.
Un clúster con buen rendimiento, no solo tiene salida en el sector de HPC, actualmente algunos de los supercomputadores más potentes del mundo se usan para
dar otro tipo de servicios, como granjas de máquinas virtuales, o servidores web muy
potentes, la ventaja que supone reducir el consumo en este tipo de máquinas puede
interesar a estos sectores también.
7.1.2.
Impacto Social
A pesar de que la sociedad no percibe de manera directa los beneficios derivados
del uso de la supercomputación. Si que de manera indirecta tiene un impacto muy
importante en el dı́a a dı́a de cualquier sociedad moderna.
En general, los usos de los computadores actuales para HPC tienen un impacto positivo, indirecto en la sociedad. Son las máquinas que ayudan a liderar proyectos
de investigación importantes, como en medicina, mediante simulaciones sobre enfermedades o de fármacos. La gran capacidad de cálculo de estos dispositivos permite
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
72
Capı́tulo 7. Sostenibilidad
acortar tiempos de investigación y ahorrar recursos mediante aproximaciones de los
modelos reales. También pueden ayudar en otros campos de investigación, como fı́sica o la quı́mica, por ejemplo: la simulación de fluidos. Todos estos resultados ayudan
a la sociedad a hacer progresos.
A parte de investigación y desarrollo, los supercomputadores tienen mucha utilidad
en proveer cálculos para ciertos servicios que necesita una sociedad, como por ejemplo la aproximación del clima, que es fundamental para sectores como el transporte.
Otro campo al cual proveer potencia de cálculo mediante un supercomputador, es en
la prospección de recursos naturales, como por ejemplo el petróleo, donde el uso de
algoritmos para detectar dónde se encuentran los recursos naturales puede ser vital
para ahorrar los cuantiosos costes que requieren hacer exploraciones de este tipo. [17]
7.1.3.
Impacto Ambiental
Al ser un clúster basado en procesadores de bajo consumo con uno de los objetivos principales fijado en la eficiencia energética, no solo tiene un impacto ambiental
relativamente bajo, sino que pretende mejorar el paradigma de la sostenibilidad en
HPC, debido a la regla impuesta de consumir menos de 3.000 W . Por ejemplo,
si basada en esta tecnologı́a se desarrollara un clúster con buen rendimiento por
W consumido, un grupo de investigación con necesidad de un clúster HPC podrı́a
montar una réplica de éste con el ahorro energético que supondrı́a.
Además, en Cataluña el consumo de energı́a primaria en cuanto a renovables es
muy bajo, un 4,1 %. Esto implica que más del 90 % de la energı́a primaria que se
consume en Cataluña sale de energı́a no renovable como el carbón, petróleo... Esto
es un punto más a favor para tener en cuenta el consumo de un clúster de supercomputación como este.[3]
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
73
Capı́tulo 8
Conclusiones individuales
8.1.
Evaluación global
Tras finalizar el trabajo, señalar los puntos más importantes que hemos aprendido
a nivel de aplicaciones.
El SoC Exynos 5420, efectivamente, es capaz de ejecutar las aplicaciones del
estado del arte HPC actual y funcionar como un clúster.
Todas las aplicaciones del estado del arte trabajan en doble precisión. Los test
con microkernels demuestran que con un procesador de 32-bit partimos en
desventaja.
Los ficheros de configuración de HPL y HPCC, son útiles para optimizar en
la medida de lo posible las ejecuciones, pero si se quiere solventar los fuertes
problemas de escalabilidad que aparecen en los resultados debemos pasar al
siguiente nivel, usar herramientas de análisis.
La red de interconexión tiene un impacto negativo enorme en el rendimiento
y la escalabilidad de las aplicaciones.
El rendimiento de las aplicaciones es muy sensible a las tareas que hay ejecutándose en background del sistema operativo.
Nuestro clúster y las aplicaciones out-of-the-box no obtiene un rendimiento
como para ser competitivo en una competición como el SCC, pero hay mucho
margen para optimizar.
En muchos casos, no podemos evitar los accesos a memoria entre nodos, pero si podemos minimizarlos: optimizar el código de la aplicación para hacer
blocking, ajustar el tamaño de problema al máximo de la memoria fı́sica, etc.
Es importante disponer de un buen surtido de librerı́as con funciones optimizadas para HPC. Las mejoras de rendimiento que ofrecen son muy grandes y
son relativamente poco costosas de incluir en el sistema.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
74
Capı́tulo 8. Conclusiones individuales
Es importante estudiar los resultados de los benchmarks cuidadosamente, sin
lanzarse a conclusiones precipitadas. Un mal resultado puede tener su causa
en muchos factores.
Los benchmarks son una manera simple de detectar cuellos de botella. Son
herramientas clave para la mejora del trabajo de todo el equipo.
8.2.
Trabajo futuro
De cara al trabajo futuro, lo primero serı́a abordar el uso de herramientas de análisis que en este trabajo solo han podido mostrarse de manera teórica por problemas
técnicos. Instalar correctamente y ganar experiencia con ellas, asunto de gran importancia de cara a optimizar aplicaciones mediante análisis.
En los futuros análisis, se deberı́a dar prioridad a estudiar el rendimiento de la
red para ası́ poder ofrecer feedback al resto del equipo y ası́ poder tomar mejores
decisiones.
Por otro lado serı́a interesante instalar y configurar individualmente los benchmarks dentro de HPCC para poder lanzar únicamente los test que nos interesan
con parámetros independientes. Esto permitirı́a al grupo trabajar mejor y más rápido.
En el momento en el que esté disponible el soporte para OpenCL, se deberı́an
obtener o desarrollar versiones de las aplicaciones para la tarjeta gráfica. Esto se
extiende a otros recursos hardware de la máquina que puedan estar en desuso como
las unidades vectoriales.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
75
Capı́tulo 9
Conclusiones de equipo
9.1.
Conclusiones de cara a la competición
En el estado actual de nuestro proyecto resulta inviable participar en la competición por varios motivos.
No reboot - Always Up. La normativa de la competición establece que las máquinas no se pueden reiniciar ni apagar durante toda la competición (excepto por motivos de seguridad). Nuestro sistema es todavı́a inestable, hasta el punto que resulta
improbable sobrevivir cinco dı́as sin reiniciar o que alguno de los nodos falle, de
hecho serı́a improbable aguantar uno. Además se prevé tener que instalar nuevo
software e incluso alguna librerı́a dado que hay un set de aplicaciones a ejecutar que
se darán a conocer durante la competición. Sin duda, este serı́a un objetivo prioritario y una manera de abordar este problema serı́a abandonar el uso de tarjetas SD
hacı́a un sistema de inicio y ficheros en red mediante NFS.
Rendimiento. El rendimiento no es bueno, al menos no suficiente. En ediciones
pasadas de la competición se alcanzaron los 8.5 TFLOPS en HPL que, en el peor
caso, suponen 2.8 GFLOPS/W, 12 veces más que nuestros 0.229 GFLOPS/W actuales. No serı́a realista esperar asistir por primera vez con una máquina preparada
para competir por los primeros puestos, pero si que podamos competir por no quedar últimos. Consideramos que una primera meta serı́a desarrollar un prototipo con
unas previsiones de rendimiento mı́nimas de 6 TFLOPS en HPL para plantear el
seriamente el asistir.
Preparación, tanto de los componentes del equipo como del clúster. Aún teniendo
la formación adecuada, tomar decisiones de diseño, montar una máquina y prepararla a nivel de software de sistema y aplicaciones requiere mucho tiempo. Contar
que además el equipo deberı́a ser de seis personas, por un lado agiliza el desarrollo
pero por otro lado requiere mayor nivel de coordinación. Además entendemos que,
para formar un equipo estable, se requerirı́a una persona vinculada a la FIB con
conocimiento de primera mano del estado del arte HPC. Asumirı́a el rol de director
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
76
Capı́tulo 9. Conclusiones de equipo
equipo y además de coordinar deberı́a garantizar la continuidad de la representación
de la facultad en sucesivas ediciones.
Recursos. Este proyecto ha podido llevarse a cabo únicamente con recursos cedidos por el departamento de AC y por el BSC. Creemos que el desarrollo de un
prototipo competitivo a pequeña escala podrı́a hacerse con un coste no mucho mayor, pero en el caso de asistir a la competición, harı́a falta un desembolso de dinero
considerable. Es en este punto en el que entran en juego los sponsors. Todos los
equipos que asisten a la competición están esponsorizados por grandes fabricantes
de hardware que aprovechan la competición a modo de escaparate. Nuestro plan
serı́a conseguir uno o varios sponsors que financiaran como mı́nimo, el coste total de
los componentes del clúster y el desplazamiento y alojamiento durante el evento.
9.2.
Trabajo futuro
Este trabajo, pese a demostrar no estar preparados para la competición, ha servido
para sentar las bases a partir de las cuales poder seguir trabajando y mejorar los
puntos débiles de nuestro prototipo.
De cara al futuro, la primera acción a realizar serı́a valorar todas las opciones y
decidir si continuamos desarrollando un clúster basado en tecnologı́a móvil, si se
decide abandonar en favor de tecnologı́a HPC más habitual (p.ej: Intel Xeon y aceleradores Nvidia) o valorar otras opciones menos estudiadas y no mencionadas como
por ejemplo: procesadores móviles con aceleradores externos Nvidia.
Personalmente creemos que en el ámbito de procesadores móviles queda mucho trabajo por hacer y que lo mejor está por venir. En esta lı́nea, por tanto, tenemos
mucho trabajo futuro sobre la mesa. A corto plazo empezarı́amos por abordar el
problema de la red de interconexión de nodos, y a la vez, tratarı́amos de hacer un
mejor uso del hardware disponible: aceleradores, ocho núcleos y máxima frecuencia
de procesador entre otros. A medio plazo se buscarı́a obtener nuevas placas de desarrollo con arquitectura ARMv8 de 64-bits y profundizar en el análisis y optimización
profunda de las aplicaciones.
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
77
Agradecimientos
En este espacio quiero aprovechar para dar las gracias a aquellas personas que han
colaborado de una manera u otra con este proyecto.
A Álex Ramı́rez, por darnos la oportunidad y las ideas para desarrollar el proyecto.
A Nikola Rajovic, por el trato cordial y proporcionar información y material para usar el medidor de potencia Yokogawa y los benchmarks de Montblanc.
A Agustı́n Fernández que como director de este trabajo ha ofrecido soporte y seguimiento durante todo el trabajo.
Al departamento de Arquitectura de Computadores y el BSC por la cesión de todo
el material y recursos necesarios para realizar el montaje del clúster.
A Dani y Uri por compartir conocimiento y experiencia que ha resultado de gran
utilidad.
A Enric Agüera por su curso acelerado de LateX.
A mis padres y mi hermano por su apoyo incondicional.
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
78
Facultat d’Informàtica de Barcelona
Capı́tulo 9. Conclusiones de equipo
Constantino Gómez Crespo
Diseño y evaluación de un clúster HPC: aplicaciones
79
Bibliografı́a
[1] J. Dongarra A. Cleary A. Petitet, R. C. Whaley. Hpl - a portable implementation of the high-performance linpack benchmark for distributed-memory
computers, 2008. [Online; accedido 30-Abril-2014]. 42
[2] HPC Advisory Council. Hpc advisory council - isc’14 student cluster competition - home, 2014. [Online; accedido 10-Abril-2014]. 20
[3] Generalitat de Catalunya. Balanç energètic de catalunya - institut català
d’energia, 2009. [Online; accedido 2-Junio-2014]. 72
[4] J. J. Dongarra and P. Luszczek. Hpc challenge: Design, history, and implementation highlights. 45, 46, 47
[5] J. J. Dongarra and P. Luszczek. Introduction to the hpcchallenge benchmark
suite. December 2004. 43, 47
[6] D. Jiménez E. Ayguadé. Parallelism, analysis of parallel applications. 2012. 51
[7] hpcc.org. The hpcchallenge award competition, 2014. [Online; accedido 5-Mayo2014]. 43
[8] hpcc.org. Randomaccess rules, 2014. [Online; accedido 5-Mayo-2014]. 46
[9] P. Luszczek J. J. Dongarra and A. Petitet. The linpack benchmark: Past,
present, and future. August 2003. 42
[10] mabraham. About gromacs – gromacs, 2013. [Online; accedido 17-Mayo-2014].
48
[11] A. Rico et al. N. Rajovic. Experiences with mobile processors for energy efficient
hpc. March 2013. 48
[12] P. Carpenter et al. N. Rajovic. Supercomputing with commodity cpus: Are
mobile socs ready for hpc. November 2013. 48
[13] University of Tenesse. High performance linpack benchmark poster at sc2010,
2010. [Online; accedido 30-Abril-2014]. 41
[14] openfoam.org. Features of openfoam, 2014. [Online; accedido 20-Mayo-2014].
50
Constantino Gómez Crespo
Facultat d’Informàtica de Barcelona
80
Bibliografı́a
[15] quantum espresso.org. Manifesto – quantumespresso, 2014. [Online; accedido
20-Mayo-2014]. 50
[16] Nikola Rajovic, Alejandro Rico, Nikola Puzovic, Chris Adeniyi-Jones,
and Alex Ramirez.
Tibidabo: Making the case for an arm-based
{HPC} system.
Future Generation Computer Systems, 2013.
DOI:
http://dx.doi.org/10.1016/j.future.2013.07.013. 48
[17] SINC. La supercomputación ayuda a repsol a descubrir nuevos yacimientos,
2013. [Online; accedido 2-Junio-2014]. 72
[18] V. Springel. Cosmological simulations with gadget, 2005. [Online; accedido
20-Mayo-2014]. 50
[19] Stanford University. The software — folding@home, 2014. [Online; accedido
10-Junio-2014]. 48
[20] university of tennesse. Hpcc record: Cray xt5 196608 amd opteron 2.6 ghz,
2009. [Online; accedido 15-Junio-2014]. 69
[21] Wikipedia. Folding@home — Wikipedia, the free encyclopedia, 2014. [Online;
accedido 10-Junio-2014]. 48
[22] Wikipedia. Linpack — Wikipedia, the free encyclopedia, 2014. [Online; accedido
10-Junio-2014]. 41
[23] Wikipedia. Linpack benchmarks — Wikipedia, the free encyclopedia, 2014.
[Online; accedido 30-Abril-2014]. 41
Facultat d’Informàtica de Barcelona
Constantino Gómez Crespo