Arquitectura de Sistemas Paralelos 1

Transcripción

1 Arquitectura de Sistemas Paralelos 1 Tema 1 INTRODUCCIÓN A LA ARQUITECTURA DE COMPUTADORES Y ANÁLISIS DE PRESTACIONES Daniel Cascado Caballero Alejandro Linares Barranco Francisco Gómez Rodríguez Saturnino Vicente Díaz Dpto de Arquitectura y Tecnología de Computadores Universidad de Sevilla 1

2 Definición de Arquitectura (I) Según H&P hay 3 niveles independientes de Arquitectura: 1. Organización Alto nivel, memoria, buses, bloques de la CPU S.O. Software 2. Lenguaje Máquina o Ensamblador Repertorio de instrucciones visto por el programador. Frontera entre el Soft y el Hard Compilador 3. Implementación Diseño lógico detallado y tecnología de encapsulamiento, microelectrónica. 3

3 Definición de Arquitectura (II) Mucha gente piensa que la Arquitectura de computadores es igual al diseño de repertorio de instrucciones (L.M.) y el resto es implementación ERROR Las mayores o menores prestaciones del diseño de un L.M. dependerán de: un conocimiento exhaustivo del hardware, de la organización, y de una correcta implementación 4

4 Definición de Arquitectura (III) Ejemplos CISC (Computador de repertorio complejo de instrucciones) L.M. con instrucciones complejas (acercamos mucho el L.M. al lenguaje de alto nivel) Compiladores muy sencillos Hardware complejo Menos frecuencia de reloj RISC (Computador de repertorio reducido de instrucciones, posteriormente, instrucciones sencillas) L.M. con instrucciones muy simples Compiladores más complejos a priori pero más flexibles Hardware sencillo y rápido Mayor frecuencia de reloj 5

5 Términos de la Arquitectura de Computadores Entrada/Salida y almacenamiento Discos magnéticos, Cintas, CD, DVD, etc. RAID DRAM Memoria entrelazada, protocolos de bus Jerarquía de memoria VLSI Caché L2 Caché L1 Arq. conjunto de instrucciones Segmentación, dependencias, Superescalar, Reordenación, predicción, especulación, Vectorial Coherencia, ancho de banda, latencia Direccionamiento, Protección, Manejo de excepciones Segmentación y paralelismo a nivel de instrucciones 6

6 Evolución de la tecnología e influencia de la arquitectura (I) 7

7 Evolución de la tecnología e influencia de la arquitectura (II) Límites de la ley de Moore (2 postulados) 1: Densidad de datos x2 cada 18 meses. 2: Nº de transistores x2 cada año. Aumento en la escala de integración: Aumento de la densidad de transistores y de su velocidad Velocidad proporcional a la longitud de la puerta Retardos en la transmisión de la señal Incremento considerable de la resistencia Mantenimiento de la capacidad Retraso de las líneas proporcional al producto R*C Menor espacio recorrido por la señal en un ciclo No muy significativo para microarquitecturas actuales Dimensiones del circuito se reducen cuadráticamente Problema: Complicación del hardware para incrementar el IPC. (Ej. P4 usa 2 etapas para propagar la señal) Incremento en prestaciones: Pasar del 50%-60% anual al 12%-17% anual Cuidado con consumo y disipación de potencia + nº transistores => mayor consumo => problemas de refrigeración. Intel paso de los 135W del p4 a los 65W del core 2 duo. 8

8 Evolución de la tecnología e influencia de la arquitectura (III) Avance en el diseño de la arquitectura Han influido menos en el rendimiento Mejoras tecnológicas garantizan un gran incremento en prestaciones Las empresas invierten más en tecnología que en diseño de arquitecturas nuevas Es difícil innovar rápidamente en un campo con tanto negocio. El introducir un cambio en la arquitectura supone un riesgo Por ejemplo, la compatibilidad software es crucial para que una empresa sobreviva 9

9 Evolución de la tecnología e influencia de la arquitectura (IV) Existe realimentación entre Tecnología, Arquitectura y Software. Por ejemplo: En los 60 s, la memoria y la potencia era poca Se programaba en lenguaje máquina La programación era una tarea compleja, luego se intentan diseñar arquitecturas con L.M. complejo, similar a un lenguaje de alto nivel Hardware complejo Existieron intentos de hacer esto, pero fracasaron porque la naturaleza de los circuitos es digital y no algorítmica Posteriormente se desarrollan los compiladores abandono de la programación en código máquina Ya no tiene sentido un L.M. complejo, podemos construir nuestra arquitectura con instrucciones de L.M. muy sencillas Se simplifica el hardware, lo cual nos permite usar técnicas avanzadas para explotar el paralelismo Explosión del rendimiento 10

10 Interacción Tecnología-Mercado- Aplicaciones-Arquitectura Posibilidades Promueve Capacidades Prestaciones Tecnología Arquitectura Aplicaciones Posibilidades Selección Restricciones Posibilidades Demanda Restricciones Mercado Generación Fundamental Fuerte Visible 11

11 Introducción al paralelismo (I) Tradicionalmente, la computadora ha sido vista como una máquina secuencial La mayor parte de los lenguajes de programación requiere que el programador especifique algoritmos como secuencias de instrucciones Las CPU s ejecutan programas ejecutando instrucciones de código máquina en una secuencia, una a la vez Cada instrucción es ejecutada en una secuencia de operaciones (búsqueda de instrucción, búsqueda de operandos, ejecución de la operación y almacenamiento de resultados) 12

12 Introducción al paralelismo (II) Ejecución secuencial Instr. 1 Instr. 2 Instr. 3 Instr. 4 Encadenamiento de instrucciones de código máquina (segmentación, pipelining) Dividimos la ejecución de las intrucciones en P etapas, lo cual nos permite la ejecución en cadena Inst. 1 Inst. 2 Inst. 3 Inst. 4 P Instrucciones en el aire (P=4) 13

13 Introducción al paralelismo (III) Paralelismo a nivel de instrucciones (ILP) El procesador puede ejecutar varias instrucciones a la vez Se puede combinar (y de hecho se hace) con el encadenamiento Inst. 1 ALU Inst. 2 Inst. 3 Acc. mem Salto Ventana de V instrucciones (V=3) Inst. 4 Inst. 5 Inst. 6 Tendremos V*P instrucciones en el aire (P=4 = nº de etapas) Tendremos V*P instrucciones en el aire, donde P es el número de etapas en las que hemos dividido las instrucciones (P=4) 14

14 Introducción al paralelismo (IV) Multiprocesamiento. Ejecución paralela de distintos fragmentos de un mismo programa en distintos procesadores La posibilidad de paralelismo puede provenir de: Paralelismo disponible en instrucciones. Es hacer la misma operación sobre muchos datos (p.e. multiplicar 2 vectores). Típico en programas científicos (vectoriales) y de transacciones (p.e. bancos, comercios, comunicaciones, etc.) Paralelismo disponible en datos. Mucho más difícil y sutil, pero mucho más interesante porque afecta a todo tipo de programas Procesador 1 Procesador 2 Procesador 3 V P 15

15 Evaluación de prestaciones (I) Cómo medir el rendimiento de una máquina? Cómo comparar máquinas de naturaleza muy distinta y con un proceso para obtener el ejecutable tan diferente? Del análisis cuantitativo extraeremos que: Aunque parezca una obviedad lo de la máquina más rápida, no es tan fácil medirlo La adopción de una aprox. cuantitativa (en lugar de cualitativa) llevó a conclusiones sobre el funcionamiento (comportamiento del soft y el hard) que permite conocer como incrementar el rendimiento 16

16 Evaluación de prestaciones (II) Máq A Máq B Prog P1 1 2 Prog P2 2 1 Máq A Máq B Prog P Prog P2 2 1 Máq A Máq B Prog P Prog P2 2 1 Aritmét Geom. (0.2) 1/2 (0.2) 1/2 Media aritmética: iguales Pero si B considera que P1 se usa la mitad que P2: Peso(P1)=1/3, Peso(P2)=2/3 Viceversa: P2 peso doble. Media geométrica más robusta Pero favorece valores distantes (falla ante optimización de un único programa) Soluciones: Media aritm. con pesos realistas Media geom. vigilando que no haya valores dispares 17

17 Evaluación de prestaciones (III) Del análisis del código objeto (comportamientos no intuitivos): Ley de localidad de referencia (espacial y temporal) 10%/90% para código Para datos es peor Mejorar jerarquía de memoria Saltos tomados entre 60-70%, pero la mayoría de los saltos o se toman siempre o no se toman nunca. Luego hay que intentar descubrirlo lo antes posible, lo cual supondría una gran aceleración (BTB) El número de instrucciones que se pueden ejecutar en paralelo de un código generado por un compilador es de 2 ó 3 (para un código normal). Tendremos que intentar optimizar el código generado para aumentar el grado de paralelismo (hasta 40 ó 50 para otros estudios) (Planificación estática y dinámica) 18

18 Rendimiento, productividad y coste (I) Definiciones Productividad: Cantidad de tareas que pueden realizar en un segundo No lo utilizaremos casi nunca Duplicar el número de máquinas duplicar la productividad pero la tarea dura lo mismo Rendimiento: Tiempo que tarda en realizar una tarea Rendimient o t ejecución 1 1 programa El rendimiento no es fácil de aumentar 19

19 Rendimiento, productividad y coste (II) Pero nosotros para comparar dos máquinas, siempre hablaremos de aceleración. De forma que diremos la máquina x es n% más rápida que la máquina y, lo cual significa: Máq más lenta Ejemplo: t t ejecución, ejecución, y x 1 n 100, siendo n 0 t t ejecución, ejecución, y x ms ms ms ms 1 n 100 n 100 % 20

20 Aceleración parcial: Ley de Amdahl (I) Sirve para calcular la aceleración obtenida de la mejora de un determinado aspecto de la máquina o del software Ejemplo: Si consigo aumentar la velocidad de ejecución de un tipo de instrucciones (p.e. saltos) en el doble, no quiere decir que se acelere la ejecución del programa en el doble Si podemos extraer con exactitud la parte o porcentaje mejorado (F), se puede calcular fácilmente la aceleración total en función de F y de la Aceleración parcial 21

21 Aceleración parcial: Ley de Amdahl (II) t ejec. inicial 1-F F t ejec. inicial 1 (lo normalizam os) 0 F 1 1-F F A parcial t ejec. final 1- F A F parcial t ejec. final A total t t ejec. ejec. inicial final 1- F 1 A F parcial 22

22 Aceleración parcial: Ley de Amdahl (III) Ejemplo: Sup. que consigo paralelizar el 50% de un programa, de forma que se pueden ejecutar en 10 procesadores a la vez obteniendo una aceleración parcial de 10. Cuál sería la aceleración total? 10*0.5 = 5 : NO A total 1-0,5 1 0, ,55 1,81 81 % Podemos observar que no llega al doble la aceleración total obtenida y también que por muchos procesadores que añadamos la aceleración no pasará de 2 Si F 0,5; lim A p A 2 100% 23

23 Aceleración parcial: Ley de Amdahl (IV) Conclusión Hacer rápido el caso común Por ejemplo, en un programa: Hay que optimizar la parte del programa donde se pasa más tiempo (10%/90%) Optimizar el código inicial o el código de salida de errores es perder el tiempo Hay que atacar a los bucles de muchas iteraciones Un sólo ciclo ganado en un bucle de una matriz gráfica de una ventana supondrá 640 x 480 = ciclos (1 ciclo por pixel) 24

24 Componentes del tiempo de ejecución de un programa (I) CPU ciclos Ciclos de reloj de CPU por programa t ejecución CPU ciclos Periodo del ciclo de reloj CPU Frecuencia ciclos del reloj CPI Nº CPU ciclos Inst ruccio nes Núm de instr dinámico (que se ejecutan) t ejecución Nº Inst ruccio nes CPI Periodo del ciclo de reloj inst r. Programa ciclos inst r. segundos ciclos segundos Programa 25

25 Componentes del tiempo de ejecución de un programa (II) Periodo del ciclo de reloj (T) Depende de la tecnología hardware y de la implementación (en cada ciclo hay que hacer más cosas) CPI Depende de la implementación y del conjunto de instrucciones (RISC vs. CISC) Nº Instrucciones Depende del conjunto de instrucciones y de los compiladores Ej. (1990) VAX 8700 (CISC) t ejec = N * (6*CPI) * (1.5*T) = 9*N*CPI*T MIPS 2000 (RISC) t ejec = (2*N) * CPI * T = 2*N*CPI*T 26

26 Componentes del tiempo de ejecución de un programa (III) Las expresiones anteriores se pueden detallar más CPU CPI N i i ciclos n i 1 CPI i N i Duración media de la instrucció n i (en ciclos) Número de veces que la instrucció n i se ejecuta en el programa CPI programa n i 1 CPI N Nº inst. i i n i 1 CPI i Nº N i inst Nº N i inst Fracción que cada instrucció n aparece en el programa A t t ejec, ejec, Máq Máq 1 2 Nº Nº Instr Instr 1 2 CPI CPI 1 2 T T

27 Medidas de prestaciones (I) El tiempo de ejecución depende del programa Se buscó una medida independiente de programa MIP S t Nº ejecución inst CPI ( MHz Nos encontramos con los siguientes problemas: Los MIPS dependen de la longitud de las instrucciones varían entre programas en el mismo computador pueden variar inversamente al rendimiento Ejemplo: Procesador con coprocesador para ejecutar operaciones en punto flotante MIPS pico aún peor En definitiva es un camelo y sólo sirven para máquinas totalmente compatibles 1 T 10 6 f CPI ) 28

28 Medidas de prestaciones (II) Otra posible medida indep. de programa son los MFLOPS, cuya diferencia con los MIPS es que sólo consideramos las operaciones en punto flotante Nº inst. F.P. MFLOP S 6 t ejecución 10 Muy usado para máquinas de cálculo científico Elimina el problema de la variación inversa al rendimiento, pero existen problemas adicionales Es dependiente de los programas No todas las operaciones F.P. son iguales en duración (se definió MFLOPs normalizados) Los microprocesadores suelen tener varias unidades F.P., luego el orden de llegada de instrucciones influye en el T ejec. 29

29 Medidas de prestaciones (III) En resumen Una buena medida debe ser reproducible Debe estar claro para que cualquiera pueda repetir la prueba y obtener lo mismo Debemos de especificar Programa Compilador con sus optimizaciones Datos de entrada al programa Con esto, aunque la magnitud no sea perfecta, puede ser válida para estudiar un aspecto concreto 30

30 Programas para la evaluación de prestaciones (benchmarks) (I) Los benchmarks son programas modelo que sirven para evaluar el rendimiento de una arquitectura Tenemos 5 tipos de benchmarks (De mayor a menor precisión) Aplicaciones reales Procesadores de texto, compiladores, herramientas CAD, etc Problemas Dependen mucho de los datos de entrada Suelen ser complejos de usar Los S.O. sobre los que se prueban suelen ser incompatibles No son ni estándar, ni de libre distribución Aplicaciones modificadas Usamos aplicaciones reales modificadas o le añadimos scripts para que interactue con la aplicación Podemos centrarnos en aspectos concretos del sistema Por ejemplo, para evaluar las prestaciones de una CPU, podemos utilizar una aplicación a la cual le eliminamos la parte de I/O 31

31 Programas para la evaluación de prestaciones (benchmarks) (II) Núcleos (Kernels) Pequeños extractos de programas reales que intentan aislar prestaciones de determinados aspectos Estos núcleos sólo existen para la evaluación de prestaciones y no tiene utilidad para el usuario Ejemplos, Livermore Loops y Linpack Problemas Sólo trata algunos aspectos y se quedan antiguos No son reales Benchmarks de juguete Programas sencillos ( líneas), típicos de quien empieza a aprender un lenguaje Lo que menos importa es el resultado (que ya se conoce), ya que lo que nos importa son las prestaciones Ejemplos, Quicksort, criba de Eratóstenes (cálculo de nº primos) Benchmarks sintéticos Similares a los Kernels, intentan determinar la frecuencia media de operaciones y operandos de un gran conjunto de programas No son partes de programas y determinan el perfil medio de ejecución Dhrystone, carga entera, sin F.P. típica en proc. de texto, base de datos, etc. Whetstone: programas científicos. Tiene pocos búcles y llamadas dentro 32

32 Programas para la evaluación de prestaciones (benchmarks) (III) Ventajas de los Benchmarks de juguete Son estándar Fáciles de teclear y probar en cualquier máquina Tardan poco en ejecutarse Esto genera un problema son tan pequeños que un compilador puede optimizarlo con técnicas no aplicables a programas reales, incluso hay compiladores con opciones para optimizar benchmarks específicos (incluso hardware) Un compilador que optimiza puede eliminar el 25% del código (para algunos benchmarks de juguete) Bucles que sólo se ejecutan 1 vez, llamadas CALL, etc. En 1996 Intel dio datos de rendimiento del Pentium para un programa SPEC usando un compilador propio. Alguien no creyó en un valor tan bueno y revisó el binario: el compilador había producido código erróneo 33

33 Programas para la evaluación de prestaciones (benchmarks) (IV) SPEC (System Performance Evaluation Cooperative) Conjunto de programas para medir prestaciones Surge a finales de los 80 debido a la falta de estandarización de los programas reales Se ponen de acuerdo en usarlo la mayoría de fabricantes (Digital, Sun, MIPS, HP, etc) Se definen reglas de uso: compilador, opciones, entradas, etc. Se define rendimiento base (reglas estrictas) y optimizado Con esto se diluyen los inconvenientes de un programa específico La evolución de los SPEC (orientados a CPU) ha sido: Primera versión 1989: 10 programas produciendo un simple número Segunda versión 1992 SPECInt92 (6 programas enteros): gcc, compress, espresso, etc. SPECfp92 (14 programas F.P.): spice2g6, programas de astrofísica, partículas, procesamiento de señales, etc. Máquina de referencia: VAX-11/780 34

34 Programas para la evaluación de prestaciones (benchmarks) (V) Tercera versión 1995 SPECint95 (8 programas enteros) SPECfp95 (10 programas F.P.) Cuarta versión 2000, SPEC CPU2000 CINT2000 (11 programas enteros) CFP2000 (14 programas F.P.) Benchmark crack! Aprox. la mitad de los programas de una versión, se quitan en la siguiente Hoy: SPEC para gráficos, transacciones (I/O), servidores. Para PC bajo Windows: Winstone. Para sistemas empotrados tenemos EEMBC (EDN Embedded Microprocesssor Benchmark Consortium), con conjuntos diferentes para 5 tipos de industria Aquí interesa casi siempre el rendimiento/watio 35