Comparación de arquitectura AMD e Intel para ejecución de ...

Universidad Nacional de Córdoba

Comparación de arquitectura AMDe Intel para ejecución de GADGET

Autor: Ruben Dario Graña

Directores: Federico Stasyszyn, NicolásWolovick

Córdoba, Argentina 2017

Esta obra está bajo una licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

http://creativecommons.org/licenses/by-nc-sa/4.0/

http://creativecommons.org/licenses/by-nc-sa/4.0/

Índice general

Índice general i

1. Descripción de GADGET 31.1. Autor e Historia . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. N-Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3. El método de partícula-partícula . . . . . . . . . . . . . . . . . 51.4. El código de árbol (Tree Code) . . . . . . . . . . . . . . . . . 61.5. Malla de partículas (Particle Mesh) . . . . . . . . . . . . . . . 71.6. Partición de dominio . . . . . . . . . . . . . . . . . . . . . . . 7

2. Breve historia de los CPU 112.1. Memoria principal . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Unidad de gestión de memoria . . . . . . . . . . . . . . . . . . 122.3. Ejecución fuera de orden . . . . . . . . . . . . . . . . . . . . . 132.4. Una instrucción, múltiples datos . . . . . . . . . . . . . . . . . 13

3. Equipamiento utilizado 153.1. Nodo con procesadores Intel . . . . . . . . . . . . . . . . . . . 15

3.1.1. Procesador . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.2. Diagrama de bloque . . . . . . . . . . . . . . . . . . . 163.1.3. Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Nodo con procesadores AMD . . . . . . . . . . . . . . . . . . 173.2.1. Procesador . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2. Diagrama de bloque . . . . . . . . . . . . . . . . . . . 183.2.3. Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4. Caracterización 214.1. Potencia de cálculo . . . . . . . . . . . . . . . . . . . . . . . . 214.2. DGEMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.1. DGEMM en AMD . . . . . . . . . . . . . . . . . . . . 234.2.2. DGEMM en Intel . . . . . . . . . . . . . . . . . . . . . 24

i

ii ÍNDICE GENERAL

4.3. Ancho de banda de memoria . . . . . . . . . . . . . . . . . . . 264.4. STREAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4.1. STREAM en AMD . . . . . . . . . . . . . . . . . . . . 274.4.2. STREAM en Intel . . . . . . . . . . . . . . . . . . . . 29

5. Ejecuciones realizadas 315.1. Descripción de la simulación . . . . . . . . . . . . . . . . . . . 315.2. Dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3. Ejecución patrón . . . . . . . . . . . . . . . . . . . . . . . . . 345.4. Ejecución sin optimizaciones . . . . . . . . . . . . . . . . . . . 375.5. Cambio de compiladores . . . . . . . . . . . . . . . . . . . . . 385.6. Cambio de hardware . . . . . . . . . . . . . . . . . . . . . . . 395.7. Ejecuciones en simultáneo . . . . . . . . . . . . . . . . . . . . 415.8. Resumen de ejecuciones . . . . . . . . . . . . . . . . . . . . . 425.9. Discusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6. Conclusiones 45

Bibliografía 47

Agradecimientos

Quiero dedicar este trabajo a mi familia, especialmente Nelly y Ruben,quienes estuvieron a mi lado y alentándome a lo largo de toda la carrera.Le agradezco a todos mi amigos, quienes de las más diversas formas me acom-pañaron a llegar hasta aquí.También quiero agradecer a todos los docentes que intervinieron en mi for-mación en el correr estos años y que, en aquellos momentos de desánimo, meapuntalaron para que continuara, me aconsejaron y ayudaron a continuar.Un especial agradecimiento a todo el equipo humano del IATE, quienes deuna u otra forma estuvieron pendientes de que este proyecto llegara a buenpuerto.Finalmente no quiero dejar fuera de este agradecimiento a todo el personalnodocente del departamento de alumnos y la biblioteca, quienes siempre es-tuvieron dispuestos a ayudar y resolver cualquier duda o problema con lo queme encontrara con un trato personal excepcional.

iii

iv ÍNDICE GENERAL

Resumen

El trabajo que se presenta a continuación fue realizado en la UniversidadNacional de Córdoba, en el marco de la Facultad de Matemática, Astronomía,Física y Computación, y el Instituto de Astronomía Teórica y Experimentaldependiente también del CONICET. Dentro de dicho instituto se trabaja consimulaciones numéricas, gran parte de las cuales son generadas localmente,por lo que resulta de vital importancia conocer que es lo más conveniente almomento de adquirir nuevo equipamiento.

Por ello que este trabajo nace de la necesidad de determinar que arqui-tectura de computadora es la más apropiada al momento de ejecutar Gadget,un código ampliamente utilizado en astronomía al momento de realizar si-mulaciones cosmológicas. Desde el punto de vista de la computación tambiénresulta muy interesante estudiar como trabajan las distintas arquitecturasfrente al mismo tipo de carga, una compleja en este caso, cómo impacta enel desempeño la utilización de distintos compiladores y banderas de compi-lación.

A lo largo del mismo se presenta el código, su historia y componentes. Asu vez se hace una breve introducción de lo que ha cambiado en los procesa-dores en los últimos 30 años. Luego se presentan y caracterizan los equiposque fueron utilizados. La caracterización incluye los cálculos teóricos y laspruebas realizadas para comprobar los valores teóricos. Finalmente se mues-tran distintas comparativas de ejecuciones de Gadget realizadas con diversosparámetros, compiladores y configuraciones del hardware, junto a otras es-tadísticas obtenidas.

v

Glosario

-O0 Desahbilita todo tipo de optimización por parte del compilador.. 37

-O3 Activa todas las opciones de optimización ajustadas a los estándar. 34

-ip Genera optimizaciones dentro de archivos individuales y símbolos paradebugging. 34

-march Activa todas las optimizaciones específicas a la arquitectura indica-da, pero no necesariamente en arquitecturas anteriores. 34

-mprefer-avx128 Instruye al compilador que utilice instrucciones AVX de128 bits en lugar de 256 bits en la vectorización. 40

-mtune El compilador generará código que podrá ser ejecutado en todaslas arquitecturas, pero favoreciendo secuencias de instrucciones que seejecuten más velozmente sobre la arquitectura indicada. 34

-xHost Instruye al compilador para generar código específico a la arquitec-tura indicada. 34

1

2 Glosario

Capítulo 1

Descripción de GADGET

Gadget [22] es un código para simulaciones cosmológicas N-Body/SPHde libre acceso preparado para ejecutarse en gran cantidad de núcleos decomputadoras con memoria distribuida; utiliza un modelo de comunicacionesexplícito a través de MPI y está preparado para ser compilado y ejecutadosobre el hardware de diversas arquitecturas como x86 o PowerPC, partiendode una máquina de escritorio hasta un cluster con miles de núcleos.

Éste código realiza el cálculo de fuerzas gravitacionales con un algoritmode árbol jerárquico, que brinda la opción de combinarlo con una malla paralas fuerzas gravitaciones en grandes escalas. Además tiene en cuenta la acciónde fluídos hidrodinámicos a través de métodos de partículas suavizadas, SPH,por sus siglas en inglés para smoothed-particle hydrodynamics.

El código puede ser utilizado para estudios de sistemas que incluyan ono la expansión cosmológica del universo, con o sin condiciones periódicasde contorno e inclusive con condiciones de contorno arbitrarias (i.e. vacío,tidales específicas, etc). En todo este tipo de simulaciones Gadget sigue laevolución de un sistema de N-cuerpos que gravita sobre sí mismo sin colisio-nes y permite que sean incluidas opcionalmente las dinámicas de gases. Tantola integración temporal de la gravedad como de la hidrodinámica se realizande forma simpléctica (de forma ideal), con pasos totalmente adaptativos per-mitiendo un rango dinámico que es, en principio, limitado a la precisión dela máquina utilizada.

1.1. Autor e Historia

Gadget fue escrito por Volker Springel en los últimos 17 años. La prime-ra versión, presentada en marzo de 2000, fue escrita como parte de la tesisdoctoral de Springel en el instituto de astrofísica Max Planck, Garching,

3

4 CAPÍTULO 1. DESCRIPCIÓN DE GADGET

Alemania, bajo la supervisión de Simon White. Con el correr de los añosel código ha sido mejorado durante el post-doctorado de Springel en CfA,Harvard-Smithsonian Center for Astrophysics [10] y el MPA, Max-Planck-Institut für Astrophysik [8], nuevamente en colaboración con Simon Whitey Lars Hernquist. La segunda versión pública, presentada en mayo de 2005,contiene gran parte de estas mejoras, excepto los numerosos módulos de fí-sica desarrollados para el código que van más allá de gravedad y dinámicade gases comunes. Las primeras versiones del código, en el año 1998, fuerondiseñadas casi de manera específica para ejecución serial con el objetivo deatacar principalmente problemas de colisión de interacción galaxias, lo queexplica en parte el porqué de su nombre, traducido del inglés pequeña he-rramienta. Las siglas corresponden a Galaxies with Dark matter and GasInteract

La versión para cómputo paralelo de código de árbol, en inglés Tree Code,también fue desarrollada durante el año 1998 junto con la primera versiónen paralelo de SPH agregada a finales de 1999. Para la última parte, NaokiYoshida, por aquel entonces otro estudiante de pos-grado en el MPA, se su-mó a los esfuerzos de Springel para el desarrollo y prueba de los algoritmosparalelos de SPH. Entre los años 2001 y 2003, fue creado Gadget-2. El nue-vo código fue prácticamente una reescritura completa de la versión original,incluyendo reemplazos para todo los algoritmos centrales con nuevos méto-dos. Los cambios más importantes yacen en una nueva integración temporal,un nuevo módulo del código de árbol, un nuevo esquema de comunicacionespara fuerzas gravitacionales y SPH, una nueva estrategia de descomposiciónde dominio, una nueva formulación de SPH basada en entropía (y no energíainterna) como una variable independiente y finalmente en la adición de lafuncionalidad TreePM.

Volker Springel, junto a su equipo, se encuentra en desarrollo de la ter-cera versión del código. La última versión de Gadget mejora la búsqueda,construcción, actualización y generación de las claves de Peano-Hilbert. Asi-mismo, mejora la descomposición de dominios, permitiendo tener nodos conpartículas no adyacentes y esto ayuda a mejorar el balance de cómputo lle-gando a escalar en supercomputadoras de más de 1000 núcleos eficientemente.Mejora el manejo de memoria y la caminata del árbol, eliminando cuellos debotella debido a la paralelización. Estas son algunas de las mejoras, que ha-cen que prefiera emplear ésta versión del código para los estudios realizadosen el IATE, de todos modos si bien aún no se ha presentado una versiónpública, se espera pueda ser liberada pronto.

1.2. N-BODY 5

1.2. N-Body

Muchos fenómenos físicos pueden, directa o indirectamente, ser simuladoscon sistemas de partículas, donde cada partícula interactúa con todo el restode acuerdo a las leyes de la física. Algunos ejemplos pueden ser la interaccióngravitacional entre las estrellas de una galaxia o las fuerzas de Coulombejercidas por los átomos de una molécula. El desafío de llevar a cabo demanera eficiente todos estos cálculos es conocido como el problema de N-cuerpos [12]. Matemáticamente puede ser formulado como

U(x0) =∑i

F (x0, xi) (1.1)

donde U(x0) es una cantidad física en x0 que puede ser obtenida sumando lasinteracciones sobre las partículas tomadas de a pares, para el caso asumimosun sistemas compuesto por N partículas, ubicadas en xi y con una masami. La fuerzas gravitacionales ejercidas sobre una partícula x que posee unamasa m es expresada como

F (x) =N∑i=1

Gmmix− xi|x− xi|3

(1.2)

donde G es la constante gravitacional y m la masa de la partícula x.La tarea de evaluar la función U(x0) para las N partículas usando 1.1

requiere O(n) operaciones para cada partícula, resultando en una compleji-dad total O(n2). Esta complejidad puede ser reducida a O(n log(n)) o O(n)mediante el uso de métodos eficientes para aproximar la suma del términode la derecha de la ecuación 1.1, mientras se preservan propiedades físicasimportantes como la energía y el momento.

1.3. El método de partícula-partícula

La metodología consistente en evaluar por fuerza bruta el término dere-cho de la ecuación 1.1 se vuelve impracticable para una gran cantidad departículas ya que tiene una complejidad O(n2), pero para una cantidad pe-queña puede ser un método efectivo que acabará en un valor exacto, donde laprecisión del cálculo estará limitada por la capacidad de la máquina utilizada.

Es aquí donde aparecen los algoritmos jerárquicos de cálculo de fuerzas,que vienen a reducir la brecha entre los métodos de fuerza bruta y aquellosque realizan aproximaciones. Todos los métodos jerárquicos realizan un par-ticionado de la masa distribuyéndola en una estructura de árbol, donde cada


nodo tiene una descripción concisa de la distribución de materia en algúnvolumen. En este caso se utiliza el algoritmo de Barnes & Hut de 1986 [3],de aquí en más BH86, que ha sido ámpliamente utilizado en simulaciones deastrofísica a lo largo de los últimos años.

1.4. El código de árbol (Tree Code)

La estrategia de este algoritmo consiste en reducir la sobrecarga que ge-nera la búsqueda de vecinos a través de un árbol asumiendo que los cuerposcercanos tienen una lista similar de interacciones. Las fuerzas sobre los cuer-pos son calculadas durante un recorrido del árbol completo y almacenadopor niveles. Este proceso mantiene y actualiza la lista de interacciones; pue-de verse que en cada nivel, un cuerpo b en una celda c es usado para separarel conjunto de posibles interacciones que b puede tener. El costo de este or-denamiento es distribuido sobre todo los cuerpos que se encuentran en lacelda, posibilitando una aceleración en el código que construye la lista deinteracciones para cada cuerpo. Cuando el recorrido recursivo llega al cuerpob, la lista de interacciones es utilizada para obtener la fuerza gravitacional yel potencial en b. Una forma práctica de entenderlo, consiste en visualizar lainteracción entre un satélite y el planeta tierra, en este caso no se calcula lafuerza que ejerce cada átomo sobre el satélite, sino que se hace una estimaciónde la fuerza total que ejercería una partícula con la masa del planeta tierray con ese resultado se realiza el cálculo de la fuerza. En este caso la partícu-la se encontraría en el nodo del árbol que reúne a todos los átomos, por loque cualquier interacción que se desee calcular con la tierra, se computará através de dicho nodo.

Típicamente los algoritmos de N-Cuerpos utilizan aproximadamente lamitad del tiempo en búsquedas dentro del árbol. Podría esperarse una ga-nancia de un factor dos generando listas de interacción para todos los cuerposen un solo recorrido del árbol. En la práctica las listas generadas de esta ma-nera no son específicas a cada partícula, deben ser más grandes para obteneruna buena aproximación. Una aceleración en la ejecución del código se ob-tiene a través de una evaluación más rápida de las interacciones, la cual esalcanzada realizando ajustes en el algoritmo recorriendo el árbol. Las prue-bas preliminares muestran la mejora en el tiempo de ejecución, reduciéndoloa la mitad sobre el utilizado en BH86 a un nivel de precisión determinado.Además muestra mayor robustez cuando se presentan ciertas distribucionespatológicas de masa. En procesadores escalares la mayor parte del tiempo seutiliza en la creación de las listas de interacción, una gran ventaja es ejecutareste tipo de acciones en unidades vectoriales, ya que permiten la aplicación

1.5. MALLA DE PARTÍCULAS (PARTICLE MESH) 7

de la misma operación sobre múltiples datos a la vez.

1.5. Malla de partículas (Particle Mesh)

Este algoritmo guarda algunas similitudes con los anteriormente vistos.Nuevamente se realiza una división del espacio, armando una grilla, en inglésMesh, pudiendo luego calcular una transformada de Fourier sobre la misma.Al realizar esta transformada deja de trabajarse en el espacio real para ha-cerlo con frecuencias, conocido como espacio de Fourier, lo cual simplificalos cálculos, teniendo en cuenta por ejemplo, una derivada en espacio reales simplemente una multiplicación en espacio de Fourier, teniendo luego queanti-transformar los resultados para ser utilizados en el espacio real. Es eneste punto donde se utilizan bibliotecas específicas para la transformación deun espacio a otro. Una vez calculada la masa y aceleración para cada regióndel espacio se puede interpolar a las posiciones de las partículas y añadir loscálculos de las interacciones entre ellas, para obtener la fuerza aplicada sobrela misma.

1.6. Partición de dominio

Unos de los puntos que tuvo que ser mejorado a lo largo del desarrollo deGadget es la partición de dominio [23], es decir, distribuir las partículas desdesu posición original de forma tal que la carga de los procesadores sea parejay no se produzca desbalanceo, quedando algunos procesadores sin carga yotros con exceso. En la imagen 1.1 podemos ver como se ubican las partículasde un disco exponencial. La distribución no homogénea de partículas y losdistintos pasos de tiempo como función de densidad convierten en un desafíoimportante obtener un ordenamiento de partículas que tenga buen balancede carga de procesadores y memoria.

En la primera versión de Gadget se contaba con una bisección recursivaortogonal simple de dominio. Cabe recordar que la primera versión de Gadgetera de ejecución serial y en su versión en paralelo se asignaba cada una delas regiones a un procesador, por lo tanto con la evolución en la ejecución, seproduce un desbalance imposible de manejar, ya que es estático.

En la segunda versión de Gadget se logró desarrollar otra función de des-composición, una curva de Peano-Hilbert [16] que resulta más flexible a lahora de particionar el dominio. Esta decisión también tiene una justificacióndesde el punto de vista de ejecución del código, cuando se comenzó a desarro-llar no se contaba con conectividad de alta velocidad de baja latencia como


Figura 1.1: Distribución de partículas en un disco exponencial

pueden ser en la actualidad Omnipath o InfiniBand, por lo que el método dePeano-Gilbert permite que las regiones adyacentes permanezcan adyacentesen los nodos también, reduciendo el tiempo y la necesidad de comunicacio-nes. En este caso resulta de mayor importancia este particionamiento debidoa que que Gadget-2 ya se ejecuta en paralelo, por lo que una distribuciónpoco óptima puede llevar a tener importantes desbalanceos de carga y por lotanto tiempos excesivos de ejecución.

Como puede verse en la figura 1.3 es notable el cambio que se realiza enla función de descomposición.

Se proyecta que para la tercera versión de Gadget se desarrolle una parti-ción de dominio aún mejor, también basado en una curva de Peano-Hilbert,como puede verse en la figura 1.4. Se espera, nuevamente, que este cambiotenga impacto en un mejor desempeño en la ejecución del código.

1.6. PARTICIÓN DE DOMINIO 9

Figura 1.2: Bisección recursiva ortogonal simple

Figura 1.3: Curva de Peano-Hilbert


Figura 1.4: Nueva curva de Peano-Hilbert

Capítulo 2

Breve historia de los CPU

¿Qué fue lo que cambió en los microprocesadores en los últimos 30 años?[13]Esta pregunta tiene varias aristas que abordaremos en esta sección.

2.1. Memoria principal

Este es uno de los cambios que se ha vuelto más complejo en los últimosaños. Pensemos que, por ejemplo, en una computadora con un procesador80286 de finales de la década de 1980 y principios de 1990 un acceso a me-moria no tomaba más que un par de ciclos de reloj. En el año 2005 a unprocesador Pentium 4 le tomaba más de 400 ciclos. Esto nos muestra clara-mente que la velocidad de los procesadores ha crecido mucho más allá de loque creció la velocidad de la memoria. Es para resolver este problema queaparecen las memorias cache, memorias de muy alta velocidad pero peque-ñas, en las que se almacenan los datos más frecuentemente utilizados y que secargan por adelantado. Este sistema es conocido en inglés como prefetching yestá encargado de almacenar información en la memoria cache según patronesde acceso frecuente. Viendo estos datos, se podría pensar que se han tomadomalas decisiones de diseño, ya que pasamos de unos pocos ciclos de reloj a400 en arquitecturas modernas para un acceso a memoria. Sin embargo, si unprograma posee un ciclo iterativo en el que se accede secuencialmente a unaporción de memoria y el procesador logra detectar el patrón de acceso parahacer la precarga de datos, es claro que la pérdida de rendimiento es notable-mente inferior. Existen casos en los que no es deseable dejar a interpretacióndel procesador el manejo de los datos que se cargan en caché, por lo queteniendo en cuenta ciertos parámetros de la arquitectura se puede diseñar elcódigo de manera tal que aproveche al máximo las capacidades disponibles.

11

12 CAPÍTULO 2. BREVE HISTORIA DE LOS CPU

2.2. Unidad de gestión de memoria

Como se verá posteriormente, en la descripción de los procesadores utiliza-dos, existen varios niveles de memoria caché con diversas funciones. Conocersobre estos aspectos de la arquitectura es necesario en aquellos casos en queel desarrollador esté diseñando un programa que se ejecute de manera óp-tima sobre la misma, caso contrario puede abstraerse de ellas. Sin embargoaún hay que tener un factor en cuenta, la necesidad de traducir direccioneslógicas a direcciones físicas y como este proceso funciona.

La unidad de gestión de memoria, conocida por sus siglas en inglés MMUcorrespondientes a memory management unit, es el dispositivo encargado deadministrar los accesos a memoria de parte del procesador. Las funciones deeste dispositivo incluyen, el control de caché, la traducción de las direccioneslógicas a direcciones físicas y la protección de la memoria, entre otras.

Cuando el procesador intenta acceder a una dirección de memoria lógica,la MMU hace una búsqueda en una tabla especial llamada TLB, por sussiglas en inglés Translation Lookaside Buffer, donde se almacenan los accesosmás recientes. Cuando la dirección solicitada se encuentra en la TLB, sutraducción a dirección física es enviada, este hecho es conocido como aciertode TLB o TLB hit. En caso que la dirección solicitada no se encuentre en laTLB, hecho conocido como fallo de TLB o TLB miss, el procesador realiza labúsqueda en la tabla de páginas del proceso, utilizando el número de páginabuscada como entrada a ella. En la entrada de la tabla de páginas del procesohay ubicado un bit de presencia que indica si la página buscada está alojadaen la memoria principal. Si dicho bit está activado, se carga esta entradaen la TLB y se devuelve la dirección física. Caso contrario, debe informarseal sistema operativo mediante un fallo de página. El sistema operativo es elencargado de ubicar en la memoria física la página solicitada, usando algunode los algoritmos de reemplazo de páginas.

Debido a que el primer nivel de la TLB debe ser extremadamente rápidose encuentra limitada en su tamaño, en las arquitecturas que se verán másadelante, constan de 64 entradas, mientras que arquitecturas posteriores co-mo Intel Broadwell [26] [2] constan de 128 entradas. Si se utilizan páginasde 4 kilobytes de tamaño, esto limita la cantidad de memoria que puede serdireccionada sin incurrir en un fallo de búsqueda. La arquitectura de x86también soporta tamaños de página mayores, de 2 Megabytes y 1 Gigabyte,de lo cual algunas aplicaciones pueden beneficiarse, sobre todo aquellas quenecesitan largos tiempos de ejecución y gran cantidad de memoria.

A su vez la memoria caché de primer nivel usualmente se encuentra li-mitada por los tamaños de página. Si el tamaño de la memoria cache esmuy pequeño los bits utilizados para la indexación dentro de la caché son

2.3. EJECUCIÓN FUERA DE ORDEN 13

los mismos, independientemente de estar mirando la dirección física o lógica.No es necesaria la traducción entre ambas. Si la cache es demasiado grande,debe hacerse primero una búsqueda en la TLB, que aumentará el costo, ocrear un índice virtual, lo cual es posible pero incrementa la complejidad delprograma.

2.3. Ejecución fuera de orden

Desde hace algunas décadas, los procesadores de arquitectura x86 han si-do capaces de ejecutar de una manera especulativa e incluso de reordenar laejecución para prevenir el bloqueo de la misma debido a la no disponibilidadde algún recurso. Esto puede resultar en un rendimiento dispar pero la arqui-tectura es estricta por lo que, para un solo núcleo y observando el estado dememoria y registros desde el exterior, debe verse todo como si la ejecuciónfuera en el orden original, caso contrario se vería alterada la semántica delprograma [13].

Esta restricción que hace ver que la ejecución se realiza en orden significaque, para la mayor parte, se puede ignorar la existencia de la ejecución fuerade orden a no ser que se esté intentando el mayor rendimiento posible delprocesador. Las mayores excepciones se dan cuando es necesario asegurar quela ejecución no solo aparenta haber sido realizada en el orden correspondiente,sino que efectivamente se ejecuta en ese orden.

Es importante notar que para que este tipo de ejecución sea posible, sedebe contar con un procesador que sea segmentado y superescalar ya queal detenerse la ejecución de instrucciones de un programa en un núcleo, laejecución del mismo está sujeta a la liberación de los recursos necesarios ydeberá ser llevada a cabo en otro núcleo. Para garantizar el resultado de lacomputación, hay una unidad dentro del procesador encargada de asegurarque la semántica del programa no sea alterada. Un procesador se llama seg-mentado cuando divide una tarea compleja en otras más simples, a fin deque la salida de una tarea sea la entrada de la siguiente y de esta manerapoder explotar en mejor medida el paralelismo dentro del procesador. Enconsonancia, un procesador superescalar es aquel capaz de realizar distintastareas sobre distintos datos en un mismo pulso de reloj.

2.4. Una instrucción, múltiples datos

En la actualidad la mayoría de los procesadores x86 tienen soporte parainstrucciones AVX, correspondiente a Advanced Vector Extensions, y SSE,

14 CAPÍTULO 2. BREVE HISTORIA DE LOS CPU

por sus siglas en ingles Streaming SIMD Extensions, en sus versiones 2, 3, 4,4.1 y 4.2, vectores de registros e instrucción de 128, 256 y 512 bits. En vista deque es común querer aplicar la misma operación sobre múltiples datos más deuna vez, tanto Intel como AMD agregaron instrucciones que permiten operarsobre porciones de datos de, por ejemplo, un bloque de 128 bits, o dos de 64bits, o 4 de 16 bits, etcétera. Es habitual obtener una aceleración que reduce eltiempo de ejecución a la mitad o a la cuarta parte del tiempo, utilizando estetipo de instrucciones. No hay que olvidar en este caso la ley de Ambdahl,que establece que un programa puede reducir su tiempo de ejecución entanto parte de ese programa pueda ser ejecutada en paralelo. La sección delprograma que no pueda ser paralelizada, se mantendrá ocupando la mismaporción de tiempo. Los compiladores tienen buenas capacidades al momentode analizar el código fuente y determinar que partes del código pueden serreemplazadas por instrucciones vectoriales, pero no siempre consiguen losmejores resultados. Es por este motivo que se recomienda hacer un análisis delcódigo assembly obtenido de la compilación y verificar que se estén utilizandodichas instrucciones. En caso de no lograr que el compilador reconozca dondeaplicar estas instrucciones, deberá ajustarse el código, de manera que puedaser capaz de identificarlo, ya que programar la vectorización a mano haríapoco portable el código.

Capítulo 3

Equipamiento utilizado

A continuación se presentará el equipamiento utilizado para este trabajoy sus características técnicas.

3.1. Nodo con procesadores IntelPara la comparación que se presenta en este trabajo, se utilizó un nodo

del cluster Mendieta perteneciente al CCAD-UNC [5]. Se trata de un servidormarca Dell modelo Poweredge R720, que en su interior cuenta con una placamadre Dell 0VWT90, dos procesadores Intel Xeon E5 2670 y 256 Gigabytesde memoria principal.

3.1.1. Procesador

El procesador Intel Xeon E5 2670 en su primera generación fue lanzadoen el primer trimestre del año 2012, forma parte de la familia de procesa-dores Sandy Bridge EP, consta de 8 núcleos, 16 hilos, una frecuencia basede 2.60 GHz, una frecuencia turbo de 3.30 GHz, 3 niveles de memoria cacheestructurados de la siguiente manera:

Cache L1

• 8 x 32 KB 8-vías conjunto asociativo de caché de instrucciones

• 8 x 32 KB 8-vías conjunto asociativo de caché de datos

Cache L2

• 8 x 256 KB 8-vías conjunto asociativo de caché

Cache L3

15

16 CAPÍTULO 3. EQUIPAMIENTO UTILIZADO

• 20 MB 20-vías conjunto asociativo de caché

Su consumo, trabajando a frecuencia base con carga plena es de 115Wsegún la hoja de datos del fabricante.

3.1.2. Diagrama de bloque

Figura 3.1: Representación de un núcleo Sandy Bridge [25]

Como puede verse en el diagrama 3.1, cada uno de los núcleos de esteprocesador cuenta con sus propias unidades de punto flotante, lo que aseguraen una primera instancia y mientras no se encienda el sistema de HyperTh-reading, que el uso del núcleo puede dedicarse de manera exclusiva a cálculo.El sistema de HyperThreading [29] [11] Intel exhibe un núcleo virtual ademásdel físico ya existente, por lo que el sistema operativo visualiza el doble deprocesadores de los que verdaderamente existen de manera física.

3.2. NODO CON PROCESADORES AMD 17

3.1.3. Memoria

El microprocesador instalado en este nodo es capaz de direccionar unmáximo de 384 GB de memoria de tipo DDR3 con velocidades de 800MHz,1066MHz, 1333MHz y 1600MHz, 4 canales de memoria con un ancho debanda máximo teórico de 51.2GB/s y código de corrección de errores (ECC).El nodo cuenta con un total de 24 conectores para memoria de los cuales 16 seencuentran ocupados con módulos de memoria DDR3 de 16GB de capacidady 1333MHz de velocidad. Los canales se encuentran balanceados en cantidadde memoria, garantizando que no se produzca saturación en ningún canal.

3.2. Nodo con procesadores AMDLa contraparte de esta comparación, fue realizada utilizando un equipo

perteneciente al Instituto de Astronomía Teórica y Experimental [4] cuyadescripción técnica se verá a continuación. Se trata de un servidor Supermi-cro AS-4022G-6F que consta de una placa madre Supermicro H8DGi, dosprocesadores AMD Opteron 6282SE y 256 Gigabytes de memoria principal.

3.2.1. Procesador

El procesador AMD Opteron 6282SE fue lanzado en el último trimestredel año 2011, consta de una microarquitectura Bulldozer de la plataformaMaranello, consta de 8 módulos, cada uno de los cuales cuenta con dos uni-dades de cálculo entero y una unidad de punto flotante de 256 bits, unafrecuencia base de 3.0GHz, una frecuencia turbo de 3.30 GHz, 3 niveles dememoria cache estructurados de la siguiente manera

Cache L1

• 8 x 64 KB 2-vías conjunto asociativo compartido de caché de ins-trucciones

• 16 x 16 KB 4-vías conjunto asociativo de caché de datos

Cache L2

• 8 x 2 MB 16-vías conjunto asociativo compartido exclusivo decaché

Cache L3

• 2 x 8 MB hasta 64-vías conjunto asociativo compartido de caché


Su consumo, trabajando a frecuencia base con carga plena es de 140W segúnla hoja de datos del fabricante.

3.2.2. Diagrama de bloque

Figura 3.2: Representación de módulo AMD Bulldozer [28]

Como puede verse en la figura 3.2, el módulo Bulldozer consta de dosunidades para cálculo entero y comparte una unidad de punto flotante de256 bits y el dispatcher. Este hecho supone que a pesar de contar en totalcon 32 núcleos para cálculo según muestra el sistema operativo, solo cuentacon 16 unidades de punto flotante.

3.2. NODO CON PROCESADORES AMD 19

3.2.3. Memoria

El microprocesador instalado en este nodo soporta memoria de tipo DDR3con velocidades de 1333MHz y 1600MHz, cuenta con 2 controladores de me-moria, cada uno con capacidad de manejar 2 canales, totalizando 4 canalesy un ancho de banda máximo teórico de 51.2GB/s y código de corrección deerrores (ECC). El nodo cuenta con un total de 16 conectores para memorialos cuales se encuentran ocupados con módulos de memoria DDR3 de 16GBde capacidad y 1600MHz de velocidad.

Capítulo 4

Caracterización

Con la finalidad de caracterizar el equipamiento que sería utilizado paralas ejecuciones de Gadget se realizaron cálculos teóricos de ancho de bandade memoria y potencia de cálculo. A su vez estos parámetros fueron medidosa fin de corroborar cuanto se correspondían los cálculos teóricos con el usoefectivo del equipo.

4.1. Potencia de cálculoLa potencia de cálculo es medida en cantidad de operaciones por segun-

do. Específicamente en este caso nos interesa la cantidad de operaciones depunto flotante por segundo, conocido por su acrónimo en inglés FLOPS co-rrespondiente a Floating point Operations Per Second, ya que también sepodría medir la cantidad de operaciones de números enteros.

Una forma muy habitual de medir la potencia de cálculo teórica es através de la siguiente ecuación:

FLOPS = fpus× ops/cycle× (vector width/64)× base clock frequency(4.1)

Siendo fpus la cantidad de unidades de punto flotante de doble precisión, 64bits, de las que dispone el procesador, ops/cycle es la cantidad de operacionesde punto flotante que es capaz de realizar por ciclo de reloj, (vector width /64) es la cantidad de valores de doble precisión con los que puede trabajaren simultáneo y base clock frequency es la frecuencia de base del procesador.Es importante resaltar que en este último parámetro se debe tener en cuentala frecuencia base y no la turbo o similares, ya que en principio el procesadorno es capaz de tener todos los núcleos trabajando a esa frecuencia.

Sin embargo en este caso la fórmula utilizada es otra, debido a dos facto-res. En el caso del procesador Intel, este cuenta con una unidad de suma y

21

22 CAPÍTULO 4. CARACTERIZACIÓN

otra de multiplicación, cada una en un puerto independiente, por lo que pue-de realizar una operación de suma y otra de multiplicación en paralelo. Por elotro lado, el procesador AMD, cuenta con capacidad de realizar operacionesde multiplicación y suma en un mismo pulso de reloj; sus siglas en inglésson FMA correspondientes a Fused Multiply-Add. Este tipo de operacionesresulta en extremo útil al momento de trabajar, por ejemplo con multiplica-ción de matrices. La fórmula que calcula la cantidad de operaciones de puntoflotante por segundo con este tipo de capacidades, es la siguiente:

FLOPS = fpus×ops FMA/cycle×(vector width/64)×base clock frequency(4.2)

En base a la descripción que vista anteriormente de cada uno de los pro-cesadores y teniendo en cuenta la ecuación 4.2 podemos calcular la potenciapico teórica en cada caso.

CPU fpus opsFMA/cycle vector w clock freq GFLOPSXeon E5 2670 8 2 256 2.6GHz 166.4

Opteron 6282SE 8 2 256 2.6GHz 166.4

Tabla 4.1: Potencia pico teórica para los procesadores utilizados

Por lo tanto, si se tiene en cuenta que cada nodo posee dos procesadoresy cada uno cuenta con una potencia de cálculo teórica igual al doble de lavista en la tabla 4.1, obtenemos como resultado la tabla 4.2.

Nodo fpus opsFMA/cycle vector w clock freq GFLOPSIntel 16 2 256 2.6GHz 332.8AMD 16 2 256 2.6GHz 332.8

Tabla 4.2: Potencia pico teórica para los nodos utilizados

4.2. DGEMMCon el objetivo de caracterizar el equipamiento utilizado, se realizaron

varias tareas; en primer lugar se realizó una prueba de cálculo denso, se tratade multiplicación de matrices de doble precisión de la forma

C = αA×B + βC (4.3)

siendo la matriz A de la forma m filas por k columnas, B de k filas por n co-lumnas y C de m filas por n columnas. El valor α es un escalar que multiplica

4.2. DGEMM 23

al resultado de A × B y β es otro escalar utilizado para multiplicar la matrizC. Para realizar la ejecución del código se le deben pasar tres parámetrosque corresponden al tamaño de las matrices que se desea multiplicar, ya quepara este caso, los valores α y β no serán tenidos en cuenta. El programa so-licita la cantidad de memoria correspondiente al tamaño de las matrices porel tamaño de un valor de doble precisión, almacena en las matrices valorespseudoaleatorios, y luego llama a la función de multiplicación de matrices,tomando previamente el tiempo de inicio. Una vez terminada la multiplica-ción, toma el tiempo de finalización y evalúa la diferencia entre tiempo finaly tiempo de inicio. Con este tiempo y la cantidad de operaciones de puntoflotante realizadas puede calcular la potencia utilizando la ecuación 4.2.

DGEMM es un acrónimo para Double-precision General Matrix Multiply,que en este caso se convierte en la función utilizada para multiplicar matri-ces. Para las pruebas realizadas en esta sección, se tomaron en cuenta todasmatrices cuadradas, es decir que lo valores m, k y n son iguales. La bibliotecautilizada para esta prueba fue OpenBLAS [30] compilada de manera especí-fica para la arquitectura de cada equipo utilizado. Se decidió la utilización deeste método ya que también se utiliza para caracterizar las computadoras dealto desempeño a través del uso de Linpack. En la actualidad la lista de las500 supercomputadoras más poderosas del mundo, conocida como TOP500[27], se arma a través de la ejecución de un código similar, denominado HPL[6].

4.2.1. DGEMM en AMD

El cálculo de DGEMM en el nodo AMD se realizó en dos modalidades.La primera, cuyos resultados podemos ver en la tabla 4.3, realizado con16 núcleos y fijando a través del administrador de trabajos la afinidad delos procesos con los diferentes procesadores, de manera que no existan dosprocesos dentro del mismo módulo y así poder destinar la total disponibilidadde la unidad de punto flotante al cálculo sin interrupciones.


Tamaño Tiempo total utilizado GFLOPS2048 0.083221 s 206.4364096 0.591606 s 232.3158192 4.710643 s 233.41016384 36.920581 s 238.24318432 57.239284 s 218.80220480 70.275109 s 244.46524576 168.516876 s 176.16532768 313.201853 s 224.675

Tabla 4.3: Potencia de cálculo para el nodo AMD con 16 núcleos

Como puede verse, los resultados obtenidos se encuentran lejos de alcan-zar los valores teóricos vistos en la tabla 4.2 ya que el valor más próximo alteórico, solo llega al 73.45%.

Es por esto, que se decide realizar una nueva evaluación del nodo, estavez con los 16 módulos y los 32 núcleos. Previo realizar la prueba es ne-cesario compilar nuevamente la biblioteca OpenBLAS a fin de que utiliceeficientemente toda la capacidad del nodo.


Tabla 4.4: Potencia de cálculo para el nodo AMD con 32 núcleos

Aquí puede verse una leve mejora en los resultados obtenidos, alcanzandoun 84.58% del pico teórico calculado.

4.2.2. DGEMM en Intel

Al igual que para el nodo con arquitectura AMD, también se utilizarondistintos tamaños de matrices en el cálculo de DGEMM. Los resultados semuestran en la tabla 4.5

4.2. DGEMM 25

Figura 4.1: Porcentaje de FLOPS obtenido por cada nodo


Tabla 4.5: Potencia de cálculo para el nodo Intel

Como queda expuesto en la tabla, el mejor tiempo es obtenido para unamatriz de 8192 elementos de lado alcanzando el 94% de la capacidad teóricacalculada previamente.

En el gráfico 4.1 se puede ver la comparación de los valores obtenidos enla ejecución de DGEMM en todos los nodos y porcentaje respecto del picoteórico obtenido por cada uno. Se puede notar que cuando incrementamos eltamaño de la matriz el desempeño en AMD mejora. Lo contrario ocurre conIntel, acabando en un desempeño similar. Esto puede deberse a la diferenciaen el tamaño de la memoria caché de cada procesador.


4.3. Ancho de banda de memoriaPara ambos equipos utilizados, también se realizaron mediciones de ancho

de banda de memoria. En la ecuación 4.4 se puede observar como es calculadade manera teórica dicha magnitud.

BW = channels× 8 (64bits)× F (4.4)

En la fórmula, channels hace referencia a la cantidad de canales de memoriacon los que se cuenta y F es la frecuencia a la que trabaja la memoria.En la tabla 4.6 se pueden ver los valores teóricos calculados para ambosprocesadores.

CPU Cant. canales Frec. memoria BW teóricoXeon E5 2670 4 1333MHz 42.6GB/s

Opteron 6282SE 2 × 2 1600MHz 51.2GB/s

Tabla 4.6: Ancho de banda teórico por CPU

Las pruebas se realizaron en ambos equipos, cada uno de los cuales cuentacon dos procesadores de los antes descriptos y distintas configuraciones dememoria como muestra la tabla 4.7:

Equipo Cant. canales Frec. memoria BW teóricoNodo Intel 8 1333MHz 85.2GB/sNodo AMD 8 1600MHz 102.4GB/s

Tabla 4.7: Ancho de banda teórico por nodo

4.4. STREAMEste código [14] [15] un test sintético utilizado ampliamente para medir

el ancho de banda efectivo en MB/s y la correspondiente tasa de cómputopara vectores. La motivación original para el desarrollo de este código con-sistió en que la velocidad de los procesadores fue en constante ascenso enlas últimas décadas, sin embargo la velocidad de acceso a memoria no crecióal mismo ritmo y la brecha entre ambos se hizo cada vez más grande. Conel aumento de esta brecha, cada vez mayor cantidad de programas vieronralentizada su ejecución. Este código ha sido específicamente diseñado pa-ra poder ser ejecutado de manera que los datos utilizados no entren en lamemoria caché obligando al sistema a buscar datos en la memoria princi-pal, por lo que los resultados obtenidos son, un indicativo del rendimiento

4.4. STREAM 27

Function Best Rate GB/sgcc icc

Copy 23.6252 32.3689Scale 28.0051 40.6936Add 27.5941 38.9338Triad 27.9189 35.1233

Tabla 4.8: stream en AMD con 16 núcleos y 16.000.000 elementos gcc e icc

de la memoria. Se realizan cuatro pruebas, en primer lugar copy que midela capacidad de transferencia en ausencia de operaciones aritméticas, scaleagrega operaciones aritméticas simples, sum agrega un tercer operando parapoder medir procesadores con múltiples puertos de carga y almacenamiento,load/store, triad realiza la prueba para operaciones de suma y multiplicaciónencadenada, solapada o conjunta chained/overlapped/fused. Todos los resul-tados mostrados por stream corresponden a valores de 64 bits y cabe resaltarque se valoran las operaciones de lectura y escritura. Las compilaciones delcódigo para esta prueba se hicieron inicialmente con el compilador GCC ver-sión 5.3.0. Luego se agregaron pruebas con el compilador icc de la suite Intel2016 [21].

4.4.1. STREAM en AMD

Como se vió previamente en la tabla 4.7 el ancho de banda de memoriateórico para este nodo es de 102.4GB/s. Se probaron distintas formas deejecución para tratar de alcanzar ese límite. En el primer caso se ejecutó conun arreglo de 16.000.000 elementos y se compiló con gcc.

Como puede verse en la tabla 4.8 los resultados obtenidos con gcc estánmuy por debajo del límite teórico, alcanzando sólo un 27.34% del mismo,por lo que se procedió a realizar la compilación con icc de la suite Intel conla misma cantidad de elementos y las banderas correspondientes para ajustede código a la plataforma.

Se observa una mejora en el resultado obtenido, aunque sigue estandomuy lejos del resultado esperado. Ante estos valores, y teniendo en cuenta laarquitectura de módulos del procesador, se decidió hacer la misma ejecucióncon los dos compiladores utilizados anteriormente, pero en este caso con 32núcleos y la misma cantidad de elementos.

Nuevamente, los valores obtenidos están muy por debajo de lo esperadoy no registran diferencia con los obtenidos al ejecutar en 16 núcleos.

Aquí se obtiene una leve mejora respecto de los valores anteriores, siendo


Function Best Rate GB/sgcc icc


Tabla 4.9: stream en AMD con 32 núcleos y 16.000.000 elementos gcc e icc

los mejores valores obtenidos hasta el momento para esta plataforma con un41.89% del ancho de banda teórico. Como se verá a continuación en el gráfico4.2, hay una leve mejora en la medida cuando se utiliza el compilador icc,pero sigue siendo muy por debajo del límite teórico. Sin embargo no deja deser llamativo, el hecho de que en una arquitectura AMD el compilador deIntel exhiba mejores resultados.

Figura 4.2: Comparación de ancho de banda obtenido en nodo AMD

Todo este análisis logró demostrar que el manejo de memoria en esteprocesador no es el óptimo y la ejecución de programas con gran necesidadde acceso a memoria se vería seriamente afectada.

4.4. STREAM 29

4.4.2. STREAM en Intel

Para este nodo el ancho de banda teórico es un poco menor ya que la velo-cidad de las memorias que tiene instaladas es un poco más baja, alcanzandoun pico teórico de 85.2GB/s. Como ocurrió con el otro nodo, se realizaronlas pruebas con los dos compiladores disponibles.

Function Best Rate MB/sgcc icc


Tabla 4.10: stream en Intel con 16 núcleos y 20.000.000 elementos gcc e icc

Para el caso de gcc puede notarse que se alcanzó más de la mitad del valorteórico. La cantidad de elementos difiere ya que debió ser ajustada al tamañode memoria caché del procesador. En la prueba realizada con icc puede versecomo se logró obtener un valor incluso más cercano al teórico, alcanzandoun 78.83% del mismo. En base a estas mediciones y por lo anteriormenteexplicado de Gadget, que se trata de un problema ligado fuertemente a lamemoria, podemos plantear la hipótesis de que el mismo experimento deberíatardar más tiempo en el nodo con procesadores AMD que en aquel que poseeprocesadores Intel.

En la figura 4.3 puede verse la comparación de la ejecución de STREAMsobre el nodo con procesador Intel con compiladores gcc e icc.


Figura 4.3: Comparación de ancho de banda obtenido en nodo Intel

En el gráfico 4.4 se puede observar la comparación de todos los valoresobtenidos. Resulta notable a simple vista el mejor ancho de banda que pre-senta el nodo Intel sobre el AMD a pesar de contar con memorias con menorfrecuencia de trabajo.

Figura 4.4: Comparación de ancho de banda obtenido en ambos nodos

Capítulo 5

Ejecuciones realizadas

En este capitulo se expondrán las distintas ejecuciones realizadas del có-digo GADGET. Aquí se podrá ver la utilización de distintos parámetros decompilación, tanto para Gadget como para las bibliotecas y resultados obte-nidos en cada caso y sus comparaciones. Ademas del código de Gadget y susdependencias, se utilizó el administrador de trabajos llamado SLURM [20] alcual se le indicó según correspondiera, instrucciones específicas como puedenser el uso exclusivo del nodo o la afinidad de un determinado proceso a unnúcleo.

5.1. Descripción de la simulación

Para este trabajo, se decidió simular un cubo cosmológico periódico de250 megapársecs1 y una resolución de 5123 partículas. Con esta configuraciónse puede resolver halos de materia oscura de 30 kilopársecs donde se alber-gan las galaxias. Debido a que la finalidad del presente trabajo es compararel desempeño del código en casos concretos de uso ejecutado sobre las dis-tintas arquitecturas antes descriptas, se decidió solo trabajar con el módulode gravedad a través de la interacción de partículas de materia oscura. Estadecisión también tuvo que ver con poder realizar las ejecuciones en tiemposacotados, caso contrario cada ejecución se podría tomar semanas. La reso-lución y tamaños elegidos permiten medir el desempeño del código en dosregímenes que el algoritmo calcula el potencial de gravedad en gran escalaa través de la transformada de Fourier y en escalas pequeñas a través delmétodo de árbol. La integración de la evolución de un cubo cosmológico re-quiere tener en cuenta la expansión del universo, esto se verá manifestadoen diferentes regímenes a los largo de la simulación. Al comenzar, la distri-

1El pársec es una unidad de medida de distancia equivalente a 3.2616 años luz.

31

32 CAPÍTULO 5. EJECUCIONES REALIZADAS

bución de fuerzas es homogénea prácticamente en su totalidad, por lo quela integración a gran escala será la que más tiempo de cómputo consuma.En la medida que el sistema evolucione en el tiempo, se formarán diferentesestructuras cosmológicas como vacíos, filamentos y halos, entre otros. Con laaparición de estas estructuras, la evolución de las partículas se desacopla dela expansión del universo y comienzan a tener mayor importancia las interac-ciones entre partículas a pequeña escala, por lo que el algoritmo de árbol serámás requerido y siendo este último el que al final de la simulación definirá ladinámica de las mismas.

En la figura 5.1, puede verse el logaritmo de la densidad de materia oscura,para un corte del cubo perpendicular al eje z, donde se puede apreciar lahomogeneidad en la distribución inicial de las partículas (factor de expansióndel universo igual a 0.05). A continuación, en la figura 5.2, se puede observarla estructura del universo en gran escala y la menor homogeneidad de ladistribución de las partículas al final de la simulación.

Figura 5.1: Distribución de las partículas al iniciar la simulación

5.2. DEPENDENCIAS 33

Figura 5.2: Distribución de las partículas al finalizar la simulación

5.2. Dependencias

Las dependencias de Gadget para este tipo de ejecuciones son pocas,pero es importante ver que cada una de ellas esté correctamente configurada.Para empezar, se decidió utilizar el compilador GNU GCC 5.3.0 [9] últimodisponible al momento de comenzar con las ejecuciones para este trabajo ycapaz de crear código óptimo para ambas arquitecturas.

Luego fue necesaria la instalación de una interfaz de paso de mensajes, enadelante MPI por sus siglas en inglés Message Passing Interface; se optó porMPICH [18] versión 3.2. Esta decisión tuvo que ver con pruebas realizadas conOpenMPI [24], pero se notó un comportamiento extraño, donde se lanzabamás de un hilo por proceso, el cual no resultó fácil de resolver; teniendo encuenta que las ejecuciones se hicieron dentro de un nodo, los administradoresde proceso de ambos tienen un desempeño similar y no hubo necesidad decomunicaciones externas, por lo cual MPICH resultó la opción más acertada.

La siguiente dependencia es FFTW [7], por sus siglas en inglés FastestFourier Transform in the West, encargada de realizar la transformada de


Fourier dentro del código. En este caso se utilizó la versión 2.1.5. Esto sedebe a que las nuevas versiones, de la 3 en adelante, se volvieron incompati-bles con las anteriores. En las nuevas versiones hubo importantes cambios desemántica que responden a cuestiones de mejoras en el rendimiento, dichasmejoras no pueden emular de manera eficiente la interfaz anterior. Debido aque hasta este momento no hay versiones estables de Gadget que utilicen lanueva versión de FFTW, las ejecuciones de este trabajo debieron ser realiza-das con una versión desactualizada. A su vez, FFTW tiene como dependenciaMPI.

Finalmente queda la biblioteca GSL [17], GNU Scientific Library, de lacual se utilizó la versión 2.1. Al revisar el código y ver que influencia podríatener GSL en la óptima ejecución del programa, nos encontramos que sólose utilizaban constantes numéricas de la misma, por lo que las banderas conlas que fuera compilada, no afectarían a la ejecución.

En todos los casos, las bibliotecas fueron compiladas con las banderas-O3 -march=sandybridge -mtune=sandybridge para la arquitectura Intely -O3 -march=bdver1 -mtune=bdver1 para la arquitectura AMD. Con estaconfiguración inicial se midieron los primeros valores que se tomaron comopatrones.

Para tener otro parámetro de comparación, también se realizaron prue-bas con compiladores de Intel, al igual que se realizó previamente con lacaracterización del equipamiento disponible. A tal fin también debieron sercompiladas las bibliotecas. Para el caso patrón del compilador de Intel seutilizaron las banderas -O3 -xHost -ip.

5.3. Ejecución patrón

Para ambas arquitecturas se tomó una ejecución patrón que, como se men-cionó antes, se realizó compilando con GCC 5.3.0 y las bibliotecas necesarias.También el código de Gadget fue compilado utilizando las mismas banderasde compilación. La ejecución se realizó en ambos casos con 16 núcleos, enel caso Intel son todos los disponibles, en el caso AMD se dio instruccionesal administrador de trabajos para que mantuviera los procesos ligados a unprocesador y que ejecutara este trabajo de manera exclusiva, es decir que apesar de haber recursos disponibles, no permitiera el ingreso de otros traba-jos al nodo. En el gráfico que veremos a continuación, se puede observar lacomparación de los resultados obtenidos.

5.3. EJECUCIÓN PATRÓN 35

Figura 5.3: Tiempo total utilizado en cada arquitectura

Este gráfico muestra el porcentaje de avance de la simulación versus eltiempo acumulado, en horas, hasta ese momento. Desde un comienzo resultanotoria la diferencia en el tiempo de ejecución en ambas arquitecturas aiguales condiciones de trabajo.

Figura 5.4: Tiempo total utilizado en cada arquitectura y el speedup

Aquí puede verse la comparación de la ejecución en ambas arquitecturas,compilando con gcc y las optimizaciones antes mencionadas, mostrando en


el eje x el tiempo utilizado expresado en horas, en el eje y el porcentaje depasos realizados. En verde se puede ver la división de los tiempos, en este casoAMD dividido por los tiempos de Intel, para obtener que cantidad de vecesmás rápido ha sido el cálculo, dicho valor puede verse en el eje x superior

En vista de estos dos resultados, se decidió revisar cuanto tiempo de laejecución se estaba asignando a cada una de las tareas del código.

Figura 5.5: Tiempo total utilizado en cada arquitectura por etapa

Aquí puede verse que la mayor parte del tiempo en cada uno de los pa-sos se dedicó a recorrer el árbol en memoria. Acorde a lo propuesto por elroofline model [19], el algoritmo de Gadget queda ubicado a la izquierda,con una baja intensidad computacional, es decir que se realiza poca cantidadde operaciones por cada byte leído de memoria y además hay una alta tasade acceso a memoria. Este es el primer resultado que comienza a explicarel gráfico 5.3, ya que como se vió previamente en la caracterización de cadanodo, el sistema AMD no tiene un manejo óptimo del acceso a la memoriaprincipal.

Una vez obtenidos estos valores que serían utilizados como patrones, sedecidió hacer otras ejecuciones con algunas variaciones, tanto en los compi-ladores utilizados, las banderas utilizadas para la compilación del código deGadget y las bibliotecas.

5.4. EJECUCIÓN SIN OPTIMIZACIONES 37

5.4. Ejecución sin optimizaciones

La primera pregunta que surgió fue, qué tanto podría variar el tiempo deejecución si la compilación del código se realizara con la bandera -O0 y deesta manera poder obtener la aceleración que se estaba adquiriendo.

Figura 5.6: Tiempo de ejecución para la arquitectura Intel sin optimizaciones

Es claro que en el caso de Intel, la ganancia no ha sido sorprendente. Comopuede observarse, la mayor parte de la diferencia entre ambas ejecuciones,ocurre en la primera etapa, donde se utiliza el cálculo con FFTW. Para estaejecución también fue compilada con la bandera -O0, por lo que el cálculotarda un poco más de tiempo.

Figura 5.7: Tiempo de ejecución para la arquitectura AMD sin optimizaciones


Sin embargo, en el caso de AMD, es en extremo notoria la diferencia; enprimer lugar la simulación no logró ser terminada luego de 7 días de ejecución,alcanzado el paso número 382 de un total de 2788, mientras que en el casopatrón la ejecución completa se realizó en poco más de 5 días.

5.5. Cambio de compiladoresAnte la disponibilidad de otra suite de herramientas para realizar la com-

pilación del código, en este caso la suite de compiladores de Intel, se decidióutilizarla a fin de observar que mejoras se obtenían. Para poder llevar el ex-perimento adelante, nuevamente fue necesario compilar Gadget y todas susdependencias con las banderas correspondientes. En el gráfico 5.8 puedenverse los resultados obtenidos en la ejecución en el nodo Intel.

Figura 5.8: Tiempo de ejecución para la arquitectura Intel con distintos com-piladores

Si bien puede observarse una mejora en el tiempo, lo cual era esperableteniendo en cuenta los resultados obtenidos con STREAM en la sección decaracterización, la mejora obtenida es en torno al 6% lo cual dista de lamedida anteriormente, que era en promedio del 30%.

Por otro lado la misma prueba se realizó en el nodo AMD, donde debióser nuevamente compilado Gadget y sus dependencias, en este caso siguien-do la guía de optimizaciones provista por AMD [1] para esta arquitectura.Lamentablemente, en este caso no fue posible obtener resultados concretosdebido a que la ejecución fue lanzada en repetidas ocasiones sin conseguir

5.6. CAMBIO DE HARDWARE 39

que ninguna de ellas llegara a terminar de manera correcta, en algunos casospor cortes de suministro eléctrico y en otros por una excesiva extensión enel tiempo de ejecución. De los tiempo parciales observados, puede notarseun tremendo incremento en el tiempo de ejecución. Investigando sobre estetema, se puede observar que el compilador icc realiza una comprobación delprocesador sobre el cual está realizando la compilación. Al detectar que nose trata de un procesador Intel, desactiva todas las optimizaciones y generaun archivo binario muy general, motivo por el cual el código se ejecutó demanera similar a la realizada con el compilador gcc sin optimizaciones.

5.6. Cambio de hardwareEn vista de los resultados obtenidos, teniendo en cuenta la disponibilidad

de mayor cantidad de núcleos, aunque no de unidades de punto flotante ybuscando reducir el tiempo total de espera por parte del usuario, se decidióhacer la ejecución de código con las mismas banderas de la prueba patrón,pero esta vez ejecutando sobre el total de unidades de cómputo disponiblesen el nodo. El gráfico 5.9 ilustra los resultados.

Figura 5.9: Tiempo de ejecución para la arquitectura AMD con 16 y 32núcleos

Como puede verse de manera muy clara, se consigue una notable mejoradel 60%. Aunque no se consigue una mejora del 100% como se esperaría


habitualmente al incrementar al doble la cantidad de núcleos en un códigoque ha sido largamente probado y se sabe que para esta pequeña cantidadde núcleos escala de manera lineal.

Este comportamiento hace suponer que, la unidad de punto flotante decada módulo tienen alta latencia, por lo que es importante mantenerla siem-pre con trabajo pendiente, a fin de poder esconder de alguna manera dichalatencia.

Ante este resultado se decide compilar nuevamente el código de Gadget,agregando a las banderas de compilación, -mprefer-avx128. Este cambio sehace, esperando que al utilizarse la mitad del ancho del vector, este sea capazde computar mayor cantidad de elementos por unidad de tiempo. Sin embargoel resultado obtenido no refleja ese comportamiento, sino que mantiene elmismo que al utilizar el ancho de vector de 256 bits.

Este caso es un poco más llamativo, ya que con el doble de núcleos nose obtiene una mejora en el tiempo de ejecución, sino que por el contrario,puede verse como la arquitectura Intel se mantiene por debajo de AMD en eltiempo de ejecución, a pesar de reducirse la brecha que existía entre ambos.

Para realizar una experiencia similar en el nodo Intel, se decidió encenderel sistema de HyperThreading. El gráfico 5.10 muestra los resultados.

Figura 5.10: Tiempo de ejecución para la arquitectura Intel HT y sin HT

Se puede observar que se obtiene una mejora. Sin embargo, al igual queocurrió con el nodo AMD, no se obtiene una reducción equivalente a la canti-dad de núcleos en los que se ejecuta. Aunque puede ser un dato de utilidad al

5.7. EJECUCIONES EN SIMULTÁNEO 41

realizar una simulación de grandes dimensiones, ya que a pesar de tener unaganancia baja en términos de aceleración, resulta una ganancia muy acepta-ble en términos de tiempo, teniendo en cuenta que en este caso la ejecucióndemoró 9 horas menos.

En el gráfico 5.11 se puede ver un concepto que optamos por llamarspeedup instantáneo, consiste en agrupar los tiempos en grupos de 17 valoresy sacar el promedio de cada uno, luego se divide el tiempo para obtener lacomparación de speedup.

Figura 5.11: Diferencias de velocidad entre distintas ejecuciones

Resulta interesante analizar este gráfico al poder observarse la diferenciaentre arquitectura y compiladores. Se obtiene una mejora notable en el usodel compilador gcc sobre arquitectura Intel respecto de AMD. Así mismo,también es de resaltar que no hay gran diferencia, sobre arquitectura Intel,en el uso de distintos compiladores, lo que quiere decir, que al menos en laejecución, no tendría gran sentido invertir en la compra del compilador deIntel.

5.7. Ejecuciones en simultáneoUn interrogante que surgió de medir el desempeño de los distintos equi-

pos, tanto de manera específica como a través de la ejecución de Gadget yteniendo presente cuanto tiempo ocupa cada sección del código, fue crono-metrar la ejecución en simultáneo de dos instancias de Gadget. En el gráfico5.12 pueden verse comparados el tiempo de una sola instancia de Gadget, la


que denominamos ejecución patrón, y el tiempo de dos instancias de Gadgettrabajando en el mismo nodo. Queda a la vista que el tiempo no se duplica,

Figura 5.12: Ejecución de dos instancias simultáneas de Gadget en nodo Intel

solo tarda un 77% más, lo que casualmente coincide casi de manera exactacon el desbalanceo informado por Gadget del 25.3%. La diferencia de tiempoentre ambas ejecuciones corriendo en simultáneo es de 20 segundos, tenien-do en cuenta que el tiempo total es de 133 horas, esta diferencia resultainsignificante.

5.8. Resumen de ejecuciones

En la tabla 5.1 podemos ver un resumen de todas las ejecuciones realiza-das.

El tiempo total indicado en la entrada de la tabla señalado con AMD*debió ser estimado, ya que dichas ejecuciones no consiguieron ser finalizadaspor cuestiones de suministro eléctrico. La entrada indicada como AMD32hace referencia a la ejecución realizada con los todos los núcleos del nodo.Para el caso de la arquitectura AMD, donde esta indicado -march -mtune co-rresponde a -march=bdver1 -mtune=bdver1; para el caso de la arquitecturaIntel corresponde a -march=sandybridge -mtune=sandybridge.

5.9. DISCUSIONES 43

Arquitectura Compilador Banderas Tiempo SpeedupIntel gcc -march -mtune -O3 75.16 1AMD gcc -march -mtune -O3 138.52 1.842Intel icc -xHost -ipo -O3 70.12 0.932Intel gcc -O0 78.01 1.037AMD* gcc -O0 275.00 3.658AMD 32 gcc -march -mtune -O3 83.95 1.117Intel HT gcc -march -mtune -O3 65.89 0.876

AMD* Superpuesto gcc -march -mtune -O3 163.66 2.177Intel Superpuesto gcc -march -mtune -O3 133.05 1.770

Tabla 5.1: Resumen todas las ejecuciones realizadas

5.9. Discusiones

La principal discusión surgida durante la elaboración de este trabajo tie-ne que ver con el aprovechamiento del ancho de banda de memoria, cuellode botella en todas las ejecuciones. Teniendo en cuenta que el recorrido delárbol es la principal tarea que realiza el código y se lleva el 70% del tiempode ejecución, termina siendo una barrera muy importante que debe ser te-nida en cuenta al momento de elegir el nuevo equipamiento a ser adquirido.Este parámetro no debe ser solo aplicado a Gadget sino a cualquier tipo deaplicación que, al igual que Gadget, esté altamente ligado a memoria.

Por otro lado también resulta de importancia analizar el impacto del des-balanceo de carga en la ejecución del código, que se encuentra alrededor del25%. Como pudo verse en las ejecuciones realizadas, a mayor es la carga quese genera sobre el nodo, menor es tiempo que tarda el mismo en terminarla ejecución, contrario a lo que uno esperaría, por ejemplo, en un programaque tiene alta demanda de procesador, conocido en inglés como cpu-bound.Este comportamiento pudo verse al ejecutar el código de Gadget sobre los 32núcleos disponibles del nodo AMD y al utilizar el nodo Intel con HyperThrea-ding, el cual quedó evidenciado en la ejecución que se realizó superponiendodos simulaciones en simultáneo sobre el mismo nodo. En este punto resultanotable que las mediciones que se hicieron con DGEMM y STREAM, dondese vio que el desempeño se incrementa al exigir en mayor medida al equipocon arquietectura AMD. Esto puede deberse a que, utilizando todos los re-cursos disponibles, se obtiene una mejora en el uso de los canales de memoriao de los controladores de la misma, ya que como se describió previamente,esta arquitectura cuenta con dos controladores y dos canales por cada con-trolador en cada procesador. A pesar de esto, el peor desempeño medido en


la arquitectura Intel siempre resulta superior a la arquitectura AMD.Igualmente importante resultó, sobre todo en el caso del nodo AMD,

tener en cuenta utilizar la banderas de compilación adecuadas al momentode generar el binario, como pueden ser -march=bdver1 -mtune=bdver1 enel caso de estar utilizando el compilador gcc. También en este punto pudoverse, hecho que resulta notable en los gráficos que ilustran la ejecución, loimportante de utilizar dichas banderas en la compilación de dependencias,caso contrario, por más que el código pueda ser optimizado su ejecución severá afectada en desempeño por las funciones externas que el código utiliza.Ejemplos de esto pueden verse en la compilación de OpenBLAS, donde unode los parámetros específicos indica la cantidad total de núcleos sobre losque se utilizará. En casos como puede ser FFTW, debe analizarse el tipode procesos a ejecutar y configurar la misma con -mprefer-avx128 segúncorresponda.

Adicionalmente se hicieron análisis de la ejecución con la herramientaperf determinando cuales eran las funciones más frecuentemente utilizadas.Una vez identificadas, se realizó un examen del código assembly obtenido através de gcc y se pudo determinar que no se estaban utilizando instruc-ciones AVX o SSE. Se probaron algunos cambios sobre el código para versi se observaban cambios, pero el resultado fue siempre negativo, lo que lle-va a pensar que posiblemente ciertas partes del código original, deban serreescritas para aprovechar las unidades vectoriales.

Capítulo 6

Conclusiones

De este trabajo de desprenden varias conclusiones. En primer lugar pudoobservarse que los equipos con arquitectura Intel tienen un mejor manejo dememoria respecto de los AMD, sobre todo para casos como el de Gadget, querealizan grandes recorridos de estructuras de árbol en memoria y no hacengran aprovechamiento de la memoria cache.

También es necesario resaltar la importancia de las banderas que se lepasan a los compiladores, no solo al momento de construir el binario deGadget, sino también cuando se compilan las dependencias necesarias parael mismo, debido a que un bajo desempeño en, por ejemplo FFTW, afectaráa la ejecución completa del código.

De la misma manera hay que tener en cuenta, en el caso de querer utilizarel compilador icc de la suite Intel sobre una plataforma AMD, es necesariorevisar la documentación provista por el fabricante del procesador, para queel binario obtenido resulte correctamente compilado aprovechando todas lasfunciones disponibles en la arquitectura y no un binario general que terminaráen un aumento del tiempo total de ejecución.

En relación a este punto, también cabe resaltar que las compilaciones rea-lizadas con icc no dieron una marcada aceleración al momento de ejecutarlo.En base a este resultado podría cuestionarse si siempre es verdaderamentenecesario desembolsar el costo de las licencias de la suite Intel. Según losresultados de este trabajo, puede decirse que no.

Otro ítem a tener en cuenta es la vectorización, en el caso de Gadget serealizaron algunos análisis del código assembly que producen los compiladoresy pudo observarse que no son capaces de vectorizar de manera automática,por lo que en algún momento debe plantearse la necesidad de escribir nueva-mente el código con éstas mejoras de manera manual o modificar lo necesariodel código actual para que vectorice automáticamente. De la misma maneraresulta notable la necesidad de prestar especial atención en la función de des-

45

46 CAPÍTULO 6. CONCLUSIONES

composición de dominio, ya que, como se vió en la presentación del código,el resultado de la misma tiene un impacto directo en la distribución de cargasobre los procesadores y la evolución de la misma a lo largo de la ejecución.Es recomendable, al momento de ejecutar el código en una nueva máquina,prestar especial atención al parámetro de desbalanceo o imbalance en inglés,para poder realizar los ajustes necesarios.

Por otro lado la carga de los procesadores mostró funcionar diferente enambos casos. El caso de AMD fue uno de los resultados que más resaltó,ya que mejoró el desempeño del mismo al utilizar el módulo completo y noutilizando la mitad del mismo para tener total disponibilidad de la unidad depunto flotante. Casi por el contrario en el caso de Intel al activar el sistemade HyperThreading, si bien mejoró levemente el desempeño, no se logró unadiferencia tan notable. En ambos casos, usando todos los núcleos AMD outilizando el sistema de HyperThreadng de Intel hay que resaltar que pudoreducirse el tiempo de ejecución, como pudo verse en la sección de ejecuciones.

En las proyecciones a futuro, se deben abordar varios aspectos. Uno delos principales, al momento de adquirir nuevo equipamiento, se debe tener encuenta cuando se los elija que los mismos tengan el mayor ancho de bandaposible en memoria, no solo en los microprocesadores, sino tener en cuentala cobertura total de los canales de memoria disponibles en la placa madre.Por otro lado, los nuevos procesadores cuentan cada vez con más y mejorasconjuntos de instrucciones vectoriales, lo que el código de Gadget debería seradecuado a dichas instrucciones. En el momento que la tercera versión deGadget sea liberada, debe ser evaluada respecto de su desbalanceo y funciónde descomposición de dominio, para evaluar si es necesario encender el siste-ma de HyperThreading a fin de reducir el tiempo total de ejecución. Comocomplemento a estos puntos también es necesario resaltar la necesidad deutilizar compiladores actualizados, que estén en capacidad de utilizar de lamejor manera posible los recursos del equipamiento utilizado.

Resulta de interés analizar en profundidad algunos aspectos del programacon herramientas como likwid1 o perf2 en busca de posibles cuellos de botellao deficiencias en la ejecución. Este trabajo podría ser continuado en un futuro,ya que escapa a los objetivos originalmente planteados en esta tesis.

1https://github.com/RRZE-HPC/likwid2https://perf.wiki.kernel.org/index.php/Main_Page

Bibliografía

[1] AMD. Compiler options quick reference guide.http://developer.amd.com/wordpress/media/2012/10/CompilerOptQuickRef-62004200.pdf.

[2] Anandtech.com. Intel broadwell architecture.https://www.anandtech.com/show/8355/intel-broadwell-architecture-preview/2.

[3] J. Barnes and P. Hut. A hierarchical O(N log N) force-calculation algo-rithm. Nature, 324:446–449, December 1986.

[4] Instituto de Astronomía Teórica y Experimental CONICET. IATE -Cluster Mirta. http://iate.oac.uncor.edu.

[5] Universidad Nacional de Córdoba. CCAD - Cluster Mendieta.http://ccad.unc.edu.ar/.

[6] Jack Dongarra. What’s HPL? http://www.netlib.org/utk/people/JackDongarra/faq-linpack.html#_What_is_HPL?

[7] Matteo Frigo and Steve G. Johnson. FFTW Fastest Fourier Transformin the west. http://www.fftw.org.

[8] Max Planck Gesellschaft. Max-Planck Institut für Astrophysik.http://www.mpa-garching.mpg.de/.

[9] GNU Project. GCC Compiler Collection. https://gcc.gnu.org.

[10] Smithsonian Institution Harvard University. Harvard-Smithsonian Cen-ter for Astrophysics. https://www.cfa.harvard.edu/.

[11] Intel. Intel hyper-threading technology.https://www.intel.com/content/www/us/en/architecture-and-technology/hyper-threading/hyper-threading-technology.html.

47

48 BIBLIOGRAFÍA

[12] Tandred Lindholm. N-body algorithms.http://www.cs.hut.fi/ ctl/NBody.pdf.

[13] Dan Luu. New cpu features. https://danluu.com/new-cpu-features/,Enero 2015.

[14] John D. McCalpin. Stream: Sustainable memory bandwidth in highperformance computers. Technical report, University of Virginia, Char-lottesville, Virginia, 1991-2007. A continually updated technical report.http://www.cs.virginia.edu/stream/.

[15] John D. McCalpin. Memory bandwidth and machine balance in cu-rrent high performance computers. IEEE Computer Society TechnicalCommittee on Computer Architecture (TCCA) Newsletter, pages 19–25,December 1995.

[16] Giuseppe Peano and David Hilbert. Peano-Hilbert filling curve.https://en.wikipedia.org/wiki/Space-filling_curve.

[17] GNU Project. Gnu scientific library. https://www.gnu.org/software/gsl.

[18] MPICH Project. High-performance portable mpi.http://http://www.mpich.org.

[19] David Patterson Samuel Williams, Andrew Waterman. Roofline: aninsightful visual performance model for multicore architectures. Com-munications of the ACM - A Direct Path to Dependable Software, pages65–76, april 2009.

[20] SchedMD. SLURM. https://slurm.schedmd.com.

[21] Intel Software. Parallel Studio XE. https://software.intel.com/en-us/parallel-studio-xe.

[22] Volker Springel. Gadget-2. http://wwwmpa.mpa-garching.mpg.de/gadget/.

[23] Volker Springel. Summer school on cosmological numerical simulations.http://www.aip.de/summerschool2006/lectures/volker/monday.pdf.

[24] Open MPI Team. A high performance message passing library.https://www.open-mpi.org/.

[25] techpowerup.com. Intel sandy bridge (microarchitecture).https://www.techpowerup.com/forums/attachments/sb_pipeline-jpg.47843/.

BIBLIOGRAFÍA 49

[26] Techreport.com. Intel broadwell architecture.https://techreport.com/review/26896/intel-broadwell-processor-revealed/3.

[27] top500 List. top500 list. https://www.top500.org.

[28] wikipedia.org. Amd bulldozer (microarchitecture).https://en.wikipedia.org/wiki/Bulldozer_(microarchitecture).

[29] wikipedia.org. Intel hyper-threading technology.https://en.wikipedia.org/wiki/Hyper-threading.

[30] Zhang Xianyi. OpenBLAS. https://github.com/xianyi/OpenBLAS.

50 BIBLIOGRAFÍA

Los abajo firmantes, miembros del tribunal de evaluación de tesis, damosfe que el presente ejemplar impreso se corresponde con el aprobado por estetribunal

Comparación de arquitectura AMD e Intel para ejecución de ...

Documents

Transcript of Comparación de arquitectura AMD e Intel para ejecución de ...