Contenidos [62 diapositivas] Málaga, del 15 al 24 de Julio, 2015

Transcripción

1 Nuevas prestaciones hardware en Kepler IX Curso de verano de la UMA Programación de GPUs con CUDA Contenidos [62 diapositivas] Málaga, del 15 al 24 de Julio, Presentación de la arquitectura [6 diapositivas] La memoria [6] Los cores SMX [9] Funcionamiento del SMX: Front-end y back-end [20] Mejoras funcionales [20] 1. Paralelismo dinámico [7] 2. Hyper-Q [6] 3. El tamaño del warp [7] Manuel Ujaldón Profesor Universidad de Málaga Conjoint Senior Univ. de Newcastle (Australia) CUDA Nvidia 2 Kepler, Johannes ( ) Autor de las leyes del movimiento planetario. 1. Presentación de la arquitectura Primera ley: Las órbitas de los planetas son planas. El sol está en el plano de la órbita. La trayectoria del planeta respecto del sol es una elipse en la que el sol ocupa uno de los fotos. Segunda ley: El radio vector que une al sol y el planeta barre áreas iguales en tiempos iguales. Un planeta se mueve más rápidamente en su perihelio que en su afelio, y mientras más excéntrica sea su órbita, mayor será la diferencia de velocidad entre sus extremos. Tercera ley: Los cuadrados de los períodos de revolución en torno al sol son proporcionales a los cubos de los semiejes mayores de las órbitas. La velocidad media con que un planeta recorre su órbita disminuye a medida que el planeta está más lejos del sol. La influencia que el sol ejerce sobre los planetas disminuye con la distancia. 4

2 Nuestra Kepler también tiene 3 leyes Y tres innovaciones principales SMX: Un multiprocesador con más recursos y menos consumo. Paralelismo dinámico: La GPU es más autónoma, puede lanzar kernels CUDA. Consumo Rendimiento Programabilidad Hyper-Q: Múltiples kernels pueden compartir los SMX. 5 GPU Kepler con memoria de vídeo GDDR5 6 Resumen de sus rasgos más sobresalientes Fabricación: 7100 Mt. integrados a 28 nm. por TSMC. Arquitectura: Entre 7 y 15 multiprocesadores SMX, dotados de 192 cores cada uno. Modelos más populares: K20 (con 13 SMXs), K20X (14), K40 (15). Aritmética: Más de 1 TeraFLOP en punto flotante de doble precisión (formato IEEE-754 de 64 bits). Los valores concretos dependen de la frecuencia de cada modelo. Con sólo 10 racks de servidores, podemos alcanzar 1 PetaFLOP. Principales innovaciones en el diseño de los cores: Paralelismo dinámico. Planificación de hilos (Hyper-Q). 7 8

3 Resumen de las mejoras en Kepler GK110 frente a Fermi GF100 Recurso Factor de mejora Ritmo de cálculo con opers. punto flotante 2-3x Máximo número de bloques por SMX 2x Máximo número de hilos por SMX 1.3x Ancho de banda del banco de registros 2x Capacidad del banco de registros 2x Ancho de banda de la memoria compartida 2x Capacidad de la memoria compartida 1x Ancho de banda de la caché L2 2x Capacidad de la caché L2 2x 2. La memoria 9 Diferencias en la jerarquía de memoria: Fermi vs. Kepler La memoria en las Teslas: Fermi vs. Kepler Tarjeta gráfica Tesla M2075 M2090 K20 K20X K40 Registros de 32 bits / multiprocesador Tamaño caché L1 + mem. compartida 64 KB. 64 KB. 64 KB. 64 KB. 64 KB. 64 bits 64 bits Anchura de los 32 bancos de m.c. 32 bits 32 bits 64 bits Frecuencia de SRAM (la de la GPU) 575 MHz 650 MHz 706 MHz 732 MHz 745, 810, 875 Ancho de banda L1 y mem. compartida 73.6 GB/s GB/s GB/s GB/s GB/s. Tamaño de la caché L2 Ancho de banda L2 (bytes por ciclo) 768 KB. 768 KB MB. 1.5 MB MB L2 en ops. atómicas (dir. compartida) 1/9 por clk 1/9 por clk 1 por clk 1 por clk 1 per clk L2 en ops. atómicas (dirs. separadas) 24 por clk 24 por clk 64 por clk 64 por clk 64 per clk Anchura del bus de memoria DRAM 384 bits 384 bits 320 bits 384 bits 384 bits Frecuencia de la memoria (MHz) 2x x x x x 3000 Ancho de banda DRAM (no ECC) Tamaño DRAM (todas GDDR5) Bus externo de conexión con la CPU 144 GB/s. 177 GB/s. 208 GB/s. 250 GB/s. 288 GB/s. 6 GB. 6 GB. 5 GB. 6 GB. 12 GB. PCI-e 2.0 PCI-e 2.0 PCI-e 3.0 PCI-e 3.0 PCI-e

4 Motivación para usar la nueva caché de datos Cómo utilizar la nueva caché de datos 48 Kbytes extra para expandir el tamaño de la caché L1. Posee el mayor ancho de banda en caso de fallo a caché. Usa la caché de texturas, pero de forma transparente al programador, y elimina el tiempo de configuración de ésta. Permite que una dirección global pueda buscarse y ubicarse en esta caché, utilizando para ello un camino separado del que accede a caché L1 y memoria compartida. Es flexible, no requiere que los accesos estén alineados. Gestionada automáticamente por el compilador. 13 Declarar los punteros con el prefijo "const restrict ". El compilador automáticamente mapeará la carga de esos valores en la caché para usar el nuevo camino de datos a través de la memoria de texturas. global void saxpy(float x, float y, const float * restrict input, float * output) { size_t offset = threadidx.x + (blockidx.x * blockdim.x); } // El compilador utilizará la nueva caché para "input" output[offset] = (input[offset] * x) + y; 14 Comparativa con la memoria de constantes La jerarquía de memoria en cifras A comparar Memoria de constantes Caché de datos de sólo lectura Disponibilidad Tamaño Implementación hardware Acceso Mejor rasgo Peor rasgo Mejor escenario de uso Desde CUDA Compute Capability 1.0 A partir de CCC 3.5 (aunque desde CCC 1.0 se podía usar la memoria de texturas manualmente) 64 Kbytes 48 Kbytes Una partición de la memoria global (DRAM) A través de una caché de 8 Kbytes que posee cada multiprocesador Latencia muy baja Menor ancho de banda Acceso con el mismo coeficiente (sin usar threadidx) a un pequeño conjunto de datos de sólo lectura Caché de texturas que expande la L1 (SRAM) Mediante un camino aparte en el cauce de segmentación gráfico Gran ancho de banda Mayor latencia Cuando el kernel es memory-bound, aún después de haber saturado el ancho de banda con memoria compartida 15 Generación de GPU Modelo hardware CUDA Compute Capability (CCC) Tope de registros de 32 bits / hilo Regs. de 32 bits / Multiprocesador Mem. compartida / Multiprocesador Caché L1 / Multiprocesador Caché L2 / GPU Todos los modelos de Fermi y Kepler incorporan: Corrección de errores ECC en DRAM. Fermi Kepler GF100 GF104 GK104 GK110 Limitación Anchura de 64 bits en el bus de direcciones. Impacto SW. Working set 32 K 32 K 64 K 64 K HW. Working set 16-48KB 16-48KB KB KB HW. Tile size 48-16KB 48-16KB KB KB Anchura de 64 bits en el bus de datos por cada controlador (todos presentan 6 controladores para 384 bits, salvo GF104 que tiene 4). HW. 768 KB. 768 KB. 768 KB KB. HW. Velocidad de acceso Velocidad de acceso 16

5 Kepler en perspectiva: Recursos hardware y rendimiento pico Tarjeta Tesla (modelo comercial) M2075 Modelo GeForce similar en cores GTX 470 GTX 580 Generación de GPU (y CCC) Fermi GF100 (2.0) Multiprocesadores x (cores/multipr.) Número total de cores 14 x x Tipo de multiprocesador Distancia de integración de los trans. SM 40 nm. K20 K20X - GTX Titan K40 Kepler GK110 (3.5) 13 x x K80 GTX Titan GTX Black Titan Z x x SMX con paralelismo dinámico y HyperQ 28 nm. 28 nm. 575 MHz 650 MHz 706 MHz 732 MHz Frecuencia de los cores (para GPGPU) 1150 MHz 1300 MHz 706 MHz 732 MHz Frecuencia de la GPU (para gráficos) 3. Los cores SMX M nm. 28 nm. 28 nm Número de cores (simple precisión) GFLOPS (pico en simple precisión) Número de cores (doble precisión) GFLOPS (pico en doble precisión) Rendimiento pico en GPU vs. CPU FLOPS pico en doble precisión GeForce GTX Titan Z: El techo de rendimiento en GPUs domésticas Ancho de banda 5760 cores (el doble que la K40). 12 Gbytes de memoria de vídeo. Más de 8 TeraFLOPS de rendimiento pico. Precio inicial (Marzo de 2014): $3000. Precio un año después de su lanzamiento: $1500. GPU 6x mejor en double : GPU: 3000 GFLOPS CPU: 500 GFLOPS GPU 6x ancho de banda: 7 GHz x 48 bytes = 336 GB/s. 2 GHz x 32 bytes = 64 GB/s

6 GPU Boost Permite acelerar hasta un 17% el reloj de la GPU si el consumo de una aplicación es bajo. Se retornará al reloj base si se sobrepasan los 235 W. Se puede configurar un modo persistente de vigencia permanente de un reloj, u otro para ejecuciones puntuales. Consumo sin apurar Maximiza los relojes gráficos sin salirse de los márgenes de consumo nominales Rendimiento Board Power (Watts) Cada aplicación tiene un comportamiento distinto en relación al consumo Aquí vemos el consumo medio (vatios) en la Tesla K20X de aplicaciones muy populares en el ámbito HPC: Reloj base Reloj a máxima frecuencia 745 MHz 810 MHz 875 MHz 0 AMBER ANSYS Black ScholesChroma GROMACS GTC LAMMPS LSMS NAMD Nbody QMCPACK RTM SPECFEM3D Aquellas aplicaciones que menos consumen pueden beneficiarse de una frecuencia mayor En el caso de la K40, se definen tres saltos de frecuencia con incrementos del 8.7%. GPU Boost frente a otras implementaciones Resulta mejor un régimen estacionario para la frecuencia desde el punto de vista del estrés térmico y la fiabilidad. Reloj acelerado #2 Reloj acelerado #1 875 MHz 810 MHz Reloj de la GPU Otros fabricantes Boost Clock # 2 Boost Clock # 1 Base Clock # 1 Tesla K40 Reloj base 745 MHz Conmutación automática de reloj Relojes deterministas 235W Consumo máximo. Referencia (peor caso). 235W Consumo moderado. Ej: AMBER 235W Consumo bajo. Ej: ANSYS Fluent A 875 MHz, la K40 mejora el rendimiento hasta en un 40% respecto a la K20X. Y no sólo mejoran los GFLOPS, también lo hace el ancho de banda efectivo con memoria. 23 Valor por defecto Opciones predefinidas Interfaz con el usuario Duración del reloj acelerado Otros fabricantes Reloj acelerado Bloquear a la frecuencia base Panel de control Aprox. 50% del tiempo de ejec. Tesla K40 Reloj base 3 niveles: Base, Boost1 o Boost2 Comandos en el shell: nv-smi 100% del tiempo de ejecución 24

7 Lista de comandos GPU Boost Comando Ejemplo: Consultando el reloj en uso nvidia-smi -q -d CLOCK id=0000:86:00.0 Efecto nvidia-smi -q -d SUPPORTED_CLOCKS Muestra los relojes que soporta nuestra GPU nvidia-smi -ac <MEM clock, Graphics clock> Activa uno de los relojes soportados nvidia-smi -pm 1 Habilita el modo persistente (el reloj sigue vigente tras el apagado) nvidia-smi -pm 0 Modo no persistente: El reloj vuelve a su configuración base tras apagar la máquina nvidia-smi -q -d CLOCK nvidia-smi -rac nvidia-smi -acp 0 Consulta el reloj en uso Inicializa los relojes en su configuración base Permite cambiar los relojes a los usuarios que no son root Kepler GK110: Disposición física de las UFs para la Tesla K40 dotada de 15 SMXs 4. Funcionamiento del SMX: Front-end y back-end 28

8 El multiprocesador SMX Planificación y emisión de instrucciones en warps Front-end Del multiprocesador SM de Fermi GF100 al multiprocesador SMX de Kepler GK110 Front-end Ejecución de instrucciones. 512 unidades funcionales: para aritmética entera para aritmética s.p para aritmética d.p para carga/almacen para SFUs (log,sqrt,...) Back-end Back-end Acceso a memoria Interfaz Comparación entre la emisión y ejecución de instrucciones (front-end vs. back-end) Fermi (GF100) Kepler (GK110) Búsqueda y emisión (front-end) Puede emitir 2 warps, 1 instr. cada uno. Total: Máx. 2 warps por ciclo. Warps activos: 48 en cada SM, seleccionados de entre 8 bloques máx. En GTX580: 16*48= 768 warps activos. Puede emitir 4 warps, 2 instrs. cada uno. Total: Máx. 8 warps por ciclo. Warps activos: 64 en cada SMX, seleccionados de entre 16 bloques máx. En K40: 15 * 64 = 960 warps activos. Ejecución en SM-SMX (back-end) 32 cores (1 warp) para "int" y "float". 16 cores para "double" (1/2 warp). 16 unids. de carga/almacen. (1/2 warp). 4 unids. de funcs. especiales (1/8 warp). Total: Hasta 5 warps concurrentes. 192 cores (6 warps) para "int" y "float". 64 cores para "double" (2 warps). 32 unids. de carga/almacen. (1 warp). 32 unids. de funcs. especiales (1 warp). Total: Hasta 16 warps concurrentes. Gigathread, o cómo el programa es devorado por el procesador Cada malla (grid) contiene un número de bloques, que son asignados a los SMXs (hasta 16 en Kepler, 8 en Fermi). Los bloques se dividen en warps o grupos de 32 hilos. Los warps se ejecutan para cada instrucción de los hilos (hasta 64 warps activos en Kepler, 48 en Fermi). Ejemplo: En Kepler, cada SMX puede emitir 8 warp-instrucciones por ciclo, pero debido a limitaciones por recursos y dependencias: 7 es el pico sostenible. 4-5 es una buena cantidad para códigos limitados por instrucción. <4 en códigos limitados por memoria o latencia

9 Mejoras en concurrencia y paralelismo Expresando todo el paralelismo Generación de GPU Modelo hardware CUDA Compute Capability (CCC) Número de hilos / warp (tamaño del warp) Máximo número de warps / Multiprocesador Máximo número de bloques / Multiprocesador Máximo número de hilos / Bloque Máximo número de hilos / Multiprocesador Fermi Kepler GF100 GF104 GK104 GK Mejoras cruciales para ocultar latencias Máx. concurrencia en cada SMX 33 Tetris (baldosa = warp_instr.): - Emite 4 warp_instrs. - Ejecuta hasta 10 warps = 320 hilos. - Warp_instrs. son simétricos y se ejecutan todos en 1 ciclo. Correspondencia de colores: para instrucciones int. para instrs. float. double. Emite 4 warp_instrs. load/store. log/sqrt.... El jugador planifica los warps! Se pueden rotar las fichas si no hay dependencias entre sus 4 warps Ejecuta hasta 10 warp_instrs. instr. warp G80: Tarda 4 ciclos en ejecutar cada warp_instrs. G80: 16 U.F. Ejemplo: Kernel con bloques de 384 hilos (12 warps). Fermi: - Emite 2. - Ejecuta hasta 5. SM en Fermi: 100 U.F. paralelas. Bloque 0: Bloque 1: sub fmadd fdiv64 load sqrt Kepler: - Emite 4 warps x 2 instrs. - Ejecuta hasta 16 warp_instrs. (512 unidades funcionales). 6x32 = 192 ALUs 192 FPU SP 64 FPU DP SMX en Kepler: 512 U.F. paralelas SFU 32 LD/ST 34 int Una breve incursión en el concurso Una breve incursión en el concurso (2) 1: De tareas (TLP) int float double Procesamiento de matrices dispersas 2: De instrs. (ILP) Procesamiento de matrices dispersas 3: De datos (SIMD) Estrategia base: 4: Vectorial (warp = 32) Nuestro código recorre toda la matriz, realizando operaciones con cada elemento de forma independiente. Lanzaremos un kernel CUDA por cada columna de la matriz. Cada kernel tendrá el menor número posible de bloques. Cada bloque tendrá el mayor número posible de warps SFU 32 LD/ST 64 FPU DP 6x32 = 192 ALUs 192 FPU SP SMX en Kepler: 512 U.F. paralelas. int float double values[numelements]; for all elements assigned to each thread: for numops. to be done on each element values[i] *= values[i]; Cambiar el operador a más sencillo (suma) o más complejo (división) también afectará según la latencia de cada operación. 36

10 Las instrucciones para el concurso están en nuestra web: Paralelismo dependiente del volumen de datos El programa paralelo más elemental: Los bucles son paralelizables. Conocemos a priori la carga de trabajo. for (i=0; i<n; i++) for (j=0; j<m; j++) convolution (i, j); N M El programa imposible más elemental: Desconocemos la carga de trabajo. El reto es su distribución (partición de datos). N max(elementsonrow[i]) 37 for (i=0; i<n; i++) for (j=0; j<elementsonrow[i]; j++) convolution (i, j); Una solución mala: Supercómputo. Una solución peor: Serialización. 38 Cómo se representa una matriz dispersa en formato comprimido por columnas (CCS) Ejemplo para una matriz 5x5: Índices de fila colptr value según se recorren verticalmente rowidx for (i=0; i<n; i++) for (j=colptr[i]; j<colptr[i+1]; j++) value[j] += value[j]; número de elementos en cada columna (acumulados) posición horizontal de cada valor Para esta estructura de datos, así recorremos la matriz: 39 Un desafío para los programadores CUDA: Realizado en 8 países hasta la fecha Qué hace el programa? Iterar en paralelo sobre cada elemento de una matriz dispersa comprimida por columnas. La matriz dispersa puede tener N=100 o N=200 columnas, cada una con un número distinto de elementos no nulos. Se computan bucle i numops sobre cada elemento. for (i=0; i<n; i++) for (j=colptr[i]; j<colptr[i+1]; j++) for (k=0;k<numops;k++) value[j] += value[j]; Todos los bucles son forall. La carga computacional se desconoce en tiempo de compilación. El desafío está en la partición de datos: max(elementsoncol[i]) Desplegar streams, kernels, bloques e hilos sabiamente. bucle j N 40

11 Matrices dispersas de entrada (tomadas de la colección Matrix Market) Cómo trabaja el front-end de la GPU: (1) Planificación de warps Área científica Filas de la matriz Columnas de la matriz Elementos no nulos Carga de trabajo Economía Base Demografía x Base Oceanografía x Base Física cuántica x Base Álgebra lineal Base Procesamiento de imágenes x Base Astrofísica x Base Bioquímica x Base 41 SM (Fermi) SMX (Kepler) 42 La conexión entre front-end y back-end: (2) Emisión de warps En los 5 ciclos ilustrados, hemos podido ejecutar hasta aquí. En Fermi hay déficit en las SFUs (azul), mientras que en Kepler lo hay en las unidades de carga/almacenamiento (verde). Kepler equilibra la doble precisión (rojo) y tiene gran superávit en computación int y float, señal de que los códigos reales tienen mayor presencia de instrs. naranjas, y sobre todo, amarillas. Cómo trabaja el back-end de la GPU: (3) Ejecución de warps Suponemos que en el momento en que comenzamos a monitorizar la ejecución quedaban pendientes de ejecutar: Un par de warps de punto flotante en simple precisión (naranjas). Otro par de warps en doble precisión (rojos). Parece conveniente que el front-end vaya un poco adelantado respecto al back-end (prebúsquedas) con objeto de maximizar el throughput. SM (Fermi) SMX (Kepler) 43 SM (Fermi) SMX (Kepler) 44

12 Puntualizaciones al modelo tetris En Fermi, las baldosas rojas no pueden combinarse con otras. En Kepler, no se pueden tomar 8 warp_instrs. en horizontal, deben ser de altura 2 como mínimo. Las instrucciones tienen distinta latencia, así que las que consuman más de un ciclo (como los operandos en doble precisión) deben expandirse verticalmente en proporción. Si el warp tiene divergencias, tarda más de un ciclo: Es la carencia del vectorial. Se podría representar como el anterior. Los códigos tienen más fichas amarillas ( int domina). Algunas fichas vienen cojas porque el planificador de warps no puede encontrar un lote de 4x2 sin dependencias. Las fichas pueden ensamblar baldosas no contiguas. Latencia de los warps Aunque todas las baldosas tardaran un ciclo en ejecutarse, la duración de los warps no sería ésa. El tiempo que un warp gasta en la máquina es la suma de tres: Tiempo en planificación. Tiempo en emisión. Tiempo en ejecución. La planificación y ejecución son bastante regulares, pero la emisión no: Depende de la montaña de baldosas que haya en el cubilete (estaciones de reserva). De ahí la varianza que experimenta su duración El comportamiento de los warps nos enseña que la GPU no es un procesador regular Factores impredecibles en tiempo de ejecución dificultan un reparto equilibrado de la carga computacional entre los multiprocesadores. Aquí vemos un ejemplo de la varianza existente entre los 8 últimos warps ejecutados en cada SM: 5. Mejoras funcionales 47

13 Principales mejoras hardware Computación a gran escala (grandes tamaños de problema) Generación de GPU Fermi Modelo hardware Kepler GF100 GF104 GK104 Compute Capability (CCC) Máxima dimensión X de la malla 2^16-1 2^ ^32-1 GK110 Limitación Impacto Software Tamaño del problema Limitación Impacto 3.5 2^32-1 Novedades funcionales: Generación de GPU Fermi Modelo hardware 5.1. Paralelismo dinámico Kepler GF100 GF104 GK104 GK110 Compute Capability (CCC) Paralelismo dinámico No No No Sí Hardware Estructura del problema Hyper-Q No No No Sí Hardware Planificación de hilos 50 Así se hacían las cosas en la era pre-kepler: La GPU era un mero esclavo del host o CPU Qué es el paralelismo dinámico? La habilidad para lanzar nuevos procesos (mallas de bloques de hilos) desde la GPU de forma: Gran ancho de banda en las comunicaciones: Externas: Superior a 10 GB/s (PCI-express 3). Internas: Superior a 100 GB/s (memoria de vídeo GDDR5 y anchura de bus en torno a 384 bits, que es como un séxtuple canal en CPU). Dinámica: Basándonos en datos obtenidos en tiempo de ejecución. Simultánea: Desde múltiples hilos a la vez. Independiente: Cada hilo puede lanzar una malla diferente. Función Lib Lib Función Función Init GPU Alloc CPU GPU Fermi: Sólo la CPU puede generar trabajo en GPU. CPU GPU CPU Kepler: La GPU puede generar trabajo por sí sola. Operación 1 51 Operación 2 Operación 3 52

14 Y así se pueden hacer con Kepler: Las GPUs lanzan sus propios kernels Antes la GPU era un co-procesador Con Kepler, la GPU is más autónoma: Entra en escena el paralelismo dinámico CPU GPU CPU GPU Ejemplo 1: Generación dinámica de la carga Asigna los recursos dinámicamente según se vaya requiriendo precisión en tiempo real, lo que facilita la computación de aplicaciones irregulares en GPU. Amplía el ámbito de aplicación donde puede ser útil. Malla gruesa Malla fina Malla dinámica Ahora los programas van más rápido y se expresan de una forma más natural. 53 Rendimiento elevado, precisión baja Rendimiento bajo, precisión elevada Sacrifica rendimiento sólo donde se requiere precisión 54 Ejemplo 2: Desplegando paralelismo según el nivel de detalle A vigilar cuando se use el paralelismo dinámico CUDA hasta 2012: La CPU lanza kernels de forma regular. Todos los píxeles se procesan igual. La potencia computacional se asocia a las regiones según su interés CUDA sobre Kepler: La GPU lanza un número diferente de kernels/bloques para cada región computacional. Es un mecanismo mucho más potente de lo que aparenta su simplicidad en el código. Sin embargo... Lo que escribimos dentro de un kernel CUDA se fotocopia para todos los hilos. Por lo tanto, la llamada a un kernel provocará millones de lanzamientos si no va precedida de algún IF que la delimite (por ejemplo, sólo el hilo 0 lanza). Si un bloque CUDA lanza kernels hijos, pueden éstos utilizar la memoria compartida del padre? No. Sería fácil de implementar en hardware, pero muy complejo para el programador garantizar que no se producen riesgos por dependencias (condiciones de carrera)

15 Hyper-Q En Fermi, diversos procesos de CPU ya podían enviar sus mallas de bloques de hilos sobre una misma GPU, pero su ejecución concurrente se encontraba severamente limitada por hardware. En Kepler, pueden ejecutarse simultáneamente hasta 32 kernels procedentes de: Varios procesos de MPI, hilos de CPU o streams de CUDA. Esto incrementa el porcentaje de ocupación temporal de la GPU. FERMI KEPLER 1 sola tarea MPI activa 32 tareas MPI simultáneas 5.2. Hyper-Q 58 global kernel_a(pars) {body} // Same for B...Z cudastream_t stream_1, stream_2, stream_3;... cudastreamcreatewithflags(&stream_1,...); cudastreamcreatewithflags(&stream_2,...); cudastreamcreatewithflags(&stream_3,...);... kernel_a <<< dimgrida, dimblocka, 0, stream_1 >>> (pars); kernel_b <<< dimgridb, dimblockb, 0, stream_1 >>> (pars); kernel_c <<< dimgridc, dimblockc, 0, stream_1 >>> (pars);... kernel_p <<< dimgridp, dimblockp, 0, stream_2 >>> (pars); kernel_q <<< dimgridq, dimblockq, 0, stream_2 >>> (pars); kernel_r <<< dimgridr, dimblockr, 0, stream_2 >>> (pars);... kernel_x <<< dimgridx, dimblockx, 0, stream_3 >>> (pars); kernel_y <<< dimgridy, dimblocky, 0, stream_3 >>> (pars); kernel_z <<< dimgridz, dimblockz, 0, stream_3 >>> (pars); El gestor de kernels/mallas: Fermi vs. Kepler Kepler GK110 Fermi stream_1 kernel_a Colas de streams kernel_b (colas ordenadas de mallas) Stream 1 kernel_c stream_2 Stream 2 R Z Stream 3 B Q Y A P X Kernel C Kernel R Kernel Z Kernel B Kernel Q Kernel Y Kernel A Kernel P Kernel X kernel_p Cola de streams C Hardware paralelo de streams Gestor de kernels/mallas Una sola cola hardware multiplexa los streams kernel_q kernel_r Distribuidor de carga para los bloques lanzados desde las mallas 16 mallas activas stream_3 kernel_x kernel_y SM kernel_z 59 SM SM SM Mallas pendientes y suspendidas Miles de mallas pendientes Carga de trabajo generada por CUDA stream 3 stream 2 stream 1 Un ejemplo: 3 streams, cada uno compuesto de 3 kernels Permite suspender mallas Distribuidor de carga Se encarga de las mallas activas 32 mallas activas SMX SMX SMX SMX 60

16 Relación entre las colas software y hardware Fermi: Relación entre las colas software y hardware Fermi: A -- B -- C...pero los streams se multiplexan en una cola única El hardware de la GPU puede A--B--C P--Q--R X--Y--Z albergar hasta 16 mallas en Oportunidad para solapar: ejecución... Sólo en las fronteras entre streams...pero los streams se multiplexan en una cola única El hardware de la GPU puede A--B--C P--Q--R X--Y--Z albergar hasta 16 mallas en Oportunidad para solapar: ejecución... Sólo en las fronteras entre streams Stream 1 P -- Q -- R Stream 2 X -- Y -- Z Stream 3 El número de mallas en ejecución crece hasta % utilización de la GPU C C D E X--Y--Z X -- Y -- Z Concurrencia plena entre streams Stream 3 Stream 2 F Tiempo Con Hyper-Q: Multiproceso simultáneo E F 100 % utilización de la GPU D D D C A F C C 50 B E F B F E 0 Procesos en CPU......mapeados sobre GPU 5.3. El tamaño del warp B A D 0 E A Tiempo ganado 63 A -- B -- C P -- Q -- R 50 B X -- Y -- Z P--Q--R 100 A Stream 2 Stream 1 Sin Hyper-Q: Multiproceso por división temporal 0 P -- Q -- R Desaparecen las dependencias entre streams A--B--C B Stream 1 Stream 3 Kepler: A A -- B -- C 62

17 La forma en que cada multiprocesador engulle las instrucciones SIMD Un hipotético front-end para la GPU con tamaño de warp ampliado a 64 Instr. 1 UC Warp scheduler Instr. 2 Bloque Dispatch Unit Warp scheduler Dispatch Unit Dispatch Unit Dispatch Unit Instr. 3 Fermi Kepler 65 La forma en que se engullen las instrucciones SIMD utilizando un warp de tamaño El back-end de la GPU: Transformando el SMX para un tamaño de warp de 64 Instr. 1 Unidad funcional CU Instr. 2 El coste de la unidad de control ahora es justo la mitad. La penalidad por dependencias de datos es potencialmente más baja, y su circuitería más sencilla. La penalidad por dependencias de control es mayor. # tam. de warp 32 tam. de warp 64 int/fp fp load/store /2 SFU /2 El déficit está en las unidades de carga y almacenamiento y las SFUs, y de éste ya fueron capaces de recuperarse tras la generación Fermi. Kepler 67 68

18 Otros hechos que promueven el cambio a warps de tamaño 64 Memoria compartida: La concurrencia se consigue a través de los bancos, que ya subieron de 16 (pre-fermi) a 32. Memoria de vídeo: Se requiere mayor ancho de banda, pero ése no es el problema de la saga DDR, sino la latencia. Bifurcaciones: Las técnicas que minimizan la penalización en saltos condicionales están más preparadas para este reto. Escalabilidad en el número de cores: Simplicidad en la unidad de control permitiría subir el número de cores. Nvidia está anticipando este cambio con continuos avisos. Otras marcas se mueven también en esta dirección: Graphics Core Next (GCN) de AMD es un SIMD de 4 x 16 cores. Para beneficiarse del cambio tecnológico a warps de 64 hilos Hacer los bloques grandes: Menos de 64 hilos por bloque está vetado. 256 sería el mínimo. 384 cobra protagonismo. Prestar una mayor atención a las divergencias. Favorece más a las aplicaciones regulares. De ahí que la sofisticación del planificador de mallas se haya pensado para acelerar las aplicaciones irregulares Cómo sería Kepler si tuviera un warp de 64 Síntesis final Kepler32: - Emite 4 warps x 2 instrs. - Ejecuta hasta 16 warp_instrs. (512 unidades funcionales). 6x32 = 192 ALUs 192 FPU SP 64 FPU DP SMX en Kepler: 512 U.F. paralelas. 32 SFU 32 LD/ST Kepler64: - Emitiría 4 warps. - Ejecutaría hasta 8. Si contamos con que Nvidia suele completar a warps enteros las Unidades Funcionales en la siguiente generación, verde y azul aumentarían, y el parecido de Kepler64 con el Tetris del video-juego sería asombroso. 71 Kepler simboliza la generación de GPUs de Nvidia para , más adecuada para miles de cores. Despliega todas las formas de paralelismo a gran escala: De tareas, de instrucciones, de datos y vectorial. Hace énfasis en la eficiencia energética y en ampliar la programabilidad del modelo CUDA. La GPU es más autónoma, pero a la vez admite mayor interacción con la CPU. También se mejora la jerarquía de memoria y las conexiones entre las memorias de las GPUs. La conexión SMX-DRAM será determinante en el futuro. 72