Estudio de utilizaci on efectiva de procesadores vectoriales · procesadores vectoriales Proyecto de Fin de Carrera Ingenier a en Inform atica Laura Aut on Garc a Tutores: Francisca

Universidad de Las Palmas de Gran Canaria

Estudio de utilizacion efectiva deprocesadores vectoriales

Proyecto de Fin de Carrera

Ingenierıa en Informatica

Laura Auton 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 sueno de cual-quier futuro ingeniero informatico cuando avista cada vez mas cerca la meta de su esfuerzo. Esteviaje no solo ha dado como resultado el presente trabajo, sino tambien la satisfaccion profesio-nal de haber trabajado en Intel, empresa puntera en el ambito de la computacion, y personal dehaber trabajado con extraordinarios ingenieros a la vez que fantasticas personas durante todo elproceso. Entre ellos, quiero agradecer especialmente a Manel Fernandez por la enorme pacienciay dedicacion con las que consiguio guiarme cuando me desviaba del camino, y a Jesus Sanchezporque 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 Candido por haber sabidoapoyarme desde la distancia con sus palabras al otro lado del telefono. Y a Raul, mi gran companeroen este viaje, porque ha sido la unica persona de este mundo que realmente ha conocido mis masprofundas inquietudes, y que ha sabido iluminarme el camino y cederme las mangas sobre las quederramar mis lagrimas.

i

Indice 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. Simulacion en modo buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3. Simulacion en modo instruccion a instruccion . . . . . . . . . . . . . . . . . . . . . 335.4. Ejemplo de bloque basico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.5. Proceso de descubrimiento de bloques . . . . . . . . . . . . . . . . . . . . . . . . . 345.6. Punteros a objetos cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1. Indice de vectorizacion de las aplicaciones de Polyhedron . . . . . . . . . . . . . . . 406.2. Razones para no vectorizar bucles en Polyhedron . . . . . . . . . . . . . . . . . . . 416.3. Indice de vectorizacion de las aplicaciones de Mantevo 1.0 . . . . . . . . . . . . . . 426.4. Razones para no vectorizar bucles en Mantevo 1.0 . . . . . . . . . . . . . . . . . . 436.5. Indice de vectorizacion de las aplicaciones de Sequoia . . . . . . . . . . . . . . . . . 446.6. Razones para no vectorizar bucles en Sequoia . . . . . . . . . . . . . . . . . . . . . 446.7. Indice de vectorizacion de las aplicaciones de NPB . . . . . . . . . . . . . . . . . . 456.8. Razones para no vectorizar bucles en NPB . . . . . . . . . . . . . . . . . . . . . . . 466.9. Indice de vectorizacion 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. Localizacion del simulador de pipeline en CMP$im . . . . . . . . . . . . . . . . . . 567.4. Idea para la implementacion de KNC . . . . . . . . . . . . . . . . . . . . . . . . . . 567.5. Instruccion que toca dos lıneas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.6. Bloques con ningun y un corte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.7. Bloques con 2 cortes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

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

iii

iv INDICE DE FIGURAS

8.6. Ciclos desglosados de las aplicaciones de Sequoia . . . . . . . . . . . . . . . . . . . 708.7. Version vectorizada vs no vectorizada de NPB . . . . . . . . . . . . . . . . . . . . . 718.8. Ciclos desglosados de las aplicaciones de NPB . . . . . . . . . . . . . . . . . . . . . 728.9. Version vectorizada vs no vectorizada de SPEC fp . . . . . . . . . . . . . . . . . . 738.10. Ciclos desglosados de las aplicaciones de SPEC fp 2006 . . . . . . . . . . . . . . . . 738.11. Comparacion 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

Indice 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 instruccion (load-op) . . . . . . . . . . . . . . . . . . . 51

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

Indice general

Agradecimientos I

Lista de figuras VIII

Lista de tablas VIII

1. Introduccion 11.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Estado del arte 32.1. Taxonomıa de Flynn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. Vectorizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2. Estructuras y clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3. Parametros de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

vii

viii INDICE GENERAL

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

7. Adaptacion del Simulador 497.1. Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.2. Deteccion 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. Invocacion 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. Diagnostico 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. Diagnostico 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

Introduccion

Echando una profunda mirada al pasado para recorrer toda la historia de la informatica, desdedonde venimos, en que punto nos encontramos y a donde vamos, nos damos cuenta del gran esfuerzoque ha hecho y sigue haciendo el ser humano para no solo automatizar tareas, sino tambien paraque estas se hagan lo mas rapido posible. Y es que, ya en su momento, para realizar calculosbalısticos de gran utilidad en posibles contiendas, se incrementaba el numero 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 mas tarde se adopto para las maquinas que sustituyeron su trabajo.

Desde entonces, la capacidad de computo de las maquinas 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 afirmacion se bautizo como Leyde Moore. Cuando las limitaciones fısicas se convirtieron en un problema, empezamos a introducirmas nucleos en un mismo procesador: primero dos, luego cuatro... Esta claro que, sean los motivosque sean los que impulsen al ser humano a seguir escudrinando 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 vectorizacion.

Hoy en dıa, una importante muestra de procesadores disponibles en el mercado disponen deunidades de computo, denominadas vectoriales, que permiten la explotacion de este concepto. Yes que la vectorizacion explota un caso particular de paralelismo cuyo objetivo consiste en realizarla misma operacion, en vez de sobre un unico 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 explotacion 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 mas, y que no es otro que un compilador especialmente construido para maquinascomo estas, que sea capaz de extraer el mayor paralelismo de datos posible de una aplicacion.

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 computo, nosiempre se obtienen los resultados esperados. Las razones pueden residir tanto en el software comoen el hardware. Puede que la aplicacion no experimente las mejoras esperadas despues de servectorizada. Es posible que el compilador no sea capaz por sı mismo de encontrar potencialessecciones de codigo vectorizables debido a ambiguedades en el acceso a los datos. O bien, podrıa

1

2 CAPITULO 1. INTRODUCCION

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

Basandonos pues en la realidad descrita, se propuso la realizacion del trabajo que se detallaen este documento, con el objetivo fundamental de determinar el grado de utilizacion efectivade la unidad vectorial de un procesador. Se realizarıa entonces, para aquellos casos donde el usofuera menor del esperado, un diagnostico del problema que permitiera lograr una mejora en elrendimiento de la aplicacion.

1.1. Objetivos

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

Analizar y clasificar un conjunto de aplicaciones numericas en funcion del grado de vectori-zacion sobre un compilador determinado.

Determinar las causas del bajo grado de vectorizacion, a partir de la simulacion de lasaplicaciones segun el funcionamiento de un producto existente que hace uso de la unidadvectorial. Las posibles causas seran las siguientes:

• Problematica en el algoritmo base de la aplicacion debido a dependencias en el codigo.

• Problematica en los criterios seguidos a la hora de escribir el codigo fuente.

• Incapacidad del compilador de detectar que el codigo 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 computacion paralela es una forma de computo consistente en paralelizar la mayor cantidadde tareas posible con el objetivo de reducir el coste de computo de un programa. Tradicionalmentese utilizaba otro paradigma: la computacion serie. Con ella las instrucciones se ejecutaban unatras otra en la Unidad Central de Procesamiento (CPU). La utilizacion de este paradigma produceque, a medida que se incrementa la frecuencia de funcionamiento de la maquina, se disminiuya eltiempo que tardan en ejecutarse los programas[HP02]. El aumento de la frecuencia, que tuvo suapogeo durante las dos ultimas decadas 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 generacion de calor. Por este motivo, pese a que la computacion paralela se empezo ausar principalmente en el area de la computacion de altas prestaciones, este lımite en el aumentode la frecuencia propicio que desde la ultima decada, el paradigma principal en arquitectura decomputadores sea la computacion paralela.[Bar07]

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

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

• Superescalares: capaces de introducir en el pipeline de ejecucion una o mas 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 seejecutaran simultaneamente.

Con el objetivo de explotar al maximo esta fuente de paralelismo, existen diferentes tecnicasque se podrıan clasificar en tecnicas de planificacion estatica y dinamica[Dı06].

• Tecnicas de planificacion estatica: trabajan sobre el codigo de la aplicacion paraconseguir eliminar todos los obstaculos que impiden que las instrucciones se ejecutenlo antes posible: desenrollamiento de bucles, reordenamiento de instrucciones...

• Tecnicas de planificacion dinamica: se aplican sobre el diseno del hardware paraque tengan lugar en tiempo de ejecucion: Ejecucion Fuera de Orden (OOO).

DLP: consiste en la realizacion de la misma operacion simultaneamente sobre un conjuntode datos. Para explotar esta tecnica de paralelismo, es necesario que el programa tenga

3

4 CAPITULO 2. ESTADO DEL ARTE

secciones de codigo que se puedan adaptar a la aplicacion de este concepto. Ademas, 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 mas de un dato. La estructura de ejecucion porantonomasia sobre la que se pone en practica este mecanismo, es el bucle. Las estructurasde datos analogas son los vectores y matrices.

TLP: el concepto radica en la descomposicion de la ejecucion del programa en diferentestrazas con instrucciones independientes para ejecutarlas de forma concurrente. Un ejemplo esla Tecnologıa Multihilos, SMT, del ingles 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 extension SIMD Avanzada, tambien conocida como NEON o MPE, del ingles MediaProcessing Engine, para explotar el paralelismo de instrucciones; Nvidia y su plataforma CUDA,del ingles Computed Unified Device Architecture, junto con el set de instrucciones PTX, delingles Parallel Thread Execution[nvi], que define una maquina virtual y un ISA con el objetivo deexplotar la GPU como maquina de ejecucion de hilos paralelos de proposito general; Intel R©y suarquitectura Intel R© MIC, del ingles Many Integrated Core, sobre la que han desarrollado variosproductos, siendo el ultimo de ellos el Intel R© Xeon PhiTM Coprocessor, lanzado al mercado enNoviembre de 2012 y descrito en la Seccion 2.3 (pag. 8), que explota tanto el paralelismo deinstrucciones como de tareas.

2.1. Taxonomıa de Flynn

La taxonomıa de Flynn consiste en una clasificacion 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 segun la concurrencia delprocesamiento de secuencias, datos e instrucciones. Esto da como resultado una metodologıa declasificacion de las distintas operaciones paralelas disponibles en el procesador. Propuesta comouna aproximacion 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 maquinas tradicionales de ununico procesador secuencial o antiguos mainframes entrarıan en esta categorizacion. VerFigura 2.1 (pag. 5).

Single Instruction Multiple Data (SIMD): arquitectura que explota el paralelismo du-rante la ejecucion de una unica instruccion para realizar operaciones de naturaleza paralela.Claros ejemplos son los procesadores vectoriales o las GPU. Ver Figura 2.2 (pag. 5).

Multiple instruction Single Data (MISD): multiples instrucciones operan sobre ununico stream de datos. Es una arquitectura poco comun 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 (pag. 5).

Multiple instruction Multiple Data (MIMD): multiples procesadores executan si-multaneamente diferentes instrucciones sobre diferentes datos. Las arquitecturas VLIW sonun claro ejemplo aparte de sistemas distribuidos o procesadores multicore. Ver Figura 2.4(pag. 5).

2.2. VECTORIZACION 5

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

2.2. Vectorizacion

La vectorizacion es un proceso de explotacion de paralelismo de datos consistente en convertirun algoritmo de implementacion escalar a vectorial. La implementacion escalar es aquella enla que se realiza una unica operacion simultanea sobre un par de operandos que contienen ununico dato cada uno. La implementacion vectorial realizarıa la misma operacion, pero el par deoperandos pasan de contener un unico 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<n; i++)

2 c[i] = a[i] + b[i];

Listado 2.1: Bucle vectorizable

Con el objetivo de poner en practica esta tecnica, es necesario que la arquitectura sobre la quese va a ejecutar el programa disponga de un repertorio de instrucciones especıfico, de una unidadvectorial y de registros vectoriales que puedan contener una serie de datos[LPG13] [SMP11] [Pip12][SLA05]. Este repertorio de instrucciones suele ser una extension sobre las que ya conformen laISA con la que se trabaje, denominadas instrucciones SIMD. SIMD tambien sirve para indicar eltipo de la maquina. La unidad vectorial contendra las unidades funcionales necesarias para operarsobre los registros vectoriales. Finalmente, para generar el codigo vectorizado, hace falta utilizarun compilador que sea capaz de reconocer secciones de codigo potencialmente vectoriales paragenerar las instrucciones SIMD que correspondan.

2.2.1. SIMD

SIMD, como se describio previamente, es un termino definido dentro de la taxonomıa de Flynnpara caracterizar aquellas arquitecturas que explotan el Paralelismo de Datos (DLP). Son ar-quitecturas que contienen multiples elementos de procesamiento que permiten realizar la mismaoperacion sobre varios datos simultaneamente. Esta forma de paralelismo se diferencia de la con-currencia en que es en el mismo momento, y no en momentos diferentes, cuando se realiza de formasimultanea la misma operacion sobre el conjunto de datos que corresponda. Estas instrucciones sedenominan comunmente como instrucciones SIMD.

Un procesador vectorial, por tanto, es un procesador que puede operar en todos los elementos deun vector dado con una unica instruccion. Esto supone una reduccion importante en el numero deinstrucciones leıdas, decodificadas y ejecutadas para un mismo programa vectorizado, frente a otroque no haya sido compilado o escrito usando este recurso. El vector sobre el que se opere, puede asu vez ser leıdo usando diferentes tecnicas que diferencian a unos procesadores vectoriales de otros.En el caso de ser una arquitectura vectorial memoria-memoria, los operandos son inyectados a la


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 reduccion del numero de instrucciones leıdas y decodificadas resulta no ser tal si al final lainstruccion va a tener que esperar a que se lea el vector o porcion del vector de memoria. Poresto, existen diversos esquemas de optimizacion del rendimiento centrados en reducir el tiempo deacceso a la memoria:

Hardware y software prefetching: prefetching en terminos generales significa traer datoso instrucciones de memoria antes de que se necesiten. Cuando la aplicacion necesita datos quese han traıdo con el prefetching, puede tomarlos directamente en vez de tener que esperar porla memoria. Esta tecnica 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 mascarasque indicarıan los elementos del vector sobre los que se realizarıa la operacion. Estas podrıanser utiles en caso de haber condiciones en el interior del bucle para acceder a datos de formadispersa.

Stripmining: tecnica que afronta un problema en la vectorizacion consistente en que losregistros vectoriales no tienen por que ser capaces de contener un vector completo definidoen la aplicacion. Consistirıa en romper el bucle de la aplicacion que opera sobre el vector endiferentes bucles: prologo, principal y epılogo segun conviniera, para tratar un numero dedatos <= MV L, donde MVL es la Longitud Maxima de Vector del procesador.

Bancos de memoria: permiten realizar varios load y stores simultaneamente. Los datostratados cada vez no tendrıan por que ser necesariamente secuenciales.

Repertorio de instrucciones SIMD

El primer uso de instrucciones SIMD fue en los supercomputadores vectoriales a principios delos 70. Sin embargo, el modo de funcionamiento de entonces era ligeramente distinto al conceptoactual. Anteriormente la instruccion que operaba sobre el vector lo hacıa sobre un pipeline deprocesadores, cada uno de los cuales operaba unicamente sobre una palabra del vector. En elconcepto moderno, es un procesador el que realiza la operacion simultaneamente sobre el vectorcompleto o una porcion del mismo.

A lo largo del tiempo, esta tecnologıa salto a las maquinas sobremesa, mercado en el quetuvo gran repercusion y posterior demanda debido a que podıa soportar aplicaciones tales comoprocesamiento de vıdeo y juegos en tiempo real. Es por ello que a lo largo de la historia hahabido gran variedad de repertorios SIMD fruto de la competencia entre diferentes companıas delmomento. Hoy en dıa no hay computadora de uso general que no haga uso de una arquitectura queexplote el paralelismo de datos a traves de la vectorizacion. A continuacion se nombran algunosde los diferentes repertorios de instrucciones SIMD de la historia:

VIS: Visual Instruction Set. Repertorio desarrollado y lanzado al mercado en 1994 por SunMicrosystems, adquirida por Oracle Corporation en 2010. La primera version fue implemen-tada en el UltraSPARC en 1995 y por Fujitsu en el SPARC64 GP. Registros de 8, 16 y 32bits. Hubieron varias versiones posteriores esta: VIS2, VIS2+ y VIS3.

MMX: repertorio desarrollado por Intel R© y lanzado en 1997 en su gama Pentium MMX.Registros de 64 bits.

2.2. VECTORIZACION 7

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

SSE: Streaming SIMD Extensions. Extension de la arquitectura x86 disenado por Intel ylanzado al mercado en 1999 en su serie Pentium III, como respuesta al lanzamiento por partede AMD de su extension 3DNow. Registros de 128 bits.

AltiVec: repertorio disenado 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. Extension 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 anos despues cuando salio al mercado como caracterısticade la generacion 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,ultima extension con registros de 512 bits.

Ventajas

Los procesadores vectoriales y por extension el uso de la vectorizacion, proporcionan las si-guientes ventajas:

Los programas son de menor tamano al reducir el numero de instrucciones que pudierarequerir un bucle. Ademas, el numero de instrucciones ejecutadas tambien se ve reducido alpoder concentrar un bucle en una unica instruccion.

El rendimiento de la aplicacion mejora. Se tienen N operaciones independientes que utilizanla misma unidad funcional, explotando al maximo la localidad espacial de la memoria cache.

Las arquitecturas son escalables: se obtiene un mayor rendimiento cuantos mas recursoshardware haya disponibles.

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

Tomando como ejemplo una aplicacion multimedia que cambia el brillo a una imagen, lavectorizacion 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 este 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 paralelizacion del trabajo enuna unica instruccion es evidente. Cuanto mas 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 rapida y por consiguiente cara.


Hay que disenarlos de forma especıfica. La unidad vectorial de los procesadores vectorialesno se compone de elementos prefabricados mas alla de las unidades basicas, por tanto pocasventas del producto final se traducirıa en perdidas debido a su coste de diseno y validacion.

Mientras que se conseguıa una ventaja en el consumo de energıa al reducir la alimentacionde 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 vectorizacion del codigo no se adapte a los requerimientos esperados por el compilador.Existe entonces una posibilidad real de que haya una importante implicacion del ingenierotanto a nivel alto como bajo para conseguir vectorizar una aplicacion.

No hay un estandar establecido en el proceso. La utilizacion de un repertorio de instruccionesSIMD u otro puede dificultar la tarea en caso de compilar la misma aplicacion sobre distintasarquitecturas. Aparte, es posible que el ingeniero tenga que proveer de una implementacionno vectorial de la misma.

No todas las aplicaciones se pueden vectorizar. Por ejemplo, las aplicaciones de analisis decodigo, caracterizadas por su fuerte control del flujo de ejecucion, son claras candidatas parano beneficiarse de las ventajas de la vectorizacion.

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 combinacion de muchos nucleos de Intel R© dentro de un unico chip. Esta des-tinada a su uso en la Computacion de Alto Rendimiento o HPC, del ingles High PerformanceComputing, para la ejecucion de programas paralelos que se venıan ejecutando en grandes cluste-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 instalacion de multiples clusteres 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 programacion similar al entorno de programacion delprocesador Intel R© XeonTM[intb].

El coprocesador Intel R© Xeon PhiTM puede pasar por un sistema en sı mismo, puesto que correuna distribucion completa del sistema operativo Linux, soporta el modelo x86 de ordenamientode memoria y el estandar IEEE 754 de aritmetica en punto flotante. Ademas es capaz de ejecutaraplicaciones escritas en lenguajes de programacion 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 matematicas para HPC) y herramientas de caracterizaciony depurado.

Esta conectado a un procesador Intel R© Xeon, denominado ”host”, a traves de un bus PICExpress. Vease Figura 2.6 (pag. 9). Dado que el coprocesador ejecuta de forma autonoma elsistema operativo Linux, es posible virtualizar una comunicacion tcp/ip entre este y el procesador,permitiendo al usuario acceder como si fuera un nodo mas en la red. Por tanto, cualquier usuariopuede conectarse al mismo a traves de una sesion ssh (secure shell) y ejecutar sus aplicaciones.Ademas, soporta aplicaciones heterogeneas 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 mas de un Xeon

1Se aplica a los conjuntos de computadoras construidos mediante la utilizacion de elementos hardware comunesy que se comportan como si fuesen una unica 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, pudiendose establecer entre ellos la comunicacion ya sea a traves de lainterconexion p2p (peer to peer) o a traves de la tarjeta de red del sistema, sin intervencion enambos casos del host.

Figura 2.6: Esquema general

2.3.1. Microarquitectura

El coprocesador Intel R© Xeon Phi esta formado por mas de 50 nucleos de procesamiento,memorias cache, controladores de memoria, logica de cliente PCIe y un anillo de interconexionbidireccional que proporciona un elevado ancho de banda al sistema. Vease Figura 2.7 (pag. 10).La ejecucion es en orden mientras que la terminacion 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 ingles Tag Directory. Los controladores de memoria y la logicade cliente PCIe proporcionan una interfaz directa con la memoria GDDR5 del coprocesador y elbus PCIe respectivamente. Ademas, cada core fue disenado 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 nucleo del coprocesador Intel R© Xeon PhiTM es la VPU.Vease Figura 2.8 (pag. 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 precision (SP) u 8 de doble precision (DP) por ciclo. Tambiensoporta instrucciones Fused Multiply-Add (FMA), que ordenan multiplicar y sumar en la mismainstruccion, y gracias a las cuales se pueden ejecutar 32 instrucciones de simple precision 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 energetica en la ejecucion de apli-caciones HPC, ya que una unica operacion 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 ejecucion de multiples instrucciones. Sin embargo, hicieron falta varias mejoras para lograr so-portar instrucciones SIMD de estas caracterısticas. Por ejemplo, se anadio el uso de mascaras a laVPU para permitir predecir sobre que datos operar dentro de un registro vectorial. Esto ayudo enla vectorizacion de bucles con flujos de ejecucion condicionales, mejorando ası la eficiencia softwaredel pipeline. La VPU tambien soporta instrucciones de tipo gather y scatter directamente a travesdel hardware. De este modo, para aquellos codigos con patrones de acceso a memoria esporadicose irregulares, el uso de este tipo de instrucciones ayuda a mantener el codigo vectorizado.

Finalmente, la VPU tambien cuenta con una EMU, del ingles Extended Math Unit, que puedeejecutar instrucciones trascendentes como son las recıprocas, raıces cuadradas y logarıtmicas. LaEMU funciona calculando aproximaciones polinomicas de estas funciones.

2.3. INTEL R© XEON PHITM COPROCESSOR 11

Interconexion

La interconexion se implementa como un anillo bidireccional. Vease Figura 2.9 (pag. 11). Cadadireccion esta compuesta de tres anillos independientes. El primero, que se corresponde con elmas 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 esmas estrecho y se utiliza para enviar comandos de lectura/escritura y direcciones de memoria.Por ultimo, el anillo mas 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 direccion se envıa sobre elanillo de direcciones a los directorios de etiquetas. Vease Figura 2.10 (pag. 11). Las direcciones dememoria se distribuyen de manera uniforme entre los distintos directorios que hay en el anillo paraanadir la fluidez de trafico como una caracterıstica mas del mismo. Si el bloque de datos solicitadose encuentra en la cache L2 de otro core, se dirige una peticion 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 direccion dememoria desde el directorio de etiqueta hasta el controlador de memoria.

La Figura 2.11 (pag. 12) muestra la distribucion de los controladores de memoria en el anillo.Como se aprecia, se intercalan de forma simetrica alrededor del el. La asignacion de los directoriosde etiquetas a los controladores de memoria se realiza de forma todos-a-todos. Las direccionesse distribuyen uniformemente a traves de todos los controladores, eliminando de este modo loshotspots y proporcionando un patron 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, este genera una peticion de direccion 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 direccion y solicita los datos a la memoria. Una vezque el controlador recibe el bloque de datos desde la memoria, se entrega al core a traves delanillo de datos. En todo el proceso los elementos trasmitidos a los anillos son: un bloque de datos,dos solicitudes de direccion junto con dos mensajes de confirmacion. Debido a que los anillos dedatos son los mas caros y estan disenados para soportar el ancho de banda requerido, es necesarioincrementar el numero de anillos de direccion y reconocimiento, mas baratos en comparacion, enun factor de dos para soportar las necesidades de ancho de banda causadas por el elevado numerode peticiones sobre los anillos.

Caches

La arquitectura Intel R© MIC invierte en mayor medida tanto en caches L1 como L2 en compa-racion 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, mas rapido que el ancho de banda dela memoria principal. Por lo tanto, el uso efectivo de esta jerarquıa es clave para lograr el maximorendimiento en el coprocesador. Ademas de mejorar el ancho de banda, son tambien mas eficientesque la memoria principal en cuanto al uso de energıa para el suministro de datos al core. En la erade la computacion exascale3, las caches jugaran un papel crucial a la hora de conseguir maximizarel rendimiento bajo estrictas restricciones de potencia.

Imagenes 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 ingles Advanced Vector Extensions engloba, como veıamos en la Seccion 2.2.1 (pag. 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 ano.

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 laextension SSE podıan ser usadas para operar en los 128 bits menos significativos de los registrosYMM. Entonces podıa seguir usandose la nomenclatura XMM0-XMM7.

AVX introdujo ademas un formato de instruccion SIMD de tres operandos donde el registrode destino podıa ser distinto a los dos registros fuente. Por ejemplo, una instruccion SSE usandola forma convencional a = a + b, podıa ahora utilizar el metodo de tres operandos c = a + b,impidiendo que se destruyera la informacion 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 proposito 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 tambien sobre numerosnaturales, ampliando casi la totalidad del conjunto SSE de 128 bits a 256 bits. El formato nodestructivo de tres operandos estuvo ahora tambien disponible para instrucciones a nivel de bitsy multiplicacion de proposito general y para instrucciones FMA (Fused Multiply-Accumulate).Finalmente, esta nueva ampliacion 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 ano 2015[inta]. No todas las extensio-nes estan destinadas a ser soportadas por todos los procesadores que las implementen. Solo laextension del nucleo 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 codificacion EVEX para soportar los registros de 512 bits, las operaciones con


mascaras, la difusion de parametros y las excepciones de control y redondeo empotradas.

AVX-512 Conflict Detection Instructions (CDI): anade deteccion de conflictos efi-ciente para permitir que mas bucles puedan ser vectorizados.

AVX-512 Exponential and Reciprocal Instructions (ERI): operaciones exponencialesy recıprocas disenadas para ayudar en la implementacion de operaciones trascendentes, comopor ejemplo la funcion de logaritmo.

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

En cuanto a las caracterısticas tecnicas, se resumen en los siguientes puntos:

32 registros vectoriales de 512 bits de ancho bajo la nomenclatura ZMM0-ZMM31.

8 registros dedicados a las mascaras, 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 podran entonces empaquetar en los nuevos registros de 512 bits cualquiera delas siguientes combinaciones de datos: 8 datos en punto flotante de precision doble, o 16 datos enpunto flotante de precision 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 instruccion 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 penalizacion 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 operaran 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 analisis. Comprendıadesde el analisis de todas y cada una de las herramientas a utilizar, hasta el analisis de cada resul-tado, cada grafica elaborada, cada bloque basico implicado y cada lınea de codigo que supusieraun objeto de interes 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 mas estadısticas aparte de aquellas conseguidas gracias alas herramientas ya disponibles para los ingenieros de Intel R©. Sin embargo, incluso el tomar ladecision de incorporar el desarrollo de este simulador como una extension de otro ya existente,supuso un fuerte trabajo de analisis para tratar de reciclar la mayor cantidad de informacion yadisponible. Esta informacion 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 tambien 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 consecucion del trabajo, como se distribuyeron todas las tareas arealizar y el tipo de metodologıa usada cuando se procedio al desarrollo de la nueva extension delsimulador.

3.1. Plan de trabajo

Al plan de trabajo disenado inicialmente y presentado en el anteproyecto se le aplicaron mo-dificaciones sin que ello repercutiese en el computo total de horas. A continuacion se presenta laplanificacion final y las justificaciones sobre los cambios en el caso de haberlos.

Fase 1: Seleccion y caracterizacion de benchmarks

1. Seleccion 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 extension AVX-512 para la obtencion de una caracterizacion inicial. Utilizando los compiladores disponibles,

15

16 CAPITULO 3. METODOLOGIA

como ICC e IFORT, se realiza la compilacion del conjunto de aplicaciones seleccionadas uti-lizando aquellas opciones que permitan realizar optimizaciones y vectorizacion del codigo.Implica un pequeno analisis mediante el parsing del informe generado, para tener una apro-ximacion inicial al comportamiento de cada aplicacion.

Esta fase se redujo a la seleccion y posterior caracterizacion de las aplicaciones. El motivo porel que no se realizo una criba inicial radica en que al principio, sin mas datos que los disponiblesestaticamente con el informe del compilador, la mera descripcion de la aplicacion no parecıasuficiente para descartar unas u otras. Era mas interesante quedarnos con todas las disponiblesy, a partir de diferentes estadısticas, tomar decisiones sobre cuales analizar segun las solucionessoftware o hardware a aplicar.

Fase 2: Recopilacion y analisis de informacion sobre la ejecucion vectorial de losprogramas de prueba

1. Determinacion del grado de vectorizacion de los programas: Usando el emulador Pin/SDE,se obtiene el numero de instrucciones ejecutado por cada programa y se determina el gradode vectorizacion de los mismos.

2. Recopilacion de informacion 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. Determinacion del grado de utilizacion de la unidad vectorial: En este apartado se desa-rrollara un nucleo sencillo basado en la arquitectura del coprocesador Intel R© Xeon PhiTM

sobre el simulador CMP$im, que permita obtener datos estadısticos para ası determinar elgrado de utilizacion de la unidad vectorial.

La unica modificacion 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 informacion de interes que puede utilizarsepara la simulacion de la arquitectura. Ademas, contiene multitud de estructuras y clases que sepueden utilizar a la vez que se introduce el codigo sobre el esqueleto correspondiente a la simulacionde cache.

En primer lugar se llevarıa a cabo una exhaustiva fase de analisis sobre CMP$im, para conoceren profundidad tanto la configuracion de ficheros del simulador, como las estructuras y clasesusados, aparte del funcionamiento especıfico de la simulacion de la cache. Los objetivos principaleseran reutilizar estructuras, esquemas y clases ya presentes, saber de que modo introducir el codigocorrespondiente al simulador de la arquitectura para no entorpecer la simulacion 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 extension correspondiente a la simulacion de la arquitectura vectorial. Lametodologıa mas 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 incorporacion del siguiente incremento.Cada una de las funcionalidades se iba a discutir y disenar 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: Determinacion de cuellos de botella en la ejecucion vectorial y propuesta desoluciones

1. Seleccion de un subconjunto de aplicaciones numericas de entre todos los benchmarks selec-cionados, teniendo como referencia las estadısticas recolectadas. Para la seleccion se tomaroncomo criterio tanto la relacion entre las versiones escalar y vectorial, ası como el desglose deciclos de la aplicacion segun las dependencias ocasionadas durante la ejecucion.

2. Con la informacion recolectada en los puntos anteriores se determinara cuales son las re-giones del codigo que tienen un bajo uso de la unidad vectorial. Se estudiara a posterioricual es el motivo: si se trata de una falta de vectorizacion, si se produce por lımites en lamicroarquitecura u otros.

3. Adicionalmente, se propondran 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 seleccion de las aplicaciones, ya que a estas alturas estan com-pletamente caracterizadas, de manera que la informacion disponible permite tomar decisionesbasandonos exclusivamente en el comportamiento de las mismas.

Capıtulo 4

Herramientas

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

4.1. Pin

Pin1 es una herramienta de codigo abierto desarrollada por la empresa Intel R©, destinada ala instrumentacion de aplicaciones [pin]. Se denomina herramienta de Instrumentacion BinariaDinamica porque la instrumentacion se realiza en tiempo de ejecucion (JIT, Just in Time):

No requiere que la aplicacion a instrumentar se tenga que recompilar.

Permite instrumentar programas que generan codigo dinamicamente.

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 permitiran 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 informacion decontexto, tales como el contenido de los registros o las direcciones de acceso a memoria, pasandolacomo diferentes parametros dentro del codigo que el proceso de instrumentacion inserta en elbinario. Ademas, Pin salva y recupera el contenido de los registros que se utilizaran en dichocodigo, de manera que no influyan en la ejecucion normal del programa instrumentado.

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

4.1.1. Pintools

Una pintool, sea cual sea su funcionalidad, constara de dos secciones fundamentales en sucodigo:

1No es un acronimo.

19

20 CAPITULO 4. HERRAMIENTAS

Instrumentacion: contendra las instrucciones necesarias que indiquen a Pin que informacionse quiere recoger del codigo que se esta ejecutando, como codigos de registro, hilos en ejecu-cion o contador de programa, entre otros. Tambien indica en donde se quieren insertar lasllamadas a las funciones y procedimientos que haran uso de toda la informacion recogida.

Analisis: contendra la definicion de todas las funciones y procedimientos que trataran lainformacion recogida en la seccion de instrumentacion.

Ademas de estas dos secciones, tambien contendra, como cualquier aplicacion de C o C++, lafuncion main y, como novedad, un procedimiento denominado Fini que es invocado por Pin cuandola aplicacion termina. El motivo por el que se tiene que desarrollar este ultimo procedimiento, resideen que una vez hemos dado el control a Pin, no retorna a la funcion main para terminar.

Pin proporciona una amplia baterıa de pintools con diferentes funcionalidades. En el Listado 4.1(pag. 20) se muestra el codigo de una pintool denominada inscount0 que cuenta el numero deinstrucciones ejecutadas de una aplicacion. Se encuentra dentro de la extensa baterıa de pintoolsde ejemplo que acompanan a la herramienta. Es una muestra perfecta de la estructura mas comunde una pintool, en donde se aprecian tanto las secciones principales descritas, como la definicionde knobs, opciones de la pintool y otras funciones de interes.

1 #include <iostream >

2 #include <fstream >

3 #include "pin.H"

4 ofstream OutFile;

5 static UINT64 icount = 0;

67 // Seccion de analisis

8 VOID docount () { icount ++; }

910 // Seccion de instrumentacion

11 VOID Instruction(INS ins , VOID *v){

12 INS_InsertCall(ins ,

13 IPOINT_BEFORE ,

14 (AFUNPTR)docount ,

15 IARG_END);

16 }

1718 KNOB <string > 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 << "Count " << icount << endl;

26 OutFile.close ();

27 }

2829 INT32 Usage(){

30 cerr << "This tool counts the number of dynamic instructions executed" << ←↩endl;

31 cerr << endl << KNOB_BASE :: StringKnobSummary () << endl;

32 return -1;

33 }

3435 int main(int argc , char * argv []){

36 if (PIN_Init(argc , argv)) return Usage();

37 OutFile.open(KnobOutputFile.Value().c_str ());

38 INS_AddInstrumentFunction(Instruction , 0);

39 PIN_AddFiniFunction(Fini , 0);

40 PIN_StartProgram ();

41 return 0;

42 }

Listado 4.1: Codigo de ejemplo de la pintool inscount0

4.1. PIN 21

Analizando mas 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 funcion se encargara de la instrumentacion anivel de instruccion.

PIN AddFiniFunction: registra que funcion se invocara antes de que la aplicacion instru-mentada termine.

PIN StartProgram: arranca la ejecucion de la aplicacion. No se retorna.

INS InsertCall: registra que funcion se ha de llamar cuando se encuentren instruccionescandidatas a instrumentar. Entre los parametros que se observan en Listado 4.2 tenemos:

• ins: instruccion a instrumentar.

• IPOINT BEFORE: se invocara el analisis antes de que se ejecute.

• docount: funcion de analisis.

• IARG END: fin de parametros, tanto si los hubiera como si no. Estos parametros son losque pasarıan a la funcion docount del ejemplo. Vease Listado 4.3.


2 IPOINT_BEFORE ,


4 IARG_END);

Listado 4.2: Funcion de instrumentacion

1 VOID docount(UINT32 threadId , ADDRINT pc) { ... }

23 VOID Instruction(INS ins , VOID *v)

4 {


6 IPOINT_BEFORE ,


8 IARG_THREAD_ID ,

9 IARG_ADDRINT , INS_Address(ins),

10 IARG_END);

11 }

Listado 4.3: Argumentos para la funcion de analisis

4.1.2. Arquitectura software

En la Figura 4.1 se observa la arquitectura software de Pin [LCM+05]. El elemento principal esla maquina virtual, que contiene un compilador just in time que se encarga de recompilar aquellasporciones de la aplicacion que se hayan indicado en la seccion de instrumentacion, sobre las quese inyectara el codigo de la seccion de analisis que le corresponda.

El dispatcher es el encargado de lanzar el codigo recien compilado que almacena en el areadenominada 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 maquina virtual.

De entre las entradas que alimentan a Pin, se encuentran logicamente tanto la pintool como laaplicacion. En el Listado 4.4 se observa el esqueleto general de la invocacion.


Figura 4.1: Arquitectura software de Pin

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

Listado 4.4: Ejemplo de invocacion 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 instrumentacion binaria dinamica, que suponıa una alternativa frente a otros metodos desimulacion como trace-driven basado en trazas [JCLJ06][JCLJ08].

Es interesante destacar que CMP$im es una herramienta muy rapida y facil de utilizar. Ademasproporciona una gran cantidad opciones, tanto estaticas de forma #define MACRO, como dinamicas(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 simulacion. Entre estas opciones se destacanlas siguientes:

Numero de niveles de cache.

Numero de caches por nivel.

Numero maximo de threads que se pueden lanzar con la aplicacion.

Polıticas de escritura y reemplazo.

Caracterısticas particulares para cada cache, como tamano, asociatividad, latencia, tamanode 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 simulacion del mismo modoespecificado en el Listado 4.4 (pag. 22). La salida se compone de un informe con estadısticasmuy detalladas, que proporcionan tanto informacion general de la aplicacion, como particulardesglosada por hilos de ejecucion y por nivel de cache. Entre ellos, se muestran datos relativos a:

Numero total de instrucciones ejecutadas y desglosadas por hilos.

Estimacion2 del numero de ciclos, donde la latencia de cada instruccion es, por defecto, deun ciclo, anadiendo al total la latencia total generada por los accesos a memoria.

Numero 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 nucleo del coprocesador Intel R©XeonPhiTM. Imagenes cortesıa de Intel R©.

4.3. Benchmarks

El benchmarking es una tecnica 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 maquinaobtiene buenos resultados o no, de cara a utilizarlos para el fin que convenga.

Aplicado en el campo de la informatica consistirıa en la ejecucion de aplicaciones especıfica-mente disenadas para medir el rendimiento de una maquina 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 utilizacion efectiva de la unidad vectorial de un procesador.

Los benchmarks se pueden clasificar en diferentes categorıas. Veamos una posible clasificacion:

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 tarjetagrafica o el procesador.

• Benchmarks de alto nivel o nivel sistema: evaluan el rendimiento global de una maquina.Este tipo es interesante para comparar sistemas que se basan en arquitecturas distintas.

Benchmarks basados en el codigo que los componen:

• Benchmarks sinteticos: 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 descripcion seasocia rapidamente 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 busqueda de datos en disco en el benchmark.

2No implementa ningun mecanismo que haga uso del paralelismo de instrucciones (ILP).


• Benchmarks de aplicacion: hacen uso de aplicaciones reales. En este caso los desa-rrolladores del benchmark pueden tener interes 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 comocontribuye cada componente al dicho rendimiento.

Independiente de esta clasificacion, se pueden tipificar siguiendo otros patrones mas especıficos.Por ejemplo, existen benchmarks que sirven para medir el rendimiento de maquinas con multiplesnucleos en su procesador o con multiples 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 sinteticos, 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 sintetico creado por la companıa Futuremark Corporation, con el obje-tivo de medir la capacidad de rendering sobre graficos 3D que tiene la GPU de una maquina,ası como la capacidad de procesamiento de la CPU.

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

FurmKar: benchmark sintetico que mide el rendimiento de una tarjeta grafica al traves dela ejecucion de un algoritmo de renderizado de pelaje. Su peculiaridad es que, al tratarse deun algoritmo que somete a la GPU a un nivel de estres muy fuerte, permite medir muy bienla capacidad de aguante y estabilidad de la tarjeta.

El conjunto de benchmarks que se presenta a continuacion es una muestra continente de va-riedad de aplicaciones numericas usadas comunmente en el ambito de la computacion 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, disenados para com-parar el rendimiento de los diferentes ejecutables generados por distintos compiladores. Todos losprogramas se pueden descargar y hacer uso de ellos segun 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 simulacion completa de los programas.El nuevo benchmark tiene conjuntos de datos que ralentizaban demasiado su simulacion. 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 medicion del rendimiento de las aplicacionesviene determinada por una combinacion de diferentes opciones, proporcionan una aproxi-macion excelente para explorarlas. Las opciones mencionadas englobarıan las siguientes: elcompilador usado, el hardware de la maquina a medir, el algoritmo, el entorno de ejecucion,el uso de miniaplicaciones, definidas como pequenos proxies autocontenidos para aplicacionesreales, etc.

Minidrivers, pequenas 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 dinamica 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 estan 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 nucleos del coprocesador Intel R© Xeon PhiTM, se seleccionaron solamente lasaplicaciones correspondientes a la seccion 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-dicion del rendimiento de supercomputadores paralelos. Fueron desarrolladas por la division NAS(NASA Advanced Supercomputing). Inicialmente, en la especificacion NPB 1, estaba conformadopor 5 kernels y 3 pseudo aplicaciones. Mas adelante fue extendida para incluir nuevos benchmarkssobre mallas adaptativas, aplicaciones E/S paralelas y redes computacionales. Se utilizo la version3.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 pequenas pruebas.

Class W : destinada a estaciones de trabajo.

Classes A, B, C : test de mayor tamano, 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 numero 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 organizacion sin animo delucro cuyo objetivo es producir, establecer, mantener y promocionar un paquete estandar de bench-marks para medir el rendimiento de diferentes maquinas. En este sentido, se dispone del conjuntode benchmarks denominado SPEC CPU2006 disenado para proporcionar una medida comparati-va, con el objetivo de analizar el rendimiento conseguido despues de realizar calculos intensivossobre una maquina. El conjunto de aplicaciones que lo conforman fueron desarrolladas basadas enaplicaciones de usuario reales. Los resultados que se obtengan seran 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, estan disponibles los siguientes:

all : comun para todos los benchmarks, se usa en caso de ser necesario.

ref : es el conjunto de datos real y completo.

test : entrada para tests mas sencillos.

train: tests mas 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 codigo necesario con el que se trabajara despues. Si bien todos los elementos expuestosen este capıtulo son indispensables para conseguir las sinergias que permitiran completar todoslos objetivos definidos en la Seccion 1.1 (pag. 2), los compiladores se alzan con la responsabilidadsuprema. En el caso particular de los optimizadores de que constan, son responsables de generar uncodigo adecuado con el que se pueda partir, trabajar y mejorar en caso necesario. Si no fuera ası,ningun 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 ultima version de los com-piladores. Por tanto, este trabajo servıa tambien como depurador de los cambios introducidos encada version. La version 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 codigo generado al compilar contiene las extensiones AVX-512 descritas en la Seccion 2.4(pag. 13). Asimismo, mientras los compiladores estan disponibles en multitud de plataformas, eneste trabajo se uso la version para Linux.

Los compiladores fueron usados a la hora de construir la caracterizacion de todas y cada una delas aplicaciones, y para tener los ejecutables disponibles en el momento de proceder a la simulacioncon la version de CMP$immodificada.

4.4.1. ICC

El compilador Intel R© ICC permite generar codigo 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 vectorizacion 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, ademas, permitıan generar codigo AVX-512. El vectorizadorautomatico es un componente importante del compilador, ya que utiliza automaticamente 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 automatico de las instrucciones de tipo SIMD. El usuario puedeayudar a este modulo mediante el uso de pragmas. Consultese el conjunto de pragmas disponiblesen la Seccion 4.5 (pag. 29)

ICC tiene multitud de knobs de compilacion[intc]. Para este trabajo, el formato de las mismasse corresponde con aquel para Linux. A continuacion se mostraran las opciones mas significativasusadas en este trabajo. La lınea de compilacion tiene el formato mostrado en el Listado 4.5. Laopcion -no-vec que se observa en la lınea de compilacion, se usaba para indicar al compiladorque no vectorizase. Como se vera mas adelante, la version no vectorizada de las aplicaciones es deinteres porque sirven de referencia para compararlas con la version vectorizada.

1 icc -g -debug inline -debug -info -vec -report6

2 -ansi -alias -O3 -no-prec -div -ipo -static

3 -xKNL [-no -vec] -o <ouput > <inputfiles >

Listado 4.5: Lınea de compilacion


-g Produce informacion para depuracion simbolica en elfichero objeto.

-debug inline-debug-info Genera informacion de depuracion mejorada tanto enel caso de codigo del que se haga inline como en elrastro generado por sucesivas llamadas a funciones.

-vec-report6 Genera un log con toda la informacion 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 estandares de la ISO de C.

-O3 Aparte de las optimizaciones de la opcion -O2, in-cluye prefetching, transformacion de bucles y susti-tucion de escalares.

-no-prec-div Permite optimizaciones que, a cambio de divisionesalgo menos precisas que las operaciones de divisionen 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 mas ficheros objetivo dependiendo deuna estimacion del tamano de la aplicacion.

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

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

-no-vec Impide al compilador hacer uso del modulo de vecto-rizacion. El log resultante de aplicar esta opcion nocontendrıa mas informacion que la lınea de compila-cion 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ısticasanalogas al compilador ICC, como es el soporte para la vectorizacion de aplicaciones, y compartela mayorıa de knobs disponibles.

La lınea de compilacion solo difiere en la opcion -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 compilacion.El resto permanecen invariantes.

1 ifort -fpp -g -debug inline -debug -info -vec -report6

2 -ansi -alias -O3 -no-prec -div -ipo -static

3 -xKNL [-no -vec] -o <ouput > <inputfiles >

Listado 4.6: Lınea de compilacion

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 programacion, ya que no figuran en su gramati-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$. Ademas, hayque tener en cuenta que los pragmas son dependientes tanto de la maquina como del sistemaoperativo, aparte de que cada compilador tiene su propio conjunto. Es tambien posible que lafuncionalidad proporcionada por un pragma se consiga con alguna opcion particular de compila-cion. En caso de coincidir en funcionalidad las opciones del compilador con los pragmas, tienenprioridad los segundos.

Los pragmas, que se pueden consultar en el Apendice A (pag. 105), el Apendice B (pag. 109)y el Apendice C (pag. 113), estan 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 mas 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 clasificacion:

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 organizacion, al poner su disponibilidad bajo la previa aprobacion 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 autorizacion, tuve acceso a un conjunto de ellas de cara a facili-tarme la tarea durante el desarrollo de este trabajo. Estas herramientas facilitaban el analisis 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 mas legible y facil de estudiar, que lo que un fichero de texto con multitud de numeros 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 basicos individualmente.

Consultar el codigo fuente asociado a cada bloque basico.

Visualizar el flujo de ejecucion del programa.

Consultar la distribucion de funciones e instrucciones.

Sintetizar la informacion procedente de cada nivel de la cache.

Todas ellas se usaron principalmente durante la caracterizacion de las aplicaciones y a la horade realizar el diagnostico software para averiguar las causas del bajo grado de vectorizacion.

Capıtulo 5

Arquitectura del Simulador

En el presente capıtulo se hara un analisis mas en detalle del funcionamiento del simuladorCMP$im presentado en la Seccion 4.2 (pag. 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 ejecucion

Las dos secciones principales en las que se organiza una pintool, como se describieron en laSeccion 4.1.1 (pag. 19), son las secciones de instrumentacion y de analisis. CMP$im no es unaexcepcion. En la Figura 5.1 (pag. 31) se presenta una vision general de como funciona.

En primer lugar tenemos la funcion main, donde se recogen las opciones de configuracion dela pintool introducidas por parametro y tanto la aplicacion objeto del analisis como sus datos deentrada. Aquı tambien se llevan a cabo las inicializaciones pertinentes segun la configuracion decache que se haya elegido. Una vez se lanza la simulacion no se retorna. Por ello, la finalizacion dela aplicacion esta ligada a una funcion de terminacion que sera invocada por Pin en el momentooportuno.

Figura 5.1: Diagrama de funcionamiento CMP$im

31

32 CAPITULO 5. ARQUITECTURA DEL SIMULADOR

En segundo lugar tenemos el bloque principal compuesto por las fases de instrumentacion yanalisis. Pese a que la instrumentacion es la fase con la que se inicia, ambas se van intercalandoa medida que se avanza en la simulacion. Durante esta fase se van insertando las llamadas a lasfunciones segun el tipo de estructura con el que se este tratando. Estas funciones se encargaran derealizar la simulacion de la cache. Asimismo, iran recogiendo todas las estadısticas que se hubieranprogramado en ellas, como por ejemplo aquellas mencionadas en la Seccion 4.2 (pag. 22). En el casode la simulacion de cache se recogen, por ejemplo, el numero de aciertos y de fallos, desglosadospor hilo, nivel de cache y PC. En el caso de las funciones asociadas a los bloques, se almacenarıanel numero total de instrucciones ejecutadas por cada bloque desglosadas por cada hilo lanzado porla aplicacion. El objetivo es almacenar en las estructuras definidas a tal efecto, toda la informacionque sea de utilidad para caracterizar la aplicacion y estudiar su comportamiento sobre la cachedefinida.

Finalmente, una vez ha terminado la aplicacion, se ejecuta la funcion de finalizacion. En estase lleva a cabo todo el volcado de la informacion almacenada en las diferentes estructuras para suposterior tratamiento.

En la Figura 5.2 (pag. 32) se muestra de forma mas detallada el flujo de ejecucion para simularla cache en un modo denominado modo buffer. Este modo se usa cuando se van almacenandotodas las instrucciones de memoria de un bloque antes de simularlas. Las llamadas insertadas enla instrumentacion estan indicadas con la palabra clave call. La llamada a foo1 se insertarıa aldetectar una instruccion de carga de memoria; foo2 cuando es de almacenamiento; finalmente, foo3se insertara al detectar un bloque basico. Para el modo buffer, la funcion foo3 serıa la encargadade iniciar la simulacion de instrucciones previamente instrumentadas. Dado que foo3 se ejecutarıaantes que foo1 y foo2, la primera vez no habrıa instrucciones que simular. En las veces sucesivasya se habrıan instrumentado instrucciones de memoria. Por ello, se da la circunstancia de quecada bloque basico lanzarıa la simulacion de las instrucciones registradas en el bloque anterior.Este bloque podrıa ser tanto el mismo, en caso de bucle, como otro. Para evitar problemas con lasimulacion de las instrucciones del ultimo bloque, la funcion de finalizacion es una buen candidatadonde comprobar si faltan instrucciones de memoria por simular.

Figura 5.2: Simulacion en modo buffer

En la Figura 5.3 (pag. 33) se muestra el flujo de ejecucion en modo instruccion a instruccion.En este otro caso las instrucciones se van simulando a medida que se van encontrando, lo cual lohace mas lento que el caso anterior al tener que proceder a realizar todo el trasiego de paso deparametros para cada instruccion de memoria que se encuentre en el programa.

5.2. ESTRUCTURAS Y CLASES 33

Figura 5.3: Simulacion en modo instruccion a instruccion

5.2. Estructuras y clases

Las estructuras de datos y clases mas importantes usadas en el simulador, y que podrıanaprovecharse mas adelante, son las siguientes:

Bloque Basico

Rutina

Cache

Estadısticas

BLOQUE BASICO

Dentro de cada bloque basico CMP$im almacena los siguientes campos:

Direcciones de comienzo y fin: son los PCs de la primera y ultima instrucciones delbloque. Es muy importante saber donde empieza un bloque y donde termina porque, comovimos en el modo buffer descrito en la Seccion 5.1 (pag. 31), las instrucciones que se tratanson las del bloque anterior. Si conocemos sus lımites, se pueden utilizarlos en adelante amodo de ındice.

Contador: numero de veces que se ejecuta un bloque. Se utiliza como estadıstica para poderelaborar una lista de bloques basicos ordenados por frecuencia de ejecucion.

La estructura esta instanciada a modo de lista STL. Vease el Listado 5.1 (pag. 33). Hay quetener en cuenta que la instrumentacion, pese a estar programada en modo buffer para el caso delos bloques, dentro de pin realmente se realizaba a nivel de traza. Como una traza puede contenervarios bloques basicos, en el momento en que se reconoce uno y se inserta en la llamada a lafuncion de analisis correspondiente, no se tiene en cuenta si esta solapado con otros bloques. Enla Figura 5.5 (pag. 34) se presenta la problematica.

1 list <const BBInfo*> BBInfoList;

Listado 5.1: Lista STL de Bloques Basicos


Figura 5.4: Ejemplo de bloque basico

Figura 5.5: Proceso de descubrimiento de bloques

Imaginemos que tenemos un caso de bloques basicos como el de la Figura 5.4 (pag. 34). Antesde reconocer los dos bloques por separado, Pin identifica un unico bloque de instrucciones hasta elsiguiente salto. En la Figura 5.5 (pag. 34) se ha denominado BBL 0. Durante la instrumentacion seinsertarıa entonces una entrada en la lista con la informacion del BBL 0 y, en caso de simulacionen modo buffer, su correspondiente call a la funcion de analisis tal y como se ejemplificaba en laFigura 5.2 (pag. 32).

A continuacion, encontrarıa una instruccion de salto a una posicion dentro BBL 0. Es entoncescuando indicarıa que hay dos bloques, BBL 1 y BBL 2, que se insertarıan en la lista y sobre loscuales se agregarıan los correspondientes call. Ya sea con el nombre BBL 0 o con el nombre BBL 1,ambos comenzarıan en la misma instruccion. Ademas, en el codigo instrumentado aparecerıan dosllamadas a la funcion de analisis que cuenta el numero de veces que se ejecuta el bloque. Dentrode los parametros de las llamadas a la funciones de analisis se indicarıa el elemento de la lista debloques sobre el que incrementar el contador. Dado que al final de la ejecucion ambas entradastendran la misma cantidad en el campo Contador, serıa posible anadir un tratamiento posteriorque mejorara las estadısticas finales.

Situaciones como esta son inevitables, ya que Pin no puede predecir inicialmente que va ahaber un salto a una instruccion intermedia hasta que esta tenga lugar. Por tanto, almacenartodos los bloques que encuentre inicialmente es necesario para, al final de la simulacion, realizarlas intersecciones y uniones pertinentes para imprimirlos en el informe final.

RUTINA

El almacenamiento de todas las rutinas ejecutadas permite averiguar, para un bloque basico,en que rutina se encuentra. Esta informacion, en posteriores analisis, participa en la identificaciondel codigo fuente correspondiente a un bloque en concreto. Los campos de mas relevancia son lossiguientes.

Nombre: de cara al codigo fuente, es un buen modo de identificar todo el codigo ensambladorperteneciente a una rutina. Hay que tener en cuenta que habra llamadas sobre las que sehaya hecho inline.

Direcciones de comienzo y fin: son los PCs de las instrucciones inicial y final de la rutina.

5.2. ESTRUCTURAS Y CLASES 35

Ayudaran a indexar los bloques basicos que encierran.

La estructura estaba instanciada como un mapa STL indexado por el contador de programade la primera instruccion de la rutina. Vease el Listado 5.3 (pag. 36). La documentacion de Pinno aconseja averiguar la ultima instruccion de la rutina. En el caso de que hubiera varios puntosde salida (return) no se asegura que la ultima instruccion sea realmente la esperada.

1 map <UINT64 , RTNInfo*> RTNInfoMap;

Listado 5.2: Mapa STL de Rutinas

CACHE

La clase CACHE contiene toda la descripcion de las caracterısticas y comportamiento aproxi-mados de lo que serıa una cache real. En ella se centran las rutinas mas importantes que simulanel comportamiento en memoria de una aplicacion. Los atributos de que consta son los propios deuna memoria cache tales como tamano, asociatividad, tamano de la lınea, latencia, inclusividado exclusividad, polıtica de reemplazo, etc. Hay que destacar que, tal y como estaba organizado elsimulador, pese a que es una clase que podrıa coexistir en sı misma, estaba disenada como clasederivada de una clase padre denominada ESTADISTICAS.

La funcion mas importante se denominaba CacheAccess. Los parametros principales de estafuncion son:

PC: instruccion responsable del acceso.

Address: direccion de la lınea a la que se quiere acceder.

Tipo de acceso: es un enumerado que acepta cualquiera de los siguientes tipos de acceso:

• LOAD: acceso de lectura.

• STORE: acceso de escritura.

• SOFTWARE PREFETCH: software prefetch.

• READ FOR WRITE: caso especial en el que se accederıa al siguiente o siguientes nive-les de cache para traer una lınea que ocasiono un fallo y sobre la que se quiere escribir.Este tipo de accesos no se verıan en una configuracion de cache con polıtica de escriturawrite-through.

• WRITE BACK: si la polıtica de reemplazo ocasiona que se sustituya un bloque dondeel dirty-bit se encontraba a uno, se producira un acceso de este tipo para escribir elbloque antes de que se produzca el reemplazo.

• WRITE THROUGH: en una configuracion con polıtica de escritura write-through, losaccesos a los niveles posteriores al mas proximo a la CPU tendrıan este etiquetado.

• INVAL: acceso que se produce en todas las caches del mismo nivel para invalidar undato que podrıa haberse modificado.

• BACK INVAL: acceso en casos de caches inclusivas. Cuando se producen desalojosde bloques en niveles lejanos al procesador, hay que regresar a los mas cercanos parainvalidarlos si fuera necesario, manteniendo la inclusividad.

Resultado: parametro de entrada/salida que recoge si ha habido acierto o fallo.


Figura 5.6: Punteros a objetos cache

1 void CacheAccess(INT64 PC, ADDR address , enum TYPE_ACCESS typeAccess);

Listado 5.3: Funcion de acceso a la cache

En la definicion de la funcion, hay llamadas sucesivas a otras funciones miembro privadas quese encargaban de lo siguiente:

Examinar el mapa de su cache asociado.

Averiguar si existıa la lınea solicitada.

Proceder a realizar los reemplazos necesarios en caso de que se tratara de un fallo.

Lanzar las ordenes de invalidacion sobre el resto de caches.

Actualizar las estadısticas de hit o miss para el PC responsable de la solicitud.

El numero de objetos creados de la clase CACHE dependen de la configuracion pasada porparametro a la pintool. En la Figura 5.6 (pag. 36) se presenta el modo de almacenar todos lospunteros a los diferentes objetos cache creados a traves de una matriz.

CMP$im soporta aplicaciones multi-hilo. En la configuracion inicial es posible indicar cuantosthreads acceden a determinado objeto de cache. Es un requerimiento que el numero de hilosesperados por la pintool sea potencia de dos, aunque los creados por la aplicacion no lo sean.Cada vez que un hilo quisiera acceder a su objeto de cache, existe una funcion que marca lacorrespondencia entre el id del thread y el ındice de la cache. Una vez obtenido el puntero, seinvocarıa la funcion CacheAccess.

ESTADISTICAS

La clase que almacena las estadısticas es una clase de la que posteriormente hereda la claseCACHE. Se encarga simplemente de proveer, para cada uno de los niveles de cache, de los atributosy funciones miembro necesarios para contener estadısticas y volcarlas al final de la ejecucion. Lamayorıa de estos atributos son a su vez estructuras. Todos estan indexados por thread y PC eneste orden. Entre los datos mas importantes que se contabilizan figuran los siguientes: accesos,aciertos, fallos, tipos de acceso, fallos forzosos, desalojos, vıctimas e invalidaciones.

5.3. PARAMETROS DE EJECUCION 37

5.3. Parametros de ejecucion

La lınea utilizada para simular todas las aplicaciones se presenta en el Listado 5.4 (pag. 37).Los knobs que en figuran en este listado son:

-cache: sirve para configurar los distintos niveles de cache. Habra un knob por cada nivel.

1 -cache <identificador >:<tamano >:<tamano linea >:<asociatividad >:<bancos >

En nuestro caso, vamos a configurar 2 niveles, siendo el primero de ellos una cache de datosL1 y el segundo una cache unificada L2. Los identificadores estan predefinidos, por tantoseran DL1 y UL2. La DL1 sera de 32KB con lıneas de 64B y asociatividad 8. La UL2 sera de1KB con lıneas de 64B y asociatividad 16.

-tlb: para configurar los distintos niveles de TLB.

1 -tlb <identificador >:<lineas >:<tamano pagina >:<asociatividad >

Configuraremos dos niveles de TLB de datos. En este caso, de nuevo los identificadores estanpredefinidos, por tanto seran DTLB y DTLB2. La DTLB tendra de 64 lineas y un tamanode pagina de 4KB, permitiendo mapear 256KB. La DTLB2 tendra 256 entradas y paginasde 4KB para mapear 1MB.

-dl1lat: la latencia de la DL1 sera 4.

-ul2lat: la latencia de la UL2 sera 16.

-dtlblat: la latencia de la DTLB sera 0.

-dtlb2lat: la latencia de la DTLB2 sera 6.

-inclusive: se modelaran caches inclusivas, por tanto se activara indicandolo con un ’1’.

-threads: no se modelaran aplicaciones multihilo, por tanto se indicara que solo se quiere1 hilo.

La latencia de la memoria principal se ha dejado a su valor por defecto, 350 ciclos. Estoinfluira tanto en los fallos de la UL2 como en los de la DTLB2.

1 pin -t cmpsim -cache DL1 :32:64:8:1

2 -cache UL2 :1024:64:16:1

3 -tlb DTLB :64:4096:8

4 -tlb DTLB2 :256:4096:8

5 -dl1lat 4

6 -l2lat 16

7 -dtlblat 0

8 -dtlb2lat 6

9 -inclusive 1

10 -threads 1 -- <app > <input >

Listado 5.4: Lınea para el lanzamiento de la simulacion

Capıtulo 6

Caracterizacion de benchmarks

En este capıtulo se presenta la caracterizacion de los benchmarks descritos en la Seccion 4.3(pag. 23). Se fundamenta en el primero de los objetivos de la Seccion 1.1 (pag. 2) que hacıa refe-rencia al analisis y clasificacion de un conjunto de aplicaciones numericas en funcion del grado devectorizacion. La caracterizacion se ha llevado a cabo de la siguiente manera: una vez seleccionadala muestra de benchmarks, se han compilado y se ha extraıdo el porcentaje de vectorizacion. Parala generacion de este porcentaje se ha hecho uso de una herramienta interna disponible en Intelque instrumentaba de manera muy rapida las instrucciones de una aplicacion. Como en este puntoera importante cuantificar el numero de instrucciones vectoriales de que se compone, se realizo lasiguiente clasificacion: instrucciones enteras e instrucciones en punto flotante. Las instruccionesen punto flotante estan clasificadas a su vez entre aquellas que operan sobre un unico elemento,llamadas escalares, vec 1, y las que lo hacen sobre n elementos, llamadas vectoriales, vec n. Adi-cionalmente, a partir del informe generado por el compilador, se ha extraıdo un resumen sobrelas causas encontradas por este para no vectorizar. Esta informacion se presenta en dos grafi-cas por cada benchmark, una con el porcentaje de vectorizacion y otra con las causas de la novectorizacion.

6.1. Polyhedron

La Figura 6.1 muestra el porcentaje de instrucciones escalares y vectoriales de los benchmarksde Polyhedron. Estan ordenados de izquierda a derecha desde los de menor ındice de vectorizacionhasta los de mayor, respectivamente. En la Tabla 6.1 (pag. 40) se adjunta el desglose numericodel que se sostiene la figura mencionada.

A la derecha de la grafica tenemos aplicaciones como channel, linpk y test fpu, cuyos ındicesde vectorizacion son optimos, sobre todo en el caso de channel. En el extremo opuesto tenemosa tfft con el peor ratio de vectorizacion. Las aplicaciones protein y ace son ejemplos sobre losque no merece la pena centrarse, ya que mayoritariamente tienen instrucciones enteras, las cualesestan fuera de ser objetivo de la vectorizacion. En su lugar, otras aplicaciones como fatigue, doduc,mdbx, nf o induct, parecen interesantes candidatos a ser analizados.

Dada la importancia de comprobar el informe generado por el compilador, se presenta la Fi-gura 6.2. El eje de coordenadas izquierdo representa la distribucion en porcentajes de las razonesmas significativas. En el decidimos incluir la distribucion de bucles que sı han sido vectorizados.El eje de coordenadas derecho presenta la cantidad real de regiones tratadas por el compilador. Sevisualizan con una marca blanca rectangular y sirve de referencia para determinar si la vectoriza-

39

40 CAPITULO 6. CARACTERIZACION DE BENCHMARKS

Figura 6.1: Indice de vectorizacion de las aplicaciones de Polyhedron

cion en realidad ha sido buena. En la leyenda, una de las series se denomina Other. En esta seriese han incluido aquellas que tenıan poco peso. En el caso de Polyhedron, se incluyen las siguientes:insufficient computational work, cannot vectorize empty loop, unsupported reduction, conditionalassignment to a scalar y statement cannot be vectorized. Conviene resaltar que esta grafica nodeja de ser una representacion estatica del log del compilador. Existen bucles que, habiendo sidovectorizados, o bien no se ejecutan debido a los datos de entrada, o bien el numero de instruccionesque contiene es pequeno, impidiendo que el ındice de vectorizacion sea mas favorable.

Polyhedron Enteras % Escalares % Vectoriales %

channel 468.500.485 24,62 2.930.591 0,15 1.431.883.011 75,23linpk 899.584.515 29,43 134.296.667 4,39 2.022.708.587 66,18test fpu 4.029.631.938 50,00 519.826.479 6,45 3.510.250.489 43,55induct 988.762.995 9,05 5.319.266.886 48,66 4.623.569.301 42,30gas dyn 1.329.097.003 38,71 764.150.080 22,26 1.340.360.535 39,04nf 2.760.204.099 29,81 4.497.941.028 48,57 2.002.646.277 21,63capacita 52.878.534.140 61,32 15.135.853.071 17,55 18.214.751.144 21,12air 9.305.166.389 60,05 3.080.714.025 19,88 3.110.552.221 20,07mdbx 8.203.617.802 35,86 11.730.283.833 51,27 2.945.337.303 12,87doduc 29.803.502.394 35,56 44.849.452.311 53,51 9.160.986.696 10,93aermod 41.360.047.064 58,32 25.593.434.008 36,09 3.967.026.727 5,59fatigue 4.582.406.825 29,36 10.443.420.655 66,92 580.509.855 3,72ac 8.552.412.161 79,56 2.009.202.064 18,69 188.047.565 1,75protein 125.788.239.418 96,33 3.640.638.101 2,79 1.155.380.485 0,88tfft 1.307.018.392 29,89 3.061.907.878 70,03 3.443.341 0,08

Tabla 6.1: Desglose de instrucciones de las aplicaciones de Polyhedron

Se observa que channel esta en cabeza en cuanto al numero de bucles vectorizados. Hacen untotal de 66, cantidad pequena comparativamente. Pese a ello, el 82 % de dichos bucles esta vec-torizado permitiendo que la oportunidad de ejecutar una instruccion vectorial aumente. Esto setraduce en un optimo ındice de vectorizacion (recuerdese la Figura 6.1 (pag. 40)). La aplicaciontfft es interesante porque mientras que el ındice de vectorizacion era nulo, los bucles vectorizados

6.2. MANTEVO 1.0 41

Figura 6.2: Razones para no vectorizar bucles en Polyhedron

ocupan el 33 % del total. Se tratarıa por tanto de bucles que no se ejecutan o que lo hacen conmuy poca frecuencia. Por otro lado, mientras que aermod destaca por la cantidad de bucles quecontiene, 2597, un 72 % no se ha vectorizado, siendo la razon de peso que los bucles no iteran losuficiente como para que sea eficiente, low trip count. En air, el numero de bucles vectorizadoscompite con los que no lo han sido. El motivo principal es not inner loop. Cada vez que el com-pilador se dispone a vectorizar un bucle de entre un conjunto de bucles anidados, para todos losbucles externos registra como motivo que no son bucles internos. En air, se entiende entonces quehay muchos bucles anidados.

6.2. Mantevo 1.0

El ındice de vectorizacion de las aplicaciones de Mantevo visualizadas en la Figura 6.3 (pag. 42)no parecen dar tanto juego como en Polyhedron. La Tabla 6.4 (pag. 43) adjunta el desglose deinstrucciones. La aplicacion CoMD, que podrıa ser uno de los candidatos, tiene un 69,35 % de ins-trucciones enteras. Si bien podrıa ser estudiado para reducir el numero de instrucciones escalares,vec 1, las enteras no parecen dejar mucho margen para conseguir una mejora mas significativa.

En la Figura 6.4 (pag. 43) con las razones del compilador para no vectorizar, las opcionesenglobadas en la categorıa other son: low trip count, loop was transformed to memset or memcpyy conditional assignment to a scalar. La aplicacion CloverLeaf, que presentaba el mejor ındice devectorizacion con un 73,13 % de instrucciones vec n, aquı se encontrarıa por detras de miniGhosten cuanto a bucles vectorizados. Entre los motivos para no vectorizar, es mayoritaria la razonnot inner loop. En Polyhedron ya vimos que no es una razon de peso. Ademas, dado que es laaplicacion con mayor numero de bucles, 1127, en realidad se trata de un caso de exito. En lamisma lınea tenemos a miniGhost, con un resultado semejante en cuanto a bucles vectorizados,


Figura 6.3: Indice de vectorizacion de las aplicaciones de Mantevo 1.0

Mantevo Enteras % Escalares % Vectoriales %

CloverLeaf 3.312.609.977 17,09 1.896.586.386 9,78 14.174.588.802 73,13miniGhost 5.817.781.939 57,48 290.628.926 2,87 4.013.310.416 39,65HPCCG 9.153.318.789 54,30 1.813.492.799 10,76 5.890.463.437 34,94miniMD 9.076.376.697 50,00 3.886.133.542 21,41 5.189.843.145 28,59miniFE 30.524.781.122 66,90 5.714.424.611 12,52 9.384.984.596 20,57miniXyce 151.901.922.911 96,07 4.734.235.225 2,99 1.485.511.169 0,94CoMD 3.899.688.850 69,35 1.711.104.306 30,43 12.159.534 0,22

Tabla 6.2: Desglose de instrucciones de las aplicaciones de Mantevo

pero con 294 bucles. Volviendo a su ındice de vectorizacion, 39,65 %, no deja de ser bajo debido alas instrucciones enteras. Por otro lado, HPCCG sorprende, ya que es el que tiene menor numerode bucles, 78, pero pese a ser pocos, se consigue vectorizar un 46 %, que se traducen en un ındicede vectorizacion del 34,94 %. Finalmente, miniXyce y CoMD estan a la cola como ocurrıa consus ındices de vectorizacion respectivos. Sorprende miniXyce, ya que tiene mas bucles que CoMD,pero su ındice de vectorizacion es insignificante al ser una aplicacion mayoritariamente entera.

6.3. Sequoia

En la Figura 6.5 (pag. 44), las aplicaciones SPhotmk y Crystalmk, con un 50,5 % y un 46,69 %de instrucciones escalares, respectivamente, parecen claros candidatos a elegir para su analisis.Vease tambien el desglose de instrucciones en la Tabla 6.3 (pag. 43).

En la Figura 6.6 (pag. 44), los motivos incluidos en la categorıa other son: unsupported loopstructure, cannot vectorize empty loop y conditional assignment to a scalar.

Las aplicaciones de este benchmark tienen pocos bucles, comparados a grosso modo con losbenchmarks vistos anteriormente. Aquel que mas tiene, UMTmk, asciende a 105. Sin embargo,

6.4. NPB 43

Figura 6.4: Razones para no vectorizar bucles en Mantevo 1.0

Sequoia Enteras % Escalares % Vectoriales %

IRSmk 6.418.427.371 44,33 60.616.654 0,42 8.000.112.715 55,25UMTmk 85.434.122 66,40 12.366.599 9,61 30.872.142 23,99Crystalmk 5.566.079.613 47,53 5.468.000.498 46,69 677.000.196 5,78SPhotmk 47.201.295 43,94 54.255.433 50,50 5.972.314 5,56

Tabla 6.3: Desglose de instrucciones de las aplicaciones de Sequoia

dejando de lado este dato, sorprende SPhotmk que, junto con Crystalmk, y pese a tener ambos lospeores ındices de vectorizacion, tienen mas bucles que la aplicacion con mejor ındice, IRSmk. Estosignifica dos cosas: el numero de bucles vectorizados serıa mayor proporcionalmente; al haber masbucles, hay mas candidatos a ser mejorados y por tanto son aplicaciones interesantes para abor-darlas de cara al analisis. Finalmente, la aplicacion IRSmk tambien sorprende porque, teniendomejor ındice, en realidad el numero de bucles tratados es inferior a 20. Por tanto, los bucles de queconsta, por pocos que sean, concentran la mayor parte del computo dando lugar a un rendimientooptimo pese a la limitacion impuesta por las instrucciones enteras.

6.4. NPB

La Tabla 6.4 (pag. 45) y la Figura 6.7 (pag. 45) muestran que las aplicaciones UA, IS, BT yLU se corresponderıan a los candidatos de mas interes. Hasta ahora, en las graficas mostradascomprobamos que, pese a que una aplicacion tenga un buen ındice de vectorizacion, es en lasinstrucciones escalares donde se encuentran las oportunidades para vectorizar.


Figura 6.5: Indice de vectorizacion de las aplicaciones de Sequoia

Figura 6.6: Razones para no vectorizar bucles en Sequoia

6.4. NPB 45

Figura 6.7: Indice de vectorizacion de las aplicaciones de NPB

NPB Enteras % Escalares % Vectoriales %

FT 141.213.978 45,61 7.116.085 2,30 161.292.981 52,09MG 95.558.650 32,86 45.070.701 15,50 150.211.106 51,65EP 537.991.137 36,23 451.200.929 30,38 495.838.486 33,39SP 5.435.933.967 50,67 1.944.681.817 18,13 3.348.529.940 31,21CG 419.556.698 62,22 62.606.098 9,28 192.116.340 28,49LU 3.604.965.775 28,18 6.447.471.196 50,40 2.740.743.624 21,42BT 986.948.941 13,41 5.286.544.985 71,85 1.083.789.029 14,73IS 141.146.461 56,20 88.048.143 35,06 21.974.211 8,75UA 2.089.546.384 26,02 5.495.880.739 68,43 445.471.779 5,55DC 135.544.766.627 97,66 825.664.200 0,59 2.424.457.394 1,75

Tabla 6.4: Desglose de instrucciones de las aplicaciones de NPB

En la Figura 6.8 (pag. 46), los motivos englobados en la categorıa other son: statement cannotbe vectorized, condition may protect exception, operator unsuited for vectorization, unsupporteddata type y cannot vectorize empty loop.

La aplicacion FT presenta el mejor ındice de vectorizacion, 52,09 %, pero el informe generadopor el compilador para ella destaca por el bajo numero de bucles tratados, 35. Se trata de otro casocomo IRSmk de Sequoia. El ındice es bueno porque, al ser pocos bucles, aparentemente se hanvectorizado aquellos que se ejecutan mas, incluso siendo el porcentaje de bucles vectorizados desolo un 35 %. Por otro lado tenemos UA, con 906 bucles. Si de todos estos bucles un 36 % ha sidovectorizado y un 31 % eran bucles externos, parece que no es suficiente la razon vectorization posiblebut seems inefficient para justificar el bajo ındice de vectorizacion obtenido, 5,55 %. Parece un casocontrario al de FT, en el que los bucles vectorizados no tienen un peso suficiente en la ejecucion.Finalmente, comentar que el compilador ha tratado unicamente 16 bucles para la aplicacion EPy, teniendo en cuenta que tiene un ındice de vectorizacion del 33,39 %, demuestra que el computogeneral del programa esta repartido entre pocos bucles.


Figura 6.8: Razones para no vectorizar bucles en NPB

6.5. SPEC FP

Pese a que la Figura 6.9 (pag. 47) y la Tabla 6.5 (pag. 47) nos muestran que las aplicacionescactusADM y zeusmp estan por detras de lbm en el grupo de las aplicaciones con mejor ındice devectorizacion, el porcentaje de instrucciones escalares no deja de ser menos significativo que otrasaplicaciones como namd. Al igual que namd, povray y milc presentan una buena candidatura porel simple hecho de que su ındice de vectorizacion es practicamente inexistente.

En la Figura 6.10 (pag. 48) las razones incluidas en la categorıa other son: statement cannot bevectorized, condition may protect exception, operator unsuited for vectorization, unsupported datatype y cannot vectorize empty loop.

Destaca gamess por la gran cantidad de bucles tratados por el compilador, 52237. Sin embargo,pese al 47 % de bucles vectorizados, el ındice de vectorizacion no es mas que del 13,08 %, con loque dichos bucles no tienen gran parte del peso del programa. Por su parte, lbm destaca por tenermuy poca cantidad de bucles, 64, pero con mas de la mitad de ellos vectorizados ha sido suficientepara obtener un ındice de vectorizacion del 76,41 %.

Lo datos presentados dejan fehaciente que, pese a que el compilador este especialmente disenadopara explotar la vectorizacion, no se consiguen resultados favorables para todas las aplicaciones.Esto se traducirıa en un deficiente uso de la unidad de vectorizacion. Tambien hay que tenerpresente el contraste entre el caracter dinamico de la grafica con el porcentaje de vectorizacion,frente al caracter estatico de aquella con el informe generado por el compilador. Estas razones danlugar a generar informes mas completos del comportamiento de las aplicaciones, para lo cual esnecesario completar el simulador CMP$im.

6.5. SPEC FP 47

Figura 6.9: Indice de vectorizacion de las aplicaciones de SPEC fp

SPEC fp Enteras % Escalares % Vectoriales %

470.lbm 247.043.444 17,79 80.478.947 5,80 1.061.043.618 76,41436.cactusADM 87.202.676 17,90 717.855.566 44,73 599.834.350 37,38434.zeusmp 3.098.091.055 22,22 5.964.021.317 42,78 4.879.315.996 35,00437.leslie3d 3.466.782.814 42,50 1.932.662.908 23,69 2.757.121.526 33,80481.wrf 1.430.157.094 60,39 379.485.584 16,02 558.461.158 23,58410.bwaves 5.608.197.533 61,63 1.506.737.948 16,56 1.985.594.787 21,82459.GemsFDTD 2.579.077.218 79,49 135.223.572 4,17 530.125.307 16,34416.gamess 814.275.217 64,01 291.456.487 22,91 166.450.557 13,08465.tonto 1.735.105.509 63,42 686.200.465 25,08 314.702.162 11,50435.gromacs 1.077.444.401 58,22 567.698.837 30,68 205.426.782 11,10482.sphinx3 3.949.495.345 84,16 256.885.880 5,47 486.219.594 10,36450.soplex 37.411.459 80,35 7.610.447 16,34 1.539.792 3,31454.calculix 101.212.053 91,84 5.847.184 5,31 3.139.907 2,85433.milc 2.126.321.655 13,85 12.860.333.431 83,76 366.588.682 2,39453.povray 1.225.769.598 65,92 597.196.874 32,11 36.644.135 1,97444.namd 18.465.424.606 40,98 26.139.516.627 58,00 460.045.395 1,02447.dealII 34.050.212.478 74,97 11.045.728.175 24,32 321.833.495 0,71

Tabla 6.5: Desglose de instrucciones de las aplicaciones de SPEC FP


Figura 6.10: Razones para no vectorizar bucles en SPEC fp

Capıtulo 7

Adaptacion del Simulador

En este capıtulo se describen las ampliaciones que se han realizado sobre el simulador CMP$imparaincluir capacidades de ejecucion vectoriales. A la hora de decidir que tipo de capacidades vecto-riales incluir, se ha optado por realizar un modelado sencillo de la arquitectura del coprocesadorIntel R© Xeon PhiTM. No se pretendıa realizar un analisis del rendimiento de este producto, sinotener un modelo que se sabe hace uso de unidades vectoriales con el que generar estadısticas sobreesta caracterıstica de formas rapida y sencilla.

Para abordar una descripcion detallada del simulador construido, se va a partir de las siguientestres preguntas:

¿Que caracterısticas tiene que tener el pipeline para adaptarse a la arquitectura Intel R© XeonPhiTM Coprocessor?

¿Hay datos intermedios ya generados por CMP$imque puedan ser reutilizados?

¿Que estadısticas particulares permitiran discernir sobre el uso de la unidad vectorial?

7.1. Pipeline

Al instrumentar una aplicacion, es sencillo contar el numero de instrucciones ejecutadas puesunicamente se trata de incrementar un contador. La contabilizacion de ciclos tambien serıa unatarea sencilla en caso de una maquina multiciclo, en la que hasta que no finaliza una instruccion,no se ejecuta la siguiente. En el caso de una maquina segmentada esta tarea ya no es tan trivial.Hay que tener en cuenta las peculiaridades de la arquitectura para situar a una instruccion en laetapa correcta segun avance la ejecucion.

Rememorando lo comentado en la Seccion 5.1 (pag. 31), se presenta la Figura 7.1 (pag. 50)con el boceto sobre donde se colocarıa la simulacion del pipeline. Sabemos que se alternan lasfases de instrumentacion y analisis a medida que se avanza en la ejecucion. La fase de simulacionde cache se hace durante la fase de analisis usando datos que se han registrado en la fase deinstrumentacion. La simulacion del pipeline es analoga y, en este caso ademas, necesita de lasimulacion de cache para utilizar la informacion que de esta se genera. Por tanto, necesariamentetiene que ir a continuacion como se visualiza en la figura.

El coprocesador Intel R© Xeon Phi R© es una maquina en orden con terminacion fuera de orden(vease Seccion 2.3 (pag. 8)). Para simplificar el modelo no se han implementado etapas, con lo

49

50 CAPITULO 7. ADAPTACION DEL SIMULADOR

Figura 7.1: Pipeline dentro de CMP$im

que cuando una instruccion entra en nuestro pipeline, significa que se va a ejecutar, ya sea unacceso a memoria o una division vectorial. Se han tomado las siguientes consideraciones a la horade implementar el pipeline:

Cada instruccion entrara en el pipeline un ciclo despues de la entrada de la instruccionanterior.

No hay lımite de recursos.

Los registros se escriben en el banco de registros despues de la finalizacion de la instruccion.Si se producen dependencias de instrucciones no harıa falta esperar a la escritura en el banco.Existen buses por donde recoger esa informacion antes de llegar al banco.

La latencia de una instruccion se caracteriza por los ciclos que necesita para completar unaoperacion sin contar las dependencias.

Un fallo en el primer nivel de cache que implique traer una lınea de los niveles siguientes,congela automaticamente el pipeline tanto si la instruccion siguiente necesita el dato comosi no. Esto se produce con cualquier tipo de acceso a memoria bajo demanda (load, store,software prefetch, etc.)

Los ciclos situados entre ciclo entrada ins actual− ciclo entrada ins anterior + 1 se utili-zaran exclusivamente con fines estadısticos.

Para ejemplificarlo se utilizara un pequeno kernel escrito en Fortran y basado en el bucle s171del conjunto de bucles del benchmark LCD. Vease el codigo en Listado 7.1 (pag. 51). El bloque conmayor numero de instrucciones ejecutadas mostrado en el Listado 7.2 (pag. 51) se correspondeexactamente con el bucle do..continue del kernel. Como es un ejemplo simple para mostrar elfuncionamiento del pipeline no se ha compilado para la arquitectura AVX-512. Para el ejemplono se mostrara mas que una iteracion. La estructura de bloques disponibles es indispensable paralo que serıa la creacion de un histograma con informacion estatica de las instrucciones. Permitirıaentonces acceder a los datos que caracterizan a las instrucciones, como por ejemplo la latencia paraaquellos casos donde se realice una operacion. Aparte, como se mostro en la Figura 7.1 (pag. 50),para construir un pipeline ficticio es indispensable hacer uso de los datos proporcionados por lasrutinas de simulacion de cache de CMP$im.

En la Tabla 7.1 (pag. 51) se muestra la informacion recopilada de las instrucciones de masinteres desenrolladas por el compilador. Esta informacion recoge datos de latencias de tlb, cachey operacion. La instrucciones que realizan las operaciones de suma y multiplicacion entran dentrode la clasificacion de las FMA. Su latencia, 4, se puede consultar mas adelante en el Listado 7.5

7.1. PIPELINE 51

(pag. 55). Vease la Figura 7.2 (pag. 52) con el detalle del pipeline. Tengase en cuenta que lacuadrıcula es una aproximacion para entender el funcionamiento de nuestro kernel basado en elcoprocesador Intel R© Xeon Phi R©.

c

c -- Fichero: main.f

c

integer n

real a(100000) , b(100000) , c(100000)

open (unit=1, file="N")

read (1,*) n

close (1)

call s171(a, b, c, n)

end

c

c -- Fichero: s171.f

c

subroutine s171(a, b, c, n)

integer n

real a(n),b(n),c(n)

do 10 i = 1,n

a(i) = a(i) + b(i) * c(i)

10 continue

return

end

Listado 7.1: Kernel s171 basado en el mismo bucle en LCD

1 4004f9: movups xmm0 , xmmword ptr [rsi+rax*4]

2 4004fd: movups xmm1 , xmmword ptr [rsi+rax *4+0 x10]

3 400502: mulps xmm0 , xmmword ptr [rdx+rax *4]

4 400506: mulps xmm1 , xmmword ptr [rdx+rax *4+0 x10]

5 40050b: addps xmm0 , xmmword ptr [rdi+rax*4]

6 40050f: addps xmm1 , xmmword ptr [rdi+rax *4+0 x10]

7 400514: movups xmmword ptr [rdi+rax*4], xmm0

8 400518: movups xmmword ptr [rdi+rax *4+0 x10], xmm1

9 40051d: add rax , 0x8

10 400521: cmp rax , r9

11 400524: jb 0x4004f9

Listado 7.2: Bloque basico de s171 con mayor numero de instrucciones ejecutadas

Latencias TLB Cache Operacion

load 356 370

load 4

mul 4 4

mul 4 4

add 356 370 4

add 4 4

store 4

store 4

Tabla 7.1: Latencias de memoria y de instruccion (load-op)

A continuacion se explica en detalle el pipeline de la Figura 7.2 (pag. 52):


Figura 7.2: Pipeline del bloque de s171

load - movups xmm0, xmmword ptr [rsi+rax*4]: La latencia es alta porque se ha pro-ducido fallo tanto en TLB como en L1. Se ha tenido que llegar a la memoria principal. Como secomento, esta situacion provoca la congelacion del pipeline. La siguiente instruccion no entrarıahasta el ciclo 726.

load - movups xmm1, xmmword ptr [rsi+rax*4+0x10]: Acierto en el primer nivel decache, DL1, por lo que entra en el 726 y termina en el 730.

mul - mulps xmm0, xmmword ptr [rdx+rax*4]: Instruccion tipo load-op. Dependencia delregistro xmm0 sobre la primera carga sin consecuencias. La instruccion entrarıa en el ciclo 726+1,a continuacion de la anterior porque el registro xmm0 estarıa disponible. Como es load-op cargaprimero el dato, acierto en DL1 (4 ciclos) y opera (4 ciclos), haciendo un total de 8 ciclos. Entrarıapues en el 727 y saldrıa en el 735.

mul - mulps xmm1, xmmword ptr [rdx+rax*4+0x10]: Instruccion tipo load-op. Depen-dencia del registro xmm1 en el segundo load. Idealmente entrarıa en el 728, pero como la cargade la que depende no termina hasta el 730, se retrasa 2 ciclos. De nuevo cargarıa primero el dato(4 ciclos) y operarıa sobre el (4 ciclos). Entrarıa pues en el ciclo 730 y sale en el 738.

add - addps xmm0, xmmword ptr [rdi+rax*4]: Instruccion tipo load-op. Dependencia delregistro xmm0 sobre la primera multiplicacion. Idealmente entrarıa en el 731, pero se retrasa 4ciclos. Falla en el TLB y en la cache y tiene que ir hasta memoria, ocasionando que se congeleel pipeline. La siguiente instruccion no entrarıa hasta que pasaran los 726 ciclos de memoria.Finalmente realiza la suma (4 ciclos). Entra entonces en el ciclo 735 y sale en el 1465.

add - addps xmm1, xmmword ptr [rdi+rax*4+0x10]: Instruccion tipo load-op. Depen-dencia del registro xmm1 sobre la segunda multiplicacion sin consecuencias. Entra en el ciclo 1461debido a la congelacion del pipeline de la instruccion anterior. Termina en el 1469 por el acceso amemoria (4 ciclos) y la suma (4 ciclos).

store - movups xmmword ptr [rdi+rax*4], xmm0: Dependencia del registro xmm0 sobrela primera suma. Idealmente entrarıa en el ciclo 1462 pero se retrasa 3 ciclos. Entonces entra enel 1465 y termina en el 1469. Acierta en la cache.

7.2. DETECCION DE INSTRUCCIONES Y REGISTROS 53

store - movups xmmword ptr [rdi+rax*4+0x10], xmm1: Dependencia del registro xmm1sobre la segunda suma. Idealmente entrarıa en el 1466 pero se retrasa 3 ciclos hasta el 1469. Finalizaen el 1473 pues acierta en el primer nivel de cache.

7.2. Deteccion de instrucciones y registros

La caracterizacion de las instrucciones es un paso esencial para el funcionamiento de estesimulador. Permite conocer al detalle las instrucciones de cara a construir, por ejemplo, una tablade registros. Tambien permitirıa saber cuanto tiempo va a requerir para terminar la operacion quecontenga, independientemente de las dependencias de los operandos. De cara a las instruccionesexclusivamente de memoria o las load-op, que cargan un dato y operan sobre el mismo, no esposible conocer los ciclos totales hasta la simulacion sobre la cache.

La API de Pin para instrumentar instrucciones pone a disposicion del usuario multitud defunciones que ayudan a la caracterizacion. Sin embargo, mientras que existen funciones que de-tectan facilmente si, por ejemplo, la instruccion es un salto o una comparacion, el repertorio noes suficientemente granular para caracterizar instrucciones vectoriales. No es capaz de discernir sila instruccion es simplemente vectorial o si los registros son vectoriales. Lo mismo ocurre con lacaracterizacion de las instrucciones tipo load-op. Hay que tener en cuenta que las instrucciones quese iban a instrumentar eran de las extensiones AVX-512. Estas instrucciones, en el momento deconstruir el simulador, no eran publicas. Por tanto no era posible para Pin proporcionar una APIque permitiera reconocer los nuevos registros de 512 bits. Ya fuera entonces por la no publicidadde la arquitectura, o porque simplemente no disponıa de funciones con la suficiente granularidad,se creo el codigo necesario para subsanar estas carencias.

7.2.1. Instrucciones

INS IsVector: para discernir si una instruccion es vectorial o no, usamos librerıas de usointerno en donde todas y cada una de las instrucciones de AVX-512 estaban caracterizadas.Mediante estas funciones era posible consultar campos como la categorıa o extension de unainstruccion. Para nuestros propositos, bastaba con usar la extension, cuya clasificacion eramas generica, reduciendo por tanto las lıneas de codigo.

is scalar simd: de nuevo, mediante el uso de la misma librerıa interna, era posible de-terminar si una instruccion estaba operando sobre un unico o multiples elementos de unvector.

is load op: la heurıstica consiste en contar el numero de operandos de lectura totales de lainstruccion, x, y el numero de operandos de memoria, y. Si x > y entonces la instrucciones load-op, ya que el operando de mas es aquel que se operara junto con el dato cargado dememoria. Vease el detalle en el Listado 7.3 (pag. 53).

1 bool is_load_op(INS ins)

2 {

3 if (IsMemInstruction(ins))

4 {

5 UINT32 operandCount = INS_OperandCount(ins);

6 UINT32 readOp = 0;

7 UINT32 memReadOp = 0;

89 for (UINT32 i = 0; i < operandCount; i++)

10 if (INS_OperandRead(ins ,i))

11 {

12 readOp ++;

13 if (INS_OperandIsMemory(ins ,i)) memReadOp ++;


14 }

1516 if (memReadOp && readOp > memReadOp)

17 return true;

18 }

19 return false;

20 }

Listado 7.3: Funcion para detectar instrucciones load-op

7.2.2. Registros

La deteccion de registros paso a formar parte del algoritmo general de instrumentacion deinstrucciones. Tambien se utilizaron funciones de librerıas internas que reconocieran los registroszmm de AVX-512. El modus operandi consistio en analizar individualmente cada operando yclasificarlo del siguiente modo:

Operando con registro: es aquel sobre el que se va a operar, ya sea para leer o escribir.

Operando de memoria: tuvimos en cuenta que habrıa registros con los que se opera paraobtener una direccion de memoria.

La ventaja de acceder a los registros de este modo es que nos permite conocer, a traves deloperando, si es un registro del que se va a leer o sobre el que se va a escribir. Los operandos dememoria nos permitieron hacer un analisis mas granular mediante la clasificacion de los registrossegun el tipo de direccionamiento: base, ındice o segmento.

7.2.3. Latencias

En CMP$im, la latencia de las instrucciones se toma por defecto a 1. Para las instrucciones dememoria se agregarıa la cantidad de ciclos correspondientes a la latencia, ya suponga un aciertoen la L1 o se tuviera que traer la lınea desde memoria. Para este trabajo tuvimos que modificar eltratamiento de latencias de las instrucciones alejandolo del sistema ideal por defecto de CMP$im.En el Listado 7.4 (pag. 54) se presenta la clasificacion que hicimos de las instrucciones. Por defecto,los valores se mantuvieron a 1.

1 #define NONVPU_LATENCY 1

2 #define MISC_LATENCY 1

3 #define DIV_SQRT_LATENCY 1

4 #define RCP_RSQRT_LATENCY 1

5 #define FMA_LATENCY 1

Listado 7.4: Clasificacion de las latencias por defecto

Veamoslas en detalle:

NONVPU : conjunto de instrucciones enteras.

DIV/SQRT : tanto la division como la raız cuadrada son operaciones muy costosas que tienensemejante numero de ciclos.

7.3. NUEVAS ESTRUCTURAS Y CLASES 55

RCP/RSQRT : las instrucciones recıprocas tienen equivalente latencia, incluyendo las raıcesrecıprocas. La categorıa recıprocas indica que se esta calculando el inverso: 1/x en el casode las rcp en general y −1/2

√x en el caso de las rsqrt.

FMA: operaciones de punto flotante que realizan suma y multiplicacion en el mismo paso.

MISC : resto de instrucciones que no entran en el perfil de las enteras, pero que sı puedenser vectoriales/escalares.

Dado que estas latencias deberıan ser modificables, se tomo la decision de incorporar un knobque permitiera introducir esta configuracion a traves de un fichero. Vease el ejemplo del Listado 7.5(pag. 55)

1 # Example configuration file for instruction latencies.

2 # Non -VPU instructions

3 nonvpu 1

45 # VPU instructions

6 rcprsqrt 8

7 divsqrt 30

8 fma 4

910 # Default VPU instructions

11 misc 2

Listado 7.5: Fichero de ejemplo con latencias

Finalmente, durante la caracterizacion de instrucciones vista en Seccion 7.2.1 (pag. 53), seagrego una nueva funcion denominada GetLatencyByIclass que, haciendo uso de funciones in-ternas, permiten consultar la clase de la instruccion y asignarle una latencia en funcion de lamisma.

7.3. Nuevas estructuras y clases

Las estructuras nuevas para el nucleo basado en el coprocesador Intel R© Xeon PhiTMque sepresenta en este apartado son el resultado de entenderlo como un modulo anadido a toda la simu-lacion de CMP$im. Se necesita la informacion recogida por las instrucciones, ya sean de memoriao no, y se tiene que respetar el funcionamiento original de CMP$im para ambos modos buffer einstruccion a instruccion. Decidimos por tanto desarrollarlo en dos nuevos ficheros core.cpp ycore.h.

La localizacion de las llamadas al pipeline de este nucleo era un problema que habıa queabordar desde el punto de vista del analisis mas que de instrumentacion. Recordamos el analisisrealizado sobre el pipeline en la Seccion 7.1 (pag. 49). Decidimos situarlas antes de la ejecucionde cada bloque. Vease la Figura 7.3 (pag. 56). Este esquema encaja con el modo buffer porquepreviamente se han simulado las instrucciones del bloque anterior. En el caso del primer bloqueno se simulara nada, mientras que en el caso del ultimo bloque sera la funcion de finalizacion laque lanzarıa el pipeline. Tambien encaja con el modo instruccion a instruccion porque cuando seha llegado al bloque siguiente, las instrucciones de memoria del anterior ya se han simulado en lacache, aunque fuera individualmente.

La idea consistio en desarrollar una clase nueva denominada CORE. Este concepto de corees ligeramente distinto a lo que venıamos nombrando como nucleo. La clase CORE representa elesquema de los cores que componen el coprocesador. Si quisieramos simular la tarjeta completa,se crearıan 50 objetos. Dado que en este trabajo no se toca el campo multi-thread, con simular uncore era suficiente. La idea se asemeja a la clase CACHE explicada en la Seccion 5.2 (pag. 33). De


Figura 7.3: Localizacion del simulador de pipeline en CMP$im

hecho, estan ıntimamente relacionados, ya que cada objeto CORE creado tendra su objeto CACHE

asociado. Cada objeto CORE ademas tendrıa su propio pipeline y sus propias estructuras dealmacenamiento de estadısticas y del estado del core en cada momento. Por otro lado, al tenerque almacenar informacion detallada sobre todas las instrucciones instrumentadas, ya fueran dememoria o no, era necesaria una estructura solo modificable en tiempo de instrumentacion conel footprint de la aplicacion. Ademas, tambien serıa necesario guardar los registros utilizados entiempo de analisis para detectar dependencias. Vease la Figura 7.4 (pag. 56) para obtener unaimagen visual de estos conceptos.

Figura 7.4: Idea para la implementacion de KNC

Las estructuras y clases principales desarrolladas para ello fueron las siguientes:

Footprint

Basic Block State

Register File

State

Stats

Core


FOOTPRINT

Durante la fase de instrumentacion se analizan todas las instrucciones de la aplicacion. Esnecesario por tanto almacenar la informacion estatica recopilada de cada una de ellas para suposterior uso durante la fase de analisis. Esta estructura se implemento para tal fin. Los camposde que consta son los siguientes:

Tipo: enumerado que recoge la siguiente clasificacion posible:

Entera Escalar Vectorial Memoria

1 typedef enum

2 {

3 INS_TYPE_NONVPU ,

4 INS_TYPE_V_VECTOR ,

5 INS_TYPE_V_SCALAR ,

6 INS_TYPE_MEM ,

7 INS_TYPE_NUM

8 }INS_TYPE_t;

Latencia operacional: si una instruccion tiene esperar a que otra termine de realizar unaoperacion para usar su resultado, es necesario conocer cuanto va a tardar la operacion en sı.Esto incluye a las instrucciones denominadas load-op, las cuales a la vez que cargan un datoen la cache, operan sobre el una vez disponible. Sin embargo, este campo no servira paraalmacenar la latencia provocada por una instruccion de memoria.

Tamano de la instruccion: para saber exactamente en que punto termina un bloquebasico.

Registros fuente y destino: necesarios para realizar el control de dependencias de registro.

Desensamblado: con fines de depuracion.

Rutina: a que rutina pertenece la instruccion.

Esta estructura se declaro sobre un mapa STL, siendo la clave de acceso el PC de la instruccion.Vease el Listado 7.6 (pag. 57).

1 typedef map <UINT64 , INS_FOOT_PRINT_t > FOOT_PRINT;

Listado 7.6: Footprint de las instrucciones de la aplicacion

REGISTER TABLE

La deteccion de las dependencias entre registros requiere llevar un seguimiento de las escriturasde los mismos. Por ello, se creo una pequena estructura que almacena la siguiente informacion.

Ciclo: se actualiza cada vez que se escriba el registro. Por tanto, indica el ciclo en el que unregistro estara disponible.

Direccion: PC de la instruccion que ha sido la ultima en escribir dicho registro. Sirve parapoder responsabilizar a una instruccion de que otra ha tenido que atrasar su ejecucion.

Desglose de ciclos: para casos en que una instruccion de memoria haya escrito el registro,se almacena el desglose de ciclos generados para conseguir el dato. Esta informacion estemporal y solo influye en tiempo de simulacion, no en los resultados finales. Seran vectoresde tamano fijo dado por las macros KNC TLB LVLS y KNC CACHE LVLS.


Figura 7.5: Instruccion que toca dos lıneas

Esta estructura se declaro en el interior de un mapa STL indexado por el codigo del registro.Habra tantas entradas como registros se hayan accedido en la ejecucion. Vease el Listado 7.7(pag. 58). Esta tabla solo se actualiza durante la simulacion, puesto que ya tenemos disponibleslos registros utilizados por cada instruccion. Estos fueron previamente almacenados durante lainstrumentacion de las instrucciones.

1 typedef map <UINT32 , REG_FILE_STATE_t > REG_FILE;

Listado 7.7: Mapa STL de la Tabla de Registros

BASIC BLOCK STATE

Para llevar un seguimiento del comportamiento de las instrucciones de memoria para cadauno de los bloques basicos ejecutados por la aplicacion, presentamos la siguiente estructura. Tienecaracter temporal. Los campos definidos son los siguientes:

Nivel de hit de TLB: es el ultimo nivel de TLB al que se ha accedido. Este nivel incluirıala memoria principal como ultimo nivel en caso de tener que acceder a la tabla de paginasdel proceso.

Nivel de hit de Cache: analogo al campo anterior, pero para el caso de la jerarquıa decache.

Desglose de ciclos de la TLB y de la CACHE: aquı se van almacenando los ciclosrequeridos por una instruccion al acceder a distintos niveles de ambas caches. Seran vectoresde tamano fijo dado por las macros KNC TLB LVLS y KNC CACHE LVLS.

Fue declarada como parte de un mapa STL indexado por una clave que tiene dos campos <PC,acceso>. Vease el Listado 7.8 (pag. 59) con la declaracion con los tipos de datos requeridos. Alrealizar una instruccion un acceso a memoria, existe la posibilidad de que tenga que realizar masde un acceso. Es posible que el dato no este alineado, teniendo que tocar dos lıneas de cache.Vease la Figura 7.5 (pag. 58). En estos casos es necesario almacenar los accesos por separado yaque el primero puede ser un fallo y el segundo un acierto. Si este histograma se indexara solo porel PC de la instruccion, destruirıamos la informacion del primer acceso al registrar el segundo.Esto tambien ocurre de forma totalmente distinta, en el caso de instrucciones tipo gather. Estainstruccion tiene la especialidad que no toca dos lıneas porque el dato no esta alineado, el interesradica en que se despliega en todo un conjunto de accesos independientes los cuales a su vez puedenestar desalineados. Al acceder a la estructura con el par <PC, acceso> el problema desaparece.En el mapa de ciclos el primer acceso tendra el valor <PC,0>, y el resto de accesos, por numerososque fueran, se indexarıan incrementando el segundo campo.


1 typedef std::pair <UINT64 , UINT32 > BBL_ENTRY_KEY;

2 typedef map <BBL_ENTRY_KEY , BBL_STATE_t > BBL_STATE;

Listado 7.8: Mapa STL de los accesos a cache de las instrucciones de memoria de un BBL

STATE

Para hacer una fotografıa al estado actual de la simulacion se creo esta estructura. Englo-ba campos creados a partir de las estructuras anteriores BBL STATE y REG FILE. Ademasalmacenara los siguientes campos:

Ciclo de issue: en el momento de la simulacion, es importante conocer el ciclo en el que seinserta una instruccion en el pipeline. De este modo se podra determinar cuando empezarıala siguiente.

Ciclo de write back: en el caso de instrucciones que escriban en un registro, ya sea elresultado de una operacion o una carga de memoria, es importante saber en que ciclo escribede cara a entregarle ese dato a la tabla de registros.

Estado de la memoria: desglose de ciclos de la ultima instruccion de memoria ejecutada.Se creo para abrir la posibilidad de lanzar una aplicacion multi-thread.

Ultima instruccion: informacion sobre la ultima instruccion que ocupo el pipeline.

STATS

La estadısticas son una parte fundamental. En esta clase se acumularıan los datos necesariospara su tratamiento a posteriori. En la Seccion 7.4 (pag. 62) se explica al detalle este post-tratamiento. Las estadısticas se acumulan desde dos perspectivas: a nivel de instruccion y a nivelglobal.

Los campos de que consta las estadısticas por instruccion son los siguientes:

Bytes cargados: para propositos de validacion. Si sabemos exactamente cuantos elementosva a recorrer un bucle y de que tipo son, podemos localizar el bloque del bucle en el informefinal y validar que sus instrucciones de memoria han cargado el numero de bytes esperados.

Ciclos totales de parada: numero acumulado de ciclos que una instruccion ha tenido queesperar, o ha tenido que hacer esperar, para entrar en el pipeline. Estas dos opciones secorresponden con dos modos: productor y consumidor. Se trata de decidir a que instruccionculpar del retraso experimentado por una instruccion. Vease Seccion 7.4 (pag. 62) para masdetalles.

Desglose de ciclos de parada (stalls): cada vez que una instruccion tiene que entrarmas tarde al pipeline, ocasiona un incremento en el computo total de ciclos del programaimpidiendo un IPC de 1. De cara a conocer que recursos son los que estan trabajando maspara generar el dato motivo de la dependencia, es necesario almacenarlo.

1 typedef enum

2 {

3 INS_STALL_ISSUE ,

4 INS_STALL_NONVPU ,

5 INS_STALL_V_SCALAR ,

6 INS_STALL_V_VECTOR ,


7 INS_STALL_NUM

8 }INS_STALL_t;

Listado 7.9: Tipos de stalls

A los tipos de stalls presentados en el Listado 7.9 (pag. 59) se tendrıan que anadir aquellosrelacionados con los accesos a memoria. Sin embargo las paradas por memoria se almacenaranen vectores individuales que no necesitan el uso de un enumerado. Lease la descripcion detodas las opciones a continuacion:

• issue: ciclos correspondientes a las instrucciones que lograron entrar al pipeline exac-tamente un ciclo despues que la anterior. Es un motivo optimista.

• nonvpu: ciclos que las instrucciones tuvieron que esperar para entrar al pipeline a causade dependencias con instrucciones que no son ni escalares ni vectoriales.

• vpu 1 y vpu N : ciclos a esperar a causa de dependencias con instrucciones escalares yvectoriales respectivamente.

Desglose de ciclos de parada por memoria: en el caso de que el motivo de la paradafuera la memoria, se almacenara en vectores separados para el TLB y para el resto de lajerarquıa de cache. Lease descripcion detallada:

• tlb: ciclos a esperar a causa de la traduccion de direcciones. Este campo estarıa a suvez desglosado segun la jerarquıa establecida para los tlbs.

• cache: ciclos que se ha tenido que esperar en los niveles de cache que se hayan confi-gurado, incluyendo la memoria principal, a causa tanto de dependencias de datos dememoria como por congelaciones ocurridas en el pipeline debido a fallos en el primernivel de cache. Estos se tienen que resolver antes de que las siguientes instrucciones sesigan ejecutando.

Las estadısticas por instruccion fueron definidas en un mapa cuyo ındice es el PC de la ins-truccion.

1 typedef map <UINT64 , STATS_INS_s > STATS_INS_t;

Listado 7.10: Mapa STL de las estadısticas por instruccion

Los campos de que consta las estadısticas globales son los siguientes:

Sumatorio global de ciclos: numero global de ciclos consumidos en el core por la aplica-cion.

Desglose global de ciclos de parada (stalls y memoria): como en el caso del desglosepor instruccion, en este caso son los datos globales del core.

Al final se creo una estructura sencilla ambas estadısticas:

1 typedef struct

2 {

3 STATS_INS_t *stats_ins;

4 STATS_GLB_t *stats_glb;

5 } STATS;

Listado 7.11: Estadısticas por instruccion y globales


CORE

CORE es una clase que englobara todas las estructuras anteriores excepto el Footprint, puestoque esta es una estructura global para la aplicacion y no especıfica del core. El resto sı formanparte de la especificacion detallada de un CORE del coprocesador Intel R©Xeon PhiTM. La visionsimplificada de la misma es la siguiente:

1 class CORE{

23 STATE state;

4 STATS stats;

56 UINT32 coreID;

78 void InsertInPipeline(

9 UINT32 tid ,

10 BBL_STATE :: iterator ins );

1112 void DistributeCycles(

13 UINT32 tid ,

14 UINT64 storeLIP ,

15 COUNTER cycles ,

16 BBL_ENTRY_KEY culprit ,

17 bool regStall ,

18 bool memStall ,

19 BBL_ENTRY_KEY currentIP = make_pair (0,0),

20 INT32 regDependency = -1);

2122 void InsertBreakdownStats(

23 UINT32 tid ,

24 STATS_INS_t ::iterator ,

25 UINT32 cycles ,

26 BREAKDOWN_t breakdown ,

27 UINT32 index);

2829 public:

3031 CORE(UINT32 coreID , UINT32 nThreads);

3233 ~CORE();

3435 void Pipeline( UINT32 tid , BBInfo *bbl );

3637 string PrintGlobalStats( UINT32 tid );

3839 }

Listado 7.12: Clase CORE

Estas son las funciones destacadas:

Pipeline: publica. Se describio a grosso modo en la Seccion 7.1 (pag. 49). Una vez termi-nada la simulacion de la cache, es la funcion encargada de organizar el pipeline para lasinstrucciones del bloque ya simulado en cuestion.

InsertInPipeline: privada. Inserta una unica instruccion en el pipeline. Sera invocada desdela funcion Pipeline.

DistributeCycles: privada. Una vez insertada una instruccion en el pipeline, se invocara pa-ra distribuir los ciclos que ha tardado en entrar al pipeline, ya hubiera habido stalls o no.

InsertBreakdownStats: privada. Funcion generica para determinar sobre que vector se vaa insertar el desglose de ciclos generado por una instruccion.


Finalmente se creo un array de punteros a objetos de la clase CORE sobre el que se insertarıantodos aquellos que se establecieran en la configuracion.

1 extern CORE * CoreArray [ MAX_EXPERIMENTS ][ MAX_NUM_THREADS ];

Listado 7.13: Array de punteros a objetos CORE

7.4. Estadısticas

Durante el procedimiento de construccion del pipeline, no solo se tendra informacion del numerototal de ciclos, sino que para cada bloque tratado tambien se dispondra especıficamente las razonespor las que las instrucciones tuvieron que entrar mas tarde al pipeline. En el primer caso habıaque tener en cuenta que el ultimo ciclo de la aplicacion no tiene por que ser el ciclo de fin de laultima instruccion del programa. El motivo es la terminacion en desorden. Respecto a la segundainformacion, es necesario recogerla para poder saber que recursos son aquellos que impiden alprograma ir mas rapido.

Una parte de la informacion sobre las instrucciones se encuentra insertada en el FOOTPRINT yotra en la rama de la estructura STATS dedicada a instrucciones exclusivamente. Ambas han sidoya expuestas en la Seccion 7.3 (pag. 55). A la hora de almacenar los ciclos que ocasionan stalls seplanteo la posibilidad de decidir sobre que instruccion almacenarlos. Se trataba de determinar acual culpabilizar. De cara a visualizar el computo total de ciclos esta decision es indiferente, perono lo es si quisieramos consultar informacion de un bloque concreto. Las dos alternativas sobrelas que responsabilizar son:

Productor: si una instruccion depende de que otra genere un dato, sera la productora sobrela que recaerıan los ciclos.

Consumidor: en este caso, culparıamos a la instruccion dependiente por tener que necesitarun dato.

La opcion por defecto fue responsabilizar al consumidor.

Finalizada por tanto la ejecucion de la aplicacion, y la recogida de las estadısticas correspon-dientes, es el turno de la funcion que realmente pone fin a toda la simulacion. Si se recuerda laSeccion 5.1 (pag. 31), en caso de que la ejecucion fuera en modo buffer, al no haber mas bloquesque se encarguen de lanzar la ultima simulacion de cache, es necesario que esta funcion se hagacargo de subsanarlo. Posteriormente, tanto para modo buffer como instruccion a instruccion, selanzarıa la construccion del pipeline y se recogerıan las estadısticas. Finalmente, llegarıa el mo-mento de invocar a las funciones que se encargan de escribir toda la informacion recopilada en unfichero para su posterior tratamiento. Ni que decir tiene que CMP$im ya almacenaba informacionacerca de los accesos y fallos de las instrucciones desglosadas por nivel de cache, entre otros. Estainformacion sera aprovechada para completar nuestras estadısticas.

El objetivo reside en crear una tabla en el informe de salida con toda la informacion desglosadapor cada una de las regiones tratadas: funciones, bloques e instrucciones; y separadas por comas,’,’. La cabecera contendrıa los siguientes campos:

Region: cada una de las entradas estarıa clasificada con las palabras clave FUN, BEG, INS yGLB, significando funcion, bloque, instrucciones y global, respectivamente. La global sera unaregion mostrada al final de la tabla con el acumulado de todos los datos.

7.4. ESTADISTICAS 63

Direcciones de comienzo y fin: en el caso de funciones y bloques, serıan las direcciones decomienzo y fin. La direccion de comienzo coincide con el PC de la primera instruccion, y ladireccion de fin coincide con la primera instruccion del bloque siguiente. El objetivo es queesta informacion incluya el tamano de estas regiones sin tener que agregar mas campos. Enel caso de las instrucciones, aparecerıa unicamente su PC, quedando el campo de direccionde fin vacıo.

Ejecuciones del bloque: solo se mostrara si la region es el bloque, quedando vacıo para lasregiones restantes. Indica el numero de veces que se ha ejecutado el bloque.

Numero de instrucciones: para funciones y bloques, contendra el numero total de instruccio-nes ejecutadas.

Numero total de bytes: se corresponde con el total de bytes que han sido solicitados porlas instrucciones de carga, load. Su finalidad es, entre otras, de validacion, para comprobarque efectivamente el numero de bytes cargados por un bloque particular es el esperado. Semostrara para todas las regiones.

Numero total de ciclos: es un modo de tener una idea del numero total de ciclos requeridospor todas las instrucciones sin necesidad de realizar calculos adicionales.

Accesos desglosados: esta informacion se encontraba ya disponible para cada instruccion,desglosada por nivel de cache. Se presentara pues para cada instruccion tal y como esta ya,y se realizara el acumulado para mostrarlo por bloque y funcion.

Fallos desglosados: es analogo a los accesos, pero mostrando los fallos.

Ciclos desglosados: se corresponden con toda la retahıla de razones explicadas al inicio deesta seccion.

En este punto, lo tenemos todo para visualizar la informacion. Sin embargo, si recordamos elpunto sobre los bloques basicos de la Seccion 5.2 (pag. 33), originalmente se almacenaban en unalista para no ralentizar la simulacion. Es ahora cuando se tiene que trabajar sobre la lista paraconvertirla en un mapa con bloques unicos. Inicialmente, se lleva a cabo generando una worklistindexada por una clave de dos campos, <PC,PC>, correspondientes a la direccion de la primerainstruccion y de la ultima. Vease la declaracion en el Listado 7.14 (pag. 63). A continuacion, seanalizan los bloques de dos en dos, como se muestra en la Figura 7.6 (pag. 63) y la Figura 7.7(pag. 64), para cortarlos y fusionarlos siempre que sea necesario. Una vez hecho esto, el procesoconsiste en un bucle que se recorre mientras haya entradas (bloques) en la worklist. Para evitarproblemas al tratar el ultimo bloque, se introduce al final de la worklist uno ficticio con unas clavesficticias. A medida que se recorre la worklist, en caso de no haber ningun corte se elimina el primerbloque para introducirlo en el mapa de bloques unicos. Si se produce un corte, se modifican losbloques consecuentemente y se vuelve a iterar. Cuando la lista solo contiene el bloque ficticio sefinaliza el proceso.

1 map <pair <UINT64 ,UINT64 >, COUNTER > BBInfoMap;

Listado 7.14: Mapa STL de Bloques Basicos

Figura 7.6: Bloques con ningun y un corte

Finalmente, se escribirıa toda la informacion en el informe final y se finalizarıa el proceso.


Figura 7.7: Bloques con 2 cortes

7.5. Invocacion activando la funcionalidad vectorial

La lınea de invocacion que veıamos en la Seccion 5.3 (pag. 37) se incrementa en un knob conel que se activa la funcionalidad vectorial. La entrada de datos del knob nuevo es el fichero deconfiguracion de las latencias de instrucciones que se presentaron en la Seccion 7.2.3 (pag. 54).

1 pin -t cmpsim -cache DL1 :32:64:8:1

2 -cache UL2 :1024:64:16:1

3 -tlb DTLB :64:4096:8

4 -tlb DTLB2 :256:4096:8

5 -dl1lat 4

6 -l2lat 16

7 -dtlblat 0

8 -dtlb2lat 6

9 -inclusive 1

10 -threads 1

11 -dependencies inslat.conf -- <app > <input >

Listado 7.15: Lınea para el lanzamiento de la simulacion

Capıtulo 8

Estudio experimental

En el Capıtulo 6 (pag. 39) presentamos la caracterizacion inicial de los benchmarks seleccio-nados, desde los puntos de vista del indice de vectorizacion y el desglose de motivos determinadospor el compilador para no vectorizar. Teniendo esto en cuenta este capıtulo fue dividido en dospartes: resultados y diagnostico. En la primera presentaremos graficamente los resultados obteni-dos a partir de la simulacion en el CMP$im modificado con las capacidades vectoriales del Intel R©Xeon PhiTMdescrito en el Capıtulo 7 (pag. 49). Estos resultados incluyen las ejecuciones escalaresy vectoriales de todas las aplicaciones. Querıamos conocer, tanto a nivel de instrucciones comode ciclos, cuan diferente es la version vectorizada frente a aquella en la que no se activo la vec-torizacion. El motivo reside en que esta comparativa proporciona un punto de vista adicional alya visto con los ındices de vectorizacion. Con esta informacion decidiremos entonces acerca deque aplicaciones analizar en profundidad para detectar los focos donde se pueda explotar la vecto-rizacion en mayor medida. En la segunda parte del capıtulo, el diagnostico, dividiremos el analisisen dos partes: software y hardware. En el diagnostico software se analizan los bloques basicosmas ejecutados de la aplicacion, el codigo fuente y el compilado. En el diagnostico hardware sepresentaran los resultados obtenidos al modificar la cache, de cara a comprobar que efectos tendrıaen aquellas aplicaciones que, pese a tener un buen ındice de vectorizacion, se encuentran limitadasen su ejecucion por los accesos a memoria.

8.1. Resultados

8.1.1. Polyhedron

La Figura 8.1 (pag. 66) muestra la relacion entre el numero de instrucciones y de ciclos delas versiones vectorizada y no vectorizada de los benchmarks de Polyhedron. El eje de abscisasse corresponde con la relacion de instrucciones ejecutadas de la version vectorizada frente a lano vectorizada. El eje de ordenadas se corresponde con la relacion de ciclos, obtenidos a travesde la version modificada de CMP$im, tambien entre las versiones vectorizada y no vectorizada.Ademas, se han dibujado segmentos de los siguientes tres colores:

verde: marca los puntos de la grafica en los que la relacion de instrucciones para ambasversiones es igual a 1.

rojo: analogamente al segmento verde, marca los puntos de la grafica en los que la relacionde ciclos para ambas versiones es igual a 1.

65

66 CAPITULO 8. ESTUDIO EXPERIMENTAL

morado: indica los puntos donde las relaciones de instrucciones y ciclos sen han visto afec-tadas de forma equitativa.

A continuacion se explican en detalle las diferentes situaciones e implicaciones de cada puntoen esta grafica desde los puntos de vista de las instrucciones y los ciclos:

Instrucciones

== 1: linea verde. Se pueden dar dos circunstancias: o bien no se ha vectorizado, o bien sı seha hecho pero la inclusion de instrucciones adicionales relacionadas con la vectorizacion hahecho que el numero total de instrucciones no disminuya. Es comun ver a las aplicacionesque cumplen esto arremolinadas en el punto de interseccion (1, 1).

< 1: se ha conseguido vectorizar. Se encontrarıan dentro del area cuadrada encerrada porlos segmentos verde y rojo.

> 1: se ha vectorizado pero, debido a comprobaciones o instrucciones relacionadas con lavectorizacion, el numero de instrucciones ejecutadas ha resultado ser mayor. En la grafica,estas aplicaciones estarıan fuera del area cuadrada formada por los segmentos verde y rojo.

Figura 8.1: Version vectorizada vs no vectorizada de Polyhedron

Ciclos

== 1: linea roja. Hay dos circunstancias en relacion a la relacion de instrucciones vista:

1. relacion de instrucciones == 1: si no hay mejora de instrucciones no la hay de ciclos.

2. relacion de instrucciones < 1: pese al exito de la vectorizacion, la aplicacion esta limitadapor memoria. Las aplicaciones se encontrarıan adyacentes al segmento rojo.

< 1: de nuevo se producen dos circunstancias:

1. la reduccion de instrucciones y de ciclos siguen mas o menos la misma lınea. Aquellasproximas al segmento morado cumplen este patron.

8.1. RESULTADOS 67

2. pese a que se hayan reducido el numero de instrucciones, esta reduccion no se ha tradu-cido en una reduccion de ciclos equivalente. Se encontrarıan dentro del area encerradapor los segmentos morado y verde.

> 1: la vectorizacion provoco un aumento de ciclos.

Volviendo a Polyhedron, la caracterizacion de las aplicaciones tfft, fatigue, doduct, mdbx, nfe induct, las hacıa destacar como posibles candidatas para su analisis dado alto porcentaje deinstrucciones escalares frente a las vectoriales. Entre ellas, la Figura 8.1 (pag. 66) nos destacafatigue y, como novedad, gas dyn. La primera porque al vectorizar se ha obtenido un 3 % mas deinstrucciones que han supuesto un 9 % mas de ciclos. La segunda porque en su caracterizacionpasaba desapercibida entre el resto, mientras que aquı destaca frente a la version escalar, con un90 % menos de instrucciones ejecutadas y un 86 % menos de ciclos.

Por otro lado, aplicaciones como channel, linpk y test fpu, que eran las que mejor ındice devectorizacion mostraban en su caracterizacion, en esta grafica se muestran como un claro ejemplode estar limitadas por la memoria. Se observa que la reduccion de instrucciones no se traduceen la misma medida en la de ciclos. En el caso de channel, por ejemplo, es un 79 % menos deinstrucciones frente a un 9 % menos de ciclos.

El resto de aplicaciones se encuentran o bien distribuidas a lo largo del segmento morado, elcual es un buen resultado ya que indica que la vectorizacion ha funcionado, o bien aglomeradasen el punto (1, 1), donde la vectorizacion no ha dado buenos resultados.

Figura 8.2: Ciclos desglosados de las aplicaciones de Polyhedron

La Figura 8.2 (pag. 67), que muestra en forma de ciclos las razones por las que los IPCs de lasaplicaciones son inferiores a 1, sirve para confirmar que las aplicaciones channel, linpk y test fpu,estan claramente penalizadas por los continuos accesos a la memoria principal. Las denominaremosmemory bound. tfft, pese a que en su caracterizacion presentaba el peor ındice de vectorizacion,0,07 %, resulta que tambien es memory bound, con lo que una posible mejora en la vectorizacionpodrıa no traducirse en una mejora de ciclos. Las mejoras para abordar esta aplicacion residirıanen encontrar una configuracion de memoria adaptada a ella, para luego identificar las deficienciasen su codigo. En el caso de capacita, que tambien entra en esta categorıa, es la unica que presentaun perfil semejante, ya que tiene un 38 % de ciclos a consecuencia de fallos en el segundo nivel deTLB. En este caso, parece viable probar a ejecutarla modificando el numero de lıneas en el TLBde segundo nivel.

Siguiendo la lınea de las aplicaciones memory bound, tenemos a gas dyn como caso particular.Pese a su excelente resultado respecto a la version escalar, su IPC es 0,19. Esto se debe a los fallos


en DL1, que se traducen en un porcentaje alto de aciertos en UL2. Por muy buen uso de la unidadvectorial que haga, el rendimiento general de la aplicacion no es acorde. Ya que los responsablesson los fallos en la DL1 y no en la UL2, serıa interesante de analizar.

Al lado derecho de la grafica tenemos aplicaciones como induct, doduc, aermod y fatigue,que tienen los mayores porcentajes de ciclos ocasionados por dependencias sobre instruccionesescalares. Si se aumentara el numero de vectoriales que sustituyeran a las escalares, se reducirıanestos ciclos. Es posible que, como efecto colateral, se trasladaran las dependencias entre escalaresa las vectoriales. Serıa una solucion aceptable pues habrıa mejorado el uso efectivo de la unidadvectorial del procesador, pudiendose plantear soluciones de otra ındole. De todos modos, hay querecordar que el compilador conseguıa vectorizar un 67 % de bucles de doduc, por lo que no damucho margen de maniobra. No es ası con induct, fatigue y aermod, que se situaban a la cola. Lade mas interes parece ser aermod al tener mas de 2500 bucles registrados.

Finalmente tenemos a protein, aplicacion con un 96 % de instrucciones enteras. Fue descartadade entrada como candidata a ser analizada debido a que los esfuerzos deberıan centrarse en lareduccion de instrucciones escalares. Como las enteras tienen una latencia de un ciclo por defecto,provocan que el porcentaje de instrucciones que entran correctamente en el pipeline aumente,incrementando entonces el IPC y situandola a la cabeza. Recuerdese que si una instruccion entrabacorrectamente en el pipeline, el ciclo se clasificaba con el nombre Issue. Sin embargo, dejando aun lado este detalle, el lımite para que se obtenga un resultado mejor son los accesos a DL1.En realidad estos accesos son en su mayorıa aciertos en la DL1, ya que no se ve la participacionni de la UL2 ni de memoria principal. Por tanto, estos ciclos implican dependencias de otrasinstrucciones sobre los datos cargados por loads. Representan un 47 % del total de ciclos. Estetipo de aplicaciones serıa mejor englobarla fuera de las memory bound para clasificarlas en sulugar como cache dependence bound.

Las candidatas a un analisis mas profundo, segun los razonamientos arriba expuestos, son:

aermod: su objetivo es simular el modelo de dispersion de aire ISCST2.

induct: su proposito es generar la entrada de PSpice que sirva para el modelado de laspropiedades electromagneticas de baja frecuencia de un sistema de comunicaciones res-q.

fatigue: sirve para modelar la fatiga de los metales ductiles.

gas dyn: destinada a resolver ecuaciones de continuidad de masa, momento y energıa conel objetivo de modelar el flujo de un gas es una dimension.

8.1.2. Mantevo

La caracterizacion de las aplicaciones de Mantevo invitaba a examinar algunas de ellas comoCloverleaf, ya que su ındice de vectorizacion ascendıa a un 73 % de las instrucciones ejecutadasdel programa. El resto de aplicaciones con un ındice inferior al 40 % y con poco peso en cuantoa instrucciones escalares, no parecıan ser candidatas de interes. Entre ellas, la que obtenıa peoresresultados era CoMD, con un 0,21 % de instrucciones vectoriales frente a un 30 % de escalares,datos que parecıan concordar con el informe del compilador.

La Figura 8.3 (pag. 69), que se presenta con la comparacion entre las versiones escalar y vecto-rial, muestra un Cloverleaf que presumiblemente va a estar limitado por la memoria principal. Lareduccion de ciclos es de un 19 % frente al 81 % sobre las instrucciones. Este mismo comportamien-to lo presentan HPCCG, miniFE y miniGhost. CoMD se reitera como candidata a ser analizadaporque se encuentra fuera del area encerrada por los segmentos.

8.1. RESULTADOS 69

Figura 8.3: Version vectorizada vs no vectorizada de Mantevo

El desglose de ciclos de la Figura 8.4 (pag. 69) confirma que Cloverleaf, HPCCG, miniFE yminiGhost se engloban dentro del grupo memory bound. Por otro lado, pese a que en CoMD se dala circunstancia mencionada sobre que se encuentra fuera del area en la primera figura, significandoque la version vectorial ha sido peor que la escalar, presenta aquı un interesante porcentaje dedependencias con instrucciones escalares sobre las que se puede centrar el analisis. Esto reafirmauna vez mas su candidatura.

Figura 8.4: Ciclos desglosados de las aplicaciones de Mantevo

Finalmente vemos que miniXyce es una aplicacion con un comportamiento analogo al mani-festado por protein de Polyhedron. Su caracterizacion mostraba un 69 % de instrucciones enterasde latencia 1, que se traducen aquı en un gran porcentaje de ciclos Issue que incrementan el IPCfalseando su apariencia de buena candidata.

La unica candidata de este benchmark para ser analizada en profundidad, sera:

CoMD: es un proxy para computacion en aplicaciones tipo Molecular dynamics. Todas lasaplicaciones de este tipo tienen caracterısticas compartidas, como son los parametros x, y, z


de cada partıcula, operaciones en las que unas partıculas interaccionan con otras, etc.

8.1.3. Sequoia

Sequoia presentaba ya dos candidaturas para realizar un diagnostico software: SPhotmk yCrystalmkm. En la Figura 8.5 (pag. 70) Crystalmk presenta un comportamiento a ser analizadopor su empeoramiento respecto a la version escalar, que asciende a un 13 % de empeoramiento encuanto a instrucciones y un 15 % en ciclos. IRSmk y UMTmk presumiblemente estaran limitadaspor memoria, pese a tener unos ındices de vectorizacion del 54 % y 24 %, respectivamente. Estehecho se ve corroborado en la Figura 8.6 (pag. 70).

Figura 8.5: Version vectorizada vs no vectorizada de Sequoia

Figura 8.6: Ciclos desglosados de las aplicaciones de Sequoia

En el caso de SPhotmk y Crystalmk presentan altos porcentajes de dependencias ocurridas porinstrucciones escalares, por tanto siguen siendo candidatas:

SPhotmk: consiste en un conjunto seleccionado de pequenas porciones de codigo de otros

8.1. RESULTADOS 71

paquetes mayores. No realiza calculos fısicos per se, sino que engloba procesos como unsolucionador de sistemas lineales por Cholesky, bucles con divisiones, bucles con llamadas afunciones matematicas de tipo built.in, etc.

SPhotmk: sirve para medir el rendimiento de la CPU y comprobar que los resultados queproporciona son correctos.

8.1.4. NPB

Las aplicaciones que inicialmente se consideraron candidatas fueron UA, IS, BT y LU. Enestas, el grado de instrucciones escalares era del 68, 35, 71 y 50 %, respectivamente. El hecho deque el numero de instrucciones escalares sea grande ayuda a que, localizando los bloques a los quepertenecen, se puedan concentrar los esfuerzos en ayudar al compilador a vectorizarlos.

Figura 8.7: Version vectorizada vs no vectorizada de NPB

En el area delimitada por los segmentos rojo y morado de la Figura 8.7 (pag. 71), se encuentranlas aplicaciones limitadas por la memoria principal, mas proximas al segmento rojo que al morado.En este benchmark, a diferencia de los anteriores, nos encontramos con muy pocas aplicacionesen el punto (1,1), donde figurarıan aquellas cuyos resultados de la version vectorial se asemejarıana la version escalar. En cambio, la mayorıa se encuentra limitada por memoria en mayor o menormedida. Entre las destacadas por la limitacion de memoria se encuentran MG, con un 78 % dereduccion de instrucciones frente al 26 % de mejora en ciclos; FT, con un 63 % de reduccion frenteal 29 % de ciclos, SP con un 55 % y 16 %, respectivamente, y CG con un 51 % de instruccionesreducidas frente al 5 % de ciclos. De las mencionadas, FT fue la que presentaba el mejor ındicede vectorizacion, pese a ser memory bound, con un 52 % de instrucciones vectoriales ejecutadasfrente al 2 % de escalares. EP, por el contrario, tenıa un ındice de vectorizacion que competıa conel de instrucciones escalares (33 % y 30 %, respectivamente). Sin embargo, aquı es la que presentauna mayor mejora, teniendo un 65 % de reduccion de instrucciones y 53 % de ciclos.

En el otro extremo tenemos DC. Su ındice de vectorizacion mostraba un 97 % de instruccionesenteras ejecutadas. Aquı figura como que el intento de vectorizacion no ha hecho sino empeorar elnumero de instrucciones en un 2 %. La relacion de ciclos se ha mantenido constante, presumible-mente por el gran numero de instrucciones enteras. Por este motivo, no merece la pena pararse a


analizar las razones de esta situacion, cuando en general no vamos a poder aumentar el numerode instrucciones vectoriales de la misma.

Figura 8.8: Ciclos desglosados de las aplicaciones de NPB

En la Figura 8.8 (pag. 72) los ciclos desglosados presentan una fuerte tendencia hacia la limita-cion provocada por los accesos a memoria principal. MG, CG, SP y UA encabezan esta tendencia.En el caso de UA es importante saber que la reduccion de instrucciones respecto a la versionescalar es pequena, 17 %. Por tanto, aunque fuera una candidata a mejorar, si la limitacion pormemoria esta presente, mejorar el ındice de vectorizacion no va a erradicar su perfil memory bound.La aplicacion IS es interesante porque presenta muchos accesos a memoria por culpa de fallos enambos niveles de TLB. Estos ciclos, junto a aquellos por fallos en la UL2, hacen un total del 75 %de ciclos de memoria. Por tanto, pese a que esta aplicacion se presentaba como una posible candi-data, serıa necesario aplicar mejoras sobre la jerarquıa de memoria en primer lugar. La estadısticade EP, con un 35 % de ciclos por dependencias de instrucciones vectoriales, confirma su ındice devectorizacion del 33 %. Igualmente, no se trata de algo positivo porque no se consigue un buenIPC. Esta aplicacion entonces se clasificarıa como dependence bound.

Finalmente tenemos la aplicacion DC, dominada por instrucciones enteras, la cual repite uncomportamiento que viene siendo habitual en todos los bechmarks cuando se identifican aplica-ciones principalmente enteras, esto es, tener el mejor IPC. Sin embargo, esta vez ni es tan alto nise refleja en un gran porcentaje de ciclos Issue debido a los fallos de TLB y en la jerarquıa decache. Igual no la podrıamos clasificar como memory bound, porque ya se sabıa que parte de losciclos de DL1 que engordan su barra son ocasionados por dependencias con instrucciones de cargade datos. Por ello, se la clasificarıa como memory dependence bound.

Tras todo este analisis, las aplicaciones seleccionadas son:

BT: de Block Tridiagonal, es una aplicacion que presenta un solucionador de sistemas nolineales de ecuaciones con derivadas parciales usando matrices de bloques tridiagonales.

LU: de Lower-Upper, es una aplicacion que tiene el mismo objetivo que BT, es decir, laresolucion de un sistema, pero aquı es realizada aplicando el metodo de factorizacion LU porGauss-Seidel.

8.1.5. SPEC fp

Las aplicaciones de mas interes mencionadas durante la caracterizacion fueron namd, povrayy milc, porque presentaban un ındice de vectorizacion muy pequeno: 1 %, 2 % y 2,4 %, respectiva-

8.1. RESULTADOS 73

mente. Predominaba en todas ellas el porcentaje de instrucciones escalares: 58 %, 32 % y 84 %.

Figura 8.9: Version vectorizada vs no vectorizada de SPEC fp

La Figura 8.9 (pag. 73) nos muestra que lbm, teniendo el mejor ındice de vectorizacion, ascen-diendo este a un 76 %, no se ve acompanada por una mejora semejante en el numero de ciclos.Se clasifica por tanto en el conjunto de aplicaciones memory bound. Independientemente de estehecho, es una ventaja que el unico frente que haya que abordar sean los accesos a memoria, yaque la mejora en el numero de instrucciones es de un 77 % y el ındice de vectorizacion no dejalugar a dudas de que es una aplicacion que hace un uso efectivo de los procesadores vectoriales.Otro caso es el de leslie3d, que muestra una mejora semejante tanto a nivel de instrucciones comode ciclos. En este caso el ındice de vectorizacion ascendıa solo al 33 %.

Figura 8.10: Ciclos desglosados de las aplicaciones de SPEC fp 2006

Zeusmp y cactusADM son interesantes porque ambas tenıan un ındice de vectorizacion seme-jante: 35 % y 37 %, respectivamente. Sin embargo, zeusmp no mejora tanto respecto al numerode ciclos (36 %), categorizandose como memory bound. Por su parte, cactusADM presenta unamejora del 62 %. La aplicacion Wrf, comparandola con zeusmp por proximidad, pese a presentarun ındice de vectorizacion del 24 % obtiene mejor resultados respecto a la version escalar: 73 %de reduccion de instrucciones, frente al 72 % de zeusmp, y 40 % de reduccion de ciclos, frente al


36 % de zeusmp. Esto significa, que pese a que una aplicacion tenga peores resultados respecto alnumero de instrucciones vectorizadas, su computo global respecto a la version no vectorial puedeser mejor. Gromacs, al igual que cactusADM, tiene incluso una mejor relacion entre reduccion deciclos e instrucciones, siendo de un 53 y un 55 % respectivamente.

En el extremo del punto (1, 1) se observa la concentracion del resto de aplicaciones, algunasmas limitadas por memoria y otras sin cambios aparentes, pero en general con mejoras discretas.Fuera de estas, se observan namd y povray sin mejora alguna. Igualmente, este empeoramientoes pequeno de cara al numero de instrucciones, siendo de un 0,49 % en namd y un 0,46 % enpovray. Lo mas significativo es el empeoramiento de povray respecto al numero de ciclos, siendoun aumento de un 4,7 %.

En la Figura 8.10 (pag. 73), en el extremo de las aplicaciones que no estan limitadas pormemoria, nos encontramos a calculix. Su elevado IPC era de esperar gracias a las instruccionesenteras que lo componen, suponiendo estas un 92 % de las instrucciones ejecutadas por la aplica-cion. De las aplicaciones que le siguen, soplex tambien es una aplicacion mayoritariamente entera,con un 81 % de instrucciones de este tipo. Pese a esto, las instrucciones escalares y vectoriales queaportan un 3 % y un 16 % respectivamente al total, provocan dependencias que impiden obtenerun porcentaje de ciclos Issue mayor.

Finalmente, comentar que el interes principal de esta grafica radica en centrarnos en si aquellasque aportan mayor numero de ciclos por culpa de dependencias de instrucciones escalares, tienencaracterısticas destacadas por el resto de graficas para determinar su candidatura. Es el caso porejemplo de namd y povray, que se mencionaron en la caracterizacion. Por tanto, las seleccionadaspara su analisis seran:

namd: es una aplicacion que simula grandes sistemas biomoleculares.

povray: realiza un tratamiento sobre una imagen de dimensiones 1280x1024 que contieneun paisaje con objetos abstractos, usando para ello un filtro de ruido denominado Perlin,por su autor Ken Perlin.

8.2. Diagnostico Software

El diagnostico es un proceso en el que, conociendo a priori el comportamiento de la aplicacion,tanto de cara al perfil estatico que nos proporciona el compilador como durante su ejecucion, nosadentramos en su interior para determinar que bloques basicos son los que estan impidiendo unuso mas efectivo de la unidad vectorial. Estos bloques basicos seran los que al final nos den lasclaves para plantear una posible solucion con el interes de incrementar el numero de instruccionesvectoriales ejecutadas por la aplicacion.

La forma de operar en esta seccion sera la siguiente: se tomaran cada uno de las aplicacionesseleccionadas en la Seccion 8.1 (pag. 65) y, para cada una, se consultaran los bloques basicosmas ejecutados, se analizaran las porciones de codigo fuente que se corresponden con ellos en labusqueda de bucles potencialmente vectorizables, se consultara el resultado del compilador paracon los bucles encontrados y se tratara de proponer alguna solucion que pudiera ser viable parasu mejora. Respecto a las soluciones propuestas, no era objetivo de este trabajo implementarlas,sino dejarlas como una posible guıa de cara a trabajos futuros.

8.2. DIAGNOSTICO SOFTWARE 75

8.2.1. Polyhedron

Las aplicaciones del benchmark Polyhedron seleccionadas para un analisis en profundidad son:Fatique, Induct, Aermod y Gas dyn.

Fatigue

Recordando las caracterısticas que se presentaron de Fatigue durante la caracterizacion, tenıa91 bucles, de los cuales un 48 % no se habıa vectorizado. La razon considerada por el compiladorera que la vectorizacion, pese a ser posible, resultaba ineficiente.

PC Funcion Instrucciones % Ciclos %

1 0x407a50 perdida m mp generalizedhookes law

3.583.528.433 23,0 5.074.024.833 8,59

2 0x40238e MAIN 3.328.267.995 21,3 8.311.166.827 14,1

Tabla 8.1: Bloques 1 y 2 de la lista de bloques basicos mas ejecutados en Fatigue, Polyhedron

La Tabla 8.1 (pag. 75) muestra los dos bucles mas ejecutados de la aplicacion. Los campos deesta tabla son: posicion del bucle en la lista, PC de la primera instruccion del bloque, nombre de lafuncion, instrucciones ejecutadas, porcentaje respecto al total, ciclos contabilizados y porcentajerespecto al total de la aplicacion. El primero de los bloques se corresponde con una funciondenominada generalized hookes que se encuentra dentro del fichero fatigue.f90 de la aplicacion.

1110 !------------ FUNCTION GENERALIZED_HOOKES_LAW ----------------------

1111

1112 function generalized_hookes_law (strain_tensor , lambda , mu) result (←↩stress_tensor)

Con una primera mirada al codigo de la funcion, vemos que esta formado por multitud de ope-raciones realizadas sobre los elementos de un vector de dimension 6 y de una matriz de dimensiones6x6. A modo de ejemplo se muestran algunas lıneas:

1158 generalized_constitutive_tensor (:,:) = 0.0 _LONGreal

1159 generalized_constitutive_tensor (1,1) = lambda + 2.0 _LONGreal * mu

1160 generalized_constitutive_tensor (1,2) = lambda



1163 generalized_constitutive_tensor (2,2) = lambda + 2.0 _LONGreal * mu

Ademas, existe un pequeno bucle dentro que el compilador no ha vectorizado por considerardicha vectorizacion como ineficiente.

1183 do i = 1, 6

1184 generalized_stress_vector(i) = dot_product(

generalized_constitutive_tensor(i,:),

1185 generalized_strain_vector (:))

1186 end do

Pese a que 6 son pocas vueltas para un bucle, y que el numero de datos en punto flotantees pequeno como para llegar a llenar los 16 que puede albergar un registro vectorial de 512 bits,


se podrıa utilizar el pragma vector always como primera opcion de mejora. Al mismo tiempo, sepodrıan convertir todos las lıneas que operan sobre los vectores y las matrices en bucles.

Despues de revisar el flujo de ejecucion del programa, vemos que el bloque correspondiente aesta funcion solo es accedido desde un unico call. La unica funcion que invoca a esta se denominaperdida. Pese a que no tiene bucles, si se comprueba el bloque desde el que se invoca, descubrimosque en realidad se ha hecho inline en la funcion main. Este bloque en cuestion se correspondeademas con el tercero mas ejecutado. Vease la Tabla 8.2 (pag. 76).


3 0x401eb4 MAIN 2.873.120.235 18,4 7.140.131.627 12,1

Tabla 8.2: Bloque 3 de la lista de bloques basicos mas ejecutados en Fatigue, Polyhedron

A continuacion se muestra una pequena porcion de la funcion main donde se invoca a perdida:

1435 do n = 1, number_of_sample_points

1436 if (.not. failed(n)) then

1437 call perdida (dt , lambda , mu, yield_stress , R_infinity , b,

1438 gamma , eta , plastic_strain_threshold , stress_tensor (:,:,n),

1439 strain_tensor (:,:,n), plastic_strain_tensor (:,:,n),

1440 strain_rate_tensor (:,:,n), accumulated_plastic_strain(n),

1441 back_stress_tensor (:,:,n), isotropic_hardening_stress(n),

1442 damage(n), failure_threshold , crack_closure_parameter)

1443 end if

1444 end do

Sin embargo, el compilador indica que el bucle anterior no es un bucle interno:

fatigue.f90(1435): (col. 10) remark: loop was not vectorized: not inner loop

Revisando de nuevo el codigo de la funcion perdida, encontramos operaciones realizadas sobretodos los elementos de una matriz de este modo:

927 stress_tensor (:,:) = (1.0 _LONGreal - damage) *

928 generalized_hookes_law (strain_tensor (:,:) -

929 plastic_strain_tensor (:,:), lambda , mu)

...

940 stress_tensor (:,:) = (1.0 _LONGreal - crack_parameter * damage) /

941 (1.0 _LONGreal - damage) * stress_tensor (:,:)

...

950 deviatoric_stress_tensor (:,:) = stress_tensor (:,:)

...

955 damaged_dev_stress_tensor (:,:) = deviatoric_stress_tensor (:,:)/

(1.0 _LONGreal - crack_parameter * damage)

El operador (:, :) del codigo anterior, usado para operar sobre los elementos de una matriz, esuna manera corta de indicar que en realidad la operacion tiene que ser realizada sobre todos loselementos. Es por tanto un bucle simplificado. Tiene entonces sentido que el compilador notificaraque el bucle que engloba estas lıneas no es un bucle interno. En concreto, el segundo bloque conmayor numero de instrucciones mostrado en la Tabla 8.1 (pag. 75) se corresponde con las lıneassiguientes:

950 deviatoric_stress_tensor (:,:) = stress_tensor (:,:)

...

955 damaged_dev_stress_tensor (:,:) = deviatoric_stress_tensor (:,:)/

(1.0 _LONGreal - crack_parameter * damage)


...

960 equivalent_stress = sqrt (1.5 _LONGreal* sum(( damaged_dev_stress_tensor (:,:)

961 - back_stress_tensor (:,:))**2))

962 yield_function = equivalent_stress - isotropic_hardening_stress

- yield_stress

Para todas ellas el compilador indica lo siguiente:

fatigue.f90(950): (col. 7) remark: loop was not vectorized: vectorization possible

but seems inefficient









Hasta ahora hemos encontrado dos puntos de interes en este analisis. El primero fue en lafuncion generalized hookes donde habıa un pequeno bucle y varios accesos a vectores y matricescompletamente desenrollados. Para el bucle, con el pragma vector always podrıa ser suficiente. Sinembargo, en el caso de los accesos a los vectores y matrices habrıa que reescribirlos para convertirlosen bucles. El segundo punto de interes estaba en la funcion perdida y sus accesos a vectores atraves del operador (:,:). En este caso, la solucion propuesta consistirıa en convertir todos accesosen bucles y usar de nuevo el pragma vector always.

Induct

Induct es una aplicacion con reparto bastante homogeneo de las instrucciones en punto flotante.Consta de un 42,3 % de instrucciones vectoriales y un 48,66 % de instrucciones escalares. Estosdatos son chocantes si tenemos en cuenta que solo un 16 % de sus 246 bucles habıa sido vectorizado.Aparte, comparativamente respecto a la version escalar de la aplicacion, seguıa a gas dyn en elsegmento gracias a la mejora tanto en instrucciones como en ciclos. Sin embargo, el 36 % deciclos de penalizacion de que constaba su simulacion debido a las dependencias entre instruccionesescalares no podıa quedar sin investigar.


1 0x408799 mqc m mp mutual indquad cir coil

2.851.200.000 26,1 12.700.800.000 31,4

2 0x407cc9 mqc m mp mutual indquad cir coil

2.851.200.000 26,1 12.700.814.660 31,4

4 0x405f18 mqr m mp mutual indquad rec coil

950.400.000 8,69 4.233.614.640 10,5

5 0x406b96 mqr m mp mutual indquad rec coil

950.400.000 8,69 3.952.800.000 9,8

Tabla 8.3: Bloques 1, 2, 4 y 5 de la lista de bloques basicos mas ejecutados en Induct, Polyhedron

La Tabla 8.3 (pag. 77) muestra cuatro de los cinco bloques basicos mas ejecutados. Las fun-ciones asociadas se encuentran en el unico fichero de la aplicacion, llamado induct.f90. Vemos quehay dos bloques en cada una de estas funciones con el mismo numero de instrucciones ejecutados.La cifra correspondiente a los ciclos no tiene por que coincidir necesariamente, ya que existe el


factor dependencias que ocasiona variaciones en la cuenta.

Al comprobar el codigo de la aplicacion correspondiente a las funciones quad cir coil yquad rec coil, vemos que practicamente eran iguales salvo en alguna lınea aislada que no influıaen lo que buscabamos. El esquema general de ambas funciones consistıa en 2 grupos de 3 buclesencadenados cada una. Hacıan un total de 4 grupos, cada uno de ellos asociado a uno de los cuatrobloques de la Tabla 8.3 (pag. 77). A continuacion se presenta el contenido de uno de los buclesinternos:

1772 do k = 1, 9

1773 q_vector (1) = 0.5 _longreal * a * (x2gauss(k) + 1.0 _longreal)

1774 q_vector (2) = 0.25 _longreal * b2 * (y2gauss(k) + 1.0 _longreal)

1775 q_vector (3) = 0.0 _longreal

...

1779 rot_q_vector (1) = dot_product(rotate_quad (1,:),q_vector (:))



...

1785 numerator = w1gauss(j) * w2gauss(k)*

1786 dot_product(coil_current_vec ,current_vector)

1787 denominator = sqrt(dot_product(rot_c_vector -rot_q_vector ,

1788 rot_c_vector -rot_q_vector))

1789 l12_upper = l12_upper + numerator/denominator

1790

1791 end do

El informe del compilador indica que se han podido vectorizar los bucles internos presentes encada uno de los cuatro bloques:

induct.f90(1772): (col. 15) remark: LOOP WAS VECTORIZED

induct.f90(1772): (col. 15) remark: remainder loop was not vectorized:

low trip count



low trip count



low trip count



low trip count

Los bloques denominados reminder son aquellos que se generan despues del bucle principal encaso de que el compilador, al vectorizar, no haya podido abarcar todos los elementos del vector. Eneste caso el numero de iteraciones que realiza, 9, no es lo suficientemente alto como para generarun bloque reminder adicional. Veamos un pequeno fragmento del primero de los bloques basicos:

1 vaddsd xmm28 , k0, xmm26 , xmm13


3 vmulpd zmm14 , k0, zmm19 , qword ptr [rax *8+0 x696340 ]{b}


5 vbroadcastsd zmm31 , k0, xmm28



8 vsubpd zmm0 , k0 , zmm31 , zmm22

9 vsubpd zmm29 , k0, zmm1 , zmm21


10 vmulpd zmm1 , k0 , zmm14 , zmm17

11 ...

12 vmulsd xmm14 , k0, xmm29 , xmm29

13 vfmadd213sd xmm13 , xmm13 , xmm14


15 vsqrtsd xmm15 , xmm15 , xmm15

16 vdivsd xmm13 , xmm3 , xmm15

Esta bien vectorizado y, como es logico, necesita intercalar algunas instrucciones escalares alas vectoriales para realizar operaciones intermedias. Esto significa que induct funciona bien yesta haciendo un uso efectivo de la unidad vectorial. Sin embargo, esto no se traduce en un buenIPC debido a las dependencias de tanto las instrucciones escalares como las vectoriales y, dadoque hay abundantes escalares en los bloques ya vectorizados, lo que parecıa un buen intento demejorar la aplicacion centrandose en estas instrucciones, no ha dado el resultado esperado. Unaposible solucion que se deja planteada consiste en hacer uso de la directiva unroll para indicar alcompilador que desenrolle por 2. Si consigue hacer un reordenamiento adecuado, se reducirıan lasdependencias y mejorarıa el IPC.

Aermod

Aermod, como vimos en la caracterizacion, es una aplicacion con una gran cantidad de bucles,2597, y con un ındice de vectorizacion muy pequeno, 5,59 %. Al analizar el listado de bloquesbasicos con mayor numero de instrucciones, vemos que estos le confieren un perfil plano. Estosignifica que el reparto de instrucciones ejecutadas es muy homogeneo no destacando ningunbloque por encima de los demas. Por este motivo, se tomo la decision de visitar uno a uno todoslos bloques que proporcionaban informacion util, clasificados por las funciones que los relacionabanentre ellos. Vease a continuacion el desglose.


1 0x5bd009 powf.L 3.437.413.941 4,85 4.054.989.375 2,32

2 0x5bd0b0 powf.L 3.261.136.303 4,60 5.552.965.738 3,18

Tabla 8.4: Bloques 1 y 2 mas ejecutados de Aermod, Polyhedron

La funcion powf.L que se muestra en la Tabla 8.4 (pag. 79), es en realidad una funcion delibrerıa. Para este caso, se busco la region desde donde se estaban realizando la mayor cantidadde llamadas a la misma. Con una de las herramientas internas que permitıa visualizar el controlde flujo de cada una de las funciones de la aplicacion, era posible hacer una consulta sobre elprimero de los bloques de la funcion para conocer aquellos que contenıan llamadas a la misma. Elresultado se muestra en la tabla siguiente:

PC Funcion Instruccion Ejecuciones %

0x5ba120 sigz call 0x5ba120 25.157.031 28,5

Pese a que sea la funcion sigz la que se indica, despues de analizar el codigo mas a fondose llego a una funcion llamada szsfcl, de la que se habıa hecho inline en sigz. Se muestraa continuacion un fragmento de la misma. El operador ** que se visualiza en la funcion es lapotencia: x**n = xn. Las lıneas no mostradas son comentarios y declaraciones de variables:


45207 SUBROUTINE SZSFCL(XARG)

...

45256 IF ( UNSTAB .AND. SURFAC ) THEN

45257 SZSURF = BSUBC *(1.0 -10.*( CENTER/ZI))** ALPHA1 *(USTAR/UEFFD)

45258 *( USTAR/UEFFD)*(XARG*XARG/ABS(OBULEN))

45259

45260 ELSEIF ( STABLE ) THEN

45261

45262 SZSURF = (RTOF2/RTOFPI)*USTAR *(XARG/UEFF)*(1.0+0.7* XARG/OBULEN)

45263 **( -0.333333)

45264

45265 ELSE

45266 SZSURF = 0.0

45267

45268 ENDIF

45269

45270 CONTINUE

45271 END

Esta funcion no tiene bucles que tratar, ni siquiera un acceso especial a algun vector o matriz.Asimismo, la funcion desde donde se invoca, sigz, tampoco tiene. Si continuamos con este meca-nismo de comprobar quien invoca a quien, encontramos llamadas a sigz desde funciones que notienen bucles. Un ejemplo es una funcion llamada adisz, desde donde se invocaba 26 millones deveces. A esta tambien se la llamaba desde una funcion llamada iblval un total de 18 millones deveces. Ninguna de estas piezas de codigo contenıa bucles, con lo que en principio parecen simplesbloques que, por el numero de instrucciones que contienen y por las veces que se las invoca desdediferentes funciones, tienen todas las papeletas para aparecer en el top de bloques basicos.

Volviendo a los 10 bloques mas ejecutados, encontramos tres de ellos pertenecientes a la mismafuncion: anyavg. Vease la Tabla 8.5 (pag. 80).


3 0x50db17 anyavg 2.256.034.787 3,18 8.790.756.239 5,03

5 0x50da34 anyavg 1.867.063.272 2,63 5.367.809.396 3.07

10 0x50d94c anyavg 1.307.726.462 1,84 1.307.726.462 0,748

Tabla 8.5: Bloques 3, 5 y 10 mas ejecutados de Aermod, Polyhedron

Estos bloques ni son bucles ni estan contenidos dentro de un bucle mayor. Al realizar la busque-da de los bloques desde donde se invoca a esta funcion, encontramos que los mas significativos seencuentran contenidos en la funcion iblval. Dado que iblval se menciono anteriormente porqueaparecıa como funcion raız desde donde se acababa invocando a powf.L y que, dentro de los 10bloques mas ejecutados aparecen otros que tambien forman parte de ella, se analizaran para versi guardan alguna relacion con anyavg o powf.L. Veanse en la Tabla 8.6 (pag. 80).


7 0x50d260 iblval 1.397.144.910 1,97 2.395.105.560 1,37

9 0x50d2af iblval 1.394.701.126 1,97 2.390.916.216 1,37

Tabla 8.6: Bloques 7 y 9 mas ejecutados de Aermod, Polyhedron

Todos ellos son identicos en contenido de instrucciones y, al comprobar las lıneas de codigo alas que pertenecen, se descubre que son de una funcion llamada Locate. Esto significa que, denuevo, se ha hecho inline de una funcion desde diferentes puntos. En este caso todos los puntosforman parte de iblval. Vease a continuacion un fragmento de la funcion:


21698 SUBROUTINE LOCATE(PARRAY ,LVLBLW ,LVLABV ,VALUE ,NDXBLW)

...

21729 IMPLICIT NONE

21730

21731 INTEGER LVLABV , LVLBLW , NDXBLW , JL , JM , JU

21732 REAL PARRAY(LVLABV) , VALUE

...

21740 JL = LVLBLW - 1

21741 JU = LVLABV + 1

21742

21743 DO WHILE ( (JU-JL).GT.1 )

21744

21745 JM = (JU+JL)/2

21746

21747 IF ( VALUE.GE.PARRAY(JM) ) THEN

21748 JL = JM

21749 ELSE

21750 JU = JM

21751 ENDIF

21752

21753 ENDDO

21754

21755 NDXBLW = JL

21756

21757 CONTINUE

21758 END

Despues de encontrar el primer bucle, comprobamos que no se ha vectorizado dando comorazon el compilador que no es una estructura soportada:

aermod.f90(21743): (col. 7) remark: loop was not vectorized: unsupported loop structure

En el bucle se esta accediendo al vector parray(jm) dentro de una condicion. El ındice, jm,se calcula en cada una de las iteraciones, convirtiendo la vectorizacion en una tarea complicada,ya que habrıa que calcular previamente todos los ındices para poder acceder a varios elementossimultaneamente. Esto se podrıa traducir en una instruccion de tipo gather que cargara cada unode los valores del vector segun los ındices que se hubieran calculado previamente. Sin embargo, elhecho de que dicho calculo necesite del acceso al vector previamente, impide la vectorizacion.

Relacionando esto con los dos ultimos bloques mostrados de la funcion iblval en la Tabla 8.6(pag. 80), encontramos que las llamadas a la funcion Locate estan ıntimamente relacionadas conlas llamadas a la funcion anyavg. En multitud de ocasiones aparecen bloques en donde, previoa llamar a anyavg, se divisa el bloque correspondiente al inline de Locate. Esta estructura dellamadas se repite 4 veces en todo el codigo, estando tres de ellas en el interior de la funcioniblval. Las siguientes lıneas muestran la disposicion de las llamadas que tienen mas peso de entretodo el conjunto de invocaciones del codigo:

21285 CALL LOCATE(GRIDHT ,1,MXGLVL ,ZHI ,NDXBHI)

21286 CALL LOCATE(GRIDHT ,1,MXGLVL ,ZLO ,NDXBLO)

21287 NDXALO = NDXBLO + 1

21288 CALL ANYAVG(MXGLVL ,GRIDHT ,GRIDWS ,ZLO ,NDXALO ,ZHI ,NDXBHI ,UEFF)

21289 CALL ANYAVG(MXGLVL ,GRIDHT ,GRIDSV ,ZLO ,NDXALO ,ZHI ,NDXBHI ,SVEFF)

21290 CALL ANYAVG(MXGLVL ,GRIDHT ,GRIDSW ,ZLO ,NDXALO ,ZHI ,NDXBHI ,SWEFF)

21291 CALL ANYAVG(MXGLVL ,GRIDHT ,GRIDTG ,ZLO ,NDXALO ,ZHI ,NDXBHI ,TGEFF)

Viendo que se invoca en cuatro ocasiones a anyavg, se propone el siguiente planteamiento:indicar al compilador que haga inline de las llamadas a anyavg con el pragma inline y comprobarsu comportamiento. Otra opcion seria rescribir el codigo englobando las llamadas en un bucle.

Finalmente, se analizara el bloque mostrado en la Tabla 8.7 (pag. 82).



8 0x480379 sigz 1.395.399.168 1,97 2.946.185.353 1,69

Tabla 8.7: Bloque 8 mas ejecutado de Aermod, Polyhedron

La funcion sigz ya se ha mencionado previamente porque se invocaba desde la funcion iblval.Sin embargo, se descubrio que el bloque mostrado no se corresponde con esta funcion en concreto,sino con Locate, la cual tambien se ha mencionado y de la que sabemos que se hace inline endiferentes puntos del codigo. Dado que en todos los casos iblval resulta ser la raız comun detodo el analisis, podrıamos seguir analizando los niveles superiores en la cadena de llamadas, paraaveriguar que funciones la invocan y como se comportan. Dado que es algo que venıamos haciendodesde el inicio, el panorama se presenta negativo porque de entre las funciones que la invocanninguna contenıa bucles que justifiquen tantas llamadas. Veamos a continuacion algunas de lasfunciones donde se invoca iblval :

PC Funcion Instruccion Ejecuciones %

0x47bf6f pwidth call 0x50b890 9.248.524 46,1

0x47d009 plumef call 0x50b890 8.797.813 43,9

0x4a948f aercalc call 0x50b890 1.010.878 5,04

0x4a0bcf volcalc call 0x50b890 986.280 4,92

Al llegar a este punto se ceso el analisis, ya que se convirtio mas en una cruzada de buscarposibles bucles de interes en un codigo de 51.885 lıneas, que en un estudio de como mejorar laaplicacion para hacer un uso mas efectivo de la unidad vectorial. Igualmente, llama la atencionque siendo una aplicacion con mas de 2.000 bucles, se den circunstancias como que los bloquesde mayor peso en la aplicacion no contuvieran mas que un bucle o ninguno. Si bien la mayorıade bucles que contenıa resultaron ser pequenos y vectorizables, muchos de ellos no se llegaban nisiquiera a ejecutar. Por ende, aermod es una aplicacion que pese a haber sido candidata, no se haobtenido el analisis que se esperaba de ella.

Gas dyn

Gas dyn es una aplicacion que tenıa buen ındice de vectorizacion, 39,04 %, y la version vectorialfrente a la escalar daba los mejores resultados de todas las aplicaciones simuladas. Sin embargo elIPC era unicamente 0,19. Por este motivo se tomo la decision de proceder a su analisis.

Instrucciones Version Escalar % Version Vectorial %

Enteras 7.815.080.079 23.91 1.329.097.003 38,71

Escalares 23.909.735.894 23,89 764.150.080 22,26

Vectoriales 1.051.987.585 3,2 1.340.360.535 39,04

Total 32.776.803.558 3.433.607.618

Tabla 8.8: Desglose de instrucciones de las versiones escalar y vectorial de Gas dyn, Polyhedron

El desglose de instrucciones de las versiones vectorial y escalar se muestra en la Tabla 8.8(pag. 82). Notese que la version escalar contiene 1 millon de instrucciones vectoriales. Tras realizarcomprobaciones varias con el equipo del compilador, no se llego a una conclusion factible del


comportamiento del compilador. Dejandose este detalle a un lado, si dividimos los 24 millones deinstrucciones escalares de la version escalar entre 16, para intentar realizar una aproximacion amano alzada de la reduccion, obtenemos 1,5M de instrucciones vectoriales. La version vectorialcontenıa 1,3M de instrucciones vectoriales. El objetivo no era realizar ninguna validacion, sino vercomo, al utilizar registros vectoriales de 512 bits que pueden contener hasta 16 datos en comaflotante de 4 bytes, se ven reducidas las instrucciones escalares y aumentadas las vectoriales.


1 0x409375 eos 718.555.926 20,9 3.435.096.196 22,43 0x409060 eos 234.311.715 6,82 4.271.972.900 27,9

Tabla 8.9: Bloques 1 y 3 mas ejecutados de Gas dyn, Polyhedron

En la Tabla 8.9 (pag. 83) se muestran dos de los bloques mas ejecutados de la aplicacion,formando ambos parte de la funcion eos. El primer bloque se corresponde con la lınea 410 delsiguiente codigo y el tercer bloque con las lıneas 407 a 409.

360 SUBROUTINE EOS(NODES , IENER , DENS , PRES , TEMP , GAMMA , CS, SHEAT , &

361 & CGAMMA , WT)

...

390 INTEGER NODES , I

391 REAL SHEAT , CGAMMA , WT

392 REAL , DIMENSION(NODES) :: IENER , DENS , PRES , TEMP , GAMMA , CS

...

406 IF (SHEAT >0.0 .AND. CGAMMA >0.0) THEN

407 TEMP(:NODES) = IENER (:NODES)/SHEAT

408 PRES(:NODES) = (CGAMMA - 1.0)*DENS(: NODES)*IENER(: NODES)

409 GAMMA(:NODES) = CGAMMA

410 CS(:NODES) = SQRT(CGAMMA*PRES(:NODES)/DENS(: NODES))

411 ELSE

...

432 ENDIF

Pese a que no veamos aparentemente un bucle, la utilizacion de :NODES para acceder a un vectorindica implıcitamente que se va a realizar la operacion a todos los elementos del vector, enten-diendolo el compilador como si fueran varios bucles uno a continuacion del otro. Esta caracterısticase denomina Intel R© Cilk TM Plus y se utiliza tanto en el compilador ICC como IFORT[inte][intd].Al comprobar la compilacion de esta porcion de codigo, se aprecia que crean bloques prologo,normal y epılogo para las lıneas 407 a 409 por un lado, y para la lınea 410 por otro. Para las lıneas407 a 409 creo un fused loop, esto es, fusiono el acceso a los vectores TEMP, PRES y GAMMA en unmismo bloque. Las lıneas del informe del compilador son las siguientes:

gas dyn.f90(410): (col. 11) remark: unroll factor set to 2

gas dyn.f90(410): (col. 11) remark: LOOP WAS VECTORIZED

gas dyn.f90(410): (col. 11) remark: PEEL LOOP WAS VECTORIZED

gas dyn.f90(410): (col. 11) remark: REMAINDER LOOP WAS VECTORIZED

gas dyn.f90(407): (col. 11) remark: FUSED LOOP WAS VECTORIZED



El hecho de que el compilador este generando codigo separado para los tres primeros vectorespor un lado y para el ultimo por otro, es una de las raıces del problema que estabamos viendoen la Seccion 8.1.1 (pag. 65), sobre la gran cantidad de ciclos ocasionados por los accesos a laUL2. En la lınea 410 de la funcion se esta accediendo a los vectores PRES y DENS despues dehaber sido accedidos en la lınea 408. Como la 410 tiene que trabajar con ellos, se traduce enque la vectorizacion no hace un buen aprovechamiento de la localidad temporal de la cache, en


detrimento del rendimiento global de la aplicacion. La solucion, que en este caso sı se implementodebido a su sencillez, consistio en rescribir el codigo transformando los accesos a los bucles usando:nodes por un bucle simple 1..n, manteniendo el desenrollamiento en factor 2 que generaba elcompilador. Vease a continuacion el codigo resultante y consultense la directivas de Fortran en laSeccion 4.5 (pag. 29).

411 !DIR$ UNROLL (2)

412 DO 10 I = 1, NODES

413 TEMP(I) = IENER(I)/SHEAT

414 PRES(I) = (CGAMMA - 1.0)*DENS(I)*IENER(I)

415 GAMMA(I) = CGAMMA

416 CS(I) = SQRT(CGAMMA*PRES(I)/DENS(I))

417 10 CONTINUE

Al convertir el acceso a los vectores en un bucle explıcito que itera uno a uno sobre todos loselementos, el compilador no generara dos secciones separadas para el bucle. Se llevo a la practicay se obtuvieron los siguientes resultados de la Figura 8.11 (pag. 84) y el mensaje del compiladorsiguiente:

gas dyn.f90(412): (col. 14) remark: unroll factor set to 2

gas dyn.f90(412): (col. 14) remark: PARTIAL LOOP WAS VECTORIZED



Figura 8.11: Comparacion entre las versiones :nodes y do de gas dyn

En primer lugar se aprecia que la lınea del codigo a la que hace referencia es unicamente la 412de inicio del bucle, aparte de que genera solamente tres bloques. En la Figura 8.11 (pag. 84) sepresenta una reduccion del 6,51 % en el total de ciclos. Esta reduccion es debido a la disminucionde accesos en la UL2 en un 16,09 %. Ahora sı se esta realizando un aprovechamiento de la localidadtemporal, mejorando por tanto el rendimiento de la aplicacion.

8.2.2. Mantevo

La aplicacion del benchmark Mantevo seleccionada para un analisis en profundidad es CoMD.


CoMD

La caracterizacion y los resultados obtenidos por el simulador CMP$im modificado, muestrana CoMD como una aplicacion complicada de abordar. Su 0,22 % de instrucciones vectoriales y su30,43 % de instrucciones escalares da poco margen para realizar cambios. Aparte, el resultado dela comparacion entre las versiones escalares y vectoriales mostraban que vectorizar la aplicacion noservıa sino para empeorar el rendimiento de la misma tanto en numero de instrucciones ejecutadascomo en ciclos consumidos. Estudiando los bloques con mas peso en el programa, encontramosque la seccion de codigo fundamental en donde se esta realizando la mayor parte del computo sonlos siguientes bucles encadenados:

188 for(ioff=ibox*MAXATOMS ,ii=0; ii <nIBox; ii++,ioff ++) { /* loop over atoms in ←↩ibox */

189 int joff;

191 s->stress -= s->p[ioff ][0]*s->p[ioff ][0]/s->mass[ioff];

192 int i = s->id[ioff]; /* the ij-th atom in ibox */

193 for(joff=MAXATOMS*jbox ,ij=0; ij <nJBox; ij++,joff ++) { /* loop over atoms ←↩in ibox */

194 int m;

195 real_t dr[3];

196 int j = s->id[joff]; /* the ij-th atom in ibox */

197 if ( j <= i ) continue;

198 r2 = 0.0;

199 for(m=0; m<3; m++) {

200 dr[m] = drbox[m]+s->r[ioff][m]-s->r[joff][m];

201 r2+=dr[m]*dr[m];

202 }

203

204 if ( r2 > r2cut) continue;

...

212 r2 =( real_t)1.0/r2;

214 r6 = (r2*r2*r2);

216 s->f[ioff ][3] += 0.5*r6*(s6*r6 - 1.0);

217 s->f[joff ][3] += 0.5*r6*(s6*r6 - 1.0);

218 etot += r6*(s6*r6 - 1.0)-eshift;

...

221 fr = - 4.0* epsilon*s6*r6*r2 *(12.0* s6*r6 - 6.0);

222 for(m=0; m<3; m++) {

223 s->f[ioff][m] += dr[m]*fr;

224 s->f[joff][m] -= dr[m]*fr;

225 }

226 s->stress += 1.0*fr*dr[0]*dr[0];

...

232 } /* loop over atoms in jbox */

233 } /* loop over atoms in ibox */

Estos bucles se encargan de computar la interaccion entre los atomos dentro de contenedoresdenominados boxes. El recorrido sobre todos los boxes se realiza con otros dos bucles encadenadosque no se visualizan aquı pero que engloban a estos, haciendo un total de 4 bucles. El contenidocompleto de esta seccion de codigo se puede consultar en el fichero ljForce.c de la aplicacion.

Los diversos bloques generados por el compilador presentan en su mayorıa instrucciones enterasintercaladas con escalares, como por ejemplo el siguiente:

1 mov rbx , qword ptr [rbp+0x58]

2 vaddss xmm8 , xmm3 , dword ptr [rbx+r8*1+0x4]

3 vaddss xmm1 , xmm4 , dword ptr [rbx+r8*1]

4 vaddss xmm9 , xmm2 , dword ptr [rbx+r8*1+0x8]

5 lea r10 , ptr [rdx+rbx*1]

6 vsubss xmm8 , xmm8 , dword ptr [r10+r14 *1+0x4]

7 vsubss xmm1 , xmm1 , dword ptr [r10+r14*1]

8 vsubss xmm9 , xmm9 , dword ptr [r10+r14 *1+0x8]

9 vmulss xmm11 , xmm8 , xmm8

10 vfmadd231ss xmm11 , xmm1 , xmm1


11 vfmadd231ss xmm11 , xmm9 , xmm9

12 vcmpss k0, k0, xmm11 , xmm17 , 0xe

13 kortestw k0, k0

14 jnz 0x4049ab

El problema que encuentra el compilador para vectorizar el codigo, son las dependencias entreiteraciones:

ljForce.c(193): (col. 3) remark: loop was not vectorized: existence of vector

dependence

Estas dependencias se producen porque los boxes que se tratan podrıan coincidir, es decir,cuando ibox == jbox. En este caso las variables ioff y joff se iniciarıan con el mismo valor y elcompilador lo esta detectando como una dependencia. Una idea para solucionarlo radicarıa enrescribir el codigo generando dos situaciones separadas: una en la que ibox fuera igual a jbox,en cuyo caso seguirıa sin vectorizar porque se seguirıan produciendo las mismas dependencias,y un else donde incluyeramos los pragmas ivdep y vector always, ya que sabrıamos que no seproducirıan dependencias y es seguro usarlas. El esquema general serıa el siguiente:

if (ibox == jbox)

for(ioff=ibox*MAXATOMS ,ii=0; ii<nIBox; ii++,ioff ++) {

/* loop over atoms in ibox */

...

for(joff=MAXATOMS*ibox ,ij=0; ij<nIBox; ij++,joff ++) {


...

else

#pragma ivdep

#pragma vector always

for(ioff=ibox*MAXATOMS ,ii=0; ii<nIBox; ii++,ioff ++) {


...

for(joff=MAXATOMS*jbox ,ij=0; ij<nJBox; ij++,joff ++) {


...

A la hora de aplicar la solucion, es necesario tener en cuenta que la aplicacion no ofrece muchasmas oportunidades para vectorizar. Cuando tratamos con aplicaciones como esta en la que masde la mitad del codigo esta formado por instrucciones enteras, 69,35 %, las versiones escalares yvectoriales seran muy semejantes y el uso de la unidad vectorial, pese a que puede mejorar, no lohara mucho.

8.2.3. Sequoia

Las aplicaciones del benchmark Sequoia seleccionadas para un analisis en profundidad son:Crystalmk y SPhotmk.

Crystalmk

La caracterizacion mostraba que el 46,7 % de las escalares, frente al 5,8 % de las vectoriales, eraun porcentaje interesante sobre el que centrarse de cara a su reduccion. Ademas, en la Seccion 8.1.3(pag. 70) se vio que la version vectorial respecto a la escalar no habıa obtenido buenos resultados, yaque la relacion de instrucciones y ciclos era de 1,13 y 1,15 % respectivamente. Por tanto, despuesde analizar el conjunto de bloques basicos mas ejecutados, la principal diferencia entre ambas


versiones radica en el procedimiento Crystal div del fichero Crystal div.c. Vease a continuacionlos bucles de las lıneas 43, 49, 53, 61 y 65 del codigo de la funcion:

16 void Crystal_div(int nSlip ,

17 double deltaTime ,

18 double slipRate[MS_XTAL_NSLIP_MAX],

19 double dSlipRate[MS_XTAL_NSLIP_MAX],

20 double tau[MS_XTAL_NSLIP_MAX],

21 double tauc[MS_XTAL_NSLIP_MAX],

22 double rhs[MS_XTAL_NSLIP_MAX],

23 double dtcdgd[MS_XTAL_NSLIP_MAX ][ MS_XTAL_NSLIP_MAX],

24 double dtdg[MS_XTAL_NSLIP_MAX ][ MS_XTAL_NSLIP_MAX],

25 double matrix[MS_XTAL_NSLIP_MAX ][ MS_XTAL_NSLIP_MAX ])

26

27 {

28 double bor_array[MS_XTAL_NSLIP_MAX ];

29 double sgn[MS_XTAL_NSLIP_MAX ];

30 double rateFact[MS_XTAL_NSLIP_MAX ];

31 double tauN[MS_XTAL_NSLIP_MAX ];

32 double err[MS_XTAL_NSLIP_MAX ];

33

34 double rate_offset = 1.e-6;

35 double tauA = 30.;

36 double tauH = 1.2;

37 double rate_exp = 0.01;

38 double bor_s_tmp = 0.0;

39

40 int n = 0;

41 int m = 0;

42

43 for ( n = 0; n < nSlip; n++){

44 sgn[n] = 1.0;

45 rateFact[n] = 0.9 + (0.2 * n) / MS_XTAL_NSLIP_MAX;

46 }

47

48 // ----MS_Xtal_PowerTay

49 for ( n = 0; n < nSlip; n++){

50 bor_array[n] = 1 / ( slipRate[n]*sgn[n] + rate_offset);

51 }

52

53 for ( n = 0; n < nSlip; n++){

54 tau[n] = tauA * rateFact[n] * sgn[n];

55 for ( m = 0; m < nSlip; m++)

56 dtcdgd[n][m] = tauH * deltaTime * rateFact[n];

57 dtcdgd[n][n] += tau[n] * rate_exp * sgn[n] * bor_array[n];

58 }

59

60 // -----MS_Xtal_SlipRateCalc

61 for (n = 0; n < nSlip; n++) {

62 bor_array[n] = 1/ dtcdgd[n][n];

63 }

64

65 for (n = 0; n < nSlip; n++){

66 tauN[n] = tau[n];

67 for (m = 0; m < nSlip; m++){

68 bor_s_tmp = dtdg[n][m]* deltaTime;

69 tauN[n] += bor_s_tmp * dSlipRate[m] ;

70 matrix[n][m] = (-bor_s_tmp + dtcdgd[n][m])*bor_array[n];

71 }

72 err[n] = tauN[n] - tauc[n];

73 rhs[n] = err[n] * bor_array[n];

74

75 }

76

77 }

En la version escalar, cuando el compilador genera el codigo para este procedimiento, identificaque todos los bucles iteran con la misma variable y por tanto condensa todas las operaciones en


el mismo bucle. Ası se consigue eliminar codigo de control que hubiese estado repetido en cadauno de los bucles. El bloque generado lo denomina fused loop y consta de 1.173 instrucciones. Enla version vectorial una parte de este bucle es vectorizada mientras que otra no, ocasionando quelas instrucciones del bloque escalar ahora se repartan en tres bloques diferentes. El bloque masgrande de los tres se corresponde con los bucles de las lıneas 61 y 65.

En el Capıtulo 6 (pag. 39) comprobamos lo habitual de la situacion en la que el compiladorintenta vectorizar el bucle interno. Sabemos que si lo consigue indicara que el bucle externo no seha vectorizado por no ser un bucle interno, not inner loop. En el caso del bucle de la lınea 65, quecontiene un bucle interno que empieza en la lınea 67, ocurrıa algo distinto. El compilador estabaintentando vectorizar desde el bucle externo:

Crystal div.c(65): (col. 4) remark: loop was not vectorized: existence of vector

dependence

Esta dependencia era de esperar porque en el bucle interno se realizan tantos calculos sobreel elemento n del vector tauN como indica la variable nSlip, antes de volver a ser utilizado en elbucle externo. La solucion consistirıa en indicar al compilador que vectorice el bucle interno conel pragma vector always, puesto que dentro del bucle interno no hay dependencias.

SPhotmk

El ındice de vectorizacion de SPhotmk era bajo, 5,56 %, frente a un 50,5 % de instruccionesescalares. La comparativa entre las versiones escalar y vectorial mostraba que no se obtenıa nireduccion de instrucciones ni de ciclos. En la Tabla 8.10 (pag. 88) figuran los bloques con mayorpeso de computo. Entre ellos encontramos los de la librerıa logaritmo pertenecientes a la funcionlog.L. Cuando parte de los bloques mas ejecutados provienen de librerıas como esta, un modo deintentar buscar una solucion para vectorizar consistirıa en conseguir que el compilador invoque lafuncion de la librerıa adaptada al calculo sobre vectores, siempre y cuando estuviera disponible.


1 0x46dda3 log.L 7.772.068 7,23 12.145.985 4,392 0x405670 execute 5.913.530 5,50 8.278.942 2,993 0x40581b execute 5.406.656 5,03 11.602.509 4,194 0x46dd20 log.L 4.054.992 3,77 5.575.614 2,02

Tabla 8.10: Bloques 1, 2, 3 y 4 mas ejecutados de SPhotmk, Sequoia

Los bloques basicos situados en las posiciones 2 y 3 se corresponden con las funciones ranfmodmultdel fichero random.f y execute del fichero execute.f respectivamente. Para ambos ficheros se pre-sentan dos pequenos extracto a continuacion:

random.f

338 subroutine ranfmodmult( A, B, C )

...

352 dimension A( IRandNumSize ), B( IRandNumSize ), C( IRandNumSize )

...

361 a1 = A(1)

362 a2 = A(2)

363 a3 = A(3)

364 b1 = B(1)

365 b2 = B(2)

366 b3 = B(3)

367 j1 = a1 * b1


368 j2 = a1 * b2 + a2 * b1

369 j3 = a1 * b3 + a2 * b2 + a3 * b1

370 j4 = a1 * B( 4 ) + a2 * b3 + a3 * b2 + A( 4 ) * b1

371

372 k1 = j1

373 k2 = j2 + k1 / 4096

374 k3 = j3 + k2 / 4096

375 k4 = j4 + k3 / 4096

376

377 C( 1 ) = mod( k1, 4096 )

378 C( 2 ) = mod( k2, 4096 )

379 C( 3 ) = mod( k3, 4096 )

380 C( 4 ) = mod( k4, 4096 )

381

382 return

383 end

execute.f

372 dist = -log(ranf(mySeed)) / sig(ir,ig) ! distance to collision

373 dcen = (tcen - age) * 2.99793 d10 ! distance to census

El fichero principal es excecute.f. Este contiene una serie de bucles encadenados que abarcan lamayor parte de la aplicacion. Un codigo de estas caracterısticas dificulta la vectorizacion porquepara todos los bucles el compilador indica que no se ha vectorizado ninguno por no ser buclesinternos. Cuando al final llega al bucle mas interno, resulta que no lo vectoriza debido a la exis-tencia de dependencias. Estas fueron muy difıciles de identificar:

execute.f(271): (col. 19) remark: loop was not vectorized: existence of vector

dependence

execute.f(268): (col. 16) remark: loop was not vectorized: not inner loop




Las dos lıneas de codigo presentadas de excecute.f se encuentran en el interior del bucle masexterno de dos bucles anidados. Contienen las funciones log y ranf. La funcion ranf es la encar-gada de invocar a la funcion ranfmodmult que mencionamos previamente. Por tanto, estas doslıneas son responsables de que los bloques mas ejecutados sean los mostrados en el top de blo-ques basicos. La busqueda de soluciones se dificulta cuando todos los datos tratados en la funcionranfmodmult resultan ser enteros. Esto viene a decir que uno de los bloques con mayor numerode instrucciones ejecutadas en el programa, participa dentro del 44 % de instrucciones enteraspresentes en la aplicacion. Por estos motivos, para mejorarla no basta simplemente con modificarligeramente el codigo o incluir pragmas en los bucles mas externos. En este caso se propone hacerun estudio mas exhaustivo del codigo y proceder a reescribirlo en la mayor medida posible.

8.2.4. NPB

Las aplicaciones del benchmark NPB seleccionadas para un analisis en profundidad son: BTy UT.

BT

La aplicacion BT fue seleccionada por su elevado porcentaje de instrucciones escalares, 71,85 %.En la Tabla 8.11 (pag. 90) se encuentra el primer y unico bloque basico de los bloques mas


ejecutados que se va a analizar. Es un bloque importante porque supone un 56.2 % del montantetotal de instrucciones de la aplicacion.


1 0x4060c0 binvcrhs 4.134.959.136 56,2 14.866.089.846 26,5

Tabla 8.11: Bloque 1 de los mas ejecutados de BT, NPB

El codigo generado por el compilador esta formado por 6 instrucciones enteras, 596 escalares y14 vectoriales, de las cuales solo 3 utilizan vectores de 512 bits. Su codigo pertenece enteramente auna funcion denominada binvcrhs que se encuentra en el fichero solve subs.f. Este fichero recogetodas las funciones de interes que se invocan desde el codigo contenido en los ficheros x solve vec.f,y solve vec.f y z solve vec.f para la version vectorizada, y desde x solve.f, y solve.f y z solve.f para lano vectorizada. La peculiaridad de estos ficheros es que en las versiones vectorizadas los bucles quecontienen las llamadas a binvcrhs traen ya el pragma ivdep incorporado. Vease en el fragmentode codigo siguiente:

344 !dir$ ivdep

345 do i = 1, grid_points (1) -2

346 call binvcrhs( lhs(1,1,bb ,i,0),

347 > lhs(1,1,cc,i,0),

348 > rhs(1,i,j,0) )

349 enddo

Sin embargo, no se obtiene el resultado esperado por parte del compilador:

x solve vec.f(347): (col. 18) remark: vectorization support: call to function

binvcrhs cannot be vectorized

x solve vec.f(346): (col. 10) remark: loop was not vectorized: existence of vector

dependence

Analizando el codigo de la funcion vemos que no tiene ningun bucle sobre el que trabajar. Elunico bucle es el que aparece en el fragmento de codigo anterior desde el que se realiza la llamada.Vease la siguiente porcion de la funcion binvcrhs:

206 subroutine binvcrhs( lhs ,c,r )

...

218 dimension lhs(5,5)

219 double precision c(5,5), r(5)

...

225 pivot = 1.00d0/lhs(1,1)

226 lhs(1,2) = lhs(1,2)*pivot

227 lhs(1,3) = lhs(1,3)*pivot

228 lhs(1,4) = lhs(1,4)*pivot

229 lhs(1,5) = lhs(1,5)*pivot

230 c(1,1) = c(1,1)*pivot

231 c(1,2) = c(1,2)*pivot

232 c(1,3) = c(1,3)*pivot

233 c(1,4) = c(1,4)*pivot

234 c(1,5) = c(1,5)*pivot

235 r(1) = r(1) *pivot

236

237 coeff = lhs(2,1)

238 lhs(2,2)= lhs(2,2) - coeff*lhs(1,2)

239 lhs(2,3)= lhs(2,3) - coeff*lhs(1,3)

240 lhs(2,4)= lhs(2,4) - coeff*lhs(1,4)

241 lhs(2,5)= lhs(2,5) - coeff*lhs(1,5)

242 c(2,1) = c(2,1) - coeff*c(1,1)

243 c(2,2) = c(2,2) - coeff*c(1,2)


244 c(2,3) = c(2,3) - coeff*c(1,3)

245 c(2,4) = c(2,4) - coeff*c(1,4)

246 c(2,5) = c(2,5) - coeff*c(1,5)

247 r(2) = r(2) - coeff*r(1)

Los diversos accesos a los vectores que se muestran representan bucles que se han desenrolladomanualmente y de forma completa. La idea que se propone es generar bucles en todas aquellassecciones de codigo de la funcion binvcrhs donde sea posible. De este modo el compilador puedeintentar vectorizar dichos bucles y, a partir de ese punto, se puede afrontar el analisis de acuerdoa las dificultades que haya encontrado el compilador para no vectorizar.

LU

La aplicacion LU, al igual que BT, fue seleccionada por su porcentaje de instrucciones escalares,50,4 %. En la Tabla 8.12 (pag. 91) se muestran unicamente los dos primeros bloques del conjuntode bloques basicos mas ejecutados, porque destacan por encima de los demas al contener un 23 %y 21 % del total de instrucciones ejecutadas en el programa, respectivamente.


1 0x41751b buts 2.968.107.121 23,2 13.636.253.898 11,02 0x41c8c8 blts 2.717.028.573 21,2 10.258.244.038 8,30

Tabla 8.12: Bloques 1 y 2 de los mas ejecutados de LU, NPB

El primero contiene parte del codigo de la funcion buts del fichero buts vec.f y el segundobloque parte de blts del fichero blts vec.f. Ambas funciones tienen la misma estructura, perocada una se encarga de trabajar con una de las dos matrices U y L, respectivamente. El codigose compone de dos secciones diferenciadas: una primera con varios bucles encadenados que elcompilador consigue vectorizar, y una segunda que esta desenrollada manualmente en un factorde 5. Esta segunda situacion es semejante a la que vimos en BT. A continuacion se muestra unpequeno fragmento esto ultimo:

77 !!dir$ unroll 5

78 ! manually unroll the loop

79 ! do m = 1, 5

80 tv( 1, i, j ) = tv( 1, i, j )

81 > + omega * ( udy( 1, 1, i, j ) * v( 1, i, j+1, k )

82 > + udx( 1, 1, i, j ) * v( 1, i+1, j, k )

83 > + udy( 1, 2, i, j ) * v( 2, i, j+1, k )

84 > + udx( 1, 2, i, j ) * v( 2, i+1, j, k )

85 > + udy( 1, 3, i, j ) * v( 3, i, j+1, k )

86 > + udx( 1, 3, i, j ) * v( 3, i+1, j, k )

87 > + udy( 1, 4, i, j ) * v( 4, i, j+1, k )

88 > + udx( 1, 4, i, j ) * v( 4, i+1, j, k )

89 > + udy( 1, 5, i, j ) * v( 5, i, j+1, k )

90 > + udx( 1, 5, i, j ) * v( 5, i+1, j, k ) )

91 tv( 2, i, j ) = tv( 2, i, j )

92 > + omega * ( udy( 2, 1, i, j ) * v( 1, i, j+1, k )

93 > + udx( 2, 1, i, j ) * v( 1, i+1, j, k )

94 > + udy( 2, 2, i, j ) * v( 2, i, j+1, k )

95 > + udx( 2, 2, i, j ) * v( 2, i+1, j, k )

96 > + udy( 2, 3, i, j ) * v( 3, i, j+1, k )

97 > + udx( 2, 3, i, j ) * v( 3, i+1, j, k )

98 > + udy( 2, 4, i, j ) * v( 4, i, j+1, k )

99 > + udx( 2, 4, i, j ) * v( 4, i+1, j, k )

...

135 ! end do


El compilador indica que parte de este codigo es vectorizado como bloques en vez de como bucle.

buts vec.f(80): (col. 19) remark: BLOCK WAS VECTORIZED

buts vec.f(312): (col. 13) remark: BLOCK WAS VECTORIZED

blts vec.f(83): (col. 19) remark: BLOCK WAS VECTORIZED

Del resto de partes del codigo que tambien se encuentran desenrolladas no muestra ningunmensaje de por que no ha vectorizado. Por tanto, la idea que se plantea consiste en aplicar lamisma solucion que para BT, para comprobar si transformando el codigo desenrollado en un bucley utilizando el pragma vector always, o el pragma ivdep, se consigue vectorizar.

8.2.5. SPEC fp

Las aplicaciones del benchmark SPEC fp seleccionadas para un analisis en profundidad son:Namd y Povray.

Namd

La aplicacion Namd se caracterizaba por tener unicamente un 1,02 % de instrucciones vecto-riales. Ademas, su 58 % de instrucciones escalares generaba una gran cantidad de dependenciasque reducıan el IPC de la aplicacion. En concreto, estas dependencias ocasionaban que un 48,33 %de los ciclos de la aplicacion fueran por este motivo. En el codigo fuente de Namd existe un ficherodenominado ComputeNonbondedBase2.h, sobre el que bascula gran parte del codigo generado. Acontinuacion se muestra un pequeno fragmento inicial de dicho codigo:

7 EXCLUDED( FAST( foo bar ) )

8 EXCLUDED( MODIFIED( foo bar ) )

9 EXCLUDED( NORMAL( foo bar ) )

10 NORMAL( MODIFIED( foo bar ) )

11

12 for (k=0; k<npairi; ++k) {

13

14 const int j = pairlisti[k];

15 register const CompAtom *p_j = p_1 + j;

16

17 register const BigReal p_ij_x = p_i_x - p_j ->position.x;

18 register BigReal r2 = p_ij_x * p_ij_x;

19 register const BigReal p_ij_y = p_i_y - p_j ->position.y;

20 r2 += p_ij_y * p_ij_y;

21 register const BigReal p_ij_z = p_i_z - p_j ->position.z;

22 r2 += p_ij_z * p_ij_z;

23

...

28 FAST(

29 const LJTable :: TableEntry * lj_pars =

30 lj_row + 2 * mol ->atomvdwtype(p_j ->id) MODIFIED (+ 1);

...

35 SHORT(

36 const BigReal* const fast_i = table_four + 16* table_i + 8;

37 BigReal fast_a = fast_i [0];

38 )

39 )

40 FULL(

41 const BigReal* const scor_i = table_four + 16* table_i + 8 SHORT (+ 4);

42 BigReal slow_a = scor_i [0];

43 )

44

45 r2f.i &= 0xfffe0000;


Veanse las macros FAST y FULL en este fragmento. Estas, ademas de otras macros queaparecen en el mismo bucle, determinan que secciones de la funcion son compiladas dependiendode donde se usen. En todas las regiones donde se hace uso de alguna de ellas se hace inline delbucle con el codigo correspondiente a la macro. Esto da lugar a que en el informe del compiladorhaya multiples resultados registrados para este bucle en concreto.

Cuando consultamos los bloques basicos con mayor numero de instrucciones y ciclos, nos en-contramos que muchos coincidıan debido a lo mencionado sobre el inline de las macros en el bucle.Ademas, todos tenıan instrucciones escalares. Consultando las razones del compilador para novectorizar este bucle en ninguna de las ocasiones, encontramos una unica razon: las dependencias.

ComputeNonbondedBase2.h(12): (col. 5) remark: loop was not vectorized: existence

of vector dependence

ComputeNonbondedBase2.h(76): (col. 7) remark: vector dependence: assumed

FLOW dependence between f j line 76 and p j line 21


ANTI dependence between p j line 21 and f j line 76


FLOW dependence between f j line 76 and f i line 76


ANTI dependence between f i line 76 and f j line 76

Segun el compilador, las dependencias se encuentran entre las instrucciones p j y f j, ası comof j y f i. En el caso de p j y f j, encontramos que p j era un puntero a un objeto de una clasellamada CompAtom, que tomaba su valor de la variable p 1. La variable f j era una referencia aun objeto de una clase llamada Force que tomaba su valor de f 1[j]. El problema radicaba enque se estaba leyendo la posicion x de p j y tambien se estaba escribiendo la posicion x de f j.Para el compilador existıa una ambiguedad respecto a si las direcciones donde estaban apuntandoambas variables era la misma.

register const CompAtom *p_j = p_1 + j;

register const BigReal p_ij_x = p_i_x - p_j ->position.x;

Force & f_j = f_1[j];

register BigReal tmp_x = force_r * p_ij_x;

f_j.x -= tmp_x;

const CompAtom *p_1 = params ->p[1];

Force *f_1 = params ->ff[1];

La variable params es un puntero a la estructura de tipo nonbonded, la cual efectivamente tienedos campos p y ff de tipos CompAtom y Force respectivamente.

21 struct nonbonded {

22 CompAtom* p[2];

23 Force* ff[2];

25 Force* fullf [2];

...

41 };

Podemos pues asegurar que tanto p j como f j son dos variables que apuntan a zonas de me-moria diferentes y no hay dependencia alguna. Entonces, para conseguir vectorizar se podrıa haceruso del pragma ivdep que indica que se ignoren las dependencias. Tambien se podrıa modificar elcodigo de modo que el procesador entienda que tanto p j como f j son diferentes. Por ejemplo, sepodrıa encerrar el codigo bajo la condicion de que ambas variables fueran diferentes, lo cual serıacierto siempre.


Povray

Las instrucciones y ciclos de esta aplicacion estan muy repartidas entre todos los bloques que lacomponen. Pese a esto, el primer bloque del conjunto de bloques mas ejecutados que se muestra enla Tabla 8.13 (pag. 94) presentaba un porcentaje mayor de instrucciones y ciclos que los siguientesen la lista. Por este motivo se procede a su analisis.


1 0x5fad40 pov::All Sphere Intersections(pov::Object Struct*,pov::Ray Struct*,pov::istack struct*)

145.789.254 7,84 399.197.976 6,22

Tabla 8.13: Bloques 1 y 2 de los mas ejecutados de Povray, SPEC FP

De este bloque fue muy util consultar la informacion generada por otra de las herramientasinternas disponibles. A continuacion se presentan dichas instrucciones junto con el detalle de laslıneas del codigo a las que pertenecen:

1 sub rsp , 0x58 # spheres.cpp :123

2 add qword ptr [rip+0 x1e8d24], 0x1 # frame.h:980

3 mov r8, rsi # spheres.cpp :123

4 vmovsd xmm2 , qword ptr [rdi+0x80] # vector.h:90

5 xor eax , eax # spheres.cpp :129



8 vmovsd xmm4 , qword ptr [rdi+0x90] # spheres.cpp :131

9 vmulsd xmm7 , xmm4 , xmm4 # vector.h:296

10 vsubsd xmm16 , k0, xmm2 , qword ptr [r8+0x8] # vector.h:90

11 vsubsd xmm5 , xmm3 , qword ptr [r8] # vector.h:89

12 vsubsd xmm9 , xmm0 , qword ptr [r8+0x10] # vector.h:91

13 vmulsd xmm8 , k0 , xmm16 , xmm16 # vector.h:223

14 vmulsd xmm6 , k0 , xmm16 , qword ptr [r8+0x20]


16 vmovsd xmm4 , qword ptr [r8] # vector.h:89

17 vmovsd xmm3 , qword ptr [r8+0x8] # vector.h:90

18 vmovsd xmm2 , qword ptr [r8+0x10] # vector.h:91

19 vfmadd231sd xmm8 , xmm9 , xmm9 # vector.h:223

20 vfmadd231sd xmm6 , xmm5 , qword ptr [r8+0x18]

21 vmovsd xmm0 , qword ptr [r8+0x20]

22 vmovsd xmm1 , qword ptr [r8+0x28]

23 vcmpsd k0, k0, xmm8 , xmm7 , 0xd # spheres.cpp :288

24 vfmadd132sd xmm9 , xmm6 , qword ptr [r8+0x28] # vector.h:223

25 kortestw k0, k0 # spheres.cpp :288

26 jz 0x5fadf4

Las instrucciones terminadas en sd son escalares. Los ficheros que participan en el bloque sonspheres.cpp, vector.h y frame.h. Vease primero un fragmento de la funcion All Sphere Intersections

del fichero spheres.h:

spheres.cpp

122 static int All_Sphere_Intersections(OBJECT *Object , RAY *Ray , ISTACK *←↩Depth_Stack)

123 {

124 register int Intersection_Found;

125 DBL Depth1 , Depth2;

126 VECTOR IPoint;

127 SPHERE *Sphere = (SPHERE *) Object;

128


129 Intersection_Found = false;

130

131 if (Intersect_Sphere(Ray , Sphere ->Center , Sqr(Sphere ->Radius), &Depth1 , &←↩Depth2))

132 {

133 if (( Depth1 > DEPTH_TOLERANCE) && (Depth1 < Max_Distance))

134 {

135 VEvaluateRay(IPoint , Ray ->Initial , Depth1 , Ray ->Direction);

136

137 if (Point_In_Clip(IPoint , Object ->Clip))

138 {

139 push_entry(Depth1 , IPoint , Object , Depth_Stack);

140

141 Intersection_Found = true;

142 }

143 }

144

145 if (( Depth2 > DEPTH_TOLERANCE) && (Depth2 < Max_Distance))

146 {

147 VEvaluateRay(IPoint , Ray ->Initial , Depth2 , Ray ->Direction);

148

149 if (Point_In_Clip(IPoint , Object ->Clip))

150 {

151 push_entry(Depth2 , IPoint , Object , Depth_Stack);

152

153 Intersection_Found = true;

154 }

155 }

156 }

157

158 return(Intersection_Found);

159 }

La lınea principal es la 131 porque contiene la llamada a la funcion Intersect Sphere, dentrodel mismo fichero, la cual contiene las llamadas a funciones de los ficheros frame.h y vector.h queparticipan en el bloque. A continuacion se muestra un fragmento de Intersect Sphere.

275 int Intersect_Sphere(RAY *Ray , VECTOR Center , DBL Radius2 , DBL *Depth1 , DBL ←↩*Depth2)

276 {

277 DBL OCSquared , t_Closest_Approach , Half_Chord , t_Half_Chord_Squared;

278 VECTOR Origin_To_Center;

279

280 Increase_Counter(stats[Ray_Sphere_Tests ]);

281

282 VSub(Origin_To_Center , Center , Ray ->Initial);

283

284 VDot(OCSquared , Origin_To_Center , Origin_To_Center);

285

286 VDot(t_Closest_Approach , Origin_To_Center , Ray ->Direction);

En la lınea 280 esta la llamada a la funcion Increase Counter de frame.h. El compilador hizoinline de esta funcion. A continuacion se muestra la unica lınea que la compone:

frame.h

978 inline void Increase_Counter(COUNTER& x)

979 {

980 x++;

981 }

Las funciones VSub y VDot de las lıneas 282, 284 y 286 son funciones tambien inline delfichero vector.h. Ambas estan sobrecargadas para diferente tipo de parametros, por lo que todascomparten el mismo contenido. A continuacion se muestran un par de ellas a modo de ejemplo:


vector.h

87 inline void VSub(VECTOR a, const VECTOR b, const VECTOR c)

88 {

89 a[X] = b[X] - c[X];

90 a[Y] = b[Y] - c[Y];

91 a[Z] = b[Z] - c[Z];

92 }

221 inline void VDot(DBL& a, const VECTOR b, const VECTOR c)

222 {

223 a = b[X] * c[X] + b[Y] * c[Y] + b[Z] * c[Z];

224 }

Si echamos un vistazo a la funcion VSub de la lınea 87, vemos que las tres instrucciones quela componen se podrıan condensar en un unico bucle para invitar al compilador a vectorizarlascon el pragma vector. Ademas, este fichero contiene multitud de funciones que se rigen bajo elmismo patron pese a que no participan en el bloque basico del que partio el analisis. El resultadode comprimir las tres operaciones en un bucle serıa como se ve en el siguiente codigo:

87 inline void VSub(VECTOR a, const VECTOR b, const VECTOR c)

88 {

89 #pragma vector

90 for (unsigned int i = 0; i < 3; i++)

91 a[i] = b[i] - c[i];

92 }

Una vez hecho esto se podrıa volver a compilar y comprobar si el compilador ha vectorizadoestos bucles. En caso de que sea ası, se podrıa traducir en un incremento de las instruccionesvectoriales en sustitucion de las escalares que minaban el bloque principal.

8.3. Diagnostico Hardware

En esta seccion se presentan los experimentos realizados sobre aquellas aplicaciones limitadaspor memoria que clasificamos con la denominacion memory bound. Cuando se mostraron los resul-tados de las simulaciones realizadas con CMP$im, habıa aplicaciones fuertemente limitadas pormemoria cuyo analisis fue descartado independientemente de su caracterizacion vectorial. En un80 % de los casos se trataba de aplicaciones que presentaban un nivel de vectorizacion importante,pero debido a las limitaciones de memoria el IPC de la aplicacion era deficiente. La siguiente listaindica aquellas que presentaban este perfil:

channel y linpk de Polyhedron,

Cloverleaf de Mantevo,

IRSmk y UMTmk de Sequoia,

MG, FT, SP y CG de NPB

470.lbm, 434.zeusmp y 437.leslie3d de SPEC fp.

Las pruebas realizadas consistieron en doblar por un lado el tamano de la cache unificada UL2,y por otro el tamano del segundo nivel de TLB de datos. Se eligieron estos niveles de memoriaporque querıamos visualizar la mejora en caso de que hubiera mas aciertos en los niveles de cacheprevios a la memoria principal. La latencia fue otro de los campos a considerar. Sin embargo, dado

8.3. DIAGNOSTICO HARDWARE 97

que la latencia configurada para la memoria principal era 22x respecto al ultimo nivel de cache,lo descartamos. El objetivo fue por tanto tener una vision general sobre que ocurrirıa cuando estetipo de aplicaciones no tienen que visitar tanto la memoria principal.

8.3.1. Incremento de UL2

Tomamos la decision de simular solamente las aplicaciones en las que la limitacion de memoriasuperaba un 30 % de los ciclos de toda la aplicacion. A la hora de entender las hipoteticas mejorasexperimentadas, hubo que tener en cuenta que, en la manipulacion de porcentajes, no es lo mismoque se haya experimentado una reduccion del 90 % de ciclos de memoria en una aplicacion dondesuponıan un 5 % del total que en otra donde suponıan un 50 %.

Por otro lado, como nos interesaba ver unicamente las aplicaciones con mejor ındice de mejora,en la Figura 8.12 (pag. 97) se visualizaron aquellas cuya mejora del IPC ascendıa a mas de un1 %. El orden de las aplicaciones en el eje de abscisas esta determinado por la mejora del IPC.Notese que las mejoras en la memoria se presentan con un porcentaje negativo (menos es mejor).Esto se traduce en un incremento positivo del IPC. En la Tabla 8.14 (pag. 97) se muestran lasaplicaciones que teniendo mas de 30 % de ciclos de memoria en la aplicacion, no han conseguidoun mınimo de un 1 % de mejora en el IPC.

Figura 8.12: Resultado de doblar la UL2 de 1024Kb a 2048Kb

Benchmark Aplicacion

Polyhedron linpk nf

Mantevo miniMD miniGhost miniFE CloverLeaf HPCCG

Sequoia UMTmk IRSmk

NPB FT CG IS MG

SPEC fp 470.lbm

Tabla 8.14: Aplicaciones con una mejora inferior al 1 %


La mejora de la aplicacion SPEC fp/433.milc, visualizada en detalle en la Figura 8.13 (pag. 98),dobla su IPC. La reduccion del 82,2 % de ciclos de memoria ha supuesto una reduccion del 52,5 %de ciclos de la aplicacion, que se traduce en un 110 % mas de IPC. A la derecha se visualiza ladistribucion del porcentaje de ciclos de la aplicacion antes y despues. Dejo de ser una aplicacionlimitada exclusivamente por memoria principal, para pasar a ser una aplicacion que, con un 87 %de instrucciones escalares, serıa candidata a ser analizada para mejorar el ındice de vectorizacion.

Figura 8.13: Mejora de SPEC fp/433.milc al doblar la L2

Tenganse en cuenta casos como NPB/BT donde, pese a haber sufrido un decremento de ciclosde memoria del 71,95 %, no repercute mas que un 28,54 % de mejora del IPC. Esto ocurre porquesu porcentaje de ciclos de memoria estaba en el lımite del 30 % establecido como corte para elexperimento. Entonces, aunque se hayan reducido los ciclos de memoria, no se puede reducir masel IPC. Otro caso caso particular es el de polyhedron/test fpu. En la grafica se aprecia, junto al25,2 % de mejora de ciclos de memoria, un 4 % en la UL2. Para analizar el resultado tenemos quetener en cuenta los dos conceptos fundamentales sobre:

Ciclos de memoria: estos son el resultado de los fallos producidos en la cache unificadade nivel 2 y, debido a la fuerte penalizacion en ciclos de memoria principal, las instruccionesasociadas siempre aparecerıan en el camino crıtico.

Ciclos de UL2: que estos ciclos formen parte del camino crıtico depende de los fallosproducidos en la cache de nivel 1. Sin embargo, como la penalizacion por un acierto en UL2no es tan grande como la que generarıa un fallo, si gracias a haber doblado el tamano dela UL2 se aumentan sus aciertos, significa que estos ciclos podrıan haber dejado de formarparte del camino crıtico si la instruccion siguiente dependiera de una load-op anterior defuerte latencia (ej. division). Vease la Figura 8.14 (pag. 99).

Entonces, sabiendo que el numero de accesos a la cache es obviamente el mismo y que no hemosdoblado el tamano de la DL1, la reduccion del 4 % tiene que estar ıntimamente relacionada conque algunas instrucciones que antes formaban parte del camino crıtico por fallo en la UL2, ahoracon el acierto, ya no lo son.

8.3. DIAGNOSTICO HARDWARE 99

Figura 8.14: Consecuencia posible por aumento de aciertos en L2

8.3.2. Incremento de TLB

Analogamente, no para todas las aplicaciones tenıa sentido simular su comportamiento con eldoble de lıneas en el segundo nivel de TLB. Dado que habıa muy pocas aplicaciones con muchosciclos de TLB, se bajo el umbral de seleccion a un 10 %. No se bajo mas porque se considera queen una aplicacion con menos del 10 % de ciclos de TLB es irrelevante aplicar una mejora costosacomo es aumentar el numero de lıneas. Incluso ası, solo cumplieron el requisito cuatro aplicaciones.Estas se muestran en la Figura 8.15 (pag. 100) siguiendo la nomenclatura usada anteriormente.

La aplicacion NPB,IS presenta una mejora del 64,50 % de ciclos que repercuten en una mejoradel IPC del 35,10 %. A su lado tenemos a NPB,DC que presenta el mismo comportamiento queveıamos para Polyhedron,test fpu en el apartado anterior. En este caso, ademas del 93,82 % demejora de los ciclos de memoria por fallos de TLB, tambien hay una reduccion del 26,37 % enlos ciclos de acceso al TLB de segundo nivel. En el modelo, un fallo de TLB que provoca unacceso a la tabla de paginas de la memoria principal acarrea una latencia importante. Si poraumentar el numero de lıneas se reducen estos accesos, es factible que, como en el caso anterior,las instrucciones que fueran responsables de dichos accesos hayan dejado de formar parte delcamino crıtico de la aplicacion. De todos modos, pese al 93,82 % de mejora de los ciclos, como lareduccion se aplica solamente sobre un 13,3 % de ciclos de TLB, al final el IPC solo mejora un12,5 %. En la Figura 8.16 (pag. 100) se presenta en detalle el resultado de mejorar NPB,IS.

En la parte izquierda de la Figura 8.16 (pag. 100), vemos el decremento en ciclos y el aumentode IPC de la aplicacion IS de NPB. Pese a que es una mejora tımida, la grafica derecha nosdevuelve a la realidad porque nos recuerda que sigue siendo una aplicacion limitada por memoria.Ademas, si recordamos la Tabla 8.14 (pag. 97), era una de las aplicaciones con una mejora inferioral 1 % cuando se doblo el tamano de la cache unificada L2. Por tanto, para esta arquitectura enconcreto, este tipo de mejoras es insuficiente y no deja otro camino que abrir el paso hacia unaposible mejora de la arquitectura en sı como alternativa.

El diagnostico hardware realizado en este apartado quiso marcar el final de la busqueda delmodo de hacer un uso efectivo de la unidad vectorial. Hemos visto aquı que, pese a que el objetivoprincipal del trabajo se cumpla, el perfil de una aplicacion al ser ejecutado sobre una maquinacon una configuracion de memoria concreta puede impedir que se obtengan las mejoras que seesperarıan al hacer un buen uso de la unidad vectorial. En definitiva, la memoria no se puedeignorar y podrıa ser necesario hacer un buen estudio previo sobre el uso de las estructuras de datosde la aplicacion, para, o bien para maximizar el rendimiento de la aplicacion sobre la maquina, obien para mejorar la maquina.


Figura 8.15: Resultado de doblar las lıneas de DTLB2 de 256 a 512

Figura 8.16: Mejora de IS de NPB al doblar la TLB

Capıtulo 9

Conclusiones

La vectorizacion es una herramienta potente que puede proporcionar buenos resultados cuan-do se consigue usar plenamente. Teniendo esto presente, el estudio de la utilizacion efectiva deprocesadores vectoriales presentado ha consistido en el proceso que se describe a continuacion.

En primer lugar se tomaron el conjunto de benchmarks Polyhedron, Mantevo, NPB, Sequoiay SPEC fp, de los cuales se seleccionaron, o bien todas las aplicaciones, o bien solo una mues-tra segun el tamano de los ficheros de entrada disponibles. Se compilaron con los compiladoresIntel R©ICC e Intel R©IFORT segun el lenguaje en el que estuvieran escritas, y se realizo una prime-ra caracterizacion de las mismas para conocer sus ındices de vectorizacion y recopilar las causasproporcionadas por el compilador para no vectorizar. Este primer acercamiento mostro que, enun 21 % de las aplicaciones, el numero de instrucciones vectoriales era igual o superior al 38 % deltotal.

A continuacion se incorporo al simulador de cache CMP$im una funcionalidad nueva: un mode-lo simplificado de los nucleos del coprocesador Intel R© Xeon PhiTM. Con los resultados obtenidoscon el simulador modificado, y apoyandonos en la comparativa de la version vectorizada frente ala no vectorizada, se descubrio que un 57 % de aplicaciones ejecutaban menos instrucciones quesus respectivas versiones no vectorizadas. Aunque podrıa parecer un dato positivo, hay que teneren cuenta que solo un 21 % de aplicaciones tenıa un 38 % o mas de instrucciones vectoriales. Poreste motivo, pese a que las versiones vectorizadas hubieran mejorado, el uso de la unidad vectoriales bajo en el 79 % de las aplicaciones. Ademas, a esto hay que anadir que un 32 % del mencionado57 % de aplicaciones, mostraron un comportamiento fuertemente limitado por los accesos a lamemoria principal.

En este punto se tenıa informacion suficiente sobre las aplicaciones no limitadas por memoria,para seleccionar las mas significativas desde el punto de vista de la mejora del uso de la unidadvectorial. Se estudiaron tanto a nivel de bloques basicos como a nivel de codigo fuente. Los objetivoseran identificar las regiones mas ejecutadas que el compilador no habıa vectorizado, estudiar lascausas y proponer una posible solucion. Solo se implemento la solucion en una de las aplicacionesporque era una tarea fuera de los objetivos de este trabajo.

Finalmente, se decidio realizar dos pruebas sobre las aplicaciones que, estando limitadas pormemoria, tenıan un buen ındice de vectorizacion: doblar el tamano de la L2 y el numero delıneas del segundo nivel de TLB. Se consideraron, para la primera prueba, aquellas cuyos ciclosde memoria principal suponıan un 30 % o mas de los ciclos de la aplicacion. Se observo que soloun 45 % obtuvo una mejora superior al 1 %. De ese 45 %, un 50 % experimento una mejora delIPC superior al 20 %. Para la segunda prueba se consideraron aquellas aplicaciones cuyos ciclosde TLB eran superiores o igual al 10 % del total. Solo se simularon 4 aplicaciones de las cuales 2

101

102 CAPITULO 9. CONCLUSIONES

obtuvieron mejora. Sin embargo solo una de ellas mejoro en mas de un 20 % el IPC.

Todos los datos presentados muestran de forma clara la fuerte dependencia que existe entrela vectorizacion, la memoria, la programacion y el compilador. La complejidad que puede llegarsea alcanzar para poder maximizar el aprovechamiento de la unidad vectorial de un procesador esfuerte. Ademas, el hecho de que el compilador sea muy bueno y proporcione multitud de funciona-lidades, podrıa resultar inutil si el codigo no esta bien escrito, o si no lo esta como el compiladorlo espera. Podrıa llegarse al punto en que hubiera que reescribirse el codigo completo. Esto hacerecaer una gran parte de la responsabilidad en el programador y su habilidad para explotar las fa-cilidades de que se dispongan para maximizar la vectorizacion de la aplicacion. Las limitaciones dememoria, por su parte, resultaron ser un motivo importante que impidio obtener buen rendimientoen aplicaciones que hacıan ya un buen uso de la unidad vectorial. El diagnostico hardware quisodemostrar precisamente que la memoria no se puede ignorar y que podrıa ser necesario estudiarbien el uso de las estructuras de datos de la aplicacion para saber que configuracion de memoriale vendrıa mejor.

Por tanto, el estudio de la utilizacion efectiva de la unidad vectorial realizado ha servido paraafirmar finalmente lo siguiente:

La vectorizacion es posible pero en ocasiones muy difıcil de conseguir.

El compilador es una herramienta crucial en todo el proceso.

La penalizacion de los accesos a memoria resulta ser en muchos casos un cuello de botellaimportante en el balance final del computo de la aplicacion, pese a la vectorizacion.

9.1. Trabajo Futuro

Entre los trabajos futuros que han quedado pendientes en el presente estudio, y que podrıanpor tanto conferirle una mayor completitud, se encuentran los siguientes:

Implementar las propuestas presentadas en el Seccion 8.2 (pag. 74) para cada una de lasaplicaciones seleccionadas:

• Usar el pragma vector always pese a que las iteraciones de un bucle sean pequenas.

• Reescribir el codigo en caso de que con pragmas sea insuficiente o porque el codigo seamuy complejo.

• Usar el pragma ivdep en caso de que las dependencias no sean tales debido a ambigueda-des de los punteros.

• Usar el pragma unroll para invitar al compilador a reordenar instrucciones en caso deproblemas por dependencias.

• Generar bucles en aquellas regiones donde el acceso a cada uno de los elementos de unvector o matriz se realizo con instrucciones sueltas.

Completar CMP$im para simular aplicaciones multi-threading y ver el comportamiento ha-ciendo uso de todos los nucleos del coprocesador Intel R© Xeon PhiTM.

Anadir etapas y lımite de recursos a CMP$im para obtener resultados mas detallados.

Estudiar diferentes configuraciones de memoria, ası como su viabilidad, para mejorar elrendimiento de las aplicaciones limitadas por memoria.

Bibliografıa

[Bar07] Blaise Barney. Introduction to parallel computing. 2007.

[Bar08] Miquel Barcelo. Una historia de la informatica. Editorial UOC, 2008.

[Dı06] Domingo Benıtez Dıaz. Arquitectura de Computadores. Manual de teorıa. Universidadde Las Palmas de Gran Canaria. Vicerrectorado de Planificacion y Calidad, 2006.

[fly] Flynn’s taxonomy.http://en.wikipedia.org/wiki/Flynn’s_taxonomy.

[Fly72] Michael J. Flynn. Some computer organizations and their effectiveness. IEEE Tran-sactions on Computers, C-21(9):948–960, 1972.

[HP02] John L. Hennessy and David A. Patterson. Computer architecture a quantitative ap-proach. Morgan Kaufmann, tercera edicion edition, 2002.

[inta] Avx-512 instructions.https://software.intel.com/en-us/blogs/2013/avx-512-instructions.

[intb] Intel R© xeon phiTM coprocessor - the architecture.https://software.intel.com/en-us/articles/intel-xeon-phi-coprocessor-\

codename-knights-corner.

[intc] Intel R© software documentation library.http://software.intel.com/en-us/intel-software-technical-documentation/.

[intd] Introduction to Intel R© cilkTM plus.http://software.intel.com/en-us/videos/introduction-to-intel-cilk-plus/.

[inte] An introduction to vectorization with the Intel R© c++ compiler.http://d3f8ykwhia686p.cloudfront.net/1live/intel/An_Introduction_to_

Vectorization_with_Intel_Compiler_021712.pdf.

[JCLJ06] Aamer Jaleel, Robert S. Cohn, Chi-Keung Luk, and Bruce Jacob. Cmp$im: A binaryinstrumentation approach to modeling memory behavior of workloads on cmps. 2006.

[JCLJ08] Aamer Jaleel, Robert S. Cohn, Chi-Keung Luk, and Bruce Jacob. Cmp$im: A pin-based on-the-fly multi-core cache simulator. 2008.

[LCM+05] Chi-Keung Luk, Robert Cohn, Robert Muth, Harish Patil, Artur Klauser, Geoff Low-ney, Steven Wallace, Vijay Janapa Reddi, and Kim Hazelwood. Pin: Building customi-zed program analysis tools with dynamic instrumentation. In Proceedings of the 2005ACM SIGPLAN conference on Programming language design and implementation, pa-ges 190–200, 2005.

[LPG13] Dominic Orchard Leaf Petersen and Neal Glew. Automatic simd vectorization forhaskell. 2013.

103

http://en.wikipedia.org/wiki/Flynn's_taxonomy

https://software.intel.com/en-us/blogs/2013/avx-512-instructions

https://software.intel.com/en-us/articles/intel-xeon-phi-coprocessor-\codename-knights-corner

https://software.intel.com/en-us/articles/intel-xeon-phi-coprocessor-\codename-knights-corner

http://software.intel.com/en-us/intel-software-technical-documentation/

http://software.intel.com/en-us/videos/introduction-to-intel-cilk-plus/

http://d3f8ykwhia686p.cloudfront.net/1live/intel/An_Introduction_to_Vectorization_with_Intel_Compiler_021712.pdf

http://d3f8ykwhia686p.cloudfront.net/1live/intel/An_Introduction_to_Vectorization_with_Intel_Compiler_021712.pdf

104 BIBLIOGRAFIA

[man] Mantevo benchmarks.http://mantevo.org/.

[MS03] Pratyusa Manadhata and Vyas Sekar. Vector processors. 2003.

[nas] Nas parallel benchmarks.http://www.nas.nasa.gov/publications/npb.html.

[nvi] Nvidia’s cuda toolkit: Parallel thread execution isa version 4.0.http://docs.nvidia.com/cuda/parallel-thread-execution/index.html.

[pin] Pin - a dynamic binary instrumentation tool. http://pintool.org/.

[Pip12] Chuck Piper. An introduction to vectorization with the intel R© fortran compiler. 2012.

[pol] Polyhedron fortran benchmarks.www.polyhedron.com.

[seq] Asc sequoia benchmark codes.https://asc.llnl.gov/sequoia/benchmarks/.

[SLA05] Rodric Rabbah Samuel Larsen and Saman Amarasinghe. Exploiting vector parallelismin software pipelined loops. 2005.

[SMP11] Maria J. Garzaran Tommy Wong Saeed Maleki, Yaoquing Gao and Daivd A. Padua.An evaluation of vectorizing compilers. 2011.

[spe] Spec cpu 2006.http://www.spec.org/cpu2006/.

http://mantevo.org/

http://www.nas.nasa.gov/publications/npb.html

http://docs.nvidia.com/cuda/parallel-thread-execution/index.html

http://pintool.org/

www.polyhedron.com

https://asc.llnl.gov/sequoia/benchmarks/

http://www.spec.org/cpu2006/

Apendice A

Intel R© ICC Specific Pragmas

Los Intel R© Specific Pragmas[intc] son pragmas desarrollados especıficamente para el compila-dor ICC de Intel R©. El listado se puede comprobar en la Tabla A.1.

alloc section Asigna una variable a una seccion especıfica.

cilk grainsize Especifica el numero maximo de iteraciones que seejecutaran en serie en un cilk for. Es un tipo espe-cial de bucle que permite que varias conjuntos deiteraciones se ejecuten paralelamente, pero las ite-raciones de cada uno de esos conjuntos se ejecutanen serie. Por tanto, el grainsize es precisamente elnumero maximo de loops en cada conjunto a ejecu-tar paralelamente.

distribute point Indica al compilador que en la region indicada seprefiere distribucion de bucles.

inline Indica al compilador la preferencia de que una llama-da a un procedimiento o funcion concretos se hagainline.

intel omp task Sirve para indicar una unidad de trabajo, ejecuta-da probablemente por un hilo distinto, de cara a ladelegacion de tareas.

intel omp taskq Define el entorno en el que se encolaran cada una delas unidades de trabajo especificadas, de cara a ladelegacion de tareas.

ivdep Indica al compilador que ignore las dependencias vec-toriales que ha detectado en el bucle que le sigue enel codigo.

loop count Indica el numero de veces que el bucle que le siguese va a ejecutar.

105

106 APENDICE A. INTEL R© ICC SPECIFIC PRAGMAS

nofusion Impide que el bucle siguiente se fusione con otrosbucles adyacentes.

novector Indica que el bucle siguiente no debe ser vectorizado.

offload La instruccion siguiente al pragma se ejecutara en eltarget especificado. Aplicable solo sobre Intel R© MICArchitecture.

offload attribute Sirve para especificar que las variables y funcionesdeclaradas a continuacion del pragma, estaran dispo-nibles en el coprocesador. Aplicable solo sobre Intel R©MIC Architecture.

offload transfer Para iniciar transferencias de datos asıncronas o ini-ciar y completar transferencias de datos sıncronas.Aplicable solo sobre Intel R© MIC Architecture

offload wait Establece un punto de espera para actividadesasıncronas iniciadas previamente. Aplicable solo so-bre Intel R© MIC Architecture.

omp atomic Sirve para asegurar que la actualizacion de una de-terminada posicion de memoria sea atomica, con elobjetivo de impedir la posibilidad de que los hilosrealicen lecturas y escrituras multiples o simultaneas.

omp task Define la region de una tarea.

omp taskyield Habilita o deshabilita optimizaciones sobre determi-nadas funciones. Es en cierto grado compatible conla implementacion de MicrosoftTMdel pragma opti-mize.

omp taskwait Especifica un punto de espera para la finalizacion detareas generadas desde el comienzo de la ejecucionde la tarea actual.

optimize Habilita o deshabilita optimizaciones sobre todo elcodigo escrito a continuacion del pragma, hasta quese encuentre con otro pragma optimize o con el finde la unidad de compilacion.

optimization level Restringe el nivel de optimizacion de una funcionconcreta. Mientras que para todo el programa se pue-de haber indicado -O3 desde la lınea de compilacion,con #pragma optimization 1 se indica que a la fun-cion que le acompana se le aplicara -O1.

optimization parameter Indica al compilador la tarea de generar codigo es-pecıfico, a nivel de funcion, para un tipo de pro-cesador. Es semejante a la opcion de compilacion-m(arch).

107

parallel/ noparallel Sirve para indicar al compilador que resuelva depen-dencias de bucles mediante la auto-paralelizacion delbucle situado inmediatamente a continuacion. En elcaso de noparallel, impide la auto-paralelizaciondel bucle inmediatamente a continuacion.

prefetch/ noprefetch Invita al compilador a emitir prefetches de datosa memoria. En el caso de noprefetch deshabilitael prefetching de datos. Aplicable solo sobre Intel R©MIC Architecture.

simd Sirve para forzar al compilador a vectorizar el buclesobre el que se defina.

unroll/ nounroll Indica al compilador el numero de veces que tieneque desenrollar un bucle. En el caso de nounroll, leimpide aplicar esta tecnica.

unroll and jam/

nounroll and jam

Estos pragmas invitan o impiden que el compiladordesenrolle y fusione bucles. Estos bucles solo puedenser de tipo FOR.

unused Indica variables que no se van a usar con el objeti-vo de impedir la generacion de warnings durante lacompilacion.

vector Indica al compilador que el bucle siguiente deberıaser vectorizado de acuerdo a los siguientes parame-tros: always, aligned, unaligned, nontemporal,temporal.

Tabla A.1: Intel R© ICC Specific Pragmas

Apendice B

Intel R© ICC Supported Pragmas

Las Intel R© Supported Pragmas[intc] son un conjunto desarrollado por fuentes externas que sonmantenidas en estos compiladores por razones de compatibilidad. Muchas de ellas se encuentran enla documentacion de los entornos de programacion ofertados por MicrosoftTM. Se puede consultaruna descripcion breve de ellas en la Tabla B.1

alloc text Indica la seccion de codigo donde tienen que estar lasdefiniciones de funcion especificada.

auto inline Aquellas funciones sobre las que se indique elparametro off, seran excluidas como candidatas pa-ra expandirse automaticamente (inline).

bss seg Especifica al compilador el segmento dentro del fi-chero .obj donde las variables no inicializadas tienenque residir.

check stack Si se especifica como parametro on, se habilitara elcheck de pila para las funciones inmediatamente acontinuacion. En el caso de que sea off, se deshabi-litara.

code seg Especifica una seccion de codigo donde se situaranlas funciones.

comment Inserta un registro de comentarios en un fichero ob-jeto o ejecutable.

component Sirve para controlar la generacion de informacioncomo pueden ser las dependencias o la denomina-da browse information, que incluye aspectos comodefiniciones, referencias, macros, etc. a partir de losfuentes de la aplicacion.

conform Especifica el comportamiento en tiempo de ejecucionde la opcion de compilacion /Zc:forScope (ForceConformance in FOR Loop Scope) incluida en el en-torno de Visual Studio de MicrosoftTM.

109

110 APENDICE B. INTEL R© ICC SUPPORTED PRAGMAS

const seg Especifica el segmento donde se alojaran las funcio-nes el fichero .obj.

data seg Seccion especıfica para la inicializacion de datos.

deprecated Indica para una funcion, tipo o cualquier otro iden-tificador, que puede no estar soportado en futurasversiones o que no deberıa usarse mas.

poison Sirve para etiquetar los identificadores que se de-berıan eliminar de la aplicacion, de manera que cuan-do se compile, aquellos identificadores marcados coneste pragma provocaran un error de compilacion.

float control Especifica que una funcion tiene operaciones en pun-to flotante.

fp contract Habilita o deshabilita la implementacion para fusio-nar expresiones.

include directory Incorpora la cadena pasada como argumento, a lalista de sitios donde buscar por ficheros de inclusion.

init seg Especifica la seccion que contiene inicializaciones enC++ para las unidades de compilacion generadastras el preprocesador.

message Muestra la cadena especificada como parametro enla salida estandar.

optimize Especifica las optimizaciones a realizar sobre las fun-ciones bajo el este pragma o hasta el siguiente prag-ma del mismo tipo. Tambien se encuentra en la an-terior lista de aquellos desarrollados por Intel R©, conel objetivo de soportar la implementacion del deMicrosoftTM.

options Pragma compatible con el compilador GCC de Ma-cOS. Configura el alineamiento de los campos en lasestructuras de datos.

pointers to members Especifica si un puntero a un miembro de una clasese puede declarar antes de la definicion de la claseen cuestion. Tambien es usado para controlar el ta-mano del puntero y el codigo que se necesitara parainterpretarlo.

pop macro Configura el valor de una macro en concreto al valorque se encuentre en la cima de la pila asociada adicha macro.

push macro Salva el valor de una macro en concreto en la cimade la pila asociada a esta macro.

111

region/endregion Sirve para especificar un segmento de codigo en elMicrosoftTMVisual Studio 2005 Code Editor, que sedespliega o contrae utilizando las caracterısticas pro-pias de esta herramienta de trabajo.

section Crea una seccion en un fichero .obj. Una vez queesta seccion es definida, permanece valida durante elresto de la compilacion.

start map region Se usa junto con stop map region.

stop map region Se usa junto con start map region

fenv access Sirve para informar a una implementacion, que unprograma podrıa testear los flags de estado o ejecu-tar o ejecutarse bajo un modo distinto al modo pordefecto.

vtordisp Si el parametro es on, se habilita la generacion demiembros vtordisp ocultos. Para el caso de off sedeshabilita.

warning Permite la alteracion selectiva del comportamientode los mensajes de aviso, warnigs, del compilador.

weak Sirve para indicar que un sımbolo es weak, es decirque en caso de no encontrarse la definicion para esesımbolo en el tiempo de linkado, no se lanza ningunerror.

Tabla B.1: Intel R© ICC Supported Pragmas

Apendice C

Intel R© Fortran Directives

El compilador Intel R© Fortran proporciona algunas directivas de compilacion de propositogeneral para permitir configurar algunas tareas a realizar durante la compilacion[intc]. El listadode la tabla Tabla C.1 presenta el conjunto de directivas disponibles.

ALIAS Sirve para especificar un nombre alternativo para lossubprogramas externos a los que se haga referencia.

ASSUME ALIGNED Especifica que una entidad se encuentra alineada enmemoria.

ATTRIBUTES Permite definir propiedades sobre objetos y procedi-mientos.

DECLARE and NODECLARE Activa o desactiva los warnings del compilador en elcaso de que haya variables que se hayan usado peroque no se hayan definido.

DEFINE and UNDEFINE Sirve para definir o eliminar la definicion de variablessimbolicas cuya existencia o valor pueda ser testeadasdurante compilacion condicional.

DISTRIBUTE POINT Sirve para sugerir al compilador los puntos donde unbucle DO puede partirse.

FIXEDFORMLINESIZE Establece la longitud de la lınea para el codigo fuentede tipo fixed-form. Por ejemplo, que en la columna 1de cada fila es donde se pone el sımbolo *, c o ! paraindicar que es un comentario. Tambien es el caso dela columna 6, que sirve para indicar con un sımboloque la lınea anterior continua en la lınea siguiente.

FREEFORM and NOFREEFORM La primera indica que el codigo fuente se correspon-de con formato free-form. La segunda indica que secorresponde con formato fixed-form.

IDENT Especifica una cadena que identifica al un moduloobjeto.

113

114 APENDICE C. INTEL R© FORTRAN DIRECTIVES

IF and IF DEFINED Sirve para especificar aquellas secciones de codigoque son de compilacion condicional.

INLINE, FORCEINLINE,

NOINLINE

Indica el tipo de inlining que el compilador tiene quellevar a cabo para rutinas o bucles DO.

INTEGER Sirve para establecer el numero de bytes por defectoque seran asignados a los enteros.

IVDEP Indica al optimizador del compilador que asuma quelas dependencias se producen en la misma direccionque su aparicion.

LOOP COUNT Especifica el numero de iteraciones que va a realizarun bucle DO.

MESSAGE Indica la cadena que se enviara a la salida estandardurante la primera pasada del compilador.

NOFUSION Impide que un bucle se fusione con otros bucles ad-yacentes en caso de ser posible.

OBJCOMMENT Especifica la ruta de busqueda de una librerıa en elfichero objeto. Se puede especificar mas de una di-rectiva de este tipo para configurar diferentes rutasa distintas librerıas en un mismo codigo fuente.

OPTIMIZE and NOOPTIMIZE Habilita o deshabilita optimizaciones sobre la unidadde programa. Una unidad de programa puede ser elprograma principal, una subrutina externa o funcion.

OPTIONS Afecta al alineamiento de datos y a los warnings pro-ducidos por ello.

PACK Especifica el alineamiento en memoria de tipos deri-vados o estructuras tipo struct.

PARALLEL and NOPARALLEL Facilita la auto-paralelizacion ayudando al analisisde dependencias del compilador sobre el bucle DOsiguiente. En el caso de NOPARALLEL, se impide.

PREFETCH and NOPREFETCH Habilita o deshabilita las pistas para el compiladorde cara a realizar prefetching de datos de memoria.

PSECT Modifica las caracterısticas de un bloque comun. Si launidad de programa cambia una o mas caracterısti-cas de uno de estos bloques, todas las unidades quelo referencien deben tambien cambiar.

REAL Sirve para establecer el numero de bytes por defectoque seran asignados a los reales.

SIMD Requiere y controla la vectorizacion SIMD de los bu-cles.

115

STRICT and NOSTRICT STRICT habilita caracterısticas del lenguaje no en-contradas en el estandar especificado en lınea de co-mandos (Fortran 2008, 2003, 95 o 90). Por el contra-rio, NOSTRICT las deshabilita.

UNROLL and NOUNROLL La primera indica al optimizador del compiladorcuantas veces hay que desenrollar el bucle DO al queafecta. La segunda impide el desenrollamiento de esebucle.

UNROLL AND JAM and

NOUNROLL AND JAM

Habilitan o deshabilitan, respectivamente, la posibi-lidad del compilador de desenrollar y fusionar. Solose pueden aplicar a bucles DO iterativos.

VECTOR and NOVECTOR Sobrescriben las heurısticas por defecto para la vec-torizacion de bucles DO.

Tabla C.1: Intel R© Fortran Directives

Apendice D

Mensajes del compilador

Los mensajes del compilador mas significativos son los siguientes:

Low trip count Bucle con un numero de iteraciones pequena.

Vectorization possible but seems ineffi-cient

Bucle demasiado largo con elevado uso de recursos,ej. registros.

Unsupported loop structure El compilador no es capaz de determinar el numerode iteraciones, por ejemplo si se usan punteros comocontadores.

Not inner loop El bucle tratado no es un bucle interno.

Existence of vector dependence existencia de dependencias entre los punteros del bu-cle.

Nonstandard loop is not a vectorizationcandidate

El bucle contiene mas de un punto de salida. Tam-bien puede ocurrir que haya una llamada en bucleque se haya pasado como parametro a la funcion quecontiene el bucle y que no puede resolver.

Unsupported reduction no soporta alguna de las reducciones que se estenrealizando dentro del bucle

Conditional assignment to a scalar El bucle tiene una operacion de asignacion a una va-riable escalar, o un campo de una estructura, dentrode una condicion.

Statement cannot be vectorized El uso de expresiones especıficas de Cilk o algunaherramienta multi-hilo como OpenMP dan lugar aeste mensaje.

Tabla D.1: Mensajes del compilador

117

Documents

Estudio de utilizaci on efectiva de procesadores vectoriales · procesadores vectoriales Proyecto de Fin de Carrera Ingenier a en Inform atica Laura Aut on Garc a Tutores: Francisca