La arquitectura de cómputo CDNA 3 de AMD
(chipsandcheese.com)- AMD CDNA 3 es una arquitectura de GPU de cómputo que busca corregir los puntos en los que CDNA 2, aunque tuvo buenos resultados en supercomputación FP64, quedó por detrás de la H100 en rendimiento de IA y escala de GPU unificada
- La MI300X expone un total de 304 Compute Unit distribuidas en 8 XCD como si fueran una sola GPU, reduciendo la carga de tener que dividir el trabajo entre dos GPU y pools de memoria separados, como ocurría con la MI250X
- La jerarquía de memoria se reorganizó con 256 MB de Infinity Cache, 4 MB de L2 por XCD y 32 KB de L1 cerca de cada CU; en teoría ofrece 17.2 TB/s de ancho de banda de caché, pero en una configuración de memoria unificada los enlaces die-to-die pueden convertirse en cuello de botella
- La unidad de ejecución introduce una estructura cercana al dual issue para elevar el aprovechamiento de FP32, además de aumentar la cantidad de hilos rastreables por SIMD; el rendimiento de operaciones matriciales también se duplica por CU frente a la generación anterior de CDNA
- El cambio clave de CDNA 3 está en la jerarquía de memoria y el empaquetado, y la MI300X está diseñada para que varios chiplets se vean como un gran acelerador único gracias al ancho de banda muy ampliado de Infinity Fabric
La brecha a la que apunta CDNA 3
- AMD ha ido desarrollando su arquitectura para alcanzar a Nvidia en el mercado de GPU de cómputo, pasando por Terascale 3, GCN y la separación entre CDNA/RDNA
- La MI250X y la MI210, basadas en CDNA 2, consiguieron varios contratos de supercomputación, incluido Frontier de ORNL, que ocupó el primer lugar del TOP500 en noviembre de 2023
- CDNA 2 ofrecía un rendimiento sólido y rentable en cómputo FP64, pero la H100 entregaba mejor rendimiento de IA y una GPU unificada de mayor tamaño
- CDNA 3 fue diseñada para reducir esa brecha combinando el empaquetado avanzado de AMD, Infinity Fabric, Infinity Cache de la familia RDNA y Compute Unit mejoradas
Distribución de la GPU en la MI300X
- La MI300X usa una estructura de chiplets que separa el cómputo en Accelerator Complex Die (XCD)
- El XCD cumple un papel parecido al Graphics Compute Die (GCD) de CDNA 2/RDNA 3 y al Core Complex Die (CCD) de Ryzen
- Como los productos CDNA no incluyen hardware gráfico dedicado de la familia RDNA, parece que AMD cambió la denominación por eso
- Cada XCD tiene físicamente 40 Compute Unit CDNA 3, y en la MI300X hay 38 activas por XCD
- Un XCD incluye 4 MB de caché L2 que usan todas las CU de ese die
- La MI300X ofrece un total de 304 Compute Unit a través de 8 XCD
- Es un aumento importante frente a las 220 CU de la MI250X, y la MI300X puede exponer esas CU como una sola GPU
- En la MI250X, cada GPU tenía su propio pool de memoria, por lo que el programador debía repartir manualmente el trabajo entre ambas GPU
- La Nvidia H100 expone 132 Streaming Multiprocessor (SM) como una sola GPU unificada, pero usa el enfoque tradicional de implementar el cómputo en un único die grande
- La H100 divide la L2 en dos instancias; un SM individual puede usar los 50 MB completos de L2, pero acceder a más de 25 MB implica una penalización de rendimiento
- El XCD de la MI300X no usa la capacidad L2 de otros XCD para caché, así que en aprovechamiento de capacidad de caché el enfoque de Nvidia es más eficiente
Comparación estructural con Ponte Vecchio
- El Ponte Vecchio (PVC) de Intel usa Compute Tile como bloque básico de cómputo, que corresponde de forma aproximada al XCD de CDNA 3
- El Base Tile de PVC incluye una gran caché de último nivel y controladores de memoria HBM, de forma similar al die de IO de CDNA 3
- Las tarjetas PVC también pueden exponerse como una sola GPU con un pool de memoria unificado, igual que la MI300X
- Las diferencias entre ambas estructuras aparecen en el tamaño de los chiplets, la disposición de caché y los enlaces entre dies
- El Compute Tile de PVC está compuesto por 8 Xe Core, por lo que es más pequeño que un XCD de CDNA 3 con 38 CU
- Intel reduce la necesidad de tráfico cross-die con una caché L1 más grande en lugar de una gran caché compartida para todo el Compute Tile
- Si se usa un Ponte Vecchio de 2 stacks como GPU unificada, el puente EMIB solo ofrece 230 GB/s, por lo que resulta difícil aprovechar por completo el ancho de banda HBM al distribuir el acceso a todos los controladores de memoria
- Intel ofrece una API para tratar la GPU como una configuración NUMA
- En la configuración física, CDNA 3 necesita un alto ancho de banda entre los dies de IO, mientras que PVC se sostiene con enlaces EMIB de menor ancho de banda, pero su diseño es más complejo por usar cuatro tipos de die y procesos/foundries distintos
- La MI300X usa solo dos tipos de die, y tanto el proceso de 6 nm como el de 5 nm son de TSMC
Infinity Cache y cuello de botella de memoria
- El rendimiento de cómputo ha aumentado más rápido que la memoria durante décadas, y las GPU, igual que las CPU, han respondido con estrategias de caché cada vez más sofisticadas
- CDNA 2 usaba una jerarquía tradicional de caché de dos niveles apoyada en 8 MB de L2 y HBM2e, pero la MI250X sufría más por falta de ancho de banda que la Nvidia H100
- CDNA 3 añade Infinity Cache tomada de RDNA 2
- La Infinity Cache de la MI300 es una caché del lado de memoria que en la documentación técnica se llama Memory Attached Last Level (MALL)
- Está más alejada de la Compute Unit que L1 y L2, y va unida al controlador de memoria
- Todo el tráfico de memoria pasa por Infinity Cache, y el tráfico de IO y la comunicación con GPU pares también pueden beneficiarse del ancho de banda de Infinity Cache
- Como siempre ve el estado más reciente del contenido de la DRAM, no necesita manejar tareas de mantenimiento de caché como snoop
- La caché del lado de memoria suele tener mayor latencia, por lo que AMD protege a las Compute Unit con una caché L2 de varios MB tanto en CDNA 3 como en RDNA 2
Capacidad de Infinity Cache y ancho de banda teórico
- La Infinity Cache de CDNA 3 usa una estructura 16-way set associative, como en RDNA 2
- La implementación de CDNA 3 está más optimizada para ancho de banda que para capacidad
- Está compuesta por 128 slices
- Cada slice tiene una capacidad de 2 MB y un ancho de banda de lectura de 64 bytes por ciclo
- En conjunto, todos los slices ofrecen 8192 bytes por ciclo, lo que equivale a 17.2 TB/s a 2.1 GHz
- La Infinity Cache de 128 MB en RDNA 2 ofrece 1024 bytes por ciclo considerando todos los slices, y teóricamente 2.5 TB/s a 2.5 GHz
- Según los die shots, cada slice de Infinity Cache en RDNA 2 parece ofrecer 4 MB de capacidad y 32 bytes por ciclo
- La MI300X puede rendir bien incluso con cargas de trabajo de baja densidad de cómputo si obtiene suficientes aciertos en Infinity Cache
- Si se construye un modelo roofline con el ancho de banda teórico de Infinity Cache, la MI300X puede alcanzar su rendimiento FP64 total con 4.75 FLOPs por byte cargado
- Si solo se usa DRAM, se requieren 14.6~15 FLOPs por byte cargado
Restricciones del ancho de banda cross-die
- El Infinity Fabric de la MI300X se extiende a lo largo de 4 dies de IO, y cada die de IO está conectado a 2 stacks de HBM y sus particiones de caché asociadas
- Cuando la MI300X funciona como una sola GPU lógica con un pool de memoria unificado, el ancho de banda de las conexiones die-to-die puede limitar que Infinity Cache alcance todo su ancho de banda teórico
- El cuello de botella en una sola partición de die de IO se hace visible en el cálculo de ancho de banda
- Tiene 2.7 TB/s de ancho de banda de ingreso en los dos bordes que tocan al die de IO adyacente
- Los 2 XCD conectados a ese die de IO pueden obtener 4.2 TB/s de ancho de banda de Infinity Cache
- Si las solicitudes con fallo en L2 se distribuyen uniformemente entre todos los dies, 3/4, es decir 3.15 TB/s, deben venir de dies pares
- Como 3.15 TB/s es mayor que 2.7 TB/s, el ancho de banda cross-die limita el ancho de banda de caché
- Si todos los dies exigen el máximo ancho de banda de Infinity Cache en una configuración unificada, las transferencias entre dies en esquinas opuestas requieren 2 hops, lo que consume todavía más ancho de banda de ingreso
- Si la MI300X se divide en varios dominios NUMA, el ancho de banda agregado de Infinity Cache puede ser mayor
- Una alta tasa de aciertos en L2 reduce la probabilidad de cuellos de botella, y cuando la tasa de aciertos en Infinity Cache es baja, los enlaces die-to-die de la MI300X sí ofrecen ancho de banda suficiente para manejar el tráfico hacia HBM
Coherencia entre XCD y funcionamiento de L2
- Infinity Cache no requiere preocuparse por la coherencia, pero la caché L2 sí necesita un manejo aparte
- Los accesos normales a memoria de GPU siguen un modelo de coherencia relajada, pero el programador puede forzar el ordering entre hilos con atomics
- Los accesos a memoria de las GPU de AMD pueden marcarse con el bit GLC (Global Level Coherent)
- En las GPU anteriores de AMD, los atomics y los accesos coherentes se procesaban en L2
- Un
loadcon el bit GLC activado evita L1 y trae los datos más recientes desde L2 - En MI300X, la cacheline más reciente puede estar en la L2 de otro XCD, así que este método por sí solo no basta
- Un
- CDNA 3 coloca un Coherent Master (CM) en la interconexión entre los XCD y el die de I/O, similar a Infinity Fabric en Ryzen, y ubica un Coherent Slave (CS) junto a cada controlador de memoria, junto con un slice de Infinity Cache
- A partir de la documentación de Ryzen, se sabe que el Coherent Slave incluye un probe filter y hardware para procesar transacciones atómicas
- MI300X parece tener una implementación de CS similar
- Cuando una escritura coherente llega al CS, cualquier hilo, sin importar en qué parte de la GPU se ejecute, debe poder observar esa escritura en una lectura coherente
- En una implementación simple, el CS tendría que hacer probe a la L2 de todos los XCD
- El probe filter rastrea qué XCD tiene esa línea en caché para evitar tráfico de probe innecesario
- El whitepaper de CDNA 3 indica que el snoop filter es lo bastante grande para cubrir varias cachés L2 de XCD
- Aun así, dentro de un XCD, CDNA 3 se comporta de forma similar a las GPU anteriores
- Una escritura normal a memoria no invalida automáticamente, como en CPU, la línea en las cachés peer
- El código debe indicar explícitamente que se haga writeback de la dirty L2 cache line y que se invalide la non-local L2 line en la caché L2 peer
- La documentación relacionada de LLVM explica el uso de
buffer_wbl2 sc1ybuffer_inv sc0 sc1en el target GFX942
Mejoras en las cachés L2 y L1
- Cada XCD de MI300X tiene una caché L2 de 4 MB cerca de las Compute Unit
- La L2 está compuesta por 16 slices
- Cada slice de 256 KB ofrece 128 bytes de ancho de banda por ciclo
- A 2.1 GHz, eso equivale a 4.3 TB/s por XCD
- MI300X tiene una relación de ancho de banda L2 a cómputo más alta que H100 y MI250X
- Como cada XCD tiene su propia L2, el ancho de banda L2 de los productos CDNA 3 aumenta de forma natural a medida que se agregan más XCD
- Así se evita el problema de mantener el ancho de banda al conectar muchas Compute Unit a una sola caché grande
- En PVC, al aumentar los Compute Tile, también aumenta la demanda de ancho de banda sobre la L2 compartida del Base Tile
- La estructura de PVC es simple desde el punto de vista de diseño de caché, porque L2 es el punto único de coherencia y también el backstop de los misses de L1
- No puede ofrecer un ancho de banda tan alto como la L2 de MI300X
- La L1 de CDNA 3 también mejora con foco en el ancho de banda
- El throughput de L1 sube de 64 bytes por ciclo a 128 bytes por ciclo
- La capacidad de L1 también aumenta de 16 KB a 32 KB
- Una caché más grande puede elevar el hit rate, reducir la latencia promedio de acceso a memoria y mejorar el aprovechamiento de las unidades de ejecución
- Como traer datos desde L2 o niveles superiores consume energía, un mayor hit rate también puede ayudar a la eficiencia energética
- Ponte Vecchio sigue siendo fuerte en L1
- Cada Xe Core ofrece 512 bytes por ciclo
- La capacidad de L1 es de 512 KB
- Los kernel limitados por memoria que caben en L1 pueden funcionar muy bien en la arquitectura de Intel
- Sin embargo, como no hay una caché de nivel intermedio a escala de Compute Tile, si los datos sobrepasan L1 el rendimiento puede caer bruscamente
Scheduling y unidades de ejecución
- Además de la estructura de chiplets y caché que hace que MI300X se vea como una sola GPU, CDNA 3 también refina de forma iterativa la arquitectura de Compute Unit para abordar el problema de aprovechamiento de FP32 en CDNA 2
- CDNA 2 procesaba FP64 de forma nativa y ofrecía FP32 a doble tasa mediante packed execution
- El compilador tenía que empaquetar dos valores FP32 en registros adyacentes y ejecutar la misma instrucción
- Si el programador no usaba vectores explícitamente, muchas veces era difícil que el compilador lograra hacerlo bien
- CDNA 3 evita este problema con un mecanismo más flexible de dual issue
- Parece más cercano a una extensión de la capacidad multi-issue de GCN que al enfoque VOPD/wave64 de RDNA 3
- En cada ciclo, el scheduler de la CU elige uno de los cuatro SIMD y revisa si hay hilos listos para ejecutar
- Si hay varios hilos listos, GCN podía enviar hasta 5 a las unidades de ejecución
- Es probable que el dual issue de CDNA 3 dependa más de que el programador exponga thread-level parallelism con un dispatch size grande que del compilador
- Si un SIMD tiene más hilos en ejecución, aumenta la probabilidad de encontrar al mismo tiempo dos hilos con instrucciones FP32
- Para alcanzar el throughput FP32 completo, se necesitan al menos 2 hilos activos por SIMD
- En la práctica, se requiere una occupancy mayor por la latencia de memoria o de ejecución
- AMD aumentó mucho la cantidad de hilos que un SIMD de CDNA 3 puede seguir, de 8 a 24
- No se mencionó un aumento en la capacidad del vector register file, y esa capacidad suele limitar la cantidad de hilos que un SIMD puede mantener al mismo tiempo
- La capacidad multi-issue puede funcionar mejor en kernel simples con poco uso de registros por hilo
- El dual issue también puede convertir el ancho de banda del register file en un problema
- El packed FP32 de CDNA 2 aprovechaba puertos anchos del register file para mover valores de 64 bits sin requerir lecturas adicionales
- Instrucciones separadas pueden referirse a registros distintos y exigir más lecturas
- AMD afirma haber mejorado generacionalmente el source caching para que una sola lectura del vector register pueda alimentar más operaciones vectoriales o matriciales downstream
- Probablemente se trate de una register cache más grande para aliviar conflictos de puertos y abastecer de datos a las unidades de ejecución
Operaciones matriciales y rendimiento de IA
- Con la expansión del machine learning, la multiplicación de matrices ganó importancia, y Nvidia invirtió fuertemente en esta área al agregar tensor cores en Volta y Turing
- AMD CDNA también soportaba matrix multiply, pero las arquitecturas contemporáneas de Nvidia invirtieron más en throughput matricial con tipos de datos de menor precisión como FP16
- MI300X duplica el throughput matricial por CU frente a las generaciones anteriores de CDNA
- El diseño con chiplets de MI300X permite una cantidad muy alta de CU, lo que aumenta el throughput total
- Nvidia sigue siendo un competidor muy fuerte gracias a su alto rendimiento matricial por SM, y CDNA 3, en la línea habitual de AMD, mantiene un fuerte rendimiento de IA al mismo tiempo que presiona con fuerza a Nvidia con su rendimiento vectorial FP64
Cambios en la caché de instrucciones
- La Compute Unit necesita traer desde memoria no solo el acceso a la memoria de datos, sino también las propias instrucciones
- El código de GPU tradicionalmente ha sido simple y de tamaño pequeño, por lo que la entrega de instrucciones era relativamente fácil
- Las GPU CDNA 2 y RDNA siguieron usando una caché de instrucciones de 32 KB, pero CDNA 3 la aumentó a 64 KB
- la asociatividad también aumentó de 4-way a 8-way
- esto eleva la tasa de aciertos de la caché de instrucciones en kernels más grandes y complejos
- AMD parece haber tenido en cuenta los casos en que código de CPU se porta de forma simple a la GPU
- el código de CPU complejo puede representar una carga para la GPU
- a la GPU le cuesta ocultar la latencia de un miss en la caché de instrucciones con prefetching de instrucciones a larga distancia y predicción de saltos precisa
- una caché de instrucciones más grande ayuda a alojar kernels grandes, y una mayor asociatividad reduce los conflict misses
- La instancia de caché de instrucciones de CDNA 3 es compartida por dos Compute Unit, igual que en CDNA 2
- como los kernels de GPU normalmente se ejecutan con un tamaño de trabajo lo bastante grande como para llenar muchas Compute Unit, compartir la caché de instrucciones es una forma eficiente de usar SRAM
- si más Compute Unit comparten una sola instancia de caché, puede volverse difícil satisfacer los requisitos de ancho de banda de instrucciones
Diferencias entre MI300X y MI300A
- El mayor cambio generacional de CDNA 3 está en la jerarquía de memoria, y la mejora clave real está en la incorporación de Infinity Cache
- El principal problema de MI250X era que se parecía más a dos GPU que comparten el mismo paquete que a una sola GPU
- el ancho de banda entre los dos GCD era de 200 GB/s por dirección
- AMD determinó que ese ancho de banda no era suficiente para que MI250X pareciera una sola GPU, así que incrementó de forma importante el ancho de banda die-to-die
- MI300 aumenta el ancho de banda total East-West a 2.4 TB/s por dirección, 12 veces más que en MI250X
- el ancho de banda total North-South es aún mayor, de 3.0 TB/s por dirección
- con este aumento de ancho de banda, MI300 puede verse como un único acelerador grande e integrado, en lugar de dos aceleradores como MI250X
- El ancho de banda total de ingreso de 4.0 TB/s de un solo die de IO casi coincide con los 4.2 TB/s que pueden usar dos XCD, por lo que en la práctica no es un gran problema
- aun así, un solo die de IO no puede aprovechar todo el ancho de banda total de memoria de 5.3 TB/s
- esto es similar a la situación en Ryzen 7000, donde un solo CCD no puede aprovechar por completo el ancho de banda de DDR5 debido a las limitaciones de Infinity Fabric
- en MI300X, la demanda de ancho de banda es más alta cuando todos los dies trabajan juntos, y en ese caso cada die consume alrededor de 1.3 TB/s, por lo que tomar 3/4 a través del enlace cross-die no representa un problema
- MI300A es un APU de “big iron” que reutiliza el mismo base die mientras combina 6 XCD CDNA3 y 24 núcleos Zen 4
- la CPU y la GPU pueden compartir el mismo espacio de direcciones de memoria
- ya no es necesario copiar datos por un bus externo para mantener la coherencia entre CPU y GPU
1 comentarios
Comentarios en Hacker News
Técnicamente, las tarjetas de consumo de AMD tienen un gran rendimiento de cómputo. Por ejemplo, UE5 renderiza mallas triangulares con cómputo en lugar de usar el pipeline gráfico https://www.youtube.com/watch?v=TMorJX3Nj6U
Además, como nVidia priorizó ray tracing y DLSS por encima del rendimiento de cómputo y del ancho de banda de memoria, hay muchos casos en los que una tarjeta AMD supera a una nVidia equivalente
El problema es que ninguna empresa tecnológica quiere agregar backends de D3D o Vulkan a bibliotecas de IA como PyTorch. nVidia no lo hace porque le conviene mantener el status quo, e Intel y AMD tampoco porque intentan reemplazar CUDA con sus propias alternativas propietarias en vez de usar APIs de GPU abiertas
Aun así, no es una torpe segmentación de producto ni un problema de arquitectura superior. Los productos especializados hacen mejor su trabajo que los productos de propósito general. La demanda de una tarjeta que haga bien tanto cómputo como gaming es pequeña, y aunque esa gente existe, son menos que quienes solo se enfocan en una de las dos cosas
El efecto de separar GCN en RDNA y CDNA fue inmediato. Si comparas la Radeon VII (GCN 5) con la RX 5700 XT (RDNA 1), en juegos van de ida y vuelta y en promedio la Radeon VII queda apenas por delante, pero la RX 5700 XT queda muy atrás en benchmarks de cómputo. Ambas son TSMC 7nm, pero la RX 5700 XT tiene menos shaders (2560 vs 3840), un die más pequeño (251 vs 311 mm2) y menor consumo (225 vs 300 W), lo que muestra que es mucho más eficiente para gaming. Con menor consumo, menos ruido y un precio cientos de dólares más bajo, era una tarjeta mucho más atractiva para gamers
Las tarjetas CDNA parecen carecer de componentes necesarios para juegos, como las unidades de salida de renderizado. Por eso no tienen soporte oficial para DirectX, OpenGL ni Vulkan. Nunca he visto un caso de alguien usándolas para jugar. En cambio, su rendimiento de cómputo es tan bueno que, pese al abrumador ecosistema de CUDA, varias empresas están comprando estas tarjetas en lugar de nVidia. En 2013, una supercomputadora basada en GCN entró al top 100, y fue el único sistema basado en GCN en ese top 100. Ahora, 8 de las 10 supercomputadoras más eficientes energéticamente usan aceleradores CDNA, y la supercomputadora más rápida del mundo también usa CDNA
https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
Fundamentalmente es una empresa de hardware (como lo muestra también la trayectoria de Lisa Su), y no aceptó lo bastante rápido que CUDA fue el golpe decisivo. Recuerdo en Phoronix a @Bridgman librando una guerra de retirada constante para intentar retener desarrolladores. Era una pelea imposible de ganar
Hasta cierto punto se entiende. La generación de hardware de los 80/90 piensa instintivamente que el hardware está en la cima del stack, y toda la dirección de AMD, incluida Su, viene de ese mundo
Kodura entendió que nVidia estaba aplastando a AMD porque CUDA también funcionaba en tarjetas de consumo. Por eso se enfrentó a Lisa Su para impulsar la Radeon VII, y esa tarjeta fue durante años, hasta hace muy poco, la única tarjeta de consumo con soporte de ROCm. Poco después, en la práctica lo despidieron, y la RVII, que era una gran tarjeta, también fue retirada rápidamente. Luego llegó Wang y consolidó la separación entre consumo y profesional
Ahora AMD intenta desesperadamente revertirlo, pero ya es demasiado tarde. Hay varios lugares donde intenta competir, pero en la práctica el único que vale la pena mencionar es AAPL con Metal
AMD dejó pasar la oportunidad
Aun así, no parece que eso le haya ayudado a la adopción de las tarjetas AMD para cargas de cómputo. Lo bueno de CUDA es que no necesitas una tarjeta aceleradora especial para desarrollar código CUDA
Si tuvieran que comprar las GPUs con su propio dinero o con fondos de investigación, pagando el mismo precio que un consumidor común, tal vez la situación sería distinta
Personalmente, me parece que la forma en que NVidia se infiltra en la academia y en el entorno de investigación universitaria es muy poco ética
Después siguieron esperando y apostando la empresa varias veces a que el mercado para el producto que habían construido “iba a llegar”
En los últimos años eso efectivamente ocurrió, y también se reflejó en la acción. Los otros jugadores básicamente vienen con 10 años de retraso, y viendo el entusiasmo actual y la popularización de los flujos de trabajo de AI/ML, parece casi imposible que alguien los alcance
En cambio, el código CUDA siguió funcionando incluso cuando salieron nuevas generaciones de tarjetas Nvidia
La mayoría está comprando A6000 o superiores a precio de consumidor en empresas como Exxact o Supermicro
Desde la época de la V100, es decir, después de los sistemas DGX-1, no creo haber visto ni una sola vez que a un investigador le den una GPU gratis
A diferencia de la CPU, la GPU no intenta compensarlo directamente. En vez de eso, acepta una latencia más alta y, en comparación con la CPU, paraleliza mucho más —o de forma más agresiva—, y una gran cantidad de pseudohilos paralelos proporciona el efecto de ocultamiento de latencia
Este efecto puede verse, por ejemplo, en presentaciones sobre optimización de código para GPU
https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
La animación que aparece a partir de la diapositiva 11 es un ejemplo
Es decir, mucho trabajo puede resolverse únicamente en registros y LDS, y los accesos a memoria global son mucho menos frecuentes que en una CPU, donde casi todo está en memoria global y suele haber alrededor de 16 registros arquitectónicos
Aun así, la memoria global sigue siendo un problema. No solo por la latencia, sino también por el ancho de banda. Por eso RDNA2 y Ada añadieron grandes cantidades de caché de última etapa. Sirve en parte para ocultar mejor la latencia, pero su propósito principal es actuar como amplificador de ancho de banda
Very long instruction word (VLIW) se refiere a una arquitectura de conjunto de instrucciones diseñada para aprovechar el paralelismo a nivel de instrucción (ILP). En general, una unidad central de procesamiento (CPU) normal solo hace que el programa indique qué instrucciones ejecutar en orden, pero un procesador VLIW permite que el programa especifique explícitamente qué instrucciones deben ejecutarse en paralelo. El objetivo de este diseño es lograr mayor rendimiento evitando la complejidad inherente de otros enfoques
Entre los métodos tradicionales para aumentar el rendimiento del procesador están el pipeline, que divide las instrucciones en subetapas para ejecutar algunas simultáneamente; la arquitectura superescalar, que envía instrucciones individuales para que se ejecuten de forma independiente en distintas partes del procesador; e incluso la ejecución fuera de orden, que ejecuta instrucciones en un orden distinto al del programa. Estos enfoques complejizan el hardware porque obligan al procesador a tomar internamente todas las decisiones
https://en.wikipedia.org/wiki/Very_long_instruction_word
No le fue muy bien. Por eso le decían Itanic
La premisa era que el compilador pudiera determinar estáticamente suficientes dependencias como para meter varias rutas de ejecución secuencial y algunas rutas de ejecución con bifurcaciones dentro de una misma instrucción. Pero al final quedó claro que los compiladores no podían hacerlo así, y por eso el procesador terminó teniendo que encontrar dinámicamente dependencias e instrucciones paralelizables dentro del flujo secuencial de instrucciones
Eso requiere mucho trabajo, muchos recursos del chip y mucha energía. Y solo funciona bien hasta cierto punto; después se topa con rendimientos decrecientes. Parece que justo ahí es donde estamos hoy
No se refiere al lenguaje con el que se envían instrucciones, sino al método de procesamiento en sí
Y también conviene tener presente que términos como VLIW4 o VLIW5 se refieren a implementaciones específicas
https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
1: https://trends.google.com/trends/explore?date=all&q=Compute&...