La tesis central de NVIDIA Olympus es que el rendimiento single-threaded sigue siendo crítico en el ámbito de los servidores, incluso con el aumento de los conteos de núcleos. En lugar de perseguir altas frecuencias de reloj, Olympus se enfoca en maximizar la cantidad de trabajo realizado por ciclo de reloj (IPC) a través de estructuras out-of-order masivas y una implementación de Simultaneous Multi-Threading (SMT) poco convencional. Este enfoque desafía la tendencia histórica de los chips de servidor de sacrificar el rendimiento single-threaded por un mayor número de núcleos, buscando un equilibrio que optimice la ejecución de cargas de trabajo sensibles a la latencia y con baja paralelización de hilos.
Históricamente, los procesadores de servidor se han diferenciado de los de cliente por priorizar la densidad de núcleos y la eficiencia energética total del socket, a menudo a expensas del rendimiento de un solo hilo. Esto se debía a que muchas cargas de trabajo de servidor eran inherentemente paralelas y podían escalar con más núcleos. Sin embargo, la realidad de muchas aplicaciones empresariales y de infraestructura moderna, que incluyen componentes con cuellos de botella single-threaded o que no escalan linealmente con el número de hilos, ha reavivado la necesidad de un rendimiento robusto por núcleo. Olympus aborda esta necesidad fundamental de la computación distribuida, donde la latencia de una operación crítica puede dominar el rendimiento general del sistema, incluso en un entorno con miles de núcleos.
Arquitectura del Sistema
Olympus es un núcleo de 10 vías out-of-order con una frecuencia de reloj modesta de 3.3 GHz. Su diseño se caracteriza por estructuras out-of-order de gran tamaño, incluyendo un Instruction TLB (iTLB) de 64 entradas, una Instruction Cache (iCache) de 64 KB (4-way set associative) que puede entregar 128 bytes por ciclo, y una cola de decodificación de 48 instrucciones. El predictor de ramas es robusto, capaz de seguir entre 5K y 48K patrones globales, y puede predecir dos ramas tomadas por ciclo, utilizando 'ahead indexing' para mejorar el throughput.
El backend de ejecución es masivo, con archivos de registro y colas de programación significativamente grandes. Cuenta con ocho ALUs de enteros organizadas en pares, cada una alimentada por una cola de programación de aproximadamente 25 entradas. La FPU tiene seis pipelines, con una cola no-programadora delante de las colas de programación más pequeñas. La jerarquía de memoria de datos incluye una Data Cache (D-Cache) L1 de 96 KB (6-way set associative) con una latencia nominal de 4 ciclos, respaldada por una L2 de 2 MB (8-way set associative) con 10 ciclos de latencia load-to-use. La L3 es de 164 MB con una latencia superior a 120 ciclos, compensada por un prefetching agresivo que soporta 50-51 solicitudes pendientes. El Data TLB (dTLB) es de 112 entradas, respaldado por un L2 TLB unificado de 3K entradas, con soporte para páginas de 64 KB para extender el alcance del TLB.
La característica más distintiva es su implementación de SMT, denominada 'spatial multithreading'. A diferencia de las implementaciones SMT convencionales que comparten recursos de forma flexible, Olympus particiona estáticamente casi todos los recursos del núcleo (incluyendo iCache, D-Cache L1/L2, colas de programación y unidades de ejecución) cuando se ejecutan dos hilos. Esto significa que cada hilo accede a la mitad de la capacidad disponible, lo que simplifica la garantía de equidad y el diseño del núcleo, aunque puede llevar a subutilización de recursos en ciertos escenarios.
| Capa | Tecnología | Justificación |
|---|---|---|
| compute | NVIDIA Olympus CPU Core | Procesador principal para cargas de trabajo de servidor, enfocado en alto rendimiento single-threaded y eficiencia por ciclo. vs AMD Zen 5 (server), Intel Lion Cove (server), Arm Neoverse V2, Arm Neoverse N2 10-wide out-of-order core, 3.3 GHz clock speed, 'spatial multithreading' SMT implementation. |
| cache | L1 Instruction Cache | Almacenar instrucciones de forma rápida para alimentar el frontend del pipeline, con una capacidad de 64 KB y 4-way set associative. vs Diferentes tamaños de caché (32KB, 128KB), Diferentes asociatividades 64 KB, 4-way set associative, 128 bytes/cycle throughput. |
| cache | L1 Data Cache | Almacenar datos de acceso frecuente para reducir la latencia de memoria, con una capacidad de 96 KB y 6-way set associative. vs Diferentes tamaños de caché (32KB, 48KB, 64KB), Diferentes asociatividades 96 KB, 6-way set associative, 4-cycle nominal latency. |
| cache | L2 Cache | Caché de segundo nivel para capturar misses de L1, con 2 MB de capacidad y 8-way set associative, ofreciendo baja latencia. vs 1 MB L2 (Grace), Diferentes tamaños y asociatividades 2 MB, 8-way set associative, 10-cycle load-to-use latency. |
| cache | L3 Cache | Caché de tercer nivel para reducir la latencia de acceso a memoria principal, con 164 MB de capacidad y prefetching agresivo. vs 114 MB L3 (Grace), Diferentes estrategias de prefetching 164 MB, >120 cycle latency, aggressive prefetching supporting 50-51 outstanding requests. |
| compute | Branch Predictor | Predecir el flujo de ejecución del programa para evitar stalls en el pipeline debido a saltos, con soporte para 'ahead indexing'. vs Diferentes algoritmos de predicción (gshare, perceptron), Diferentes tamaños de BTB/historial Capaz de seguir 5-48K patrones globales, 2 taken branches/cycle, 16K entry BTB (4 cycle latency). |
| compute | Translation Lookaside Buffer (TLB) | Caché de traducciones de direcciones virtuales a físicas para reducir la latencia de acceso a la tabla de páginas. vs Diferentes tamaños de TLB, TLBs separados para instrucciones/datos 64 entry fully associative iTLB, 112 entry fully associative dTLB, unified 3K entry L2 TLB, 64 KB page support. |
Trade-offs
Ganancias
- ▲ Rendimiento single-threaded
- ▲ IPC (Instructions Per Cycle)
- △ Facilidad de diseño y garantía de equidad SMT
- ▲ Throughput en cargas de trabajo frontend-bound con SMT
Costes
- △ Frecuencia de reloj
- ▲ Utilización de recursos en SMT (por particionamiento estático)
- ▲ Rendimiento SMT en cargas de trabajo backend-bound
- ▲ Latencia L3
Fundamentos Teóricos
El diseño de Olympus, con su énfasis en el rendimiento por ciclo y las estructuras out-of-order masivas, se basa en décadas de investigación en arquitectura de microprocesadores. Conceptos como el 'out-of-order execution' y el 'branch prediction' fueron formalizados en trabajos seminales como el de Johnson (1991) en 'Superscalar Microprocessor Design', que describió los fundamentos de la ejecución especulativa y la reordenación de instrucciones para explotar el paralelismo a nivel de instrucción (ILP). La necesidad de estructuras de reordenamiento profundas y predictores de ramas sofisticados se deriva directamente de la búsqueda de un mayor ILP.
La implementación de SMT en Olympus, aunque 'espacial' y estáticamente particionada, se relaciona con el concepto general de 'Simultaneous Multithreading' propuesto por Tullsen, Eggers y Levy (1995) en 'Simultaneous Multithreading: Maximizing On-Chip Parallelism'. Si bien la mayoría de las implementaciones SMT buscan compartir dinámicamente los recursos del núcleo para maximizar la utilización, la estrategia de particionamiento estático de NVIDIA puede verse como una simplificación para garantizar la equidad y la previsibilidad del rendimiento, aunque con posibles compromisos en la utilización total de recursos. Este enfoque contrasta con la complejidad de los algoritmos de asignación de recursos dinámicos en SMT convencionales, que buscan optimizar el throughput global del núcleo bajo diversas cargas de trabajo.