-
Universidad de Las Palmas de Gran Canaria
Estudio de utilización efectiva deprocesadores vectoriales
Proyecto de Fin de Carrera
Ingenieŕıa en Informática
Laura Autón Garćıa
Tutores:Francisca Quintana Domı́nguezRoger Espasa Sans
Las Palmas de Gran Canaria, 9 de julio de 2014
-
Agradecimientos
Quiero agradecer a Francisca Quintana y a Roger Espasa, mis
tutores de proyecto, el habermebrindado la oportunidad de
adentrarme en una experiencia que bien podŕıa ser el sueño de
cual-quier futuro ingeniero informático cuando avista cada vez
más cerca la meta de su esfuerzo. Esteviaje no solo ha dado como
resultado el presente trabajo, sino también la satisfacción
profesio-nal de haber trabajado en Intel, empresa puntera en el
ámbito de la computación, y personal dehaber trabajado con
extraordinarios ingenieros a la vez que fantásticas personas
durante todo elproceso. Entre ellos, quiero agradecer especialmente
a Manel Fernández por la enorme pacienciay dedicación con las que
consiguió guiarme cuando me desviaba del camino, y a Jesús
Sánchezporque su buen humor y positivismo amenizaba todas las
tormentas de ideas, por muy oscurasque pudieran divisarse a lo
lejos.
Del mismo modo, quiero agradecer muy especialmente a Susana y
Delf́ın, por haber sidomi familia durante mi estancia en Canarias.
A mis padres, Maŕıa y Cándido por haber sabidoapoyarme desde la
distancia con sus palabras al otro lado del teléfono. Y a Raúl,
mi gran compañeroen este viaje, porque ha sido la única persona
de este mundo que realmente ha conocido mis másprofundas
inquietudes, y que ha sabido iluminarme el camino y cederme las
mangas sobre las quederramar mis lágrimas.
i
-
Índice de figuras
2.1. SISD . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 52.2. SIMD . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52.3. MISD . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 52.4. MIMD . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.5.
Intel R© Xeon PhiTM . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 92.6. Esquema general . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 92.7.
Microarquitectura . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 102.8. Vector Processing Unit . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 102.9.
Interconexion . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 112.10. Directorio de etiquetas . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.11.
Controladores de memoria . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 12
4.1. Arquitectura software de Pin . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 22
5.1. Diagrama de funcionamiento CMP$im . . . . . . . . . . . . .
. . . . . . . . . . . . 315.2. Simulación en modo buffer . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 325.3.
Simulación en modo instrucción a instrucción . . . . . . . . . .
. . . . . . . . . . . 335.4. Ejemplo de bloque básico . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 345.5. Proceso
de descubrimiento de bloques . . . . . . . . . . . . . . . . . . .
. . . . . . 345.6. Punteros a objetos cache . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 36
6.1. Índice de vectorización de las aplicaciones de Polyhedron
. . . . . . . . . . . . . . . 406.2. Razones para no vectorizar
bucles en Polyhedron . . . . . . . . . . . . . . . . . . . 416.3.
Índice de vectorización de las aplicaciones de Mantevo 1.0 . . .
. . . . . . . . . . . 426.4. Razones para no vectorizar bucles en
Mantevo 1.0 . . . . . . . . . . . . . . . . . . 436.5. Índice de
vectorización de las aplicaciones de Sequoia . . . . . . . . . . .
. . . . . . 446.6. Razones para no vectorizar bucles en Sequoia . .
. . . . . . . . . . . . . . . . . . . 446.7. Índice de
vectorización de las aplicaciones de NPB . . . . . . . . . . . . .
. . . . . 456.8. Razones para no vectorizar bucles en NPB . . . . .
. . . . . . . . . . . . . . . . . . 466.9. Índice de
vectorización de las aplicaciones de SPEC fp . . . . . . . . . . .
. . . . . 476.10. Razones para no vectorizar bucles en SPEC fp . .
. . . . . . . . . . . . . . . . . . 48
7.1. Pipeline dentro de CMP$im . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 507.2. Pipeline del bloque de s171 . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.3.
Localización del simulador de pipeline en CMP$im . . . . . . . . .
. . . . . . . . . 567.4. Idea para la implementación de KNC . . .
. . . . . . . . . . . . . . . . . . . . . . . 567.5. Instrucción
que toca dos ĺıneas . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 587.6. Bloques con ningún y un corte . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 637.7. Bloques con 2 cortes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 64
8.1. Versión vectorizada vs no vectorizada de Polyhedron . . .
. . . . . . . . . . . . . . 668.2. Ciclos desglosados de las
aplicaciones de Polyhedron . . . . . . . . . . . . . . . . . 678.3.
Versión vectorizada vs no vectorizada de Mantevo . . . . . . . . .
. . . . . . . . . 698.4. Ciclos desglosados de las aplicaciones de
Mantevo . . . . . . . . . . . . . . . . . . . 698.5. Versión
vectorizada vs no vectorizada de Sequoia . . . . . . . . . . . . .
. . . . . . 70
iii
-
iv ÍNDICE DE FIGURAS
8.6. Ciclos desglosados de las aplicaciones de Sequoia . . . . .
. . . . . . . . . . . . . . 708.7. Versión vectorizada vs no
vectorizada de NPB . . . . . . . . . . . . . . . . . . . . . 718.8.
Ciclos desglosados de las aplicaciones de NPB . . . . . . . . . . .
. . . . . . . . . . 728.9. Versión vectorizada vs no vectorizada
de SPEC fp . . . . . . . . . . . . . . . . . . 738.10. Ciclos
desglosados de las aplicaciones de SPEC fp 2006 . . . . . . . . . .
. . . . . . 738.11. Comparación entre las versiones :nodes y do de
gas dyn . . . . . . . . . . . . . . . 848.12. Resultado de doblar
la UL2 de 1024Kb a 2048Kb . . . . . . . . . . . . . . . . . . .
978.13. Mejora de SPEC fp/433.milc al doblar la L2 . . . . . . . .
. . . . . . . . . . . . . . 988.14. Consecuencia posible por
aumento de aciertos en L2 . . . . . . . . . . . . . . . . . 998.15.
Resultado de doblar las ĺıneas de DTLB2 de 256 a 512 . . . . . . .
. . . . . . . . . 1008.16. Mejora de IS de NPB al doblar la TLB . .
. . . . . . . . . . . . . . . . . . . . . . . 100
-
Índice de tablas
4.1. Knobs soportados por Intel R© ICC . . . . . . . . . . . . .
. . . . . . . . . . . . . . 28
6.1. Desglose de instrucciones de las aplicaciones de Polyhedron
. . . . . . . . . . . . . 406.2. Desglose de instrucciones de las
aplicaciones de Mantevo . . . . . . . . . . . . . . . 426.3.
Desglose de instrucciones de las aplicaciones de Sequoia . . . . .
. . . . . . . . . . 436.4. Desglose de instrucciones de las
aplicaciones de NPB . . . . . . . . . . . . . . . . . 456.5.
Desglose de instrucciones de las aplicaciones de SPEC FP . . . . .
. . . . . . . . . 47
7.1. Latencias de memoria y de instrucción (load-op) . . . . .
. . . . . . . . . . . . . . 51
8.1. Bloques 1 y 2 de la lista de bloques básicos más
ejecutados en Fatigue, Polyhedron 758.2. Bloque 3 de la lista de
bloques básicos más ejecutados en Fatigue, Polyhedron . . .
768.3. Bloques 1, 2, 4 y 5 de la lista de bloques básicos más
ejecutados en Induct, Polyhedron 778.4. Bloques 1 y 2 más
ejecutados de Aermod, Polyhedron . . . . . . . . . . . . . . . .
798.5. Bloques 3, 5 y 10 más ejecutados de Aermod, Polyhedron . .
. . . . . . . . . . . . 808.6. Bloques 7 y 9 más ejecutados de
Aermod, Polyhedron . . . . . . . . . . . . . . . . 808.7. Bloque 8
más ejecutado de Aermod, Polyhedron . . . . . . . . . . . . . . .
. . . . 828.8. Desglose de instrucciones de las versiones escalar y
vectorial de Gas dyn, Polyhedron 828.9. Bloques 1 y 3 más
ejecutados de Gas dyn, Polyhedron . . . . . . . . . . . . . . . .
838.10. Bloques 1, 2, 3 y 4 más ejecutados de SPhotmk, Sequoia . .
. . . . . . . . . . . . . 888.11. Bloque 1 de los más ejecutados
de BT, NPB . . . . . . . . . . . . . . . . . . . . . . 908.12.
Bloques 1 y 2 de los más ejecutados de LU, NPB . . . . . . . . . .
. . . . . . . . . 918.13. Bloques 1 y 2 de los más ejecutados de
Povray, SPEC FP . . . . . . . . . . . . . . 948.14. Aplicaciones
con una mejora inferior al 1 % . . . . . . . . . . . . . . . . . .
. . . . 97
A.1. Intel R© ICC Specific Pragmas . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 107
B.1. Intel R© ICC Supported Pragmas . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 111
C.1. Intel R© Fotran Directives . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 115
D.1. Mensajes del compilador . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 117
v
-
Índice general
Agradecimientos I
Lista de figuras VIII
Lista de tablas VIII
1. Introducción 11.1. Objetivos . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Estado del arte 32.1. Taxonomı́a de Flynn . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 42.2.
Vectorización . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 5
2.2.1. SIMD . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 52.3. Intel R© Xeon PhiTM Coprocessor . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Microarquitectura . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 92.4. Intel R© Advanced Vector Extensions .
. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1. Intel R© Advanced Vector Extensions 1 . . . . . . . . . .
. . . . . . . . . . . 132.4.2. Intel R© Advanced Vector Extensions
2 . . . . . . . . . . . . . . . . . . . . . 132.4.3. Intel R©
Advanced Vector Extensions 512 . . . . . . . . . . . . . . . . . .
. . 13
3. Metodoloǵıa 153.1. Plan de trabajo . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Herramientas 194.1. Pin . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1. Pintools . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 194.1.2. Arquitectura software . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. CMP$im . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 224.3. Benchmarks . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.3.1. Polyhedron Fortran Benchmarks . . . . . . . . . . . . . .
. . . . . . . . . . 244.3.2. Mantevo 1.0 . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 254.3.3. ASC Sequoia
Benchmark Codes . . . . . . . . . . . . . . . . . . . . . . . . .
254.3.4. NAS Parallel Benchmarks . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 254.3.5. SPEC CPU 2006 . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 26
4.4. Compiladores . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 274.4.1. ICC . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.2.
IFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . 28
4.5. Pragmas . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 294.6. Herramientas internas . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5. Arquitectura del Simulador 315.1. Flujo de ejecución . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
315.2. Estructuras y clases . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 335.3. Parámetros de ejecución . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
vii
-
viii ÍNDICE GENERAL
6. Caracterización de benchmarks 396.1. Polyhedron . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
396.2. Mantevo 1.0 . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 416.3. Sequoia . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
426.4. NPB . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 436.5. SPEC FP . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
7. Adaptación del Simulador 497.1. Pipeline . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
497.2. Detección de instrucciones y registros . . . . . . . . . .
. . . . . . . . . . . . . . . 53
7.2.1. Instrucciones . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 537.2.2. Registros . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 547.2.3.
Latencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 54
7.3. Nuevas estructuras y clases . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 557.4. Estad́ısticas . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
627.5. Invocación activando la funcionalidad vectorial . . . . . .
. . . . . . . . . . . . . . 64
8. Estudio experimental 658.1. Resultados . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1.1. Polyhedron . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 658.1.2. Mantevo . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 688.1.3.
Sequoia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 708.1.4. NPB . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 718.1.5. SPEC fp . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
8.2. Diagnóstico Software . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 748.2.1. Polyhedron . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 758.2.2.
Mantevo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 848.2.3. Sequoia . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 868.2.4. NPB . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
898.2.5. SPEC fp . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 92
8.3. Diagnóstico Hardware . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 968.3.1. Incremento de UL2 . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 978.3.2.
Incremento de TLB . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 99
9. Conclusiones 1019.1. Trabajo Futuro . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 102
A. Intel R© ICC Specific Pragmas 105
B. Intel R© ICC Supported Pragmas 109
C. Intel R© Fortran Directives 113
D. Mensajes del compilador 117
-
Caṕıtulo 1
Introducción
Echando una profunda mirada al pasado para recorrer toda la
historia de la informática, desdedonde venimos, en qué punto nos
encontramos y a dónde vamos, nos damos cuenta del gran esfuerzoque
ha hecho y sigue haciendo el ser humano para no solo automatizar
tareas, sino también paraque éstas se hagan lo más rápido
posible. Y es que, ya en su momento, para realizar
cálculosbaĺısticos de gran utilidad en posibles contiendas, se
incrementaba el número de personas querealizaban una tarea. Al
segmentar el trabajo se consegúıa realizar la tarea en menos
tiempo de loque lo conseguiŕıa una sola. A estas personas se las
denominaba antiguamente computers[Bar08],nombre que más tarde se
adoptó para las máquinas que sustituyeron su trabajo.
Desde entonces, la capacidad de cómputo de las máquinas ha ido
evolucionado enormementegracias a, por ejemplo, la cantidad de
transistores que fuimos capaces de insertar dentro de unaonza de
silicio y que bien supo pronosticar Gordon Moore, cuya afirmación
se bautizo como Leyde Moore. Cuando las limitaciones f́ısicas se
convirtieron en un problema, empezamos a introducirmás núcleos en
un mismo procesador: primero dos, luego cuatro... Está claro que,
sean los motivosque sean los que impulsen al ser humano a seguir
escudriñando mejoras en cualquier tipo deartefacto, mecanismo o
sistema que tenga entre manos, y sobre el que haya trabajado
desdetiempos inmemoriales, el mundo, inexorablemente, se sigue
moviendo. Y es en ese mundo enconstante cambio y movimiento, donde
acaban por surgir ideas como aquella sobre la que se haconstruido
el trabajo que se presenta: la vectorización.
Hoy en d́ıa, una importante muestra de procesadores disponibles
en el mercado disponen deunidades de cómputo, denominadas
vectoriales, que permiten la explotación de este concepto. Yes que
la vectorización explota un caso particular de paralelismo cuyo
objetivo consiste en realizarla misma operación, en vez de sobre
un único dato como veńıa siendo hasta ahora, sobre la
mayorcantidad de datos contenidos en un vector que le sea posible.
Por ello, se denomina DLP (DataLevel Parallelism) o Paralelismo de
datos. Algunos de estos procesadores, por ejemplo, son los deIntel
R© basados en la arquitectura Sandy Bridge que, con el objetivo de
permitir la explotación delparalelismo de datos, incluyen
extensiones AVX (Advanced Vector Extensions) sobre el repertoriode
instrucciones x86. Sin embargo, esta obra de ingenieŕıa no es
suficiente por śı sola. Es necesarioun engranaje más, y que no es
otro que un compilador especialmente construido para máquinascomo
estas, que sea capaz de extraer el mayor paralelismo de datos
posible de una aplicación.
Pese a que todos los elementos mencionados conforman la receta
perfecta para sacar el mayorrendimiento posible a aplicaciones que
requieren de una importante capacidad de cómputo, nosiempre se
obtienen los resultados esperados. Las razones pueden residir tanto
en el software comoen el hardware. Puede que la aplicación no
experimente las mejoras esperadas después de servectorizada. Es
posible que el compilador no sea capaz por śı mismo de encontrar
potencialessecciones de código vectorizables debido a
ambigüedades en el acceso a los datos. O bien, podŕıa
1
-
2 CAPÍTULO 1. INTRODUCCIÓN
ser que la memoria esté suponiendo un cuello de botella a la
hora de recuperar los datos sobre losque operar.
Basándonos pues en la realidad descrita, se propuso la
realización del trabajo que se detallaen este documento, con el
objetivo fundamental de determinar el grado de utilización
efectivade la unidad vectorial de un procesador. Se realizaŕıa
entonces, para aquellos casos donde el usofuera menor del esperado,
un diagnóstico del problema que permitiera lograr una mejora en
elrendimiento de la aplicación.
1.1. Objetivos
El objetivo principal de este Proyecto Final de Carrera,
consiste en determinar el grado deutilización efectiva de la
unidad vectorial de un procesador. Para lograr la consecución del
mismo,se proponen los siguientes objetivos parciales:
Analizar y clasificar un conjunto de aplicaciones numéricas en
función del grado de vectori-zación sobre un compilador
determinado.
Determinar las causas del bajo grado de vectorización, a partir
de la simulación de lasaplicaciones según el funcionamiento de un
producto existente que hace uso de la unidadvectorial. Las posibles
causas serán las siguientes:
• Problemática en el algoritmo base de la aplicación debido a
dependencias en el código.• Problemática en los criterios
seguidos a la hora de escribir el código fuente.• Incapacidad del
compilador de detectar que el código es vectorizable.• Problemas
en la microarquitectura.
Proponer cambios hardware/software que faciliten el uso efectivo
de la unidad vectorial.
-
Caṕıtulo 2
Estado del arte
La computación paralela es una forma de cómputo consistente en
paralelizar la mayor cantidadde tareas posible con el objetivo de
reducir el coste de cómputo de un programa. Tradicionalmentese
utilizaba otro paradigma: la computación serie. Con ella las
instrucciones se ejecutaban unatras otra en la Unidad Central de
Procesamiento (CPU). La utilización de este paradigma produceque,
a medida que se incrementa la frecuencia de funcionamiento de la
máquina, se disminiuya eltiempo que tardan en ejecutarse los
programas[HP02]. El aumento de la frecuencia, que tuvo suapogeo
durante las dos últimas décadas del siglo XX y principios del
XXI, no pod́ıa ser infinito,ya que es directamente proporcional al
aumento de la enerǵıa consumida por el procesador y, porende, a la
generación de calor. Por este motivo, pese a que la computación
paralela se empezó ausar principalmente en el área de la
computación de altas prestaciones, este ĺımite en el aumentode la
frecuencia propició que desde la ultima década, el paradigma
principal en arquitectura decomputadores sea la computación
paralela.[Bar07]
Existen diferentes fuentes de paralelismo disponibles para sacar
partido a la computaciónparalela. Estas son: Paralelismo de
Instrucciones (ILP), Paralelismo de Datos (DLP) y Paralelismode
Tareas (TLP)[Dı́06]:
ILP: consiste en ejecutar el mayor número de instrucciones
posibles en paralelo sin que elloafecte al correcto flujo del
programa. Como ejemplos tenemos las arquitecturas superescalaresy
VLIW, del inglés Very Long Instruction Word:
• Superescalares: capaces de introducir en el pipeline de
ejecución una o más instruc-ciones por ciclo, de manera que se
pueden estar ejecutando paralelamente varias en unmismo ciclo.
• VLIW: la arquitectura permite empaquetar varias instrucciones
independientes que seejecutarán simultáneamente.
Con el objetivo de explotar al máximo esta fuente de
paralelismo, existen diferentes técnicasque se podŕıan clasificar
en técnicas de planificación estática y dinámica[Dı́06].
• Técnicas de planificación estática: trabajan sobre el
código de la aplicación paraconseguir eliminar todos los
obstáculos que impiden que las instrucciones se ejecutenlo antes
posible: desenrollamiento de bucles, reordenamiento de
instrucciones...
• Técnicas de planificación dinámica: se aplican sobre el
diseño del hardware paraque tengan lugar en tiempo de ejecución:
Ejecución Fuera de Orden (OOO).
DLP: consiste en la realización de la misma operación
simultáneamente sobre un conjuntode datos. Para explotar esta
técnica de paralelismo, es necesario que el programa tenga
3
-
4 CAPÍTULO 2. ESTADO DEL ARTE
secciones de código que se puedan adaptar a la aplicación de
este concepto. Además, laarquitectura tiene que proveer de
instrucciones especiales, denominadas SIMD, del inglesSimple
Instruction Multiple Data, y de recursos suficientes, como por
ejemplo los registrosvectoriales, los cuales puedan contener más
de un dato. La estructura de ejecución porantonomasia sobre la que
se pone en práctica este mecanismo, es el bucle. Las estructurasde
datos análogas son los vectores y matrices.
TLP: el concepto radica en la descomposición de la ejecución
del programa en diferentestrazas con instrucciones independientes
para ejecutarlas de forma concurrente. Un ejemplo esla Tecnoloǵıa
Multihilos, SMT, del inglés Simultaneous MultiThreading. Consiste
en ejecutarinstrucciones de diferentes hilos independientes en el
mismo ciclo de reloj.
En el mercado existen una gran variedad de arquitecturas que
implementan recursos paraexplotar cualquiera de las fuentes de
paralelismo arriba mencionadas. Por ejemplo, la arquitecturaARM con
su extensión SIMD Avanzada, también conocida como NEON o MPE, del
inglés MediaProcessing Engine, para explotar el paralelismo de
instrucciones; Nvidia y su plataforma CUDA,del inglés Computed
Unified Device Architecture, junto con el set de instrucciones PTX,
delinglés Parallel Thread Execution[nvi], que define una máquina
virtual y un ISA con el objetivo deexplotar la GPU como máquina de
ejecución de hilos paralelos de propósito general; Intel R©y
suarquitectura Intel R© MIC, del inglés Many Integrated Core,
sobre la que han desarrollado variosproductos, siendo el último de
ellos el Intel R© Xeon PhiTM Coprocessor, lanzado al mercado
enNoviembre de 2012 y descrito en la Sección 2.3 (pág. 8), que
explota tanto el paralelismo deinstrucciones como de tareas.
2.1. Taxonomı́a de Flynn
La taxonomı́a de Flynn consiste en una clasificación de
arquitecturas paralelas desarrollada porMichael J. Flynn en 1966 y
expandida en 1972[Fly72]. Desde el punto de vista del programador
enlenguaje ensamblador, las arquitecturas paralelas estaŕıan
clasificadas según la concurrencia delprocesamiento de secuencias,
datos e instrucciones. Esto da como resultado una metodoloǵıa
declasificación de las distintas operaciones paralelas disponibles
en el procesador. Propuesta comouna aproximación que clarificara
los tipos de paralelismo soportados tanto a nivel hardware
comosoftware, en ella se definen las siguientes cuatro
arquitecturas[fly]:
Single Instruction Single Data (SISD): arquitectura secuencial
que no explota el pa-ralelismo ni a nivel de instrucciones ni a
nivel de datos. Las máquinas tradicionales de unúnico procesador
secuencial o antiguos mainframes entraŕıan en esta
categorización. VerFigura 2.1 (pág. 5).
Single Instruction Multiple Data (SIMD): arquitectura que
explota el paralelismo du-rante la ejecución de una única
instrucción para realizar operaciones de naturaleza
paralela.Claros ejemplos son los procesadores vectoriales o las
GPU. Ver Figura 2.2 (pág. 5).
Multiple instruction Single Data (MISD): múltiples
instrucciones operan sobre unúnico stream de datos. Es una
arquitectura poco común generalmente usada para toleranciade
fallos, esto es, varios sistemas operan en el mismo stream de datos
y obtienen un resultadoque debe ser concorde para todos ellos. Ver
Figura 2.3 (pág. 5).
Multiple instruction Multiple Data (MIMD): múltiples
procesadores executan si-multáneamente diferentes instrucciones
sobre diferentes datos. Las arquitecturas VLIW sonun claro ejemplo
aparte de sistemas distribuidos o procesadores multicore. Ver
Figura 2.4(pág. 5).
-
2.2. VECTORIZACIÓN 5
Figura 2.1: SISD Figura 2.2: SIMD Figura 2.3: MISD Figura 2.4:
MIMD
2.2. Vectorización
La vectorización es un proceso de explotación de paralelismo
de datos consistente en convertirun algoritmo de implementación
escalar a vectorial. La implementación escalar es aquella enla que
se realiza una única operación simultánea sobre un par de
operandos que contienen unúnico dato cada uno. La implementación
vectorial realizaŕıa la misma operación, pero el par deoperandos
pasan de contener un único dato a contener una serie de valores.
Literalmente, lasescalares operan sobre un escalar y las
vectoriales sobre un vector. El bucle siguiente es un claroejemplo
de candidato a ser vectorizado.
1 for (i=0; i
-
6 CAPÍTULO 2. ESTADO DEL ARTE
unidad vectorial directamente de memoria, siendo el resultado
devuelto a la misma a posteriori. Enel caso de las arquitecturas
vectoriales vector-registro, los operandos son depositados en
registrosvectoriales que alimentaran a la unidad vectorial, siendo
asimismo el resultado depositado en otroregistro vectorial[MS03].
Independientemente de sendos modus operandi descritos, la mejora
enla reducción del número de instrucciones léıdas y
decodificadas resulta no ser tal si al final lainstrucción va a
tener que esperar a que se lea el vector o porción del vector de
memoria. Poresto, existen diversos esquemas de optimización del
rendimiento centrados en reducir el tiempo deacceso a la
memoria:
Hardware y software prefetching: prefetching en términos
generales significa traer datoso instrucciones de memoria antes de
que se necesiten. Cuando la aplicación necesita datos quese han
tráıdo con el prefetching, puede tomarlos directamente en vez de
tener que esperar porla memoria. Esta técnica puede ser iniciada
tanto desde el hardware como desde el software.
Gather-scatter: estas instrucciones permiten un tipo de
direccionamiento de memoria pro-pio del tratamiento de vectores. El
gather se encargaŕıa de indexar la lectura del vector mien-tras
que el scatter se encargaŕıa de la escritura. En su funcionamiento
intervienen máscarasque indicaŕıan los elementos del vector sobre
los que se realizaŕıa la operación. Estas podŕıanser útiles en
caso de haber condiciones en el interior del bucle para acceder a
datos de formadispersa.
Stripmining: técnica que afronta un problema en la
vectorización consistente en que losregistros vectoriales no
tienen por qué ser capaces de contener un vector completo
definidoen la aplicación. Consistiŕıa en romper el bucle de la
aplicación que opera sobre el vector endiferentes bucles:
prólogo, principal y eṕılogo según conviniera, para tratar un
número dedatos
-
2.2. VECTORIZACIÓN 7
3DNow!: extensión al repertorio de la arquitectura x86
desarrollado por AMD. Registros32 bits para operaciones de punto
flotante de simple precisión. El objetivo era mejorar elya
existente repertorio MMX de Intel de cara a elevar el rendimiento
de las aplicacionesgráficas. En 2010 AMD anunció el fin del
mantenimiento y soporte del mismo.
SSE: Streaming SIMD Extensions. Extensión de la arquitectura
x86 diseñado por Intel ylanzado al mercado en 1999 en su serie
Pentium III, como respuesta al lanzamiento por partede AMD de su
extensión 3DNow. Registros de 128 bits.
AltiVec: repertorio diseñado por y propiedad de la siguientes
empreas: Apple, aqúı recibeel nombre de Velocity Engine; IBM,
donde se denomina VMX; Freescale Semiconductor,propietaria de la
marca registrada AltiVec. Registros de 128 bits.
AVX: Advanced Vector Extensions. Extensión al repertorio de la
arquitectura x86 destinadaa procesadores Intel y AMD. Registros de
256 bits. Su desarrollo fue propuesto por Intelen 2008 pero no fue
hasta tres años después cuando salió al mercado como
caracteŕısticade la generación de procesadores Sandy Bridge de
Intel y Bulldozer de AMD. Posterior aella tenemos otra extension
denominada AVX2 soportada por Haswell, Broadwell, Skylakey
Cannonlake de Intel y por Excavator de AMD. En Julio de 2013 Intel
anunció AVX-512,última extensión con registros de 512 bits.
Ventajas
Los procesadores vectoriales y por extensión el uso de la
vectorización, proporcionan las si-guientes ventajas:
Los programas son de menor tamaño al reducir el número de
instrucciones que pudierarequerir un bucle. Ademas, el número de
instrucciones ejecutadas también se ve reducido alpoder concentrar
un bucle en una única instrucción.
El rendimiento de la aplicación mejora. Se tienen N operaciones
independientes que utilizanla misma unidad funcional, explotando al
máximo la localidad espacial de la memoria cache.
Las arquitecturas son escalables: se obtiene un mayor
rendimiento cuantos más recursoshardware haya disponibles.
El consumo de enerǵıa se reduce. Mientras la instrucción
vectorial se está ejecutando, no esnecesario alimentar otras
unidades tales como el ROB o el decodificador de instrucciones.
Tomando como ejemplo una aplicación multimedia que cambia el
brillo a una imagen, lavectorización proporciona dos mejoras
claras: en primer lugar el conjunto de datos se entiendecomo un
vector y no como valores individuales. Esto permitirá cargar en un
registro todos aquellosdatos que éste pueda albergar, en vez de
convertir el programa en una retah́ıla carga-opera-guardasobre una
gran cantidad de ṕıxeles individuales. En segundo lugar, la
paralelización del trabajo enuna única instrucción es evidente.
Cuanto más datos pueda albergar, mayor será el rendimiento.
Inconvenientes
Los procesadores vectoriales comparados con multiprocesadores o
procesadores superescalarespodŕıan resultar menos interesantes si
lo miramos desde el punto de vista del coste:
Necesitan memoria on-chip rápida y por consiguiente cara.
-
8 CAPÍTULO 2. ESTADO DEL ARTE
Hay que diseñarlos de forma espećıfica. La unidad vectorial de
los procesadores vectorialesno se compone de elementos
prefabricados más allá de las unidades básicas, por tanto
pocasventas del producto final se traduciŕıa en pérdidas debido a
su coste de diseño y validación.
Mientras que se consegúıa una ventaja en el consumo de enerǵıa
al reducir la alimentaciónde otras unidades, el consumo por parte
de los registros vectoriales podŕıa no mejorar elbalance final de
consumo.
Los compiladores, al igual que pueden facilitar la tarea, pueden
dificultarla en caso de quela vectorización del código no se
adapte a los requerimientos esperados por el compilador.Existe
entonces una posibilidad real de que haya una importante
implicación del ingenierotanto a nivel alto como bajo para
conseguir vectorizar una aplicación.
No hay un estándar establecido en el proceso. La utilización
de un repertorio de instruccionesSIMD u otro puede dificultar la
tarea en caso de compilar la misma aplicación sobre
distintasarquitecturas. Aparte, es posible que el ingeniero tenga
que proveer de una implementaciónno vectorial de la misma.
No todas las aplicaciones se pueden vectorizar. Por ejemplo, las
aplicaciones de análisis decódigo, caracterizadas por su fuerte
control del flujo de ejecución, son claras candidatas parano
beneficiarse de las ventajas de la vectorización.
2.3. Intel R© Xeon PhiTM Coprocessor
El coprocesador Intel R© Xeon PhiTM es el primer producto basado
en la arquitectura Intel R©MIC que se ha comercializado. Se lanzó
al mercado en Noviembre de 2012. La arquitectura Intel R©MIC se
basa en la combinación de muchos núcleos de Intel R© dentro de un
único chip. Esta des-tinada a su uso en la Computación de Alto
Rendimiento o HPC, del inglés High PerformanceComputing, para la
ejecución de programas paralelos que se veńıan ejecutando en
grandes clúste-res1. Pese a que su objetivo no es sustituir los
sistemas ya existentes, es una interesante alternativapara
conseguir buenos resultados de rendimiento de throughput2, en
entornos donde no haya de-masiado espacio para la instalación de
múltiples clústeres y donde se impongan limitaciones deconsumo de
enerǵıa. Ademas, un punto clave de la microarquitectura es que
esta construida espe-cialmente para proporcionar un entorno de
programación similar al entorno de programación delprocesador
Intel R© XeonTM[intb].
El coprocesador Intel R© Xeon PhiTM puede pasar por un sistema
en śı mismo, puesto que correuna distribución completa del
sistema operativo Linux, soporta el modelo x86 de ordenamientode
memoria y el estándar IEEE 754 de aritmética en punto flotante.
Ademas es capaz de ejecutaraplicaciones escritas en lenguajes de
programación propios de la industria del HPC como es el casode
Fortran, C y C++. Esto permite proporcionar con el producto un rico
entorno de desarrolloque incluye compiladores, numerosas libreŕıas
de apoyo (siendo de especial importancia aquellascon soporte
multi-thread y operaciones matemáticas para HPC) y herramientas de
caracterizacióny depurado.
Está conectado a un procesador Intel R© Xeon, denominado
”host”, a través de un bus PICExpress. Véase Figura 2.6 (pág.
9). Dado que el coprocesador ejecuta de forma autónoma elsistema
operativo Linux, es posible virtualizar una comunicación tcp/ip
entre éste y el procesador,permitiendo al usuario acceder como si
fuera un nodo más en la red. Por tanto, cualquier usuariopuede
conectarse al mismo a través de una sesión ssh (secure shell) y
ejecutar sus aplicaciones.Además, soporta aplicaciones
heterogéneas en las que una parte de la misma se ejecutaŕıa enel
host y otra en la propia tarjeta. Ni qué decir tiene que se pueden
conectar más de un Xeon
1Se aplica a los conjuntos de computadoras construidos mediante
la utilización de elementos hardware comunesy que se comportan
como si fuesen una única computadora
2Cantidad de trabajo que un ordenador puede hacer en un periodo
de tiempo determinado
-
2.3. INTEL R© XEON PHITM COPROCESSOR 9
Figura 2.5: Intel R© Xeon PhiTM
Phi en un mismo sistema, pudiéndose establecer entre ellos la
comunicación ya sea a través de lainterconexión p2p (peer to
peer) o a través de la tarjeta de red del sistema, sin
intervención enambos casos del host.
Figura 2.6: Esquema general
2.3.1. Microarquitectura
El coprocesador Intel R© Xeon Phi esta formado por más de 50
núcleos de procesamiento,memorias cache, controladores de memoria,
lógica de cliente PCIe y un anillo de interconexiónbidireccional
que proporciona un elevado ancho de banda al sistema. Véase Figura
2.7 (pág. 10).La ejecución es en orden mientras que la
terminación es en desorden. Cada core consta de una L2privada que
mantiene completamente la coherencia con el resto gracias a un
directorio de etiquetasdistribuido denominado TD, del inglés Tag
Directory. Los controladores de memoria y la lógicade cliente PCIe
proporcionan una interfaz directa con la memoria GDDR5 del
coprocesador y elbus PCIe respectivamente. Ademas, cada core fue
diseñado para minimizar el uso de enerǵıa a lavez que maximiza el
throughput en programas altamente paralelos. Usan un pipeline en
orden ysoportan hasta 4 hilos hardware.
-
10 CAPÍTULO 2. ESTADO DEL ARTE
Figura 2.7: Microarquitectura
VPU
Un importante componente de cada núcleo del coprocesador Intel
R© Xeon PhiTM es la VPU.Véase Figura 2.8 (pág. 10). La VPU cuenta
con un repertorio de instrucciones SIMD de 512 bits,oficialmente
conocido como Intel R© Initial Many Core Instructions (Intel R©
IMCI). Por ello puedeejecutar 16 operaciones de simple precisión
(SP) u 8 de doble precisión (DP) por ciclo. Tambiénsoporta
instrucciones Fused Multiply-Add (FMA), que ordenan multiplicar y
sumar en la mismainstrucción, y gracias a las cuales se pueden
ejecutar 32 instrucciones de simple precisión o 16 depunto
flotante por ciclo. Ni qué decir tiene que proporciona soporte
para operaciones con enteros.
Figura 2.8: Vector Processing Unit
Las unidades vectoriales proporcionan una evidente mejora
energética en la ejecución de apli-caciones HPC, ya que una
única operación codifica una gran cantidad de trabajo, a la vez
que noincurre en el coste adicional de enerǵıa que supondŕıan las
etapas de fetch, decode y retire parala ejecución de múltiples
instrucciones. Sin embargo, hicieron falta varias mejoras para
lograr so-portar instrucciones SIMD de estas caracteŕısticas. Por
ejemplo, se añadió el uso de máscaras a laVPU para permitir
predecir sobre qué datos operar dentro de un registro vectorial.
Esto ayudó enla vectorización de bucles con flujos de ejecución
condicionales, mejorando aśı la eficiencia softwaredel pipeline.
La VPU tambien soporta instrucciones de tipo gather y scatter
directamente a travésdel hardware. De este modo, para aquellos
códigos con patrones de acceso a memoria esporádicose
irregulares, el uso de este tipo de instrucciones ayuda a mantener
el código vectorizado.
Finalmente, la VPU también cuenta con una EMU, del inglés
Extended Math Unit, que puedeejecutar instrucciones trascendentes
como son las rećıprocas, ráıces cuadradas y logaŕıtmicas. LaEMU
funciona calculando aproximaciones polinómicas de estas
funciones.
-
2.3. INTEL R© XEON PHITM COPROCESSOR 11
Interconexión
La interconexión se implementa como un anillo bidireccional.
Véase Figura 2.9 (pág. 11). Cadadirección está compuesta de
tres anillos independientes. El primero, que se corresponde con
elmás ancho y caro de los tres, es el anillo de datos. Este es de
64 bytes para soportar el requisitode gran ancho de banda debido a
la gran cantidad de cores presentes. El anillo de direcciones
esmás estrecho y se utiliza para enviar comandos de
lectura/escritura y direcciones de memoria.Por último, el anillo
más estrecho y barato es el anillo de reconocimiento, que env́ıa
mensajes decontrol de flujo y coherencia.
Figura 2.9: Interconexion
Figura 2.10: Directorio de etiquetas
Cuando un core accede a su cache L2 y falla, una solicitud de
dirección se env́ıa sobre elanillo de direcciones a los
directorios de etiquetas. Véase Figura 2.10 (pág. 11). Las
direcciones dememoria se distribuyen de manera uniforme entre los
distintos directorios que hay en el anillo paraañadir la fluidez
de tráfico como una caracteŕıstica más del mismo. Si el bloque
de datos solicitadose encuentra en la cache L2 de otro core, se
dirige una petición a la L2 de ese core sobre el anillode
direcciones. Finalmente, el bloque de solicitud es posteriormente
reenviado sobre el anillo dedatos. Si los datos solicitados no se
encuentran en ninguna de las caches, se env́ıa la dirección
dememoria desde el directorio de etiqueta hasta el controlador de
memoria.
La Figura 2.11 (pág. 12) muestra la distribución de los
controladores de memoria en el anillo.Como se aprecia, se
intercalan de forma simétrica alrededor del él. La asignación de
los directoriosde etiquetas a los controladores de memoria se
realiza de forma todos-a-todos. Las direccionesse distribuyen
uniformemente a través de todos los controladores, eliminando de
este modo loshotspots y proporcionando un patrón de acceso
uniforme esencial para un uso efectivo del anchode banda.
Volviendo al modo de funcionamiento, durante un acceso de
memoria, cada vez que se produceun error en el nivel L2 de cache en
un core, éste genera una petición de dirección en el anillo
-
12 CAPÍTULO 2. ESTADO DEL ARTE
Figura 2.11: Controladores de memoria
de direcciones y consulta a los directorios de etiquetas. Si los
datos no se encuentran en estosdirectorios, el core genera otra
solicitud de dirección y solicita los datos a la memoria. Una
vezque el controlador recibe el bloque de datos desde la memoria,
se entrega al core a través delanillo de datos. En todo el proceso
los elementos trasmitidos a los anillos son: un bloque de datos,dos
solicitudes de dirección junto con dos mensajes de confirmación.
Debido a que los anillos dedatos son los más caros y están
diseñados para soportar el ancho de banda requerido, es
necesarioincrementar el número de anillos de dirección y
reconocimiento, más baratos en comparación, enun factor de dos
para soportar las necesidades de ancho de banda causadas por el
elevado númerode peticiones sobre los anillos.
Caches
La arquitectura Intel R© MIC invierte en mayor medida tanto en
caches L1 como L2 en compa-ración con las arquitecturas GPU. El
coprocesador Intel R© Xeon PhiTMimplementa un subsistemade memoria
en el que cada core está equipado con una cache de instrucciones
L1 de 32KB, unacache de datos L1 de 32KB y una cache L2 unificada
de 512KB. Son totalmente coherentes eimplementan el modelo de orden
de memoria x86. Las caches L1 y L2 proporcionan un ancho debanda
agregado que es entre 15 y 7 veces, respectivamente, más rápido
que el ancho de banda dela memoria principal. Por lo tanto, el uso
efectivo de esta jerarqúıa es clave para lograr el
máximorendimiento en el coprocesador. Además de mejorar el ancho
de banda, son también más eficientesque la memoria principal en
cuanto al uso de enerǵıa para el suministro de datos al core. En
la erade la computación exascale3, las caches jugarán un papel
crucial a la hora de conseguir maximizarel rendimiento bajo
estrictas restricciones de potencia.
Imágenes corteśıa de Intel R©.
3La computacion exascale se refiere a los sistemas de
computacion capaces de alcanzar un exaFLOPS.
-
2.4. INTEL R© ADVANCED VECTOR EXTENSIONS 13
2.4. Intel R© Advanced Vector Extensions
AVX, del inglés Advanced Vector Extensions engloba, como
véıamos en la Sección 2.2.1 (pág. 6),el conjunto de extensiones
sobre la arquitectura del repertorio de instrucciones x86,
propuestaspor primera vez por Intel en Marzo de 2008 tanto para
procesadores de Intel como de AMD. Elprimer producto en soportarlo
fue el procesador Sandy Bridge de Intel en el primer cuarto de2011,
seguido por el procesador Bulldozer de AMD en el tercer cuarto del
mismo año.
2.4.1. Intel R© Advanced Vector Extensions 1
Las extensiones Intel R© Advanced Vector Extensions 1 (AVX)
mejoraban las extensiones SSEmediante el incremento del ancho del
banco de registros SIMD de 128 bits a 256 bits. El nombrede los
registros, XMM0-XMM7, se cambió en consecuencia de YMM0-YMM7 (en
el caso de x86-64, YMM0-YMM15). Sin embargo, en los procesadores
con soporte AVX, las instrucciones de laextensión SSE pod́ıan ser
usadas para operar en los 128 bits menos significativos de los
registrosYMM. Entonces pod́ıa seguir usándose la nomenclatura
XMM0-XMM7.
AVX introdujo además un formato de instrucción SIMD de tres
operandos donde el registrode destino pod́ıa ser distinto a los dos
registros fuente. Por ejemplo, una instrucción SSE usandola forma
convencional a = a + b, pod́ıa ahora utilizar el método de tres
operandos c = a + b,impidiendo que se destruyera la información
almacenada en alguno de ellos como ocurŕıa hastael momento. Este
formato estaba limitado a las instrucciones que utilizan los
registros YMM, noincluyendo por tanto instrucciones con registros
de propósito general (por ejemplo EAX).
2.4.2. Intel R© Advanced Vector Extensions 2
Las extensiones Intel R© Advanced Vector Extensions 2 (AVX2)
mejoraban el set de extensionesAVX, y fueron introducidas por
primera vez en la microarquitectura Intel R© Haswell. La
compañ́ıaamplió por tanto el juego AVX con nuevas instrucciones
que funcionaban también sobre númerosnaturales, ampliando casi la
totalidad del conjunto SSE de 128 bits a 256 bits. El formato
nodestructivo de tres operandos estuvo ahora también disponible
para instrucciones a nivel de bitsy multiplicación de propósito
general y para instrucciones FMA (Fused
Multiply-Accumulate).Finalmente, esta nueva ampliación permitió
realizar instrucciones gather, lo que significaŕıa laposibilidad
de acceder a la vez a varias posiciones no contiguas en memoria,
aumentando conside-rablemente las capacidades de procesado
vectorial de la arquitectura x86-64.
2.4.3. Intel R© Advanced Vector Extensions 512
Intel R© Advanced Vector Extensions 512, AVX-512, son las
extensiones a 512 bits de las ins-trucciones SIMD recogidas en las
Advanced Vector Extensions de 256 bits. Fueron propuestaspor Intel
en Julio de 2013 para ser incluidas en el coprocesador Intel R©
Xeon PhiTM denominadoKnights Landing que se espera lanzar al
mercado en el año 2015[inta]. No todas las extensio-nes están
destinadas a ser soportadas por todos los procesadores que las
implementen. Sólo laextensión del núcleo AVX-512F (AVX-512
Foundation) se requiere para todas las implementacio-nes.
Atendiendo al repertorio de instrucciones y a las principales
caracteŕısticas de AVX-512, lasextensiones se clasifican del
siguiente modo:
AVX-512 Foundation: expande la mayoŕıa de instrucciones AVX de
32 y 64 bits con elesquema de codificación EVEX para soportar los
registros de 512 bits, las operaciones con
-
14 CAPÍTULO 2. ESTADO DEL ARTE
máscaras, la difusión de parámetros y las excepciones de
control y redondeo empotradas.
AVX-512 Conflict Detection Instructions (CDI): añade detección
de conflictos efi-ciente para permitir que más bucles puedan ser
vectorizados.
AVX-512 Exponential and Reciprocal Instructions (ERI):
operaciones exponencialesy rećıprocas diseñadas para ayudar en la
implementación de operaciones trascendentes, comopor ejemplo la
función de logaritmo.
AVX-512 Prefetch Instructions (PFI): soporte para
prefetches.
En cuanto a las caracteŕısticas técnicas, se resumen en los
siguientes puntos:
32 registros vectoriales de 512 bits de ancho bajo la
nomenclatura ZMM0-ZMM31.
8 registros dedicados a las máscaras, lo cual es de especial
trascendencia para las instruccionesgather y scatter.
Operaciones de 512 bits sobre datos empaquetados enteros y de
punto flotante.
Los programas podrán entonces empaquetar en los nuevos
registros de 512 bits cualquiera delas siguientes combinaciones de
datos: 8 datos en punto flotante de precisión doble, o 16 datos
enpunto flotante de precisión simple, u 8 enteros de 64 bits o 16
enteros de 32 bits. Esto permitirá elprocesamiento del doble de
elementos que el AVX/AVX2 con una sola instrucción y cuatro
vecesel de SSE.
Es interesante resaltar que Intel R© AVX-512 ofrece un nivel de
compatibilidad con AVXmuch́ısimo mayor que las transiciones
anteriores sobre el ancho de las operaciones. A diferencia delo que
ocurre con SSE y AVX, que no se pueden mezclar sin penalizaciones
en el rendimiento, lamezcla de instrucciones AVX y AVX-512 es
posible sin penalización alguna. Los registros YMM0-YMM15 de AVX
se mapean en los registros ZMM0–ZMM15 de AVX-512 del mismo modo que
semapeaban los registros SSE sobre AVX. Por lo tanto, en
procesadores que soporten AVX-512, lasinstrucciones AVX y AVX2
operarán en los 128 o 256 bits inferiores de los primeros 16
registrosZMM.
-
Caṕıtulo 3
Metodoloǵıa
Las ideas que surgieron a la hora de definir el anteproyecto del
presente Proyecto Final deCarrera lo describ́ıan claramente como un
trabajo con una fuerte carga de análisis. Comprend́ıadesde el
análisis de todas y cada una de las herramientas a utilizar, hasta
el análisis de cada resul-tado, cada gráfica elaborada, cada
bloque básico implicado y cada ĺınea de código que supusieraun
objeto de interés sobre el que adentrarse. Por este motivo no se
aplicó una estrategia espećıfi-camente etiquetada que seria
propia de un trabajo vinculado a la rama de ingenieŕıa del
software.Ciertamente, parte de este trabajo consist́ıa en
desarrollar un simulador sobre el que ejecutar lasaplicaciones, con
el objetivo de obtener más estad́ısticas aparte de aquellas
conseguidas gracias alas herramientas ya disponibles para los
ingenieros de Intel R©. Sin embargo, incluso el tomar ladecisión
de incorporar el desarrollo de este simulador como una extensión
de otro ya existente,supuso un fuerte trabajo de análisis para
tratar de reciclar la mayor cantidad de información yadisponible.
Esta información se encontraba almacenada, en su mayor parte,
sobre una gran varie-dad de estructuras y clases que evitaron, ya
no solo no reinventar la rueda, sino también impedirsobrecargar al
simulador con operaciones y tareas que eran necesarias y que por
supuesto ya seestaban realizando.
En este caṕıtulo, se describirá la forma de trabajo, es decir
aquellas actividades que supusieronuna importante parte para la
consecución del trabajo, cómo se distribuyeron todas las tareas
arealizar y el tipo de metodoloǵıa usada cuando se procedió al
desarrollo de la nueva extensión delsimulador.
3.1. Plan de trabajo
Al plan de trabajo diseñado inicialmente y presentado en el
anteproyecto se le aplicaron mo-dificaciones sin que ello
repercutiese en el computo total de horas. A continuación se
presenta laplanificación final y las justificaciones sobre los
cambios en el caso de haberlos.
Fase 1: Selección y caracterización de benchmarks
1. Selección del conjunto de benchmarks sobre los que realizar
el estudio a partir de los dispo-nibles, como NPB, Polyhedron,
PARSEC, etc.
2. Compilar las aplicaciones de los benchmarks para la
arquitectura x86 con la extensión AVX-512 para la obtención de
una caracterización inicial. Utilizando los compiladores
disponibles,
15
-
16 CAPÍTULO 3. METODOLOGÍA
como ICC e IFORT, se realiza la compilación del conjunto de
aplicaciones seleccionadas uti-lizando aquellas opciones que
permitan realizar optimizaciones y vectorización del
código.Implica un pequeño análisis mediante el parsing del
informe generado, para tener una apro-ximación inicial al
comportamiento de cada aplicación.
Esta fase se redujo a la selección y posterior caracterización
de las aplicaciones. El motivo porel que no se realizó una criba
inicial radica en que al principio, sin más datos que los
disponiblesestáticamente con el informe del compilador, la mera
descripción de la aplicación no parećıasuficiente para descartar
unas u otras. Era más interesante quedarnos con todas las
disponiblesy, a partir de diferentes estad́ısticas, tomar
decisiones sobre cuáles analizar según las solucionessoftware o
hardware a aplicar.
Fase 2: Recopilación y análisis de información sobre la
ejecución vectorial de losprogramas de prueba
1. Determinación del grado de vectorización de los programas:
Usando el emulador Pin/SDE,se obtiene el número de instrucciones
ejecutado por cada programa y se determina el gradode
vectorización de los mismos.
2. Recopilación de información sobre la jerarqúıa de memoria:
Usando el emulador CMP$im,se obtiene la tasa de fallos de los
diferentes niveles de la jerarqúıa de memoria para cadauno de los
programas de prueba.
3. Determinación del grado de utilización de la unidad
vectorial: En este apartado se desa-rrollará un núcleo sencillo
basado en la arquitectura del coprocesador Intel R© Xeon PhiTMsobre
el simulador CMP$im, que permita obtener datos estad́ısticos para
aśı determinar elgrado de utilización de la unidad vectorial.
La única modificación planteada en esta fase consistió en
realizar el desarrollo del simulador deun core con arquitectura
vectorial embebido dentro del simulador de cache CMP$im. El
motivoradica en que el simulador de cache proporciona mucha
información de interés que puede utilizarsepara la simulación de
la arquitectura. Además, contiene multitud de estructuras y clases
que sepueden utilizar a la vez que se introduce el código sobre el
esqueleto correspondiente a la simulaciónde cache.
En primer lugar se llevaŕıa a cabo una exhaustiva fase de
análisis sobre CMP$im, para conoceren profundidad tanto la
configuración de ficheros del simulador, como las estructuras y
clasesusados, aparte del funcionamiento espećıfico de la
simulación de la cache. Los objetivos principaleseran reutilizar
estructuras, esquemas y clases ya presentes, saber de qué modo
introducir el códigocorrespondiente al simulador de la
arquitectura para no entorpecer la simulación ya hecha y
poderhacer uso de las estad́ısticas recopiladas.
Una vez conocidas las caracteŕısticas principales mencionadas,
hab́ıa que proceder a la fasede desarrollo de la extensión
correspondiente a la simulación de la arquitectura vectorial.
Lametodoloǵıa más apropiada para desarrollarlo seŕıa
incremental. Era preciso en todo momentoque el simulador fuese
funcional. Por ello, cada vez que se incorporase una nueva
funcionalidad,esta deb́ıa protegerse con las macros
correspondientes. Ademas se teńıa que comprobar que todosegúıa
funcionando correctamente antes de proceder a la incorporación del
siguiente incremento.Cada una de las funcionalidades se iba a
discutir y diseñar en reuniones semanales, de manera queal final
de cada semana se tendŕıan tanto los progresos obtenidos como las
dificultades encontradas.Si todo estaba correcto, se tomaban las
decisiones oportunas sobre las siguientes funcionalidadesa
desarrollar.
-
3.1. PLAN DE TRABAJO 17
Fase 3: Determinación de cuellos de botella en la ejecución
vectorial y propuesta desoluciones
1. Selección de un subconjunto de aplicaciones numéricas de
entre todos los benchmarks selec-cionados, teniendo como referencia
las estad́ısticas recolectadas. Para la selección se tomaroncomo
criterio tanto la relación entre las versiones escalar y
vectorial, aśı como el desglose deciclos de la aplicación según
las dependencias ocasionadas durante la ejecución.
2. Con la información recolectada en los puntos anteriores se
determinará cuáles son las re-giones del código que tienen un
bajo uso de la unidad vectorial. Se estudiará a posterioricuál es
el motivo: si se trata de una falta de vectorización, si se
produce por ĺımites en lamicroarquitecura u otros.
3. Adicionalmente, se propondrán mejoras hardware y/o software
encaminadas a aumentar elrendimiento de estas regiones con bajo uso
de la unidad vectorial.
En esta fase, se incluyó la selección de las aplicaciones, ya
que a estas alturas están com-pletamente caracterizadas, de manera
que la información disponible permite tomar decisionesbasándonos
exclusivamente en el comportamiento de las mismas.
-
Caṕıtulo 4
Herramientas
En este caṕıtulo se introducen las caracteŕısticas principales
de las herramientas más signifi-cativas usadas a lo largo del
proyecto.
4.1. Pin
Pin1 es una herramienta de código abierto desarrollada por la
empresa Intel R©, destinada ala instrumentación de aplicaciones
[pin]. Se denomina herramienta de Instrumentación BinariaDinámica
porque la instrumentación se realiza en tiempo de ejecución (JIT,
Just in Time):
No requiere que la aplicación a instrumentar se tenga que
recompilar.
Permite instrumentar programas que generan código
dinámicamente.
Se puede adherir a procesos que ya se estuvieran ejecutando.
Proporciona una extensa API para escribir aplicaciones tanto en
C, C++ como ensamblador,denominadas pintools, que permitirán
instrumentar aplicaciones, ya sean estas single-threadedo
multi-threaded, compiladas para las arquitecturas IA-32 (x86
32-bit), IA-32E (x86 64-bit) yprocesadores Itanium R©. Dicha API
permite al programador abstraerse de todas las peculiaridadesde la
arquitectura para la que se haya compilado el binario. Por tanto,
podrá utilizar información decontexto, tales como el contenido de
los registros o las direcciones de acceso a memoria, pasándolacomo
diferentes parámetros dentro del código que el proceso de
instrumentación inserta en elbinario. Además, Pin salva y
recupera el contenido de los registros que se utilizaran en
dichocódigo, de manera que no influyan en la ejecución normal del
programa instrumentado.
Fue utilizada a la hora de estudiar y modificar el simulador que
se va a utilizar para simularlas aplicaciones numéricas.
4.1.1. Pintools
Una pintool, sea cual sea su funcionalidad, constará de dos
secciones fundamentales en sucódigo:
1No es un acrónimo.
19
-
20 CAPÍTULO 4. HERRAMIENTAS
Instrumentación: contendrá las instrucciones necesarias que
indiquen a Pin qué informaciónse quiere recoger del código que
se está ejecutando, como códigos de registro, hilos en
ejecu-ción o contador de programa, entre otros. También indica en
dónde se quieren insertar lasllamadas a las funciones y
procedimientos que harán uso de toda la información recogida.
Análisis: contendrá la definición de todas las funciones y
procedimientos que tratarán lainformación recogida en la sección
de instrumentación.
Además de estas dos secciones, también contendrá, como
cualquier aplicación de C o C++, lafunción main y, como novedad,
un procedimiento denominado Fini que es invocado por Pin cuandola
aplicación termina. El motivo por el que se tiene que desarrollar
este último procedimiento, resideen que una vez hemos dado el
control a Pin, no retorna a la función main para terminar.
Pin proporciona una amplia bateŕıa de pintools con diferentes
funcionalidades. En el Listado 4.1(pág. 20) se muestra el código
de una pintool denominada inscount0 que cuenta el número
deinstrucciones ejecutadas de una aplicación. Se encuentra dentro
de la extensa bateŕıa de pintoolsde ejemplo que acompañan a la
herramienta. Es una muestra perfecta de la estructura más comúnde
una pintool, en donde se aprecian tanto las secciones principales
descritas, como la definiciónde knobs, opciones de la pintool y
otras funciones de interés.
1 #include 2 #include 3 #include "pin.H"4 ofstream OutFile;5
static UINT64 icount = 0;67 // Seccion de analisis8 VOID docount ()
{ icount ++; }9
10 // Seccion de instrumentacion11 VOID Instruction(INS ins ,
VOID *v){12 INS_InsertCall(ins ,13 IPOINT_BEFORE ,14
(AFUNPTR)docount ,15 IARG_END);16 }1718 KNOB
KnobOutputFile(KNOB_MODE_WRITEONCE ,19 "pintool","o",20
"inscount.out",21 "specify output file name");2223 VOID Fini(INT32
code , VOID *v){24 OutFile.setf(ios:: showbase);25 OutFile
-
4.1. PIN 21
Analizando más en detalle el Listado 4.1 se observan llamadas a
funciones que forman partede la gran API proporcionada por pin:
PIN Init: inicializa Pin con los argumentos de entrada. Devuelve
false si hay errores.
INS AddInstrumentFunction: registra qué función se encargará
de la instrumentación anivel de instrucción.
PIN AddFiniFunction: registra qué función se invocará antes
de que la aplicación instru-mentada termine.
PIN StartProgram: arranca la ejecución de la aplicación. No se
retorna.
INS InsertCall: registra qué función se ha de llamar cuando se
encuentren instruccionescandidatas a instrumentar. Entre los
parámetros que se observan en Listado 4.2 tenemos:
• ins: instrucción a instrumentar.• IPOINT BEFORE: se invocara
el análisis antes de que se ejecute.• docount: función de
análisis.• IARG END: fin de parámetros, tanto si los hubiera como
si no. Estos parámetros son los
que pasaŕıan a la función docount del ejemplo. Véase Listado
4.3.
1 INS_InsertCall(ins ,2 IPOINT_BEFORE ,3 (AFUNPTR)docount ,4
IARG_END);
Listado 4.2: Función de instrumentación
1 VOID docount(UINT32 threadId , ADDRINT pc) { ... }23 VOID
Instruction(INS ins , VOID *v)4 {5 INS_InsertCall(ins ,6
IPOINT_BEFORE ,7 (AFUNPTR)docount ,8 IARG_THREAD_ID ,9 IARG_ADDRINT
, INS_Address(ins),
10 IARG_END);11 }
Listado 4.3: Argumentos para la función de análisis
4.1.2. Arquitectura software
En la Figura 4.1 se observa la arquitectura software de Pin
[LCM+05]. El elemento principal esla máquina virtual, que contiene
un compilador just in time que se encarga de recompilar
aquellasporciones de la aplicación que se hayan indicado en la
sección de instrumentación, sobre las quese inyectará el código
de la sección de análisis que le corresponda.
El dispatcher es el encargado de lanzar el código recién
compilado que almacena en el áreadenominada code cache. La
emulation unit interpreta aquellas instrucciones que no puedan
serejecutadas directamente, como es el caso de las llamadas al
sistema que tienen un tratamientoparticular dentro de la máquina
virtual.
De entre las entradas que alimentan a Pin, se encuentran
lógicamente tanto la pintool como laaplicación. En el Listado 4.4
se observa el esqueleto general de la invocación.
-
22 CAPÍTULO 4. HERRAMIENTAS
Figura 4.1: Arquitectura software de Pin
1 pin [pin_opts] -t pintool.so [pintool_opts] -- app [input]
Listado 4.4: Ejemplo de invocación de Pin
4.2. CMP$im
CMP$im (Chip Multi-Processor Cache Simulator) un simulador de
cache desarrollado porIntel R©y orientado a chips multiprocesador,
cuyo objetivo es analizar el rendimiento de memoriade aplicaciones
tanto single-threaded, multi-threaded como multi-program. Fue
desarrollada sobrePin, por lo que fundamentalmente es una pintool,
aprovechando el perfil de Pin como herramien-ta de instrumentación
binaria dinámica, que supońıa una alternativa frente a otros
métodos desimulación como trace-driven basado en trazas
[JCLJ06][JCLJ08].
Es interesante destacar que CMP$im es una herramienta muy
rápida y fácil de utilizar. Ademásproporciona una gran cantidad
opciones, tanto estáticas de forma #define MACRO, como
dinámicas(knobs) de forma -knob valor, que la hacen flexible. Por
ello permite configurar al detalle elsistema de memorias cache que
van a participar en la simulación. Entre estas opciones se
destacanlas siguientes:
Número de niveles de cache.
Número de caches por nivel.
Número máximo de threads que se pueden lanzar con la
aplicación.
Poĺıticas de escritura y reemplazo.
Caracteŕısticas particulares para cada cache, como tamaño,
asociatividad, latencia, tamañode ĺınea, etc.
Latencia de la memoria principal, aunque no se simule.
-
4.3. BENCHMARKS 23
TLBs.
Inclusividad o exclusividad.
Una vez compilada la pintool con las macros deseadas, se lanza
la simulación del mismo modoespecificado en el Listado 4.4 (pág.
22). La salida se compone de un informe con estad́ısticasmuy
detalladas, que proporcionan tanto información general de la
aplicación, como particulardesglosada por hilos de ejecución y
por nivel de cache. Entre ellos, se muestran datos relativos a:
Número total de instrucciones ejecutadas y desglosadas por
hilos.
Estimación2 del número de ciclos, donde la latencia de cada
instrucción es, por defecto, deun ciclo, añadiendo al total la
latencia total generada por los accesos a memoria.
Número de accesos, aciertos, fallos y tasas de fallo
desglosadas por nivel de cache y tipo deacceso (load, store, write
back, etc.).
Esta herramienta fue utilizada como base para desarrollar el
núcleo del coprocesador Intel R©XeonPhiTM. Imágenes corteśıa de
Intel R©.
4.3. Benchmarks
El benchmarking es una técnica consistente en medir el
rendimiento de un sistema o un com-ponente del mismo, con el
objetivo de realizar una comparativa con otro sistema similar de
modoque se tenga una referencia base sobre la que trabajar. De este
modo, se podŕıa saber si la máquinaobtiene buenos resultados o
no, de cara a utilizarlos para el fin que convenga.
Aplicado en el campo de la informática consistiŕıa en la
ejecución de aplicaciones espećıfica-mente diseñadas para medir
el rendimiento de una máquina o de uno de sus componentes.
Porello, de cara a este trabajo el uso de benchmarks software
constituye una piedra angular parapoder determinar el grado de
utilización efectiva de la unidad vectorial de un procesador.
Los benchmarks se pueden clasificar en diferentes categoŕıas.
Veamos una posible clasificación:
Benchmarks basados en el nivel del rendimiento que miden:
• Benchmarks de bajo nivel o nivel componente: se encargan de
medir directamente uncomponente espećıfico del sistema como, por
ejemplo, la memoria RAM, la tarjetagráfica o el procesador.
• Benchmarks de alto nivel o nivel sistema: evalúan el
rendimiento global de una máquina.Este tipo es interesante para
comparar sistemas que se basan en arquitecturas distintas.
Benchmarks basados en el código que los componen:
• Benchmarks sintéticos: creados espećıficamente combinando
diferentes funciones delsistema a probar, en las proporciones que
los desarrolladores estiman oportunas. Elobjetivo es conseguir
medir determinados aspectos del sistema. Esta descripción seasocia
rápidamente a los benchmarks de tipo bajo nivel ya que, por
ejemplo, paramedir el rendimiento del funcionamiento del disco, se
pueden incluir funcionalidades delectura, escritura o búsqueda de
datos en disco en el benchmark.
2No implementa ningún mecanismo que haga uso del paralelismo de
instrucciones (ILP).
-
24 CAPÍTULO 4. HERRAMIENTAS
• Benchmarks de aplicación: hacen uso de aplicaciones reales.
En este caso los desa-rrolladores del benchmark pueden tener
interés en utilizar determinadas aplicacionesque realizan
funciones enfocadas a una industria concreta o a un determinado
tipode producto. En este caso, se asocian con los benchmarks de
alto nivel ya que estetipo de aplicaciones miden el rendimiento
global del sistema, pudiendo analizar cómocontribuye cada
componente al dicho rendimiento.
Independiente de esta clasificación, se pueden tipificar
siguiendo otros patrones más espećıficos.Por ejemplo, existen
benchmarks que sirven para medir el rendimiento de máquinas con
múltiplesnúcleos en su procesador o con múltiples procesadores.
Existen otros benchmarks para medir larespuesta de las consultas
sobre una base de datos.
Existen una gran cantidad de benchmarks disponibles hoy en d́ıa,
entre los cuales podemosmencionar los siguientes a modo de
ejemplo:
Whetstone: considerado el padre de los benchmarks sintéticos,
fue creado en el Laboratorionacional de F́ısica de Inglaterra. Su
objetivo inicial era servir como test para el compiladorALGOL 60
aunque hoy en d́ıa forma parte de otros benchmarks.
3DMark: benchmark sintético creado por la compañ́ıa Futuremark
Corporation, con el obje-tivo de medir la capacidad de rendering
sobre gráficos 3D que tiene la GPU de una máquina,aśı como la
capacidad de procesamiento de la CPU.
Ciusbet: creado por Ciusbet. Es un benchmark que se compone de
un gran número depruebas para probar diferentes componentes de una
máquina, como la memoria cache, laCPU, el disco duro, etc.
FurmKar: benchmark sintético que mide el rendimiento de una
tarjeta gráfica al través dela ejecución de un algoritmo de
renderizado de pelaje. Su peculiaridad es que, al tratarse deun
algoritmo que somete a la GPU a un nivel de estrés muy fuerte,
permite medir muy bienla capacidad de aguante y estabilidad de la
tarjeta.
El conjunto de benchmarks que se presenta a continuación es una
muestra continente de va-riedad de aplicaciones numéricas usadas
comúnmente en el ámbito de la computación de altorendimiento.
Todos los programas se caracterizan por ser o bien Free software, o
bien Open sour-ce.
4.3.1. Polyhedron Fortran Benchmarks
Polyhedron[pol] es un paquete de 17 programas escritos en
Fortran 90, diseñados para com-parar el rendimiento de los
diferentes ejecutables generados por distintos compiladores. Todos
losprogramas se pueden descargar y hacer uso de ellos según
convenga. El paquete que actualmenteestá disponible para descarga,
se denomina pb11. Sin embargo, para el presente trabajo hicimosuso
de 15 aplicaciones del antiguo repertorio, denominado pb05, debido
a que el conjunto de da-tos de entrada permit́ıa una mayor rapidez
de cara a la simulación completa de los programas.El nuevo
benchmark tiene conjuntos de datos que ralentizaban demasiado su
simulación. Las 15aplicaciones son las siguientes:
ac armod air capacitachannel doduc fatigue gas dyninduct linpk
mdbx nfprotein test fpu tfft
-
4.3. BENCHMARKS 25
4.3.2. Mantevo 1.0
Mantevo[man] es un benchmark que proporciona una interesante
variedad de aplicacionesclasificadas en:
Miniapplications: partiendo de la idea de que la medición del
rendimiento de las aplicacionesviene determinada por una
combinación de diferentes opciones, proporcionan una
aproxi-mación excelente para explorarlas. Las opciones mencionadas
englobaŕıan las siguientes: elcompilador usado, el hardware de la
máquina a medir, el algoritmo, el entorno de ejecución,el uso de
miniaplicaciones, definidas como pequeños proxies autocontenidos
para aplicacionesreales, etc.
Minidrivers, pequeñas aplicaciones que sirven para simular el
funcionamiento de diferentescontroladores.
Application proxies, aplicaciones parametrizables cuyo objetivo
es simular el comportamientode aplicaciones a gran escala.
Todas ellas realizan mayoritariamente operaciones en coma
flotante para, por ejemplo, resolverecuaciones diferenciales en
derivadas parciales tanto impĺıcitas como expĺıcitas, simular
modelosde dinámica molecular que implican operaciones sobre
vectores, etc. Las aplicaciones de que secompone son las
siguientes:
CloverLeaf CoMD HPCCG-200 miniGhostminiFE miniMD miniXyce
De los tres conjuntos de ficheros de entrada disponibles para
realizar las simulaciones, noshemos quedado con los mediums, con el
objetivo de tener los resultados en tiempos razonables.
4.3.3. ASC Sequoia Benchmark Codes
Los investigadores del Laboratorio Nacional Lawrence Livermore
(LLNL), con motivo del pro-grama ASC (Advanced Simulation and
Computing) de la Administracion Nacional de SeguridadNacional
(NNSA) de Estados Unidos, llevan a cabo multitud de simulaciones
sobre el supercompu-tador de IBM denominado Sequoia. Dentro de los
recursos que están disponibles en la plataformaonline dedicados a
este programa y a los trabajos realizados sobre el supercomputador,
se encuen-tra todo un interesante repertorio de aplicaciones[seq].
De entre todas ellas, y dado que solo se ibaa simular uno de los
núcleos del coprocesador Intel R© Xeon PhiTM, se seleccionaron
solamente lasaplicaciones correspondientes a la sección Tier 3,
que se caracterizan por ser single-threaded :
UMTmk IRSmk SPhotmk Crystalmk
4.3.4. NAS Parallel Benchmarks
Los NAS Parallel Benchmarks[nas] (NPB) son un conjunto de
aplicaciones destinadas a la me-dición del rendimiento de
supercomputadores paralelos. Fueron desarrolladas por la división
NAS(NASA Advanced Supercomputing). Inicialmente, en la
especificación NPB 1, estaba conformadopor 5 kernels y 3 pseudo
aplicaciones. Más adelante fue extendida para incluir nuevos
benchmarkssobre mallas adaptativas, aplicaciones E/S paralelas y
redes computacionales. Se utilizó la versión3.3.1 que contiene
las siguientes aplicaciones:
-
26 CAPÍTULO 4. HERRAMIENTAS
BT CG DC EP FTIS LU MG SP UA
Los diferentes inputs se categorizan en las siguientes
clases:
Class S : para pequeñas pruebas.
Class W : destinada a estaciones de trabajo.
Classes A, B, C : test de mayor tamaño, cada uno de los cuales
es aproximadamente 4xsuperior al anterior.
Classes D, E, F : en este caso son entradas muy grandes, del
orden de los 16x de incrementoentre un test y el siguiente.
Para el presente caso, era suficiente utilizar la clase W,
puesto que el número de instruccionesejecutadas se encontraba en
el orden de magnitud de los otros benchmarks seleccionados.
4.3.5. SPEC CPU 2006
La Standard Performance Evaluation Corporation (SPEC), es una
organización sin ánimo delucro cuyo objetivo es producir,
establecer, mantener y promocionar un paquete estándar de
bench-marks para medir el rendimiento de diferentes máquinas. En
este sentido, se dispone del conjuntode benchmarks denominado SPEC
CPU2006 diseñado para proporcionar una medida comparati-va, con el
objetivo de analizar el rendimiento conseguido después de realizar
cálculos intensivossobre una máquina. El conjunto de aplicaciones
que lo conforman fueron desarrolladas basadas enaplicaciones de
usuario reales. Los resultados que se obtengan serán fuertemente
dependientes delprocesador, la memoria y el compilador
utilizado.
Dado que el presente trabajo está centrado en el estudio
efectivo de un procesador vectorial, noscentramos fundamentalmente
en uno de los dos suites en que se divide: CFP2006, que sirve
paramedir el rendimiento de las operaciones en punto flotante. El
otro suite, CINT2006 está enfocadoa operaciones enteras. Las
aplicaciones son las siguientes:
410.bwaves 416.gamess 433.milc 434.zeusmp435.gromacs
436.cactusADM 437.leslie3d 444.namdP447.dealII 450.soplex
453.povray 454.calculix459.GemsFDTD 465.tonto 470.lbm
481.wrf482.sphinx3
Como datos de entrada, están disponibles los siguientes:
all : común para todos los benchmarks, se usa en caso de ser
necesario.
ref : es el conjunto de datos real y completo.
test : entrada para tests más sencillos.
train: tests más grandes.
Para nuestras necesidades, basta con usar test.
-
4.4. COMPILADORES 27
4.4. Compiladores
Los compiladores son una parte fundamental de este trabajo,
puesto que son los responsables degenerar el código necesario con
el que se trabajara después. Si bien todos los elementos
expuestosen este caṕıtulo son indispensables para conseguir las
sinergias que permitirán completar todoslos objetivos definidos en
la Sección 1.1 (pág. 2), los compiladores se alzan con la
responsabilidadsuprema. En el caso particular de los optimizadores
de que constan, son responsables de generar uncódigo adecuado con
el que se pueda partir, trabajar y mejorar en caso necesario. Si no
fuera aśı,ningún resultado tendŕıa la fiabilidad suficiente. Por
estos motivos trabajamos con los compiladoresIntel R© C++ Compiler
e Intel R© Fortran Compiler.
Una de las ventajas principales de trabajar con estos
compiladores y de realizar este trabajoen la propia empresa Intel
R©, es que se dispońıa en todo momento de la última versión de
los com-piladores. Por tanto, este trabajo serv́ıa también como
depurador de los cambios introducidos encada versión. La versión
utilizada en las simulaciones se corresponde con la de Mayo de
2013. Paralas simulaciones realizadas durante los meses de Junio y
Julio utilizamos la misma para mantenerla coherencia en los
resultados. Utilizar otro implicaŕıa obtener mejoras que no
recaeŕıan sobre loscambios en configuraciones utilizadas al
simular, sino en las propias mejoras del compilador.
El código generado al compilar contiene las extensiones AVX-512
descritas en la Sección 2.4(pág. 13). Asimismo, mientras los
compiladores están disponibles en multitud de plataformas, eneste
trabajo se usó la versión para Linux.
Los compiladores fueron usados a la hora de construir la
caracterización de todas y cada una delas aplicaciones, y para
tener los ejecutables disponibles en el momento de proceder a la
simulacióncon la versión de CMP$immodificada.
4.4.1. ICC
El compilador Intel R© ICC permite generar código sobre
arquitecturas IA-32, Intel R©64 e Intel R©MIC (Multiple Integrated
Core) [intc], disponibles para los sistemas operativos Mac OS X,
Li-nux y MicrosoftTMWindows. Contiene soporte para la
vectorización de aplicaciones, pues puedegenerar instrucciones de
los repertorios SSE (Streaming SIMD Extensions), SS2, SSE3,
SSSE3(Suplemental Streaming SIMD Extensions), SSE4, AVX(Advanced
Vector Extensions) y AVX2.Las versiones internas del compilador,
además, permit́ıan generar código AVX-512. El
vectorizadorautomático es un componente importante del compilador,
ya que utiliza automáticamente instruc-ciones SIMD (Simple
Instruction Multiple Data) de los repertorios de instrucciones
mencionadosanteriormente. Se encarga de detectar aquellas
operaciones en el programa que se pueden vectori-zar para explotar
el procesamiento automático de las instrucciones de tipo SIMD. El
usuario puedeayudar a este módulo mediante el uso de pragmas.
Consúltese el conjunto de pragmas disponiblesen la Sección 4.5
(pág. 29)
ICC tiene multitud de knobs de compilación[intc]. Para este
trabajo, el formato de las mismasse corresponde con aquel para
Linux. A continuación se mostrarán las opciones más
significativasusadas en este trabajo. La ĺınea de compilación
tiene el formato mostrado en el Listado 4.5. Laopción -no-vec que
se observa en la ĺınea de compilación, se usaba para indicar al
compiladorque no vectorizase. Como se verá más adelante, la
versión no vectorizada de las aplicaciones es deinterés porque
sirven de referencia para compararlas con la versión
vectorizada.
1 icc -g -debug inline -debug -info -vec -report62 -ansi -alias
-O3 -no-prec -div -ipo -static3 -xKNL [-no -vec] -o
Listado 4.5: Ĺınea de compilación
-
28 CAPÍTULO 4. HERRAMIENTAS
-g Produce información para depuración simbólica en elfichero
objeto.
-debug inline-debug-info Genera información de depuración
mejorada tanto enel caso de código del que se haga inline como en
elrastro generado por sucesivas llamadas a funciones.
-vec-report6 Genera un log con toda la información
concernien-te a los bucles y bloques que han sido vectorizados,aśı
como de las razones porque otros no lo han sido.
-ansi-alias Indica al compilador que compile bajo las reglas
dealiasability estándares de la ISO de C.
-O3 Aparte de las optimizaciones de la opción -O2, in-cluye
prefetching, transformación de bucles y susti-tución de
escalares.
-no-prec-div Permite optimizaciones que, a cambio de
divisionesalgo menos precisas que las operaciones de divisiónen
śı mismas, sustituye estas por multiplicaciones.Por ejemplo, en
vez de A/B, se calculaŕıa A*(1/B)
-ipo Interprocedural Optimization. Indica al compiladorque haga
inline de las llamadas a funciones que seencuentran en otros
ficheros. Un ejemplo seŕıa enaquellas llamadas dentro de bucles.
Por defecto elvalor es 0, esto es que se dejara al compilador
decidirsi crear uno o más ficheros objetivo dependiendo deuna
estimación del tamaño de la aplicación.
-static Impide enlazar con libreŕıas compartidas. En su lu-gar,
enlaza todas las libreŕıas estáticamente.
-xKNL La arquitectura para la que se está generando códigoes
KNL, que incluye AVX-512.
-no-vec Impide al compilador hacer uso del módulo de
vecto-rización. El log resultante de aplicar esta opción
nocontendŕıa más información que la ĺınea de compila-ción
usada y los ficheros compilados.
Tabla 4.1: Knobs soportados por Intel R© ICC
4.4.2. IFORT
El compilador Fortran de Intel R© al igual que ICC, permite
compilar aplicaciones sobre lasarquitecturas IA-32, Intel R© 64 y
Intel R©MIC (Multiple Integrated Core) [intc], disponibles paralos
sistemas operativos Mac OS X, Linux y MicrosoftTMWindows.
Igualmente, tiene caracteŕısticasanálogas al compilador ICC, como
es el soporte para la vectorización de aplicaciones, y compartela
mayoŕıa de knobs disponibles.
La ĺınea de compilación solo difiere en la opción -fpp, la
cual sirve para indicar al compilador
-
4.5. PRAGMAS 29
que corra el preprocesador de Fortran sobre los ficheros fuentes
antes de realizar la compilación.El resto permanecen
invariantes.
1 ifort -fpp -g -debug inline -debug -info -vec -report62 -ansi
-alias -O3 -no-prec -div -ipo -static3 -xKNL [-no -vec] -o
Listado 4.6: Ĺınea de compilación
4.5. Pragmas
Los pragmas son directivas que sirven para especificar qué
tiene que hacer el compilador endeterminadas situaciones. Estas
instrucciones pueden tener efectos a nivel global o a nivel
local.Por ejemplo, para el caso del presente trabajo, puede ser
necesario el uso del pragma vector paraindicar al compilador que un
bucle concreto tiene que ser vectorizado, en cuyo caso es un
pragmaa nivel local.
Los pragmas no forman parte de un lenguaje de programación, ya
que no figuran en su gramáti-ca, pero algunos lenguajes, como C++
y Fortran, tienen disponible palabras clave para su uso, lascuales
son tratadas por el preprocesador. En C++ es #pragma y en Fotran es
!DIR$. Además, hayque tener en cuenta que los pragmas son
dependientes tanto de la máquina como del sistemaoperativo, aparte
de que cada compilador tiene su propio conjunto. Es también
posible que lafuncionalidad proporcionada por un pragma se consiga
con alguna opción particular de compila-ción. En caso de
coincidir en funcionalidad las opciones del compilador con los
pragmas, tienenprioridad los segundos.
Los pragmas, que se pueden consultar en el Apéndice A (pág.
105), el Apéndice B (pág. 109)y el Apéndice C (pág. 113),
están disponibles tanto para procesadores Intel R© como de
otrasempresas, pero es posible que en procesadores Intel R© lleven
a cabo optimizaciones adicionales.Hay que tener en cuenta que en el
caso de Fortran, al hablar de los pragmas, en realidad se hablade
directivas y su listado no coincide más que en algunos casos con
los de ICC. En el Listado 4.7y el Listado 4.8, se visualizan las
diferencias de sintaxis. Particularmente, los pragmas de ICCtienen
la siguiente clasificación:
Intel R© ICC Specific Pragmas: desarrollados espećıficamente
para trabajar con el com-pilador Intel R© C++.
Intel R© ICC Supported Pragmas: desarrollados por fuentes
externas que, por razonesde compatibilidad, son soportados por este
compilador.
1 #pragma nombre [parametros]
Listado 4.7: Sintaxis de los pragmas de ICC
1 (c|C|!|*)(DEC|DIR)$ directiva [parametros]
Listado 4.8: Sintaxis de las directivas de Fortran
4.6. Herramientas internas
Toda empresa dispone de un conjunto de herramientas que han sido
desarrolladas por los pro-pios empleados. Estas suelen tener fines
exclusivamente internos e incluso de uso restringido en
-
30 CAPÍTULO 4. HERRAMIENTAS
la propia organización, al poner su disponibilidad bajo la
previa aprobación del jefe del grupo.Intel R© es una empresa muy
grande, de importante capital y con gran cantidad de recursos
dispo-nibles para sus empleados, incluyendo las herramientas
desarrolladas por los diferentes grupos detrabajo. Por este motivo,
previa autorización, tuve acceso a un conjunto de ellas de cara a
facili-tarme la tarea durante el desarrollo de este trabajo. Estas
herramientas facilitaban el análisis delas aplicaciones, al
presentar todos los datos procedentes de los informes generados por
diferentessimuladores, como es el caso de CMP$im y otras pintools,
y del informe del compilador, de unmodo más legible y fácil de
estudiar, que lo que un fichero de texto con multitud de números
yĺıneas permite.
La herramienta que se usó principalmente permit́ıa, para cada
unas de las aplicaciones simu-ladas, entre otras funcionalidades,
las siguientes:
Analizar los bloques básicos individualmente.
Consultar el código fuente asociado a cada bloque básico.
Visualizar el flujo de ejecución del programa.
Consultar la distribución de funciones e instrucciones.
Sintetizar la información procedente de cada nivel de la
cache.
Todas ellas se usaron principalmente durante la caracterización
de las aplicaciones y a la horade realizar el diagnóstico software
para averiguar las causas del bajo grado de vectorización.
-
Caṕıtulo 5
Arquitectura del Simulador
En el presente caṕıtulo se hará un análisis más en detalle
del funcionamiento del simuladorCMP$im presentado en la Sección
4.2 (pág. 22). Debido a que es una pintool y que esta
ı́ntima-mente relacionado con la herramienta Pin, habrá detalles
de Pin que será necesario exponer paracomprender mejor el esquema
general del simulador.
5.1. Flujo de ejecución
Las dos secciones principales en las que se organiza una
pintool, como se describieron en laSección 4.1.1 (pág. 19), son
las secciones de instrumentación y de análisis. CMP$im no es
unaexcepción. En la Figura 5.1 (pág. 31) se presenta una visión
general de cómo funciona.
En primer lugar tenemos la función main, donde se recogen las
opciones de configuración dela pintool introducidas por parámetro
y tanto la aplicación objeto del análisis como sus datos
deentrada. Aqúı también se llevan a cabo las inicializaciones
pertinentes según la configuración decache que se haya elegido.
Una vez se lanza la simulación no se retorna. Por ello, la
finalización dela aplicación está ligada a una función de
terminación que