Arquitecturas y Computación de Alto Rendimiento SISTEMAS PARA COMPUTACIÓN DE ALTO RENDIMIENTO 1 Índice 1. Necesidades de cómputo. Exascale. Arquitecturas de altas prestaciones. Top 500. Green 500 2. Memoria compartida 1. soporte para programación paralela 2. coherencia de cachés: repaso y directorios 3. modelo de coherencia de memoria (introd.) 3. Memoria distribuida, clusters y cloud 4. Coprocesadores (GPUs y MIC) 2 Page 1
Soporte para programación paralela SPP 1. Memoria compartida 2. Programación 1. Comunicación 2. Sincronización 1. Tipos 2. Historia 3. Componentes 4. Implementación 1. locks 2. barriers 3 SPP: Memoria Compartida Definición: En un MP de Memoria Compartida (Shared-Memory MP) cualquier procesador puede acceder a cualquier posición de memoria Ventajas: La ubicación es transparente Su modelo de programación natural es similar al que se usa en los sistemas monoprocesadores con time-sharing: Pero los procesos se pueden ejecutar en procesadores diferentes Implican habitualmente una mejora del throughput 4 Page 2
SPP: Memoria Compartida Uso habitual: 1. como servidores 2. y para programación paralela: Permiten compartición de grano lo fino que se quiera La comunicación (acceso convencional ) y la sincronización (acceso atómico ) es siempre a través de variables compartidas Modelo load/store: no necesarios nuevos mecanismos en la arquitectura de los procesadores Automatización del movimiento de datos (cachés) y de la gestión de su coherencia 5 Comunicación: SPP: Programación Implícita a través de variables compartidas: Cómo se implementa paso de mensajes, p.ej. MPI, sobre un MP de Memoria Compartida? Sincronización: Tipos: Exclusión mutua: LOCKS (cerrojos) Sincronización de eventos: Barriers 6 Page 3
SPP: Sincronización Ejemplos: oibm 370: compare&swap atómico para multiprogramación ointel x86: cualquier instrucción de acceso a memoria puede llevar el prefijo LOCK (acceso atómico) olos SPARC (muy RISC): operaciones atómicas registromemoria: swap, compare&swap omips, PowerPC, Alpha: RISCs: no accesos atómicos sino pareja de instrucciones i load-locked/store- l d/ conditional oen general, mucho debate y discusión: qué implementar en el Hw, cómo implementarlo, etc. 7 SPP: Sincronización DECISIONES: Velocidad vs. flexibilidad Qué implementar en Hw: normalmente, sólo operaciones atómicas Sw - Hw: los mecanismos suministrados por el Hw determinan lo que los algoritmos pueden usar a la hora de diseñar el Hw se tiene en cuenta lo que el Sw demanda Evaluación: como siempre, con programas de prueba 8 Page 4
SPP: Sincronización: locks LOCKs: primera versión: lock: ld.r1, /dir_cerrojo cmp.r1, #0 bnz $lock st #1, /dir_cerrojo ret unlock: st #0, /dir_cerrojo ret 9 SPP: Sincronización: locks LOCKs: segunda versión: con test&set (t&s) lock: t&s.r1, /dir_cerrojo bnz $lock ret unlock: st #0, /dir cerrojo ret consideraciones de rendimiento: tráfico, invalidaciones, hambruna,... variaciones: t&s con backoff, test&test&set 10 Page 5
11 SPP: Sincronización: locks Test and Test and Set: A: while (LOAD(/dir_cerrojo) = 1) do nothing; if (TEST&SET(/dir_cerrojo) = 0) { región crítica; } else goto A; o, mejor: repeat while (LOAD(/dir_cerrojo) = 1) do nothing; until (TEST&SET(/dir_cerrojo) = 0)) + : hace el spin en la caché : sigue habiendo mucho tráfico si hay muchos procesos ejecutando el t&s SPP: Sincronización: locks Test and Set con backoff: Cuando hay fallo, tarda un poco antes de reintentarlo: retardo constante retardo exponencial + : mucho menos tráfico : el retardo exponencial puede producir hambruna en caso de mucha contención : los recién llegados, menos espera: y sin embargo, el retardo exponencial produce los mejores resultados en la práctica 12 Page 6
SPP: Sincronización: locks tercera versión: load-locked + store-conditional (RISCs) ll: lee la variable en un registro sc: intenta almacenar la variable en la posición de Memoria si y sólo si ningún otro procesador ha escrito en la variable desde que ejecutó ll: si hay éxito, entre ll y sc, todo atómico lock: ll.r1, /dir_cerrojo /* LL dir a R1* / bnz.r1, $lock /* cerrado? */ sc #1, /dir_cerrojo /* SC 1 en dir */ beqz $lock /* si fallo, again*/ ret unlock: st #0, /dir_cerrojo ret otras versiones: ticket lock, array-based queing: ambas logran FIFO 13 cuarta versión: SPP: Sincronización: locks Ejercicio : implemente un cerrojo (su acquire ) suponiendo que la arquitectura suministra la instrucción: lock.exchange.ri, /dir Supóngase que el flag Z se pone a 1 si se devuelve en valor cero en.ri Discusión!... 14 Page 7
SPP: Sincronización: locks Quinta versión: [exa de mayo 2013 de ACAR (6 créditos)] Véase la documentación en http://heather.cs.ucdavis.edu/~matloff/50/pln/lock.pdf. 8. [2 puntos] Utilice la instrucción ió atómica LOCK.CMPXCHG (Compare and Exchange) de la arquitectura IA32 para realizar la programación de la adquisición de un cerrojo mediante spin-lock. Procure reducir en lo posible el número de escrituras. Nota: aunque trabajamos esta instrucción en clase, a continuación se encuentra un fragmento de lo que dice sobre ella el manual de IA32: Compares the value in the EAX register with the first operand (destination operand). If the two values are equal, the second operand (source operand) is loaded into the destination operand. Otherwise, the destination operand is loaded into the EAX register. [ ] Flags affected: The ZF flag is set if the values in the destination operand and register AL, AX, or EAX are equal; otherwise it is cleared 15 SPP: Sincronización: barrier barriers: Qué es un barrier? Herramienta de programación Se utiliza para la sincronización i ió de procesos Características Permite poner una barrera (detener la ejecución) de n 1 procesos en un punto determinado del código, y hacer que continúen cuando llegue el proceso n a la barrera Se pueden, y suelen, implementar en Sw utilizando locks, contadores en memoria compartida y flags 16 Page 8
SPP: Sincronización: barrier Estructura de datos clásica de una barrera: struct bar_type { int counter; struct lock_type lock; int flag = 0; } bar_name; /*Contador*/ /*Cerrojo*/ /*Bandera*/ 17 SPP: Sincronización: barrier primera versión: barrier centralizado Counter conserva el número de procesos que ha llegado a la barrera. Se incrementa su valor cada vez que llega uno (con lock), y comprueba si ha llegado a numprocs BARRIER (bar_name, p) { LOCK(bar_name.lock); if (bar_name.counter == 0) bar_name.flag = 0; /* El primero baja la bandera*/ mycount = bar_name.counter++; /* mycount es privada */ UNLOCK(bar_name.lock); if (mycount == p) { /* El último que llega */ bar_name.counter = 0; /* inicia el contador para la siguiente barrera*/ bar_name.flag = 1; /* Libera los procesos */ } else while (bar_name.flag == 0) {}; /* Espera activa*/ } 18 Page 9
SPP: Sincronización: barrier Posibles problemas de esta implementación?: dos barriers seguidos de la misma barrera --típico en bucles--?... operaciones BARRIER ( bar1, p ) ; /*Uno que queda no llega ver el flag a 1...*/... operaciones BARRIER ( bar1, p ) ; /*El primero que llega pone el flag a 0*/ La solución necesitaría que ningún proceso entrase en una nueva instancia de la barrera hasta que no existiese garantía de que todos han salido de la instancia anterior: cómo hacerlo?... 19 SPP: Sincronización: barrier segunda versión: barrier centralizado 2 Cambio de sentido: Idea: No dar valor explícito a la bandera: en vez de poner un 1 o un 0 siempre para bajar o subir la bandera, se van alternando su valor Un solo banderazo (cambio de sentido) cada vez que están todos. BARRIER (bar_name, p) { local_sense =!(local_sense); /* Cambio de sentido privado*/ LOCK(bar_name.lock); mycount = bar_name.counter++; /* mycount es privada */ if (bar_name.counter == p) /*El último que llega */ UNLOCK(bar_name.lock); /* inicia contador para bar_name.counter = 0; la siguiente barrera*/ bar_name.flag = local_sense; /* Libera los procesos*/ else { UNLOCK(bar ( name.lock); while (bar_name.flag!= local_sense) {}; }/*Espera activa*/ } Rendimiento: 1) latencia; 2) tráfico; 3) memoria; 4) equidad (fairness); 5) contención 20 Page 10
21 SPP: Sincronización Ejemplo: lock en Alpha // El estado que se devuelve en R0 es: // 0 - fallo (spinlock a 0; sigue a 0, falla store-conditional) // 1 - éxito (spinlock a 0; puesto a 1) // 2 - fallo (spinlock a 1; sigue a 1, falla store-conditional) // 3 - fallo (spinlock a 1; sigue a 1) #define BASIC_SPINLOCK_ACQUIRE (spinlock_address){ long status = 0; While (1) { if (*(spinlock_address) == 0) { status = TEST_AND_SET (spinlock_address); if (status == 1) { MB; break; } } } } SPP: Sincronización Ejemplo: lock en Alpha #define TEST_AND_SET (spinlock_address) asm ( ldl_l $0, ($16); or $0,1,$1; stl_c $1, ($16); sll $0, 1, $0; or $0, $1, $0; (spinlock_address)); 22 Page 11
SPP: Sincronización Ejemplo: lock en Alpha LDL_L Ra.wq, disp.ab(rb.ab) Operación: va {Rbv + SEXT (disp) } CASE big_endian_data: va Little_endian_data: va va ENDCASE Lock_flag 1 Locked_physical_address PHYSICAL_ADDRESS (va) Ra SEXT ((va ) <31:0>) 23 SPP: Sincronización Ejemplo: lock en Alpha STL_C Ra.mx, disp.ab(rb.ab) Operación: va {Rbv + SEXT (disp)} CASE Big_endian_data: va z va XOR 1002 Little_endian_data: va va ENDCASE IF (lock_flag k = 1) THEN (va ) <31:0> Rav<31:0> Ra lock_flag Lock_flag 0 24 Page 12
SPP: Sincronización Ejemplo: lock en Alpha Casos Cerrojo abierto - acierto en stl_c - fallo en stl_c Cerrojo cerrado - acierto en stl_c - fallo en stl_c 25 Índice 1. Necesidades de cómputo. Exascale. Arquitecturas de altas prestaciones. Top 500. Green 500 2. Memoria compartida 1. soporte para programación paralela 2. coherencia de cachés: repaso y directorios 3. modelo de coherencia de memoria (introd.) 3. Memoria distribuida, clusters y cloud 4. Coprocesadores (GPUs y MIC) 26 Page 13
Coherencia de cachés 1. Uso de cachés privadas 2. El problema de coherencia de cachés (PCC) 3. Posibles soluciones al PCC 4. Políticas para mantener la coherencia 1. Invalidación 2. Actualización 3. Consideraciones de rendimiento 4. Decisiones de diseño 5. Variaciones 27 Coherencia de cachés Justificación del uso de cachés privadas: reducen el tiempo medio de acceso (uso monoprocesador ) reducen la demanda de ancho de banda en la red de interconexión Problema: existencia de datos compartidos modificables (shared writable data) copias de una misma variable en diferentes cachés la escritura de un procesador en su copia no se hace visible a los demás que también tienen copia: accederán a valores no actualizados (stale t l data) ) conocido como el Problema de Coherencia de Cachés (PCC) se necesita realizar alguna acción para solucionar este problema 28 Page 14
PCC: posibles soluciones Copiar en la caché cualquier bloque: todo cacheable funcionamiento monoprocesador : se lleva a la caché cualquier bloque que se necesite: independiente de su semántica coherencia mantenida por Hw: circuitería añadida que garantiza que no se acceda a una copia no actualizada de un bloque políticas:» Invalidación (I)» Actualización (A) implementaciones:» MP basados en buses: snoopy» MP escalables : directorios 29 PCC: políticas Políticas para mantener la coherencia son independientes de su implementación A) Invalidación (I): Write-Invalidate cuando un procesador modifica su copia de un bloque, se señalan como no válidas (inválidas) el resto de las copias existentes B) Actualización (A): Write-Update/Broadcast Ídem, se actualiza con la modificación el resto de las copias existentes 30 Page 15
PCC: políticas: I vs. A... Store Invalidación Px Py Pk... Actualización Px Py Pk... Variación: write-once (Goodman, 1983) 31 PCC: políticas: rendimiento Nomenclatura: P: tasa de fallos monoprocesador: el bloque no está presente en la caché F: tasa de fallos total I: tasa de fallos por invalidación (invalidation misses): el bloque está presente en la caché pero en estado no-válido T: tráfico extra debido al mecanismo de coherencia Bq: tamaño del bloque C: tamaño (capacidad) de la caché 32 Page 16
PCC: políticas: rendimiento Rendimiento Invalidación Actualización a) Tasa de fallos b) Tráfico añadido F = P + I * F = P T I = T invalidar + T fallos por invalidación * reducido por write-once 33 T A >> T I ** Dependerá de la frecuencia de los fallos por Invalidación PCC: políticas: decisiones de diseño Invalidación Decisiones de diseño Actualización a) Tamaño del bloque (Bq) Bq falsa compartición extremo: 1 solo bloque b) Tamaño de la caché (C) C t de vida bloques nº actualizaciones extremo: C = M 34 Page 17
PCC: políticas: I ó A? I ó A? Depende del comportamiento del programa: extremos: grano fino compartición secuencial Peros : la vida real 1) No comportamiento extremo 2) Cada bloque puede tener un comportamiento distinto 3) Y encima éste puede cambiar dinámicamente 35 PCC: grano fino vs. secuencial Maneras de compartir un bloque grano fino secuencial Px Py Pz............... 36 Page 18
PCC: grano fino vs. secuencial grano fino I rping-pong: ej. lock A a secuencial I a A r act. inútiles 37 PCC: políticas: variaciones Variaciones: tratan de paliar defectos Invalidación: 1. (write-once: por defecto, siempre) 2. read-broadcast: reduce a un fallo global por invalidación: particularmente adecuado para 1 escritor y varios lectores Actualización: 1. Difundir escrituras sólo si el bloque está realmente compartido: línea común adicional de shared 2. Aunque esté presente en otras cachés puede no ser útil: envejecimiento de los bloques: ej. competitive snooping: cuando todos las copias están envejecidas ( criterio?: símil del esquiador novel) invalidar y no difundir más escrituras 38 Page 19
PCC: read-broadcast Px Py Pz Pk... Load Sin read-broadcast Px Py Pz Pk... fallo por invalidación Con read-broadcast Px Py Pz Pk... 39 PCC: políticas: vida real Vida real: Hay máquinas que permiten ambas políticas de coherencia La mayoría de las arquitecturas implementa Invalidación: p.ej., muy popular el MESI (p.ej., Pentium) No suelen implementar sólo Actualización: Mucho tráfico en general Situación peor: varias escrituras por un procesador antes de la lectura por otro: varias operaciones de bus frente a 1 sola en Invalidación Problemática para protocolos no basados en buses, o sea, escalables 40 Page 20
PCC: implementaciones Implementaciones: Hw: snoopy: máquinas basadas en buses: broadcast directorios: máquinas escalables : otras redes de intercomunicación: multicast: máquinas CC-NUMA; Intel MIC NUEVO!!! redes coherentes : MP con una red de interconexión diseñada expresamente para mantener la coherencia: meros experimentos académicos Sw: no realizaciones comerciales cuestión en que parece completamente parada 41 PCC: implementaciones snoopy Implementaciones snoopy: Se utilizan en MP en los que la red de interconexión es un bus Idea básica: Las transacciones en el bus son visibles a todos los procesadores Los procesadores (realmente, sus controladores de caché -- versión ++ --) observan lo que pasa en el bus y realizan acciones para preservar la coherencia 42 Page 21
PCC: implementaciones snoopy Implementación: Se sofistica en controlador de la caché: doble interfaz: el procesador / el bus Frente a cada transacción realiza cero o más acciones:»actualizar estado»suministrar datos»generar nuevas transacciones El protocolo se implementa como una máquina de estados distribuida El tamaño del grano de coherencia es el bloque de caché 43 [...] Coherencia de cachés Políticas para mantener la coherencia 1. Invalidación 2. Actualización 3. Consideraciones de rendimiento 4. Decisiones de diseño 5. Variaciones Implementaciones 1. Hardware 1. Snoopy: buses 2. Directorios: ahora, MIC/Xeon Phi 2. Software: nada real 44 Page 22
PCC: snoopy: otros aspectos Otros aspectos generales de las implementaciones snoopy: Complicaciones de diseño: 3 estados ( papel ) / 40 estados ( silicio ) i Diseño del controlador de la caché: procesador/bus Los resultados del snoop: cómo y cuándo suministrarlos Aunque las transacciones sobre el bus puedan ser atómicas, no el funcionamiento general Serialización, interbloqueo, hambruna,... Implementación de operaciones atómicas Complicaciones adicionales (muchas) en buses de ciclo partido... 45 PCC: directorios Implementaciones con Directorios: Se utilizan en MP en los que la red de interconexión no es un bus: CC-NUMAs (tecnología demodé actualmente) Intel MIC, ha retomado la idea Idea básica: Se mantiene siempre anotado dónde existen copias de los bloques y en qué estado se encuentran multicast: operaciones procoherencia dirigidos exclusivamente a las cachés que tengan copia del bloque: gossip vs. snooping Variación: jerarquías: snooping + directorios: redes de MP basados en buses; jerarquías de directorios Implementación: Muchas posibilidades: RENDIMIENTO vs. TAMAÑO DIRECTORIO vs. ESCALABILIDAD? 46 Page 23
PCC: directorios RENDIMIENTO = grado de contención + Vel. de búsqueda Propuestas: - A) Directorios completos (full-map) - B) Directorios limitados (limited) escalabilidad - C) Directorios encadenados (chained) - Idea rescatada recientemente en la arquitectura Intel-MIC/Xeon Phi: - núcleos interconectados por un anillo bidireccional, 64 bytes de datos - mantiene la coherencia entre las cachés L2 - directorio completo distribuido alrededor del anillo en los Tag Directory (TD). - las direcciones (bloques) se distribuyen uniformemente entre los TDs - Cuando fallo en L2, se envía una petición a través de las líneas AD del anillo: - si se encuentra en la L2 de otro core, petición del bloque que se sirve a través de las líneas de datos del anillo - si no, se envía petición a memoria principal. 47 Intel Xeon Phi 48 Page 24
Intel Xeon Phi 49 PCC: soluciones Sw 50 Soluciones (mejor que implementaciones) Software: Cuestión que se comenzó a investigar a mediados de los 80s (vs. implementaciones Hw) Casi todas las soluciones propuestas (menos las triviales muy poco eficientes) se han desarrollado en entornos académicos y no se han implementado en máquinas comerciales Posibles ventajas de las soluciones Sw: 1. Aunque todas las soluciones (eficientes) requieren soporte Hw, muchas veces completamente ad hoc, son sin dudas, mucho más sencillas que las implementaciones Hw 2. Ya que el rendimiento de las políticas de coherencia depende claramente de lo que llamamos el comportamiento del programa, las soluciones Sw pueden tenerlo en cuenta para actuar eficientemente 3. Teóricamente, son escalables con el número de procesadores Page 25
PCC: soluciones Sw Ejemplo: Cheong y Veidenbaum, U. of Illinois at Urbana- Champaign, Compiler-Directed Cache Management in Multiprocessors, IEEE Computer, 1990 51 Índice 1. Necesidades de cómputo. Exascale. Arquitecturas t de altas prestaciones. Top 500. Green 500 2. Memoria compartida 1. soporte para programación paralela 2. coherencia de cachés: repaso y directorios 3. modelo de coherencia de memoria (introd.)) 3. Memoria distribuida, clusters y cloud 4. Coprocesadores (GPUs y MIC) 52 Page 26
Modelo de coherencia de memoria 3. Modelo de coherencia de memoria (introducción) 1. Introducción 2. Coherencia secuencial 3. Coherencia relajada 1. Processor consistency 2. Weak consistency 3. Release consistency 53 Memoria compartida Memory Consistency Models for Shared Memory MP a quién le importa? Lenguaje máquina C C++ Ada HPF Java compiladores/librerías/so/etc Middleware Modelo de Coherencia de Memoria 54 Page 27
Modelo de coherencia de memoria Idea: cuál es la semántica de las operaciones de acceso a memoria compartida?? O cómo se ordenan las escrituras y lecturas entre los diferentes procesadores? Nuestra mentalidad : modelo uniprocesador : accesos atómicos a M y en el orden del programa: y, sin embargo, el compilador o la UC (p.ej., superescalares) no necesariamente fuerzan el orden secuencial: p.ej., buffer de escritura, terminación fuera de orden, etc. 55 Modelo de coherencia de memoria Nuestra visión: escribir A escribir B leer A leer B Ejecución en MP donde los procesadores comparten información: el orden relativo en que se realizan los accesos es importante. t 56 Page 28
Modelo de coherencia de memoria Ejemplo: P1 A:= flag:= 0 P2 A:= 666; flag:= 1; while (flag==0) do nothing print A; Qué resultado esperamos? Por qué pudiera ser que no lo obtuviésemos?: cachés privadas:? buffer de escritura:? red de interconexión: también en buses? 57 Modelo de coherencia de memoria Coherencia Secuencial (Sequential Consistency, SC) de Lamport (1979): (A system is sequentially consistent if) the result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program. 58 Page 29
Modelo de coherencia de memoria visualización: serialización de los accesos: Accesos a M en el orden del programa P 1 P 2... P n El conmutador se mueve aleatoriamente después de cada acceso Memoria 59 Modelo de coherencia de memoria Ejemplo: A:= B:= x:= y:= 0 P1 A:= 1 (a) x:= B (b) ( barrier (2)?) print(x) P2 B:= 1 (c) y:= A (d) ( barrier (2)?) print(y) Coherencia Secuencial? Sí/No: demostración 0 0 0 1 1 0 1 1 60 Page 30
Modelo de coherencia de memoria Modelos de Coherencia Relajada (Relaxed Consistency, RC): Menos exigente que la SC, pero más eficiente: permite optimizaciones jugando con el orden de los accesos a memoria Existen diferentes modelos que siguen el principio de RC Todos los modelos de RC suministran algún tipo de mecanismo que permite forzar explícitamente la coherencia secuencial Modelos: - Processor Consistency (PC): Goodman, 1989 - Weak Consistency (WC): Dubois et al., 1986 - Release Consistency (RC): Garachorloo et al., 1990 61 Modelo de coherencia de memoria SC PC WC RC LD LD {M, M} {M, M} ST LD SYNC ACQUIRE LD ST {M, M} {M, M} LD {ST, LD} SYNC RELEASE {M, M} ST RELEASE 62 Page 31