Bienvenido a la parte más reconocible e innovadora de esta consola.
Introducción
La CPU de la PS3 es enormemente compleja, pero también un ejercicio de ingeniería fascinante. Este afronta necesidades complejas con soluciones poco convencionales, muy representativas de una era marcada por el cambio y la experimentación. Antes de adentrarnos en las entrañas de la CPU de la PS3, he escrito los siguientes párrafos para aportar algo de contexto histórico. De ese modo, podremos descomponer el chip de arriba abajo de forma que no solo entiendas cómo funciona, sino también la razón de ser de sus principales decisiones de diseño.
El estado del progreso
La CPU del PS1 (1994). Diseñada por LSI y Sony con tecnología de MIPS.
El Emotion Engine del PS2 (2001). Diseñado por Toshiba, de nuevo con tecnología MIPS.
Casi diez años después de la presentación del PlayStation original basado en MIPS, nos encontramos a comienzos de la primera década del 2000 y las perspectivas para SGI/MIPS no son nada halagüeñas. Nintendo acaba de abandonarlos en favor de un núcleo PowerPC de gama baja con IBM como nuevo proveedor, mientras que Microsoft, el recién llegado al mercado, optó por Intel y su dominio x86.
Sony tiene costumbre de tomar diseños de gama baja ya existentes (núcleos MIPS económicos) y moldearlos para alcanzar un rendimiento 3D aceptable a un coste reducido, un proceso en el que han participado otras empresas como LSI (para la CPU del PS1) y Toshiba (para el Emotion Engine del PS2). Esta metodología se prolongó hasta 2004 con el lanzamiento de la PlayStation Portable. Dicho esto ¿qué nueva amalgama de MIPS iban a construir para la PlayStation 3?
Resulta que el desarrollo de la PlayStation 3 es anterior al de la PlayStation Portable . En el año 2000, pocos meses después del lanzamiento del PS2, Sony formó una alianza con IBM y Toshiba denominada 'STI', con el único objetivo de desarrollar el siguiente chip capaz de impulsar la próxima generación de superordenadores . Por si esto no sonaba ya lo suficientemente ambicioso, ese nuevo chip también serviría para la sucesora del PS2. Finalmente, en 2004, IBM presentó el Cell Broadband Engine (también conocido como 'Cell BE' o simplemente 'Cell') .
Nuevas filosofías de diseño
El chip Cell Broadband Engine. Lamentablemente, demasiado brillante para mi cámara.
Para entender la propuesta radical de Cell, conviene tener en cuenta los problemas que acuciaban a esa época (finales de los 90, principios de los 2000).
Año tras año, los consumidores exigen más velocidad. Así ha sido siempre. Sin embargo, el último enfoque empleado para lograrlo (aplicar un pipeline al datapath y aumentar la frecuencia de reloj) está dejando de escalar. El NetBurst de Intel no puede evolucionar más y su prometido sucesor no aparece por ningún lado. De manera similar, el PowerPC 970/G5 de IBM no puede cumplir su promesa de '3 GHz' ni desarrollar una versión de bajo consumo (motivo por el que Apple no puede lanzar ningún portátil con su CPU de última generación) . En definitiva, parece que los ingenieros se enfrentan a una nueva crisis de escalabilidad.
Así, la atención se vuelca en la computación distribuida . En otras palabras: ¿por qué obsesionarse con exprimir el rendimiento de una sola máquina cuando se podrían tener varias máquinas más pequeñas repartiendo la carga de trabajo? Este enfoque no es, ni mucho menos, nuevo, dado que todas las consolas analizadas en este sitio web cuentan con más de un procesador. Sin embargo, es el desarrollo de un 'único procesador con múltiples núcleos' lo que abre nuevas oportunidades para el diseño de CPU (no necesariamente limitadas al mercado de las consolas).
En consecuencia, Cell forma parte de esta nueva ola de investigación y desarrollo. Esta nueva CPU combina un diseño multinúcleo con un énfasis especial en el procesamiento vectorial. Como recordarás, la computación vectorial es óptima para simulaciones (física, iluminación, etc.) y se materializó anteriormente en forma del Geometry Transformation Engine o de las Vector Units, pero enseguida verás por qué el diseño de Cell supone un salto enorme respecto a los dos anteriores.
Una nueva era multinúcleo
Ejemplo de diseño heterogéneo.
Ha sido la arquitectura de facto de muchas consolas potentes hasta la fecha.
Ejemplo de diseño homogéneo.
Cada núcleo puede llevar a cabo las mismas tareas que antes, pero no está necesariamente limitado a ellas.
Si te paras a pensarlo, tanto la CPU del PS1 como el Emotion Engine eran ya procesadores multinúcleo. ¿Por qué tanto revuelo con Cell, entonces? Los dos chips anteriores estaban compuestos de un núcleo de uso general y varios núcleos específicos para determinadas aplicaciones (procesador de audio, descompresión de imagen, etc.), mezclando distintas arquitecturas, donde el núcleo de uso general se encargaba de comandar a los demás.
Este tipo de diseño de CPU recibe el nombre de computación heterogénea, y ha sido la opción de facto para construir máquinas especializadas en un conjunto concreto de aplicaciones (los videojuegos, en este caso). Su contraparte, la computación homogénea, predomina en el mercado de los ordenadores, donde las CPU deben ejecutar una gama más amplia de tareas (todas con la misma prioridad). Por ello, este último tipo puede integrar múltiples núcleos, pero todos del mismo tipo.
Volviendo al tema, Cell combina ambos modelos: hay dos tipos de núcleos en esta CPU, un 'líder' de uso general y ocho 'asistentes' vectoriales. Estos núcleos vectoriales pueden asumir distintos roles y, al hacerlo, cubren las tareas que antes resolvían los diseños heterogéneos; pero como los vectores de Cell no están limitados a un único tipo de tarea, sus núcleos ofrecen la flexibilidad propia de los ordenadores homogéneos. En definitiva, este diseño no es perfecto y arrastra ciertos compromisos, pero a lo largo de este texto verás los distintos problemas que Cell intentó resolver y cómo lo logró.
Una ojeada a Cell
Tras exponer toda esta historia y teoría, creo que ya estamos preparados para presentar al protagonista de esta sección. Así es Cell ...
El Cell Broadband Engine (variante PS3).
Diseñado por IBM para supercomputación y simulación científica. El 'SPE' tachado indica que está deshabilitado (inutilizable). El otro 'SPE' de la izquierda está reservado al sistema operativo.
... y al final de esta sección sabrás qué hace cada componente.
Estructura general
Cell funciona a una frecuencia de nada menos que 3,2 GHz y está compuesto por multitud de componentes. Para facilitar el análisis, esta CPU puede dividirse en tres grandes áreas :
- El líder: es la parte de Cell que dirige al resto del circuito. Aquí encontramos un componente denominado PowerPC Processor Element (PPE).
- Los asistentes: son tan esenciales como el PPE, pero sus capacidades se limitan a un rol de asistente y acelerador. Este grupo está formado por ocho Synergistic Processor Elements (SPE).
- Las interfaces: a medida que la demanda de ancho de banda crece de forma exponencial, se implementan nuevas interfaces para mover datos sin generar cuellos de botella. En el grupo de interfaces encontramos un puñado de protocolos: el Element Interconnect Bus (EIB), el Broadband Engine Interface Unit (BEI), el Memory Interface Controller (MIC) y los Flex I/O buses.
Esta información se retomará a lo largo del artículo con más detalle, así que no hace falta que memorices estos nombres. El objetivo principal de esta sección es que te formes una imagen mental de la naturaleza de Cell y te familiarices con todos los componentes de los que hablaremos en su momento.
Cómo está organizado este análisis
Vista la estructura anterior, he tenido que organizarlo de forma que no te satures con tanta información. Así pues, analizaremos Cell estudiando cada componente en este orden:
- El bus que conecta todos los componentes: el Element Interconnect Bus (EIB).
- El PowerPC Processor Element (PPE) y su elemento central, el PowerPC Processing Unit (PPU).
- Qué memoria de uso general hay disponible en esta consola.
- Los Synergistic Processor Elements (SPE) y su elemento central, el Synergistic Processor Unit (SPU).
- El modelo de programación ideado para programar Cell de forma eficiente.
Dicho esto, comencemos con el análisis en sí.
El interior de Cell: el corazón
Desde su presentación, Cell se ha denominado Network-on-Chip (NoC) en lugar de la definición tradicional de Sistema en Chip (SoC, del inglés System-on-Chip); esto se debe al inusual bus de datos de Cell, el Element Interconnect Bus (EIB). Ya hemos visto lo exigentes que pueden ser los componentes de una CPU y lo susceptible que es un sistema a los cuellos de botella. Pues bien, para abordar este problema por undécima vez, IBM ha ideado un nuevo diseño... y lo ha documentado con términos análogos a la conducción por carretera.
Diagrama simplificado del Element Interconnect Bus (EIB).
Cada flecha entre 'Ramps' (nodos) representa dos buses unidireccionales; así, cada nodo está conectado al siguiente mediante cuatro canales.
El EIB está formado por doce nodos denominados Ramps, cada uno de los cuales conecta un componente de Cell. Los Ramps están interconectados mediante cuatro buses: dos circulan en sentido horario y los otros dos en sentido antihorario. Cada bus (o canal) tiene 128 bits de ancho. En lugar de recurrir a topologías de bus único (como hacían el Emotion Engine y su predecesor), los Ramps están interconectados siguiendo la topología de token ring, en la que los paquetes de datos deben atravesar todos los nodos vecinos hasta llegar al destino (no existe una ruta directa). Dado que el EIB dispone de cuatro canales, existen cuatro rutas posibles (anillos).
Quizás te preguntes: ¿qué sentido tiene un token ring si los datos pueden acabar recorriendo trayectos más largos (en comparación con un bus directo único)? Un bus único es muy susceptible a la congestión. Por eso, los ingenieros del EIB optaron por esta topología para gestionar grandes volúmenes de tráfico concurrente (sigue leyendo si quieres saber cómo ayudó el token ring).
Los datos se transfieren en forma de paquetes de 128 bits . Cada anillo puede gestionar hasta tres transferencias concurrentes, siempre que los paquetes no se solapen. El EIB opera mediante créditos de comando: cuando un componente necesita iniciar una transferencia, envía una solicitud al Data Arbiter del EIB, que gestiona el tráfico dentro de los anillos. En cuanto la solicitud es aprobada, los paquetes entran en el anillo y reciben un 'token', que el Data Arbiter usa como metadato para supervisar la transferencia. Además, algunos componentes tienen prioridad preferente sobre otros, como el Memory Interface Controller (MIC), donde reside la RAM principal. Por último, el Data Arbiter nunca colocará paquetes en anillos cuyo trayecto supere la mitad del anillo.
Cada Ramp interviene en la transferencia: lee la dirección de destino del paquete para decidir si envía los datos a su componente correspondiente o los reenvía al siguiente Ramp. Durante cada ciclo de reloj, los Ramps pueden recibir y enviar paquetes de 128 bits (16 bytes) al mismo tiempo. Así, teniendo en cuenta que hay cuatro canales y que el EIB opera a 1,6 GHz (la mitad de la velocidad de Cell), la tasa de transferencia teórica máxima es: 16 bytes x 2 transferencias/ciclo x 4 anillos x 1,6 GHz = 204,8 GB/s. Este valor es, por supuesto, demasiado optimista, y hay muchos otros factores externos (el trayecto origen/destino, el estado del bus, etc.) que condicionan el rendimiento real. En cualquier caso, numerosas publicaciones de investigación de IBM y otros autores han recopilado velocidades más realistas mediante experimentos prácticos .
Ahora que ya sabes cómo se interconectan todos los componentes de Cell, es hora de conocer el primer componente de este chip...
El interior de Cell: el líder
Aquí echaremos un vistazo a la 'parte principal' de Cell: la porción de silicio encargada de comandar al resto. El nombre de este componente es PowerPC Processor Element (PPE), y puedes concebirlo como el MIPS R5900 del Emotion Engine.
Composición del PPE
¿Recuerdas cómo dividí Cell en distintas áreas antes? Lo mismo puede hacerse con el PPE. IBM usa el término 'element' para describir la máquina independiente , pero en su interior usa el término 'unit' para separar el circuito central de las interfaces que comunican con el resto de Cell.
Diagrama simplificado del PowerPC Processor Element (PPE).
Dicho esto, el PowerPC Processor Element está sorprendentemente compuesto de dos partes:
- PowerPC Processing Unit (PPU): es la parte lógica del PPE (el 'núcleo'). ¡No lo confundas con la PPU de Nintendo! (aunque comparten las mismas letras del alfabeto latino... en el mismo orden...).
- PowerPC Processor Storage Subsystem (PPSS): la gran interfaz que conecta el PPU con el mundo exterior. Además, proporciona nada menos que 512 KB de caché L2.
Como puedes ver, el diseño del PPE (y del resto de Cell) es bastante modular, siguiendo los principios del diseño RISC. Pronto verás que esa modularidad se aplica incluso dentro del PPU.
El PowerPC Processing Unit
A continuación vamos a echar un vistazo al interior del PPU. Como recordatorio: hemos entrado en Cell, luego en el PPE y, finalmente, en el PPU. Lo analizaremos como cualquier otro núcleo de CPU.
Una arquitectura familiar
Para empezar, el PPU no se construyó desde cero, sino que reutiliza tecnología PowerPC ya existente. Sin embargo, a diferencia de iteraciones anteriores en las que IBM tomaba un procesador ya existente y lo actualizaba a medias para cumplir nuevos requisitos, el PPE no replica ningún diseño de CPU previo. En cambio, IBM construyó una nueva CPU que sigue la versión 2.02 de la especificación PowerPC (que resulta ser la última especificación PowerPC antes de rebautizarse como 'Power ISA'). En resumen, no encontrarás el diseño del PPU en ningún chip de aquella época, aunque se programa con el mismo código máquina que otros chips PowerPC.
¿Por qué eligió IBM la tecnología PowerPC para desarrollar un chip de alto rendimiento? Sencillo: PowerPC es una plataforma madura que disfrutó de unos diez años de pruebas y revisiones por parte de la base de usuarios de Macintosh, cumple todos los requisitos de Sony y, en caso de necesidad, puede adaptarse a distintos entornos. Por último, el uso de una arquitectura bien conocida es una buena noticia para los compiladores y bases de código existentes, lo que, para una nueva consola, supone una ventaja de partida considerable.
Vale la pena mencionar que IBM fue uno de los autores de los primeros chips PowerPC, junto con Motorola y Apple (recuerda la alianza AIM). Con todo, a principios de los 2000, los denominados miembros de la alianza ya trabajaban por separado, con Motorola/Freescale desarrollando una serie PowerPC distinta a la de IBM.
Características distintivas
El PPU comparte historia con el PowerPC 970 (llamado G5 por Apple): ambos son descendientes del POWER4, un predecesor de PowerPC empleado principalmente en estaciones de trabajo y superordenadores. Esto se hará más evidente cuando muestre las unidades de ejecución modularizadas. Supone un cambio radical respecto a la CPU 750 del GameCube, en la que Motorola tuvo un aporte considerable y que IBM luego modificó ligeramente.
Volviendo al tema, el PPU es un procesador de 64 bits completo. Esto significa:
- El tamaño de una palabra es de 64 bits.
- Dispone de registros de uso general de 64 bits (32 en total).
- El bus de datos tiene al menos 64 bits de ancho: en las siguientes secciones del artículo verás que es mucho más ancho que eso, pero por ahora quédate con que transferir palabras de 64 bits no penalizará el rendimiento.
- El bus de direcciones tiene 64 bits de ancho: en teoría, la CPU puede acceder a hasta 16 exabytes de memoria. En la práctica, esto es muy costoso si la máquina no alberga toda esa memoria, así que las CPU modernas delegan el direccionamiento en la Unidad de Gestión de Memoria (MMU, del inglés Memory Management Unit) para dar más usos al bus de direcciones.
Por último, el PPU implementa la PowerPC ISA versión 2.02, incluyendo opcodes opcionales para la raíz cuadrada en punto flotante . Además, se ha ampliado con un grupo de instrucciones SIMD llamado Vector/SIMD Multimedia Extension (VMX). Por otro lado, algunos elementos de la especificación original están ausentes, como el modo little-endian (de hecho, Cell solo opera en big-endian) y un puñado de opcodes.
Los bloques del PPU
Si aplicamos una visión 'microscópica' al PPU, podemos observar que esta unidad está compuesta de distintos bloques o subunidades que realizan operaciones independientes (leer valores de memoria, ejecutar operaciones aritméticas, etc.). Las capacidades del PPU vienen determinadas por lo que cada bloque puede hacer y cómo:
Instrucciones
Diagrama simplificado de la Instruction Unit (IU).
El primer bloque se denomina Instruction Unit (IU) y, como su nombre indica, lee instrucciones de la caché L2 y señaliza a otras unidades para que realicen la operación solicitada. Al igual que sus contemporáneos i686, parte del set de instrucciones se interpreta mediante microcode (la IU incorpora una pequeña ROM a tal efecto). La IU también alberga 32 KB de caché L1 para instrucciones.
El despacho de instrucciones se lleva a cabo mediante un pipeline de 12 etapas, aunque en la práctica el número total de etapas varía considerablemente en función del tipo de instrucción. Por ejemplo, el bloque de predicción de ramificaciones puede saltarse gran parte de ellas. Si combinamos la IU con las unidades vecinas, el número final de etapas suele rondar las 24 (sí, es un número elevado, pero recuerda que Cell funciona a 3,2 GHz).
Ahora viene lo interesante: la IU soporta dual-issuing, lo que significa que en determinadas condiciones puede despachar hasta dos instrucciones al mismo tiempo, mejorando considerablemente el rendimiento. En la práctica, sin embargo, hay muchas condiciones para que esto funcione, así que los programadores y compiladores son los responsables de optimizar sus rutinas para que la secuencia de instrucciones pueda aprovechar esta función. Por cierto, el dual-issuing ya lo habían implementado CPUs anteriores y el término varía según el fabricante; aquí he usado la definición de IBM.
Y por si fuera poco, la IU también es multi-threaded: la unidad puede ejecutar dos secuencias de instrucciones distintas (llamadas 'threads') al mismo tiempo. En realidad, la IU alterna entre los dos threads en cada ciclo, dando la apariencia de multi-threading. Esta técnica se conoce históricamente como Simultaneous Multi-Threading (SMT) o hyper-threading, tal como Intel lo denominaría más tarde. El multi-threading de IBM mitiga efectos no deseados como los pipeline stalls, ya que la CPU deja de bloquearse si una instrucción atasca el flujo. Para implementar el multi-threading, los ingenieros de IBM duplicaron los recursos internos de la IU, incluyendo los registros de uso general (antes dije que hay 32 registros disponibles; eso es por thread; en realidad hay 64 en total), pero los recursos que no forman parte de la especificación PowerPC (como la caché L1 y L2, y las interfaces) siguen siendo compartidos. Por tanto, este último grupo es de un solo thread.
En definitiva, combinando el dual-threading con el dual-issuing, el PPU puede ejecutar hasta cuatro instrucciones por ciclo. Aunque solo aplique en el mejor de los casos, sí abre oportunidades de optimización que los usuarios acabarán notando en la tasa de frames del juego.
Gestión de memoria
Diagrama simplificado de la Load-Store Unit (LSU) y sus unidades vecinas.
Los siguientes bloques otorgan al PPU la capacidad de ejecutar instrucciones de carga y almacenamiento, y de gestionar la memoria.
Para empezar, la Load and Store Unit (LSU) ejecuta los opcodes de 'load' y 'store' respaldados por 32 KB de caché L1 de datos. Por tanto, esta unidad tiene acceso directo a la memoria y al fichero de registros.
Además, la LSU está acoplada a una Unidad de Gestión de Memoria (MMU, del inglés Memory Management Unit), algo habitual en el hardware contemporáneo. En pocas palabras, la MMU gestiona el direccionamiento de memoria mediante un mapa de direcciones virtuales combinado con protección de memoria. Para mejorar lo segundo, esta MMU en particular incluye una segment unit, que agrupa las direcciones de memoria en rangos denominados 'segments'. Para evitar degradaciones de rendimiento en el proceso, se incluyen un Translation Lookaside Buffer (TLB) (que cachea las direcciones traducidas) y un Segment Lookaside Buffer (SLB) (que cachea los segmentos).
Aritmética
Diagrama simplificado de las unidades que realizan operaciones aritméticas.
Solo quedan dos unidades más del PPU por explicar: las que realizan los cálculos matemáticos que cualquier juego necesita.
La primera es una Fixed-Point Integer Unit (FXU) tradicional. La FXU realiza aritmética de enteros: división, multiplicación, rotación de bits (similar al desplazamiento de bits, pero los bits descartados regresan al otro extremo) y conteo de ceros iniciales (útil para normalizar coordenadas de vértices, por ejemplo). Su pipeline tiene 11 etapas.
Si observas el diagrama, verás que el FXU, la LSU y la MMU están agrupados en una sola unidad llamada Execution Unit (XU), porque comparten el mismo fichero de registros.
La segunda unidad es bastante más interesante: la Vector/Scalar Unit (VSU) realiza operaciones con números en punto flotante y vectores. Está compuesta por una FPU de 64 bits (que sigue el estándar IEEE 754) y una Vector/SIMD Multimedia Extension unit (VXU), que ejecuta un conjunto de instrucciones SIMD denominado VMX. Esta última opera con vectores de 128 bits formados por entre dieciséis valores de 8 bits y cuatro de 32 bits . Puede que ya hayas oído hablar de esta extensión: 'VMX' es el nombre de IBM para el 'AltiVec' de Motorola o el 'Velocity Engine' de Apple (que vivan las marcas registradas). Ahora bien, las verdaderas capacidades SIMD competitivas de Cell se encuentran en otro procesador, así que ¡no te relajes todavía!
Un vistazo general al PPE
Acabas de ver cómo funciona el PPE y de qué está hecho, pero ¿qué significa esto para un desarrollador?
Al fin y al cabo, el PowerPC Processor Element es solo un procesador de uso general, pero la clave está en que no está pensado para funcionar en solitario. ¿Recuerdas ese amplio bus principal (el EIB)? IBM diseñó el PPE para que los ingenieros puedan combinarlo con otros procesadores y acelerar aplicaciones concretas (HPC, gráficos 3D, seguridad, simulaciones científicas, redes, procesamiento de vídeo, etc.). Como este análisis trata sobre la PlayStation 3, verás que el resto de Cell está concebido pensando en los gráficos y la física, y el resto del artículo refleja ese propósito.
Fuera de Cell: la memoria principal
Salgamos de Cell por un momento, porque da igual lo bueno que sea el PPE si no tenemos un espacio de trabajo adecuado (memoria) donde ponerlo a trabajar.
Sony incorporó 256 MB de XDR DRAM en la placa base... Pero, de nuevo, ¿qué significa eso? Para saberlo, veamos cómo funcionan los bloques de memoria y cómo se conectan a Cell.
Cell junto a los cuatro chips XDR DRAM de 64 MB.
El tipo de memoria instalada se llama Extreme Data Rate (XDR). Puede que reconozcas la XDR DRAM como la sucesora de la (gafada) RDRAM del Nintendo 64 y el PlayStation 2. ¡Pero no te adelantes a las conclusiones!
Rambus, como cualquier empresa, mejora sus inventos. Su tercera revisión (XDR) funciona ahora a tasa óctuple (cuatro veces la tasa de su rival, la DDR DRAM) . La latencia ya no supone un problema: según las hojas de datos de uno de sus fabricantes, la latencia de la XDR se sitúa entre 28 ns y 36 ns , casi diez veces más rápida que los chips RDRAM de primera generación.
La primera revisión de la placa base de la PlayStation 3 contiene cuatro chips de 64 MB, gestionados en pares. La XDR se conecta a Cell mediante dos buses de 32 bits, uno por cada par. Así, cada vez que el PPU escribe una palabra (dato de 64 bits), esta se reparte entre dos chips XDR. Estos últimos funcionan a 400 MHz .
Diagrama de la arquitectura de memoria de Cell.
Cell se conecta a los chips XDR mediante el Memory Interface Controller (MIC), otro componente dentro de Cell (como el PPE). Además, el MIC almacena en buffer las transferencias de memoria para mejorar el ancho de banda, aunque tiene una limitación importante: la gran alineación de bytes. En esencia, el tamaño mínimo de datos para transferencias del MIC es de 128 bytes, lo que funciona bien para lecturas o escrituras secuenciales. Pero si los datos son inferiores a 128 B o requieren alternar entre escritura y lectura, aparecen penalizaciones de rendimiento.
Dicho esto, ¿es el MIC un cuello de botella o un acelerador? Hay que ponerlo en perspectiva: la optimización del ancho de banda es crítica en sistemas con gran demanda de datos. Ya hemos visto soluciones como el write-gather pipe o el write back buffer, así que el MIC es simplemente una nueva respuesta a un problema recurrente. En cualquier caso, Sony afirma que la tasa de transferencia es de 25,6 GB/s. Con todo, hay demasiados factores que condicionarán la tasa real en la práctica (ya has visto lo complejo que resulta mover datos de un lugar a otro dentro de Cell).
Esto es todo en cuanto a la RAM principal, pero hay más memoria en otro lugar: el disco duro. El PS3 también permite que los juegos utilicen 2 GB de su disco duro interno como área de trabajo (de manera similar a lo que el Xbox original ofrecía) .
El interior de Cell: los asistentes
Ya hemos visto cómo Sony siempre acompaña a un procesador de uso general (el PPE en este caso) con aceleradores para alcanzar un rendimiento de juego aceptable (las VPU y la IPU en el caso del PS2; el GTE y el MDEC en el del PS1). Se trata de una práctica habitual en el hardware de consolas, ya que las unidades de uso general pueden realizar una amplia gama de tareas, pero no están especializadas en ninguna. Las consolas de videojuegos solo requieren un subconjunto de habilidades (física, gráficos y audio, por ejemplo), así que los coprocesadores les proporcionan esa especialización.
[El PPE] es una versión recortada para reducir el consumo. Por eso no tiene la potencia que ves en, digamos, un Pentium 4 (...) Si tomas el código que hoy corre en tu Intel o AMD, sea cual sea su potencia, y lo recompilas para Cell, funcionará hoy mismo aquí, sin problema. Quizás tengas que cambiar alguna que otra librería, pero funcionará. Sin embargo, irá un 60 %, un 50 % más lento, y la gente dice «¡Dios mío! ¡Este procesador Cell es una porquería!» Pero es porque solo estás usando esa única pieza .
- Dr. Michael Perrone, responsable del departamento de Soluciones Cell del IBM TJ Watson Research Center
Los aceleradores incluidos en el Cell de la PS3 son los Synergistic Processor Elements (SPE). Cell incluye ocho de ellos, aunque uno se deshabilita en el arranque de la consola. Esto se debe a que la fabricación de chips exige un grado de precisión excepcional (Cell usó inicialmente el proceso de fabricación de 90 nm) y la maquinaria no es perfecta. En lugar de desechar circuitos con menos de un 10 % de defectos, Cell incluye un SPE de reserva. Así, si uno sale defectuoso, no se descarta el chip entero. Ese SPE de reserva quedará siempre desactivado, independientemente de si funciona o no (Sony no puede tener en el mercado dos PS3 diferentes).
Composición del SPE
El Synergistic Processor Element (SPE) es un pequeño ordenador independiente dentro de Cell, comandado por el PPE. ¿Recuerdas lo que expliqué antes sobre la adopción de elementos de la computación homogénea? Pues bien, estos coprocesadores son en cierta medida de uso general y no están restringidos a una única aplicación, así que podrán asistir en una amplia gama de tareas, siempre que los desarrolladores sepan programarlos correctamente.
Diagrama simplificado del Synergistic Processor Element (SPE); hay ocho dentro de Cell (uno deshabilitado).
Al igual que hicimos con el PPE, echaremos un vistazo al SPE. La explicación es más breve, así que si al final quieres saber más sobre los SPE, consulta la sección 'Fuentes' al final del artículo. Dicho esto, comencemos...
El SPE es un procesador que sigue una estructura similar a la del PPE, compuesto de dos partes:
El Memory Flow Controller
El Memory Flow Controller (MFC) es el bloque que interconecta el núcleo con el resto de Cell, equivalente al PowerPC Processor Storage Subsystem (PPSS) del PPE. Su función principal es mover datos entre la memoria local del SPU y la memoria principal de Cell, y mantener al SPU sincronizado con sus vecinos.
Para cumplir sus funciones, el MFC incorpora un controlador DMA para gestionar la comunicación entre el EIB y la memoria local del SPU. El MFC también alberga otro componente llamado Synergistic Bus Interface (SBI), situado entre el bus EIB y el controlador DMA. Es un circuito muy complejo de resumir, pero básicamente interpreta los comandos y datos recibidos del exterior y señaliza a las unidades internas del SPE. Como puerta de entrada a Cell, el SBI opera en dos modos: bus master (donde el SPE está adaptado para solicitar datos del exterior) o bus slave (donde el SPE está configurado para recibir órdenes del exterior).
Como curiosidad, dado que el límite de los paquetes del EIB es de hasta 128 bits, el bloque de Acceso Directo a Memoria del MFC solo puede mover hasta 16 KB de datos por ciclo; de lo contrario, el EIB lanza una excepción de 'Bus Error' durante la ejecución .
El Synergistic Processor Unit
El Synergistic Processor Unit (SPU) es la parte del SPE donde reside el procesador central, equivalente al 'PPU' cuando hablamos del PPE.
Al contrario que el PPU, el SPU está aislado del resto de Cell. Por tanto, no existe memoria compartida entre el PPU y los demás SPU. En cambio, el SPU cuenta con memoria local que usa como espacio de trabajo. Sin embargo, el contenido de esa memoria local puede trasladarse de un lado a otro mediante el MFC.
En cuanto a funcionalidad, el SPU es bastante más limitado que el PPU. Por ejemplo, el SPU no incluye funciones de gestión de memoria (traducción de direcciones y protección de memoria) ni funciones avanzadas como la predicción dinámica de ramificaciones. Aun así, rinde de manera excepcional en el procesamiento vectorial.
Para programar esta unidad, los desarrolladores utilizan el PPU para invocar rutinas proporcionadas por el sistema operativo de la PlayStation 3; estas cargan el ejecutable escrito específicamente para el SPU en el SPU elegido y le dan la señal de inicio de ejecución. Después, el PPU mantiene una referencia del thread del SPU para fines de sincronización .
Arquitectura del SPU
Al igual que cualquier CPU, el Synergistic Processor Unit (SPU) se programa mediante una arquitectura de set de instrucciones (ISA, del inglés Instruction Set Architecture). Tanto el SPU como el PPU siguen la metodología RISC; sin embargo, a diferencia del PPU (que implementa una ISA PowerPC), la ISA del SPU es propietaria y está compuesta principalmente por un conjunto de instrucciones de tipo SIMD. Como resultado, el SPU dispone de 128 registros de uso general de 128 bits que albergan vectores formados por valores en punto fijo o flotante de 32/16 bits. Por otro lado, para ahorrar memoria, las instrucciones del SPU son mucho más compactas: solo 32 bits de longitud. La primera parte contiene el opcode y el resto puede referenciar hasta tres operandos que se calculan en paralelo.
Esto recuerda mucho a la anterior Vector Floating Point Unit del PS2, aunque mucho ha cambiado desde entonces. Por ejemplo, el SPU no exige que los desarrolladores aprendan un nuevo lenguaje ensamblador propietario: IBM y Sony proporcionaron kits de herramientas para programar los SPU en C++, C o ensamblador.
En cuanto al diseño, este procesador no ejecuta todas las instrucciones con la misma unidad; la ejecución se divide en dos bloques o 'pipelines de ejecución', llamados Odd Pipeline y Even Pipeline. Estos dos pipelines ejecutan distintos tipos de instrucciones, lo que permite al SPU despachar dos instrucciones por ciclo cuando es posible. Por otro lado, el SPU nunca realiza dual-issuing con instrucciones que dependan entre sí, mitigando así los data hazards que puedan surgir.
Veamos ahora los dos pipelines :
Odd Pipeline
Diagrama simplificado del odd pipeline.
El Odd pipeline ejecuta la mayoría de las instrucciones, excepto las aritméticas.
En primer lugar, la SPU Load/Store unit (SLS) realiza tres funciones esenciales:
- Alberga 256 KB de memoria local para almacenar instrucciones y datos. El tipo de memoria instalada es single-ported (teniendo en cuenta la importancia de esta área, es un poco decepcionante que no usaran chips dual-ported...). Además, el bus de direcciones tiene 32 bits de longitud.
- Ejecuta instrucciones de carga y almacenamiento.
- Reenvía instrucciones a otro bloque para su despacho.
Conviene tener en cuenta que solo hay 256 KB disponibles para almacenar el programa. Como los programas SPU pueden compilarse en C/C++, no es fácil predecir el tamaño del binario resultante. Por este motivo, se recomienda que los desarrolladores asuman que solo tienen la mitad de la memoria disponible (128 KB) , lo que deja suficiente margen para que el código compilado ocupe el espacio que necesite, aunque a costa del almacenamiento y la eficiencia.
Por último, también hay una SPU Channel and DMA Transport (SSC), que el Memory Flow Controller usa para rellenar y/o leer la memoria local, y una pequeña Fixed-Point Unit que solo realiza reorganización y rotación de vectores.
Even Pipeline
Diagrama simplificado del even pipeline.
El Even pipeline destaca por sus capacidades aritméticas.
Aquí encontramos una auténtica Fixed-point Unit (FXU) que realiza aritmética básica, operaciones lógicas (AND, OR, etc.) y desplazamientos de palabras.
Por último, tenemos una Floating-point Unit (FPU) que realiza operaciones en precisión simple (32 bits, float), doble precisión (64 bits, double) y enteros (32 bits, int). Esta sigue el estándar IEEE con algunas desviaciones (los floats se comportan de forma similar al PS2).
El interior de Cell: modelos de programación
A medida que llegamos al final de Cell, quizás te preguntes cómo se supone que los desarrolladores programan este monstruo. Pues bien, de manera similar a los modelos de programación anteriores ideados para el Emotion Engine, IBM propuso las siguientes metodologías :
Enfoques centrados en el PPE
Representación del patrón multietapa, donde el PPE asigna una tarea que se va pasando de SPE en SPE hasta ser devuelta con los datos procesados.
Representación del patrón en paralelo, donde el PPE asigna una subtarea a cada SPE, que a su vez devuelve los datos procesados, y el PPE los combina.
Representación del patrón de servicios, donde el PPE asigna una tarea distinta a cada SPE y cada uno trabaja de forma independiente para cumplirla.
Los enfoques centrados en el PPE son un conjunto de patrones de programación que depositan las principales responsabilidades en el PPE y reservan los SPE para aliviar la carga de trabajo. Hay tres patrones posibles:
- Modelo de pipeline multietapa: el PPE envía trabajo a un único SPE, que realiza los cálculos necesarios y pasa los resultados al siguiente SPE. Esto continúa hasta que el último SPE de la cadena devuelve los datos procesados al PPE.
- Por razones obvias, IBM no recomienda este diseño para tareas primarias, ya que requiere un considerable ancho de banda y tiende a ser difícil de mantener.
- Modelo de etapas en paralelo: el PPE divide su tarea principal en subtareas independientes y envía cada una a un SPE distinto. Cada SPE devuelve los datos procesados al PPE al terminar; este los combina para producir el resultado final.
- Modelo de servicios: cada SPE recibe una tarea concreta (decodificación MPEG, streaming de audio, proyección en perspectiva, iluminación de vértices, etc.) y el PPE se encarga de enviar los datos brutos al SPE designado. Mientras espera, el PPE realiza otras funciones.
- Aunque esto implica que cada SPE tendrá un único trabajo, esa asignación no es permanente: el PPE debe reasignar distintos trabajos sobre la marcha según cambien las necesidades del programa.
Enfoques centrados en el SPE
Representación del patrón centrado en el SPE, donde cada SPE gestiona su propia funcionalidad e interactúa con el PPE solo para obtener un recurso.
En lugar de usar los SPE para servir al PPE, se invierte el esquema. Mediante la unidad DMA interna, los SPE leen y ejecutan tareas almacenadas en la memoria principal, mientras que el PPE se limita a la gestión de recursos.
Este modelo es bastante más radical que los anteriores, en el sentido de que los patrones previos se acercan más al paradigma tradicional tipo PC de 'procesador de uso general con coprocesadores'. Por ello, las bases de código que implementan algoritmos centrados en SPE pueden resultar más difíciles de portar a otras plataformas.
Conclusión
Como puedes imaginar, aunque el diseño multinúcleo de Cell acelera técnicas emergentes como la generación procedural, ninguno de estos diseños es particularmente sencillo de implementar, sobre todo teniendo en cuenta que los estudios de videojuegos prefieren bases de código que puedan compartirse entre distintas plataformas.
Para ilustrarlo, los desarrolladores del Unreal Engine 3 (Epic Games) pusieron de manifiesto las limitaciones de los SPE al intentar implementar su sistema de detección de colisiones . Su diseño se basa en el Particionado de Espacio Binario (BSP, del inglés Binary Space Partitioning), un algoritmo que depende en gran medida de las comparaciones (ramificaciones). Como los SPE no ofrecen predicción dinámica de ramificaciones como el PPU, su implementación decepcionó a los usuarios de PlayStation 3 al compararse con otras plataformas (el Xbox 360 o los ordenadores i686, ambos con técnicas de predicción coherentes en todos sus núcleos). Por ello, Epic Games tuvo que recurrir a optimizaciones adicionales exclusivas de Cell.
Supongo que es solo cuestión de tiempo, paciencia y mucho aprendizaje para que los ingenieros de software expriman todo el potencial de Cell. Sin embargo, la historia ha demostrado que eso no es viable para todos los estudios, lo que me hace preguntarme si esa es la razón por la que el hardware de consolas actual (a partir de 2021) se ha homogeneizado tanto.