Estudio de utilizaci on efectiva de procesadores vectoriales · 2020. 2. 26. · procesadores vectoriales Proyecto de Fin de Carrera Ingenier a en Inform atica Laura Aut on Garc a

Universidad de Las Palmas de Gran Canaria

Estudio de utilización efectiva deprocesadores vectoriales

Proyecto de Fin de Carrera

Ingenieŕıa en Informática

Laura Autón Garćı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 podŕıa ser el sueño de cual-quier futuro ingeniero informático cuando avista cada vez más cerca la meta de su esfuerzo. Esteviaje no solo ha dado como resultado el presente trabajo, sino también la satisfacción profesio-nal de haber trabajado en Intel, empresa puntera en el ámbito de la computación, y personal dehaber trabajado con extraordinarios ingenieros a la vez que fantásticas personas durante todo elproceso. Entre ellos, quiero agradecer especialmente a Manel Fernández por la enorme pacienciay dedicación con las que consiguió guiarme cuando me desviaba del camino, y a Jesús Sá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, Maŕıa y Cándido por haber sabidoapoyarme desde la distancia con sus palabras al otro lado del teléfono. Y a Raúl, mi gran compañeroen este viaje, porque ha sido la única persona de este mundo que realmente ha conocido mis másprofundas inquietudes, y que ha sabido iluminarme el camino y cederme las mangas sobre las quederramar mis lágrimas.

i

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. Simulación en modo buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3. Simulación en modo instrucción a instrucción . . . . . . . . . . . . . . . . . . . . . 335.4. Ejemplo de bloque básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.5. Proceso de descubrimiento de bloques . . . . . . . . . . . . . . . . . . . . . . . . . 345.6. Punteros a objetos cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1. Índice de vectorización de las aplicaciones de Polyhedron . . . . . . . . . . . . . . . 406.2. Razones para no vectorizar bucles en Polyhedron . . . . . . . . . . . . . . . . . . . 416.3. Índice de vectorización de las aplicaciones de Mantevo 1.0 . . . . . . . . . . . . . . 426.4. Razones para no vectorizar bucles en Mantevo 1.0 . . . . . . . . . . . . . . . . . . 436.5. Índice de vectorización de las aplicaciones de Sequoia . . . . . . . . . . . . . . . . . 446.6. Razones para no vectorizar bucles en Sequoia . . . . . . . . . . . . . . . . . . . . . 446.7. Índice de vectorización de las aplicaciones de NPB . . . . . . . . . . . . . . . . . . 456.8. Razones para no vectorizar bucles en NPB . . . . . . . . . . . . . . . . . . . . . . . 466.9. Índice de vectorizació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. Localización del simulador de pipeline en CMP$im . . . . . . . . . . . . . . . . . . 567.4. Idea para la implementación de KNC . . . . . . . . . . . . . . . . . . . . . . . . . . 567.5. Instrucción que toca dos ĺıneas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.6. Bloques con ningún y un corte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.7. Bloques con 2 cortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.1. Versión vectorizada vs no vectorizada de Polyhedron . . . . . . . . . . . . . . . . . 668.2. Ciclos desglosados de las aplicaciones de Polyhedron . . . . . . . . . . . . . . . . . 678.3. Versión vectorizada vs no vectorizada de Mantevo . . . . . . . . . . . . . . . . . . 698.4. Ciclos desglosados de las aplicaciones de Mantevo . . . . . . . . . . . . . . . . . . . 698.5. Versión vectorizada vs no vectorizada de Sequoia . . . . . . . . . . . . . . . . . . . 70

iii

iv ÍNDICE DE FIGURAS

8.6. Ciclos desglosados de las aplicaciones de Sequoia . . . . . . . . . . . . . . . . . . . 708.7. Versión vectorizada vs no vectorizada de NPB . . . . . . . . . . . . . . . . . . . . . 718.8. Ciclos desglosados de las aplicaciones de NPB . . . . . . . . . . . . . . . . . . . . . 728.9. Versión vectorizada vs no vectorizada de SPEC fp . . . . . . . . . . . . . . . . . . 738.10. Ciclos desglosados de las aplicaciones de SPEC fp 2006 . . . . . . . . . . . . . . . . 738.11. Comparació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 ĺıneas de DTLB2 de 256 a 512 . . . . . . . . . . . . . . . . 1008.16. Mejora de IS de NPB al doblar la TLB . . . . . . . . . . . . . . . . . . . . . . . . . 100

Í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 instrucción (load-op) . . . . . . . . . . . . . . . . . . . 51

8.1. Bloques 1 y 2 de la lista de bloques básicos más ejecutados en Fatigue, Polyhedron 758.2. Bloque 3 de la lista de bloques básicos más ejecutados en Fatigue, Polyhedron . . . 768.3. Bloques 1, 2, 4 y 5 de la lista de bloques básicos más ejecutados en Induct, Polyhedron 778.4. Bloques 1 y 2 más ejecutados de Aermod, Polyhedron . . . . . . . . . . . . . . . . 798.5. Bloques 3, 5 y 10 más ejecutados de Aermod, Polyhedron . . . . . . . . . . . . . . 808.6. Bloques 7 y 9 más ejecutados de Aermod, Polyhedron . . . . . . . . . . . . . . . . 808.7. Bloque 8 má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 más ejecutados de Gas dyn, Polyhedron . . . . . . . . . . . . . . . . 838.10. Bloques 1, 2, 3 y 4 más ejecutados de SPhotmk, Sequoia . . . . . . . . . . . . . . . 888.11. Bloque 1 de los más ejecutados de BT, NPB . . . . . . . . . . . . . . . . . . . . . . 908.12. Bloques 1 y 2 de los más ejecutados de LU, NPB . . . . . . . . . . . . . . . . . . . 918.13. Bloques 1 y 2 de los má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

Índice general

Agradecimientos I

Lista de figuras VIII

Lista de tablas VIII

1. Introducción 11.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Estado del arte 32.1. Taxonomı́a de Flynn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. Vectorizació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. Metodoloǵı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 ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2. Estructuras y clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3. Parámetros de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

vii

viii ÍNDICE GENERAL

6. Caracterización de benchmarks 396.1. Polyhedron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2. Mantevo 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3. Sequoia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4. NPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.5. SPEC FP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7. Adaptación del Simulador 497.1. Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.2. Detecció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. Invocació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. Diagnó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. Diagnó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

Caṕıtulo 1

Introducción

Echando una profunda mirada al pasado para recorrer toda la historia de la informática, desdedonde venimos, en qué punto nos encontramos y a dónde vamos, nos damos cuenta del gran esfuerzoque ha hecho y sigue haciendo el ser humano para no solo automatizar tareas, sino también paraque éstas se hagan lo más rápido posible. Y es que, ya en su momento, para realizar cálculosbaĺısticos de gran utilidad en posibles contiendas, se incrementaba el número de personas querealizaban una tarea. Al segmentar el trabajo se consegúıa realizar la tarea en menos tiempo de loque lo conseguiŕıa una sola. A estas personas se las denominaba antiguamente computers[Bar08],nombre que más tarde se adoptó para las máquinas que sustituyeron su trabajo.

Desde entonces, la capacidad de cómputo de las má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 afirmación se bautizo como Leyde Moore. Cuando las limitaciones f́ısicas se convirtieron en un problema, empezamos a introducirmás núcleos en un mismo procesador: primero dos, luego cuatro... Está claro que, sean los motivosque sean los que impulsen al ser humano a seguir escudriñ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 vectorización.

Hoy en d́ıa, una importante muestra de procesadores disponibles en el mercado disponen deunidades de cómputo, denominadas vectoriales, que permiten la explotación de este concepto. Yes que la vectorización explota un caso particular de paralelismo cuyo objetivo consiste en realizarla misma operación, en vez de sobre un único dato como veńı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 explotación delparalelismo de datos, incluyen extensiones AVX (Advanced Vector Extensions) sobre el repertoriode instrucciones x86. Sin embargo, esta obra de ingenieŕıa no es suficiente por śı sola. Es necesarioun engranaje más, y que no es otro que un compilador especialmente construido para máquinascomo estas, que sea capaz de extraer el mayor paralelismo de datos posible de una aplicació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 cómputo, nosiempre se obtienen los resultados esperados. Las razones pueden residir tanto en el software comoen el hardware. Puede que la aplicación no experimente las mejoras esperadas después de servectorizada. Es posible que el compilador no sea capaz por śı mismo de encontrar potencialessecciones de código vectorizables debido a ambigüedades en el acceso a los datos. O bien, podŕıa

1

2 CAPÍTULO 1. INTRODUCCIÓN

ser que la memoria esté suponiendo un cuello de botella a la hora de recuperar los datos sobre losque operar.

Basándonos pues en la realidad descrita, se propuso la realización del trabajo que se detallaen este documento, con el objetivo fundamental de determinar el grado de utilización efectivade la unidad vectorial de un procesador. Se realizaŕıa entonces, para aquellos casos donde el usofuera menor del esperado, un diagnóstico del problema que permitiera lograr una mejora en elrendimiento de la aplicación.

1.1. Objetivos

El objetivo principal de este Proyecto Final de Carrera, consiste en determinar el grado deutilización efectiva de la unidad vectorial de un procesador. Para lograr la consecución del mismo,se proponen los siguientes objetivos parciales:

Analizar y clasificar un conjunto de aplicaciones numéricas en función del grado de vectori-zación sobre un compilador determinado.

Determinar las causas del bajo grado de vectorización, a partir de la simulación de lasaplicaciones según el funcionamiento de un producto existente que hace uso de la unidadvectorial. Las posibles causas serán las siguientes:

• Problemática en el algoritmo base de la aplicación debido a dependencias en el código.• Problemática en los criterios seguidos a la hora de escribir el código fuente.• Incapacidad del compilador de detectar que el código es vectorizable.• Problemas en la microarquitectura.

Proponer cambios hardware/software que faciliten el uso efectivo de la unidad vectorial.

Caṕıtulo 2

Estado del arte

La computación paralela es una forma de cómputo consistente en paralelizar la mayor cantidadde tareas posible con el objetivo de reducir el coste de cómputo de un programa. Tradicionalmentese utilizaba otro paradigma: la computación serie. Con ella las instrucciones se ejecutaban unatras otra en la Unidad Central de Procesamiento (CPU). La utilización de este paradigma produceque, a medida que se incrementa la frecuencia de funcionamiento de la máquina, se disminiuya eltiempo que tardan en ejecutarse los programas[HP02]. El aumento de la frecuencia, que tuvo suapogeo durante las dos últimas décadas del siglo XX y principios del XXI, no pod́ıa ser infinito,ya que es directamente proporcional al aumento de la enerǵıa consumida por el procesador y, porende, a la generación de calor. Por este motivo, pese a que la computación paralela se empezó ausar principalmente en el área de la computación de altas prestaciones, este ĺımite en el aumentode la frecuencia propició que desde la ultima década, el paradigma principal en arquitectura decomputadores sea la computación paralela.[Bar07]

Existen diferentes fuentes de paralelismo disponibles para sacar partido a la computaciónparalela. Estas son: Paralelismo de Instrucciones (ILP), Paralelismo de Datos (DLP) y Paralelismode Tareas (TLP)[Dı́06]:

ILP: consiste en ejecutar el mayor número de instrucciones posibles en paralelo sin que elloafecte al correcto flujo del programa. Como ejemplos tenemos las arquitecturas superescalaresy VLIW, del inglés Very Long Instruction Word:

• Superescalares: capaces de introducir en el pipeline de ejecución una o má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 seejecutarán simultáneamente.

Con el objetivo de explotar al máximo esta fuente de paralelismo, existen diferentes técnicasque se podŕıan clasificar en técnicas de planificación estática y dinámica[Dı́06].

• Técnicas de planificación estática: trabajan sobre el código de la aplicación paraconseguir eliminar todos los obstáculos que impiden que las instrucciones se ejecutenlo antes posible: desenrollamiento de bucles, reordenamiento de instrucciones...

• Técnicas de planificación dinámica: se aplican sobre el diseño del hardware paraque tengan lugar en tiempo de ejecución: Ejecución Fuera de Orden (OOO).

DLP: consiste en la realización de la misma operación simultáneamente sobre un conjuntode datos. Para explotar esta técnica de paralelismo, es necesario que el programa tenga

3

4 CAPÍTULO 2. ESTADO DEL ARTE

secciones de código que se puedan adaptar a la aplicación de este concepto. Ademá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 más de un dato. La estructura de ejecución porantonomasia sobre la que se pone en práctica este mecanismo, es el bucle. Las estructurasde datos análogas son los vectores y matrices.

TLP: el concepto radica en la descomposición de la ejecución del programa en diferentestrazas con instrucciones independientes para ejecutarlas de forma concurrente. Un ejemplo esla Tecnoloǵıa Multihilos, SMT, del inglé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 extensión SIMD Avanzada, también conocida como NEON o MPE, del inglés MediaProcessing Engine, para explotar el paralelismo de instrucciones; Nvidia y su plataforma CUDA,del inglés Computed Unified Device Architecture, junto con el set de instrucciones PTX, delinglés Parallel Thread Execution[nvi], que define una máquina virtual y un ISA con el objetivo deexplotar la GPU como máquina de ejecución de hilos paralelos de propósito general; Intel R©y suarquitectura Intel R© MIC, del inglés Many Integrated Core, sobre la que han desarrollado variosproductos, siendo el último de ellos el Intel R© Xeon PhiTM Coprocessor, lanzado al mercado enNoviembre de 2012 y descrito en la Sección 2.3 (pá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 clasificació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 estaŕıan clasificadas según la concurrencia delprocesamiento de secuencias, datos e instrucciones. Esto da como resultado una metodoloǵıa declasificación de las distintas operaciones paralelas disponibles en el procesador. Propuesta comouna aproximació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 máquinas tradicionales de unúnico procesador secuencial o antiguos mainframes entraŕıan en esta categorización. VerFigura 2.1 (pág. 5).

Single Instruction Multiple Data (SIMD): arquitectura que explota el paralelismo du-rante la ejecución de una única instrucción para realizar operaciones de naturaleza paralela.Claros ejemplos son los procesadores vectoriales o las GPU. Ver Figura 2.2 (pág. 5).

Multiple instruction Single Data (MISD): múltiples instrucciones operan sobre unúnico stream de datos. Es una arquitectura poco comú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 (pág. 5).

Multiple instruction Multiple Data (MIMD): múltiples procesadores executan si-multáneamente diferentes instrucciones sobre diferentes datos. Las arquitecturas VLIW sonun claro ejemplo aparte de sistemas distribuidos o procesadores multicore. Ver Figura 2.4(pág. 5).

2.2. VECTORIZACIÓN 5

Figura 2.1: SISD Figura 2.2: SIMD Figura 2.3: MISD Figura 2.4: MIMD

2.2. Vectorización

La vectorización es un proceso de explotación de paralelismo de datos consistente en convertirun algoritmo de implementación escalar a vectorial. La implementación escalar es aquella enla que se realiza una única operación simultánea sobre un par de operandos que contienen unúnico dato cada uno. La implementación vectorial realizaŕıa la misma operación, pero el par deoperandos pasan de contener un ú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


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 reducción del número de instrucciones léıdas y decodificadas resulta no ser tal si al final lainstrucción va a tener que esperar a que se lea el vector o porción del vector de memoria. Poresto, existen diversos esquemas de optimización del rendimiento centrados en reducir el tiempo deacceso a la memoria:

Hardware y software prefetching: prefetching en términos generales significa traer datoso instrucciones de memoria antes de que se necesiten. Cuando la aplicación necesita datos quese han tráıdo con el prefetching, puede tomarlos directamente en vez de tener que esperar porla memoria. Esta té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 encargaŕıa de indexar la lectura del vector mien-tras que el scatter se encargaŕıa de la escritura. En su funcionamiento intervienen máscarasque indicaŕıan los elementos del vector sobre los que se realizaŕıa la operación. Estas podŕıanser útiles en caso de haber condiciones en el interior del bucle para acceder a datos de formadispersa.

Stripmining: técnica que afronta un problema en la vectorización consistente en que losregistros vectoriales no tienen por qué ser capaces de contener un vector completo definidoen la aplicación. Consistiŕıa en romper el bucle de la aplicación que opera sobre el vector endiferentes bucles: prólogo, principal y eṕılogo según conviniera, para tratar un número dedatos

2.2. VECTORIZACIÓN 7

3DNow!: extensión al repertorio de la arquitectura x86 desarrollado por AMD. Registros32 bits para operaciones de punto flotante de simple precisión. El objetivo era mejorar elya existente repertorio MMX de Intel de cara a elevar el rendimiento de las aplicacionesgráficas. En 2010 AMD anunció el fin del mantenimiento y soporte del mismo.

SSE: Streaming SIMD Extensions. Extensión de la arquitectura x86 diseñado por Intel ylanzado al mercado en 1999 en su serie Pentium III, como respuesta al lanzamiento por partede AMD de su extensión 3DNow. Registros de 128 bits.

AltiVec: repertorio diseñado por y propiedad de la siguientes empreas: Apple, aqúı 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. Extensió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 años después cuando salió al mercado como caracteŕısticade la generació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 anunció AVX-512,última extensión con registros de 512 bits.

Ventajas

Los procesadores vectoriales y por extensión el uso de la vectorización, proporcionan las si-guientes ventajas:

Los programas son de menor tamaño al reducir el número de instrucciones que pudierarequerir un bucle. Ademas, el número de instrucciones ejecutadas también se ve reducido alpoder concentrar un bucle en una única instrucción.

El rendimiento de la aplicación mejora. Se tienen N operaciones independientes que utilizanla misma unidad funcional, explotando al máximo la localidad espacial de la memoria cache.

Las arquitecturas son escalables: se obtiene un mayor rendimiento cuantos más recursoshardware haya disponibles.

El consumo de enerǵıa se reduce. Mientras la instrucción vectorial se está ejecutando, no esnecesario alimentar otras unidades tales como el ROB o el decodificador de instrucciones.

Tomando como ejemplo una aplicación multimedia que cambia el brillo a una imagen, lavectorización proporciona dos mejoras claras: en primer lugar el conjunto de datos se entiendecomo un vector y no como valores individuales. Esto permitirá cargar en un registro todos aquellosdatos que éste pueda albergar, en vez de convertir el programa en una retah́ıla carga-opera-guardasobre una gran cantidad de ṕıxeles individuales. En segundo lugar, la paralelización del trabajo enuna única instrucción es evidente. Cuanto más datos pueda albergar, mayor será el rendimiento.

Inconvenientes

Los procesadores vectoriales comparados con multiprocesadores o procesadores superescalarespodŕıan resultar menos interesantes si lo miramos desde el punto de vista del coste:

Necesitan memoria on-chip rápida y por consiguiente cara.


Hay que diseñarlos de forma espećıfica. La unidad vectorial de los procesadores vectorialesno se compone de elementos prefabricados más allá de las unidades básicas, por tanto pocasventas del producto final se traduciŕıa en pérdidas debido a su coste de diseño y validación.

Mientras que se consegúıa una ventaja en el consumo de enerǵıa al reducir la alimentaciónde otras unidades, el consumo por parte de los registros vectoriales podŕıa no mejorar elbalance final de consumo.

Los compiladores, al igual que pueden facilitar la tarea, pueden dificultarla en caso de quela vectorización del código no se adapte a los requerimientos esperados por el compilador.Existe entonces una posibilidad real de que haya una importante implicación del ingenierotanto a nivel alto como bajo para conseguir vectorizar una aplicación.

No hay un estándar establecido en el proceso. La utilización de un repertorio de instruccionesSIMD u otro puede dificultar la tarea en caso de compilar la misma aplicación sobre distintasarquitecturas. Aparte, es posible que el ingeniero tenga que proveer de una implementaciónno vectorial de la misma.

No todas las aplicaciones se pueden vectorizar. Por ejemplo, las aplicaciones de análisis decódigo, caracterizadas por su fuerte control del flujo de ejecución, son claras candidatas parano beneficiarse de las ventajas de la vectorizació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 lanzó al mercado en Noviembre de 2012. La arquitectura Intel R©MIC se basa en la combinación de muchos núcleos de Intel R© dentro de un único chip. Esta des-tinada a su uso en la Computación de Alto Rendimiento o HPC, del inglés High PerformanceComputing, para la ejecución de programas paralelos que se veńıan ejecutando en grandes clú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 instalación de múltiples clústeres y donde se impongan limitaciones deconsumo de enerǵıa. Ademas, un punto clave de la microarquitectura es que esta construida espe-cialmente para proporcionar un entorno de programación similar al entorno de programación delprocesador Intel R© XeonTM[intb].

El coprocesador Intel R© Xeon PhiTM puede pasar por un sistema en śı mismo, puesto que correuna distribución completa del sistema operativo Linux, soporta el modelo x86 de ordenamientode memoria y el estándar IEEE 754 de aritmética en punto flotante. Ademas es capaz de ejecutaraplicaciones escritas en lenguajes de programació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 libreŕıas de apoyo (siendo de especial importancia aquellascon soporte multi-thread y operaciones matemáticas para HPC) y herramientas de caracterizacióny depurado.

Está conectado a un procesador Intel R© Xeon, denominado ”host”, a través de un bus PICExpress. Véase Figura 2.6 (pág. 9). Dado que el coprocesador ejecuta de forma autónoma elsistema operativo Linux, es posible virtualizar una comunicación tcp/ip entre éste y el procesador,permitiendo al usuario acceder como si fuera un nodo más en la red. Por tanto, cualquier usuariopuede conectarse al mismo a través de una sesión ssh (secure shell) y ejecutar sus aplicaciones.Además, soporta aplicaciones heterogéneas en las que una parte de la misma se ejecutaŕıa enel host y otra en la propia tarjeta. Ni qué decir tiene que se pueden conectar más de un Xeon

1Se aplica a los conjuntos de computadoras construidos mediante la utilización de elementos hardware comunesy que se comportan como si fuesen una ú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, pudiéndose establecer entre ellos la comunicación ya sea a través de lainterconexión p2p (peer to peer) o a través de la tarjeta de red del sistema, sin intervención enambos casos del host.

Figura 2.6: Esquema general

2.3.1. Microarquitectura

El coprocesador Intel R© Xeon Phi esta formado por más de 50 núcleos de procesamiento,memorias cache, controladores de memoria, lógica de cliente PCIe y un anillo de interconexiónbidireccional que proporciona un elevado ancho de banda al sistema. Véase Figura 2.7 (pág. 10).La ejecución es en orden mientras que la terminació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 inglés Tag Directory. Los controladores de memoria y la lógicade cliente PCIe proporcionan una interfaz directa con la memoria GDDR5 del coprocesador y elbus PCIe respectivamente. Ademas, cada core fue diseñado para minimizar el uso de enerǵıa a lavez que maximiza el throughput en programas altamente paralelos. Usan un pipeline en orden ysoportan hasta 4 hilos hardware.


Figura 2.7: Microarquitectura

VPU

Un importante componente de cada núcleo del coprocesador Intel R© Xeon PhiTM es la VPU.Véase Figura 2.8 (pá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 precisión (SP) u 8 de doble precisión (DP) por ciclo. Tambiénsoporta instrucciones Fused Multiply-Add (FMA), que ordenan multiplicar y sumar en la mismainstrucción, y gracias a las cuales se pueden ejecutar 32 instrucciones de simple precisión o 16 depunto flotante por ciclo. Ni qué decir tiene que proporciona soporte para operaciones con enteros.

Figura 2.8: Vector Processing Unit

Las unidades vectoriales proporcionan una evidente mejora energética en la ejecución de apli-caciones HPC, ya que una única operación codifica una gran cantidad de trabajo, a la vez que noincurre en el coste adicional de enerǵıa que supondŕıan las etapas de fetch, decode y retire parala ejecución de múltiples instrucciones. Sin embargo, hicieron falta varias mejoras para lograr so-portar instrucciones SIMD de estas caracteŕısticas. Por ejemplo, se añadió el uso de máscaras a laVPU para permitir predecir sobre qué datos operar dentro de un registro vectorial. Esto ayudó enla vectorización de bucles con flujos de ejecución condicionales, mejorando aśı la eficiencia softwaredel pipeline. La VPU tambien soporta instrucciones de tipo gather y scatter directamente a travésdel hardware. De este modo, para aquellos códigos con patrones de acceso a memoria esporádicose irregulares, el uso de este tipo de instrucciones ayuda a mantener el código vectorizado.

Finalmente, la VPU también cuenta con una EMU, del inglés Extended Math Unit, que puedeejecutar instrucciones trascendentes como son las rećıprocas, ráıces cuadradas y logaŕıtmicas. LaEMU funciona calculando aproximaciones polinómicas de estas funciones.

2.3. INTEL R© XEON PHITM COPROCESSOR 11

Interconexión

La interconexión se implementa como un anillo bidireccional. Véase Figura 2.9 (pág. 11). Cadadirección está compuesta de tres anillos independientes. El primero, que se corresponde con elmá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 esmás estrecho y se utiliza para enviar comandos de lectura/escritura y direcciones de memoria.Por último, el anillo má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 dirección se env́ıa sobre elanillo de direcciones a los directorios de etiquetas. Véase Figura 2.10 (pág. 11). Las direcciones dememoria se distribuyen de manera uniforme entre los distintos directorios que hay en el anillo paraañadir la fluidez de tráfico como una caracteŕıstica más del mismo. Si el bloque de datos solicitadose encuentra en la cache L2 de otro core, se dirige una petició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 dirección dememoria desde el directorio de etiqueta hasta el controlador de memoria.

La Figura 2.11 (pág. 12) muestra la distribución de los controladores de memoria en el anillo.Como se aprecia, se intercalan de forma simétrica alrededor del él. La asignación de los directoriosde etiquetas a los controladores de memoria se realiza de forma todos-a-todos. Las direccionesse distribuyen uniformemente a través de todos los controladores, eliminando de este modo loshotspots y proporcionando un patró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, éste genera una petición de dirección en el anillo


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 direcció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 través delanillo de datos. En todo el proceso los elementos trasmitidos a los anillos son: un bloque de datos,dos solicitudes de dirección junto con dos mensajes de confirmación. Debido a que los anillos dedatos son los más caros y están diseñados para soportar el ancho de banda requerido, es necesarioincrementar el número de anillos de dirección y reconocimiento, más baratos en comparación, enun factor de dos para soportar las necesidades de ancho de banda causadas por el elevado númerode peticiones sobre los anillos.

Caches

La arquitectura Intel R© MIC invierte en mayor medida tanto en caches L1 como L2 en compa-ración con las arquitecturas GPU. El coprocesador Intel R© Xeon PhiTMimplementa un subsistemade memoria en el que cada core está 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, más rápido que el ancho de banda dela memoria principal. Por lo tanto, el uso efectivo de esta jerarqúıa es clave para lograr el máximorendimiento en el coprocesador. Además de mejorar el ancho de banda, son también más eficientesque la memoria principal en cuanto al uso de enerǵıa para el suministro de datos al core. En la erade la computación exascale3, las caches jugarán un papel crucial a la hora de conseguir maximizarel rendimiento bajo estrictas restricciones de potencia.

Imágenes corteśı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 inglés Advanced Vector Extensions engloba, como véıamos en la Sección 2.2.1 (pá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 añ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 cambió en consecuencia de YMM0-YMM7 (en el caso de x86-64, YMM0-YMM15). Sin embargo, en los procesadores con soporte AVX, las instrucciones de laextensión SSE pod́ıan ser usadas para operar en los 128 bits menos significativos de los registrosYMM. Entonces pod́ıa seguir usándose la nomenclatura XMM0-XMM7.

AVX introdujo además un formato de instrucción SIMD de tres operandos donde el registrode destino pod́ıa ser distinto a los dos registros fuente. Por ejemplo, una instrucción SSE usandola forma convencional a = a + b, pod́ıa ahora utilizar el método de tres operandos c = a + b,impidiendo que se destruyera la información almacenada en alguno de ellos como ocurŕıa hastael momento. Este formato estaba limitado a las instrucciones que utilizan los registros YMM, noincluyendo por tanto instrucciones con registros de propósito general (por ejemplo EAX).


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 compañ́ıaamplió por tanto el juego AVX con nuevas instrucciones que funcionaban también sobre númerosnaturales, ampliando casi la totalidad del conjunto SSE de 128 bits a 256 bits. El formato nodestructivo de tres operandos estuvo ahora también disponible para instrucciones a nivel de bitsy multiplicación de propósito general y para instrucciones FMA (Fused Multiply-Accumulate).Finalmente, esta nueva ampliación permitió realizar instrucciones gather, lo que significaŕı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.


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 año 2015[inta]. No todas las extensio-nes están destinadas a ser soportadas por todos los procesadores que las implementen. Sólo laextensión del núcleo AVX-512F (AVX-512 Foundation) se requiere para todas las implementacio-nes. Atendiendo al repertorio de instrucciones y a las principales caracteŕısticas de AVX-512, lasextensiones se clasifican del siguiente modo:

AVX-512 Foundation: expande la mayoŕıa de instrucciones AVX de 32 y 64 bits con elesquema de codificación EVEX para soportar los registros de 512 bits, las operaciones con


máscaras, la difusión de parámetros y las excepciones de control y redondeo empotradas.

AVX-512 Conflict Detection Instructions (CDI): añade detección de conflictos efi-ciente para permitir que más bucles puedan ser vectorizados.

AVX-512 Exponential and Reciprocal Instructions (ERI): operaciones exponencialesy rećıprocas diseñadas para ayudar en la implementación de operaciones trascendentes, comopor ejemplo la función de logaritmo.

AVX-512 Prefetch Instructions (PFI): soporte para prefetches.

En cuanto a las caracteŕısticas té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 má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 podrán entonces empaquetar en los nuevos registros de 512 bits cualquiera delas siguientes combinaciones de datos: 8 datos en punto flotante de precisión doble, o 16 datos enpunto flotante de precisión simple, u 8 enteros de 64 bits o 16 enteros de 32 bits. Esto permitirá elprocesamiento del doble de elementos que el AVX/AVX2 con una sola instrucció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 penalizació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 operarán en los 128 o 256 bits inferiores de los primeros 16 registrosZMM.

Caṕıtulo 3

Metodoloǵı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 análisis. Comprend́ıadesde el análisis de todas y cada una de las herramientas a utilizar, hasta el análisis de cada resul-tado, cada gráfica elaborada, cada bloque básico implicado y cada ĺınea de código que supusieraun objeto de interés sobre el que adentrarse. Por este motivo no se aplicó una estrategia espećıfi-camente etiquetada que seria propia de un trabajo vinculado a la rama de ingenieŕıa del software.Ciertamente, parte de este trabajo consist́ıa en desarrollar un simulador sobre el que ejecutar lasaplicaciones, con el objetivo de obtener más estad́ısticas aparte de aquellas conseguidas gracias alas herramientas ya disponibles para los ingenieros de Intel R©. Sin embargo, incluso el tomar ladecisión de incorporar el desarrollo de este simulador como una extensión de otro ya existente,supuso un fuerte trabajo de análisis para tratar de reciclar la mayor cantidad de información yadisponible. Esta informació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 también impedirsobrecargar al simulador con operaciones y tareas que eran necesarias y que por supuesto ya seestaban realizando.

En este caṕıtulo, se describirá la forma de trabajo, es decir aquellas actividades que supusieronuna importante parte para la consecución del trabajo, cómo se distribuyeron todas las tareas arealizar y el tipo de metodoloǵıa usada cuando se procedió al desarrollo de la nueva extensión delsimulador.

3.1. Plan de trabajo

Al plan de trabajo diseñado inicialmente y presentado en el anteproyecto se le aplicaron mo-dificaciones sin que ello repercutiese en el computo total de horas. A continuación se presenta laplanificación final y las justificaciones sobre los cambios en el caso de haberlos.

Fase 1: Selección y caracterización de benchmarks

1. Selecció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 extensión AVX-512 para la obtención de una caracterización inicial. Utilizando los compiladores disponibles,

15

16 CAPÍTULO 3. METODOLOGÍA

como ICC e IFORT, se realiza la compilación del conjunto de aplicaciones seleccionadas uti-lizando aquellas opciones que permitan realizar optimizaciones y vectorización del código.Implica un pequeño análisis mediante el parsing del informe generado, para tener una apro-ximación inicial al comportamiento de cada aplicación.

Esta fase se redujo a la selección y posterior caracterización de las aplicaciones. El motivo porel que no se realizó una criba inicial radica en que al principio, sin más datos que los disponiblesestáticamente con el informe del compilador, la mera descripción de la aplicación no parećıasuficiente para descartar unas u otras. Era más interesante quedarnos con todas las disponiblesy, a partir de diferentes estad́ısticas, tomar decisiones sobre cuáles analizar según las solucionessoftware o hardware a aplicar.

Fase 2: Recopilación y análisis de información sobre la ejecución vectorial de losprogramas de prueba

1. Determinación del grado de vectorización de los programas: Usando el emulador Pin/SDE,se obtiene el número de instrucciones ejecutado por cada programa y se determina el gradode vectorización de los mismos.

2. Recopilación de información sobre la jerarqúıa de memoria: Usando el emulador CMP$im,se obtiene la tasa de fallos de los diferentes niveles de la jerarqúıa de memoria para cadauno de los programas de prueba.

3. Determinación del grado de utilización de la unidad vectorial: En este apartado se desa-rrollará un núcleo sencillo basado en la arquitectura del coprocesador Intel R© Xeon PhiTMsobre el simulador CMP$im, que permita obtener datos estad́ısticos para aśı determinar elgrado de utilización de la unidad vectorial.

La única modificación planteada en esta fase consistió 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 información de interés que puede utilizarsepara la simulación de la arquitectura. Además, contiene multitud de estructuras y clases que sepueden utilizar a la vez que se introduce el código sobre el esqueleto correspondiente a la simulaciónde cache.

En primer lugar se llevaŕıa a cabo una exhaustiva fase de análisis sobre CMP$im, para conoceren profundidad tanto la configuración de ficheros del simulador, como las estructuras y clasesusados, aparte del funcionamiento espećıfico de la simulación de la cache. Los objetivos principaleseran reutilizar estructuras, esquemas y clases ya presentes, saber de qué modo introducir el códigocorrespondiente al simulador de la arquitectura para no entorpecer la simulación ya hecha y poderhacer uso de las estad́ısticas recopiladas.

Una vez conocidas las caracteŕısticas principales mencionadas, hab́ıa que proceder a la fasede desarrollo de la extensión correspondiente a la simulación de la arquitectura vectorial. Lametodoloǵıa más apropiada para desarrollarlo seŕı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 teńıa que comprobar que todosegúıa funcionando correctamente antes de proceder a la incorporación del siguiente incremento.Cada una de las funcionalidades se iba a discutir y diseñar en reuniones semanales, de manera queal final de cada semana se tendŕı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: Determinación de cuellos de botella en la ejecución vectorial y propuesta desoluciones

1. Selección de un subconjunto de aplicaciones numéricas de entre todos los benchmarks selec-cionados, teniendo como referencia las estad́ısticas recolectadas. Para la selección se tomaroncomo criterio tanto la relación entre las versiones escalar y vectorial, aśı como el desglose deciclos de la aplicación según las dependencias ocasionadas durante la ejecución.

2. Con la información recolectada en los puntos anteriores se determinará cuáles son las re-giones del código que tienen un bajo uso de la unidad vectorial. Se estudiará a posterioricuál es el motivo: si se trata de una falta de vectorización, si se produce por ĺımites en lamicroarquitecura u otros.

3. Adicionalmente, se propondrán mejoras hardware y/o software encaminadas a aumentar elrendimiento de estas regiones con bajo uso de la unidad vectorial.

En esta fase, se incluyó la selección de las aplicaciones, ya que a estas alturas están com-pletamente caracterizadas, de manera que la información disponible permite tomar decisionesbasándonos exclusivamente en el comportamiento de las mismas.

Caṕıtulo 4

Herramientas

En este caṕıtulo se introducen las caracteŕısticas principales de las herramientas más signifi-cativas usadas a lo largo del proyecto.

4.1. Pin

Pin1 es una herramienta de código abierto desarrollada por la empresa Intel R©, destinada ala instrumentación de aplicaciones [pin]. Se denomina herramienta de Instrumentación BinariaDinámica porque la instrumentación se realiza en tiempo de ejecución (JIT, Just in Time):

No requiere que la aplicación a instrumentar se tenga que recompilar.

Permite instrumentar programas que generan código diná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 permitirá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, podrá utilizar información decontexto, tales como el contenido de los registros o las direcciones de acceso a memoria, pasándolacomo diferentes parámetros dentro del código que el proceso de instrumentación inserta en elbinario. Además, Pin salva y recupera el contenido de los registros que se utilizaran en dichocódigo, de manera que no influyan en la ejecución normal del programa instrumentado.

Fue utilizada a la hora de estudiar y modificar el simulador que se va a utilizar para simularlas aplicaciones numéricas.

4.1.1. Pintools

Una pintool, sea cual sea su funcionalidad, constará de dos secciones fundamentales en sucódigo:

1No es un acrónimo.

19

20 CAPÍTULO 4. HERRAMIENTAS

Instrumentación: contendrá las instrucciones necesarias que indiquen a Pin qué informaciónse quiere recoger del código que se está ejecutando, como códigos de registro, hilos en ejecu-ción o contador de programa, entre otros. También indica en dónde se quieren insertar lasllamadas a las funciones y procedimientos que harán uso de toda la información recogida.

Análisis: contendrá la definición de todas las funciones y procedimientos que tratarán lainformación recogida en la sección de instrumentación.

Además de estas dos secciones, también contendrá, como cualquier aplicación de C o C++, lafunción main y, como novedad, un procedimiento denominado Fini que es invocado por Pin cuandola aplicación termina. El motivo por el que se tiene que desarrollar este último procedimiento, resideen que una vez hemos dado el control a Pin, no retorna a la función main para terminar.

Pin proporciona una amplia bateŕıa de pintools con diferentes funcionalidades. En el Listado 4.1(pág. 20) se muestra el código de una pintool denominada inscount0 que cuenta el número deinstrucciones ejecutadas de una aplicación. Se encuentra dentro de la extensa bateŕıa de pintoolsde ejemplo que acompañan a la herramienta. Es una muestra perfecta de la estructura más comúnde una pintool, en donde se aprecian tanto las secciones principales descritas, como la definiciónde knobs, opciones de la pintool y otras funciones de interé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 má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 qué función se encargará de la instrumentación anivel de instrucción.

PIN AddFiniFunction: registra qué función se invocará antes de que la aplicación instru-mentada termine.

PIN StartProgram: arranca la ejecución de la aplicación. No se retorna.

INS InsertCall: registra qué función se ha de llamar cuando se encuentren instruccionescandidatas a instrumentar. Entre los parámetros que se observan en Listado 4.2 tenemos:

• ins: instrucción a instrumentar.• IPOINT BEFORE: se invocara el análisis antes de que se ejecute.• docount: función de análisis.• IARG END: fin de parámetros, tanto si los hubiera como si no. Estos parámetros son los

que pasaŕıan a la función docount del ejemplo. Véase Listado 4.3.

1 INS_InsertCall(ins ,2 IPOINT_BEFORE ,3 (AFUNPTR)docount ,4 IARG_END);

Listado 4.2: Función de instrumentació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 función de análisis

4.1.2. Arquitectura software

En la Figura 4.1 se observa la arquitectura software de Pin [LCM+05]. El elemento principal esla máquina virtual, que contiene un compilador just in time que se encarga de recompilar aquellasporciones de la aplicación que se hayan indicado en la sección de instrumentación, sobre las quese inyectará el código de la sección de análisis que le corresponda.

El dispatcher es el encargado de lanzar el código recién compilado que almacena en el á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 máquina virtual.

De entre las entradas que alimentan a Pin, se encuentran lógicamente tanto la pintool como laaplicación. En el Listado 4.4 se observa el esqueleto general de la invocación.


Figura 4.1: Arquitectura software de Pin

1 pin [pin_opts] -t pintool.so [pintool_opts] -- app [input]

Listado 4.4: Ejemplo de invocació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 instrumentación binaria dinámica, que supońıa una alternativa frente a otros métodos desimulación como trace-driven basado en trazas [JCLJ06][JCLJ08].

Es interesante destacar que CMP$im es una herramienta muy rápida y fácil de utilizar. Ademásproporciona una gran cantidad opciones, tanto estáticas de forma #define MACRO, como diná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 simulación. Entre estas opciones se destacanlas siguientes:

Número de niveles de cache.

Número de caches por nivel.

Número máximo de threads que se pueden lanzar con la aplicación.

Poĺıticas de escritura y reemplazo.

Caracteŕısticas particulares para cada cache, como tamaño, asociatividad, latencia, tamañode ĺı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 simulación del mismo modoespecificado en el Listado 4.4 (pág. 22). La salida se compone de un informe con estad́ısticasmuy detalladas, que proporcionan tanto información general de la aplicación, como particulardesglosada por hilos de ejecución y por nivel de cache. Entre ellos, se muestran datos relativos a:

Número total de instrucciones ejecutadas y desglosadas por hilos.

Estimación2 del número de ciclos, donde la latencia de cada instrucción es, por defecto, deun ciclo, añadiendo al total la latencia total generada por los accesos a memoria.

Nú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 núcleo del coprocesador Intel R©XeonPhiTM. Imágenes corteśıa de Intel R©.

4.3. Benchmarks

El benchmarking es una té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 podŕıa saber si la máquinaobtiene buenos resultados o no, de cara a utilizarlos para el fin que convenga.

Aplicado en el campo de la informática consistiŕıa en la ejecución de aplicaciones espećıfica-mente diseñadas para medir el rendimiento de una má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 utilización efectiva de la unidad vectorial de un procesador.

Los benchmarks se pueden clasificar en diferentes categoŕıas. Veamos una posible clasificación:

Benchmarks basados en el nivel del rendimiento que miden:

• Benchmarks de bajo nivel o nivel componente: se encargan de medir directamente uncomponente espećıfico del sistema como, por ejemplo, la memoria RAM, la tarjetagráfica o el procesador.

• Benchmarks de alto nivel o nivel sistema: evalúan el rendimiento global de una máquina.Este tipo es interesante para comparar sistemas que se basan en arquitecturas distintas.

Benchmarks basados en el código que los componen:

• Benchmarks sintéticos: creados espećıficamente combinando diferentes funciones delsistema a probar, en las proporciones que los desarrolladores estiman oportunas. Elobjetivo es conseguir medir determinados aspectos del sistema. Esta descripción seasocia rá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 búsqueda de datos en disco en el benchmark.

2No implementa ningún mecanismo que haga uso del paralelismo de instrucciones (ILP).


• Benchmarks de aplicación: hacen uso de aplicaciones reales. En este caso los desa-rrolladores del benchmark pueden tener interé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 cómocontribuye cada componente al dicho rendimiento.

Independiente de esta clasificación, se pueden tipificar siguiendo otros patrones más espećıficos.Por ejemplo, existen benchmarks que sirven para medir el rendimiento de máquinas con múltiplesnúcleos en su procesador o con mú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 sinté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 sintético creado por la compañ́ıa Futuremark Corporation, con el obje-tivo de medir la capacidad de rendering sobre gráficos 3D que tiene la GPU de una máquina,aśı como la capacidad de procesamiento de la CPU.

Ciusbet: creado por Ciusbet. Es un benchmark que se compone de un gran número depruebas para probar diferentes componentes de una máquina, como la memoria cache, laCPU, el disco duro, etc.

FurmKar: benchmark sintético que mide el rendimiento de una tarjeta gráfica al través dela ejecució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 estrés muy fuerte, permite medir muy bienla capacidad de aguante y estabilidad de la tarjeta.

El conjunto de benchmarks que se presenta a continuación es una muestra continente de va-riedad de aplicaciones numéricas usadas comúnmente en el ámbito de la computació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, diseñados para com-parar el rendimiento de los diferentes ejecutables generados por distintos compiladores. Todos losprogramas se pueden descargar y hacer uso de ellos según convenga. El paquete que actualmenteestá 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 simulación completa de los programas.El nuevo benchmark tiene conjuntos de datos que ralentizaban demasiado su simulació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 medición del rendimiento de las aplicacionesviene determinada por una combinación de diferentes opciones, proporcionan una aproxi-mación excelente para explorarlas. Las opciones mencionadas englobaŕıan las siguientes: elcompilador usado, el hardware de la máquina a medir, el algoritmo, el entorno de ejecución,el uso de miniaplicaciones, definidas como pequeños proxies autocontenidos para aplicacionesreales, etc.

Minidrivers, pequeñ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 impĺıcitas como expĺıcitas, simular modelosde diná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 está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 núcleos del coprocesador Intel R© Xeon PhiTM, se seleccionaron solamente lasaplicaciones correspondientes a la secció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-dición del rendimiento de supercomputadores paralelos. Fueron desarrolladas por la división NAS(NASA Advanced Supercomputing). Inicialmente, en la especificación NPB 1, estaba conformadopor 5 kernels y 3 pseudo aplicaciones. Más adelante fue extendida para incluir nuevos benchmarkssobre mallas adaptativas, aplicaciones E/S paralelas y redes computacionales. Se utilizó la versión3.3.1 que contiene las siguientes aplicaciones:


BT CG DC EP FTIS LU MG SP UA

Los diferentes inputs se categorizan en las siguientes clases:

Class S : para pequeñas pruebas.

Class W : destinada a estaciones de trabajo.

Classes A, B, C : test de mayor tamañ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 nú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 organización sin ánimo delucro cuyo objetivo es producir, establecer, mantener y promocionar un paquete estándar de bench-marks para medir el rendimiento de diferentes máquinas. En este sentido, se dispone del conjuntode benchmarks denominado SPEC CPU2006 diseñado para proporcionar una medida comparati-va, con el objetivo de analizar el rendimiento conseguido después de realizar cálculos intensivossobre una máquina. El conjunto de aplicaciones que lo conforman fueron desarrolladas basadas enaplicaciones de usuario reales. Los resultados que se obtengan serán fuertemente dependientes delprocesador, la memoria y el compilador utilizado.

Dado que el presente trabajo está 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 está 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, están disponibles los siguientes:

all : comú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 más sencillos.

train: tests má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 código necesario con el que se trabajara después. Si bien todos los elementos expuestosen este caṕıtulo son indispensables para conseguir las sinergias que permitirán completar todoslos objetivos definidos en la Sección 1.1 (pág. 2), los compiladores se alzan con la responsabilidadsuprema. En el caso particular de los optimizadores de que constan, son responsables de generar uncódigo adecuado con el que se pueda partir, trabajar y mejorar en caso necesario. Si no fuera aśı,ningún resultado tendŕı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 dispońıa en todo momento de la última versión de los com-piladores. Por tanto, este trabajo serv́ıa también como depurador de los cambios introducidos encada versión. La versió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 implicaŕıa obtener mejoras que no recaeŕıan sobre loscambios en configuraciones utilizadas al simular, sino en las propias mejoras del compilador.

El código generado al compilar contiene las extensiones AVX-512 descritas en la Sección 2.4(pág. 13). Asimismo, mientras los compiladores están disponibles en multitud de plataformas, eneste trabajo se usó la versión para Linux.

Los compiladores fueron usados a la hora de construir la caracterización de todas y cada una delas aplicaciones, y para tener los ejecutables disponibles en el momento de proceder a la simulacióncon la versión de CMP$immodificada.

4.4.1. ICC

El compilador Intel R© ICC permite generar có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 vectorizació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, además, permit́ıan generar código AVX-512. El vectorizadorautomático es un componente importante del compilador, ya que utiliza automá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 automático de las instrucciones de tipo SIMD. El usuario puedeayudar a este módulo mediante el uso de pragmas. Consúltese el conjunto de pragmas disponiblesen la Sección 4.5 (pág. 29)

ICC tiene multitud de knobs de compilación[intc]. Para este trabajo, el formato de las mismasse corresponde con aquel para Linux. A continuación se mostrarán las opciones más significativasusadas en este trabajo. La ĺınea de compilación tiene el formato mostrado en el Listado 4.5. Laopción -no-vec que se observa en la ĺınea de compilación, se usaba para indicar al compiladorque no vectorizase. Como se verá más adelante, la versión no vectorizada de las aplicaciones es deinterés porque sirven de referencia para compararlas con la versió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: Ĺınea de compilación


-g Produce información para depuración simbólica en elfichero objeto.

-debug inline-debug-info Genera información de depuración mejorada tanto enel caso de código del que se haga inline como en elrastro generado por sucesivas llamadas a funciones.

-vec-report6 Genera un log con toda la información concernien-te a los bucles y bloques que han sido vectorizados,aśı como de las razones porque otros no lo han sido.

-ansi-alias Indica al compilador que compile bajo las reglas dealiasability estándares de la ISO de C.

-O3 Aparte de las optimizaciones de la opción -O2, in-cluye prefetching, transformación de bucles y susti-tución de escalares.

-no-prec-div Permite optimizaciones que, a cambio de divisionesalgo menos precisas que las operaciones de divisiónen śı mismas, sustituye estas por multiplicaciones.Por ejemplo, en vez de A/B, se calculaŕıa A*(1/B)

-ipo Interprocedural Optimization. Indica al compiladorque haga inline de las llamadas a funciones que seencuentran en otros ficheros. Un ejemplo seŕıa enaquellas llamadas dentro de bucles. Por defecto elvalor es 0, esto es que se dejara al compilador decidirsi crear uno o más ficheros objetivo dependiendo deuna estimación del tamaño de la aplicación.

-static Impide enlazar con libreŕıas compartidas. En su lu-gar, enlaza todas las libreŕıas estáticamente.

-xKNL La arquitectura para la que se está generando códigoes KNL, que incluye AVX-512.

-no-vec Impide al compilador hacer uso del módulo de vecto-rización. El log resultante de aplicar esta opción nocontendŕıa más información que la ĺınea de compila-ció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 caracteŕısticasanálogas al compilador ICC, como es el soporte para la vectorización de aplicaciones, y compartela mayoŕıa de knobs disponibles.

La ĺınea de compilación solo difiere en la opció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 compilació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: Ĺınea de compilación

4.5. Pragmas

Los pragmas son directivas que sirven para especificar qué 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 programación, ya que no figuran en su gramá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$. Además, hayque tener en cuenta que los pragmas son dependientes tanto de la máquina como del sistemaoperativo, aparte de que cada compilador tiene su propio conjunto. Es también posible que lafuncionalidad proporcionada por un pragma se consiga con alguna opción particular de compila-ció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 Apéndice A (pág. 105), el Apéndice B (pág. 109)y el Apéndice C (pág. 113), está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 má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 clasificación:

Intel R© ICC Specific Pragmas: desarrollados espećı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


la propia organización, al poner su disponibilidad bajo la previa aprobació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 autorizació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 aná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 más legible y fácil de estudiar, que lo que un fichero de texto con multitud de números yĺıneas permite.

La herramienta que se usó principalmente permit́ıa, para cada unas de las aplicaciones simu-ladas, entre otras funcionalidades, las siguientes:

Analizar los bloques básicos individualmente.

Consultar el código fuente asociado a cada bloque básico.

Visualizar el flujo de ejecución del programa.

Consultar la distribución de funciones e instrucciones.

Sintetizar la información procedente de cada nivel de la cache.

Todas ellas se usaron principalmente durante la caracterización de las aplicaciones y a la horade realizar el diagnóstico software para averiguar las causas del bajo grado de vectorización.

Caṕıtulo 5

Arquitectura del Simulador

En el presente caṕıtulo se hará un análisis más en detalle del funcionamiento del simuladorCMP$im presentado en la Sección 4.2 (pág. 22). Debido a que es una pintool y que esta ı́ntima-mente relacionado con la herramienta Pin, habrá detalles de Pin que será necesario exponer paracomprender mejor el esquema general del simulador.

5.1. Flujo de ejecución

Las dos secciones principales en las que se organiza una pintool, como se describieron en laSección 4.1.1 (pág. 19), son las secciones de instrumentación y de análisis. CMP$im no es unaexcepción. En la Figura 5.1 (pág. 31) se presenta una visión general de cómo funciona.

En primer lugar tenemos la función main, donde se recogen las opciones de configuración dela pintool introducidas por parámetro y tanto la aplicación objeto del análisis como sus datos deentrada. Aqúı también se llevan a cabo las inicializaciones pertinentes según la configuración decache que se haya elegido. Una vez se lanza la simulación no se retorna. Por ello, la finalización dela aplicación está ligada a una función de terminación que

Documents

Estudio de utilizaci on efectiva de procesadores vectoriales · 2020. 2. 26. · procesadores vectoriales Proyecto de Fin de Carrera Ingenier a en Inform atica Laura Aut on Garc a