La carrera de los bits y los megahercios, séptima parte

Volviendo la vista adelante: la Wii

Cuando en la quinta entrega hablé de la Xbox 360 y la PlayStation 3, me «olvidé» intencionadamente de la Wii. En ese momento no me fiaba mucho de lo que se había publicado y lo que se rumoreaba en los foros. En cambio tenía mucho material que exponer sobre las nuevas máquinas de Microsoft y Sony. Pero en este artículo, que va a ser el último de la serie, no podía olvidarme de la Wii. Aviso de que, en mi opinión, hay muchas cosas de las que no se tiene certeza, y procuraré ser precavido en mis afirmaciones. También cabe mencionar que intentaré seguir el esquema de los artículos anteriores, y aprovechando que es el último, me gustaría que fuera el más complejo; tal vez quien no los haya leído, en función de sus conocimientos, no entienda algunas cosas. Pero voy exponer una cantidad muy importante de nuevos conceptos, que resultarán muy interesantes a aquellos que deseen saber más. A por la última entrega. ¿Preparados?

La tecnología, ay sí, esta tecnología…

Ya es un hecho consensuado y aceptado por la gran mayoría, que la Wii no es rival para la 360 o la Play 3. A menudo estas afirmaciones están fundadas en lo que gente, que no debería opinar, ha oído por ahí. Y no procuro con esto defender lo contrario. Pero a veces hay que concretizar un poco, y sobretodo intentar huir de los conceptos «mejor» y «peor». Desde luego, el vacío técnologico entre la Wii y sus competidoras, en terminos de rendimiento computacional bruto, es muy importante, y lo voy a analizar a fondo a lo largo de este artículo. Pero creo que es muy interesante oír lo que Nintendo tiene que decir sobre el avance tecnológico. Para Microsoft y Sony, está claro que el progreso debía centrarse en concentrar un mayor rendimiento en los chips que componen la consola, en especial los procesadores principales (CPUs) y los gráficos (GPUs). Por ejemplo, el Emotion Engine de la Playstation 2, donde reside gran parte de su potencial, está compuesto por algo más de 10 millones de transistores, y su sintetizador gráfico, encargado de renderizar la imagen, por más de 50 millones. en total, unos 60 millones. Su sucesora, la Playstation 3, suma unos 600 millones de transistores entre su CPU de varios cores (Cell), y su GPU (RSX). Hablamos de un orden de diez más, lo cual nos da una buena indicación aproximada de la complejidad y el coste, e incluso el consumo. Nota. Hay que tener un cierto cuidado cuando utilizamos indiscriminadamente el número de transistores para justificar el coste y la complejidad de un circuito integrado, y en concreto una CPU. Lo digo porque, por ejemplo, la memoria caché consume una cantidad elevada de transistores y en cambio su diseño es mucho más sencillo que la lógica del procesador, o las unidades de ejecución, la circuitería que realmente hace el «procesado». Nintendo ha visto que sus rivales se ponían muy en serio manos a la obra para construir máquinas muy poderosas, orientadas a obtener una calidad gráfica elevada, y a hacer importantes inversiones en esa dirección, por lo que decidió aprovechar la tecnología, pero en otro sentido. Por otro camino. Han pasado unos años desde que se lanzó la Gamecube. Los chips se pueden fabricar ahora con procesos de integración más pequeños, que permiten un menor consumo, coste y una mayor minituarización. Por tanto, se decide hacer una consola innovadora en el apartado de la jugabilidad y el control, que sea más pequeña, consuma menos y sea más barata, procurando aún así ofrecer una sustanciosa mejora respecto a la Gamecube. Además, la carrera frenética por mejores gráficos no parece promover la evolución de los videojuegos, sino contribuir a perpetuar, en cierta medida, lo que ya existe, pues 12 años después del lanzamiento de la Playstation y la Saturn, seguimos jugando de la misma forma, a géneros muy parecidos. Más gráficos es practicamente todo lo que el progreso tecnológico nos ha ofrecido. La idea de Nintendo en sí me parece fabulosa. Ahora se me podrá tachar de decir lo mismo que ya han dicho muchos. Pero yo ya pensaba así cuando «Revolution» estaba aún muy lejos de ver la luz. Jugar a la Wii es en sí una experiencia nueva, como ya nos propuso la DS, pero no quiero que nadie piense que este artículo es partidario de una consola u otra. No lo he sido en el resto de mis artículos, y no lo séré ahora. Además, me interesa mucho el hardware como para infravalorar a la Xbox 360 o a la Playstation 3, que son máquinas muy pero que muy interesantes. Así pues, que quede claro que voy a intentar ser completamente imparcial. La pregunta ahora es… ¿cuánto de sustanciosa es esta controvertida mejora respecto a la Cube? LA EVOLUCIÓN TECNOLÓGICA DE NINTENDO Después de muchas incognitas, y un largo periodo de ignorancia, resulta que la Wii emplea la misma aquitectura que la Gamecube. No propone cambios radicales, e introduce pocas novedades conceptuales. No obstante, como ya he comentado, se aprovecha tanto como sus rivales del avance tecnológico, pero para lograr un sistema barato y compacto. Hay que recordar, que un parámetro importantísimo al hablar de circuitos integrados es el proceso de integración, o, hablando en terminos sencillos, la distancia mínima entre dos transistores. Actualmente, en noviembre de 2007, lo más empleado son los 65nm (nanómetros, eh? que nadie se despiste). Por empezar a hablar de algo, la CPU de la Wii, bautizada como Broadway, está fabricada en 90nm, en lugar de los 180nm empelados en el Gekko, procesador de la Gamecube. Esto permite obtener un chip cuya superficie de silicio ocupa la mitad. Y eso se traduce en casi cuatro veces más chips por cada oblea de silicio, y por tanto, empezamos ya a ver una reducción importante de costes. Sobretodo teniendo en cuenta que algunos autores estiman que el coste por oblea es proporcional al area del chip elevada a la quinta potencia. En concreto, se ha conseguido fabricar la CPU de Wii en un area de apróximadamente 19mm^2 (19 milímetros cuadrados). Por el mismo motivo, lo mismo sucede con la GPU de Wii, denominada Hollywood, y también fabricada en 90nm, que ocupa un 50% menos de área de silicio, reducida a unos 72mm^2, y que tiene alguna sorpresita más que luego comentaré, cuando le toque 🙂 Para contrastar un poco, * El Cell, procesador de la Play 3, es 12 veces mayor que el Broadway. * El RSX, GPU de la Play 3, es 2,7 veces mayor que el Hollywood. Sí, aunque parezca mentira, el Cell, ocupa 12 veces más area de silicio, que el hoy en día minusculo procesador de la Wii, y eso conlleva que su coste sea muy superior.

 

RENDIMIENTO Y ARQUITECTURA DE UNA CPU, MÁS DE CERCA

LA CPU DE WII. Por lo visto, se trata de un procesador muy similar al de la Gamecube, el Gekko, y totalmente retrocompatible con él. Su nombre es Broadway, como ya comenté, y se cree que deriva de un PowerPC 750 CL, un módelo nuevo, pero que sería básicamente un PowerPC 750 CXe, es decir, una arquitectura del año 2001, con las modificaciones que se introdujeron en el Gekko, pero sin ninguna otra innovación conocida, al margen de consumir un 20% menos, estar fabricado en tecnología de 90nm, y funcionar un 50% más rápido, es decir, a 729 MHz. No hay motivos para pensar que haya cambiado su estructura interna, y por lo tanto, al igual que el Gekko, dispondría de 64 Kb de memoria cache L1 (32Kb para datos, y 32Kb para instrucciones) asociativa por conjuntos de 8 vías, que aún así es una cifra muy interesante, y unos tampoco despreciables 256 Kb de cache L2, pero ésta asociativa por conjuntos de 2 vías. Para asegurarme de que nadie se pierde, voy a aclarar algunos conceptos, aunque recomiendo que leáis el resto de mis artículos si no entendéis este. La caché de un procesador es donde se guardan los últimos datos e instrucciones requeridos, y está estructurada en bloques. Es mucho más rápida que la memoria RAM, y por lo tanto es muy bueno que su contenido pueda reutilizarse lo más posible, así como que quepa la mayor cantidad útil de información, ya que si se llena, habrá que sacar algunos bloques para poder meter otros, y si los bloques sustituídos son requeridos de nuevo, habrá que traerlos de memoria RAM, perdiendo el beneficio del rápido acceso que otorga la caché. Lo de L1 y L2, es una simple jerarquía. La caché L1 es la más rápida, costosa, compleja y pequeña. La caché L2 es un poco más lenta, pero de mayor capacidad. La CPU intentará mantener los bloques lo más cerca posible de su núcleo de ejecución, es decir en la caché L1, pero tira de la L2 cuando lo necesita. Lo de «asociativo por conjuntos» es un tipo de memoria caché, que hace alusión al modo en el que se asignan los bloques dentro de ella. A cada bloque de memoria RAM que se trae a la caché le corresponde un conjunto de la caché. No es negociable, debe ir al que le corresponde, y no a otro. Pero dentro de ese conjunto, se puede colocar donde sea. Si se trata de una asociatividad de 8 vías, disponemos de más posibilidades de poder alojar el bloque, que una de asociatividad 2. Aprovechando la similitud del Broadway con el Gekko, y dado que ya hablé sobre éste último en la 4ª parte de esta serie de artículos, profundizaré un poco más en la arquitectura del micro. Al lado del modesto Broadway, un único core a 729 MHz, se puede pensar que la CPU de la Xbox 360, el Xenon, un chip moderno de 3 cores simétricos, funcionando a 3,2GHz, es un mundo a parte. Y lo es. Pero se podría argumentar, erróneamente, que el Xenon es unas 13 veces más potente que el Broadway, si sumamos los MHz de sus 3 cores (3 x 3200 = 9600). Este cálculo no sirve para nada. Para empezar, aunque los cores del Xenon están basados en la arquitectura PowerPC, al igual que el Broadway, esto no quiere decir, ni mucho menos, que su rendimiento por MHz debe ser el mismo, o ni siquiera comparable. Ha habido varias generaciones de procesadores PowerPC a lo largo de muchos años, que comparten una base común, pero que van añadiendo nuevas funcionalidades, o haciendo las cosas de forma distinta, aunque entendiendo un juego de instrucciones máquina muy parecido. Igual sucede en los PC. Un Pentium 4, un Athlon 64 o un Core 2 Duo son procesadores modernos que heredan una base muy antigua, la microarquitectura x86, un linaje que comenzó con el Intel 8086 en el año 1978. ¿A quién en su sano juicio se le ocurriría decir que su nuevo Athlon 64 debería ser igual de potente que una CPU del año 1978? Para empezar, un Athlon 64 puede funcionar a varios GHz, mientras que el 8086 no superaba los 10 MHz, si no recuerdo mal. Pero aunque pudiera llegar a correr hoy en día a varios GHz, su rendimiento estaría dramáticamente por debajo. Ambos son procesadores de arquitectura x86, pero el Athlon 64 lleva incorporadas un sinfin de mejoras. Pero por dar un ejemplo menos «hardcore», todavía hoy en día se venden PCs con procesadores de 32 bits (como el Core Duo, Athlon, algunos Pentium 4,…). El primer micro de 32 bits de la arquitectura x86 fue el 80386, que apareció en el 1985, hace 22 años. Ya ha llovido. Los cores del Xenon son muy rápidos, de eso no cabe duda. 3,2 GHz dan para mucho. Pero tienen una desventaja muy importante frente a una CPU más convencional. No son capaces de ejecutar instrucciones fuera de orden, como ya expliqué en detalle en el 5º artículo. En cambio, el Broadway sí es capaz de hacerlo, planificando el orden en el que ejecutarlas para optimizar sus recursos, en lugar de hacerlo tal cual van llegando. Si la ejecución de una instrucción debe detenerse en algún momento, a la espera de un resultado aún no disponible, se siguen lanzando nuevas instrucciones sin que la CPU tenga que detenerse. Esta capacidad es muy potente cuando se trata de correr aplicaciones de propósito general, o códigos poco optimizados, al igual que la inteligencia artificial y la gestión del sistema de juego, y hace que el Broadway rinda más que los cores del Xenon a igual MHz. Aún así, no hay por donde cogerlo, y la Xbox 360 gana por fuerza bruta. Ha sido concebida para generar entornos tridimensionales muy complejos, lo cual demanda un alto rendimiento en coma flotante, y elevados anchos de banda. Pero la Wii no ha sido diseñada para competir en potencia gráfica con ella. CPU. VAMOS CON ALGUNOS CONCEPTOS MÁS AVANZADOS Arovechándo que es el último artículo de la serie, quisiera comentar algunos aspectos fundamentales de CPUs antes de continuar, y esto si es material nuevo que no he expuesto con anterioridad, así que alerta. Muy interesante, pero como siempre, si no se entiende, un puto coñazo. MHz. Frecuencia y tiempo de ciclo. Ahora sí combiene tener muy claro lo que significa frequencia y ciclo de reloj. Básicamente todos los circuitos digitales más o menos complejos se rigen por una señal que, como toda señal digital, sólo puede valer «0» o «1», y que pasa de un estado a otro cada cierto periodo de tiempo. Se denomina señal de reloj. Su objetivo es sincronizar el funcionamiento de todos los componentes del circuito. Es un poco como un tambor que va marcando el ritmo. Cada golpe de tambor indica a todo el grupo que deben dar el siguiente paso. El estado interno del circuito sólo cambia cuando la señal de reloj cambia. Ejemplos de relojes pueden ser los siguientes.

Partes básicas de un procesador. * Front-End. Una de las dos partes fundamentales de una CPU. Se llama así a la que se encarga de traer, decodificar y planifican la ejecución de las instrucciones. Las instrucciones son secuencias de ceros y unos que codifican una acción particular que el procesador debe efectuar. Puede ser una operación con enteros, en punto flotante, o una transferencia de datos entre registros o con la memoria RAM. El procesador es en sí una máquina sumamente estúpida. Pero complejísima. El proceso llevado a cabo por el Fron-End, en forma super simplificada, sería: 1) Traer las instrucciones, que en el caso de la Wii son secuencias de 32 bits (es decir, 4 bytes). Primero la circuitería chequeará si la siguiente instrucción está en la caché L1 de instrucciones, por si ya ha sido procesada recientemente y aún se guarda ahí, desde donde la puede recuperar con muchisima rapidez. ¿Que no está? Pues nada, va y pregunta a la caché L2, también muy veloz. Si la instrucción tampoco está en la L2, en la mayoría de los sistemas hay que ir ya a la memoria RAM, que al contrario que la caché, es un componente externo, al que se accede a través del bus de datos de la CPU. Al proceso de traer una instrucción a la CPU se le llama en inglés, fetch. 2) La decodificación de la instrucción es el paso en el que el procesador averigua qué le pide la instrucción. En inglés, decode. 3) Una vez sabe lo que esa instrucción debe hacer, ésta pasa habitualmente a un pequeño buffer donde se planifica su ejecución. Aquí es donde gran parte de la ejecución fuera de orden reside. La CPU va a intentar encontrar el mejor orden de ejecución de las instrucciones que ya ha decodificado y aún no se han ejecutado. Si hay una serie de instrucciones que usan el mismo recurso de la CPU, se las puede programar en un orden distinto, para intercalar otras instrucciones que requieran otros recursos que estén sin usar. Todo esto proceso es dinámico, y responde en tiempo real a los cambios que suceden. Pero, por ejemplo, una CPU como la de la Xbox 360 o la Playstation 3, no tiene la capacidad de planificar un orden distinto al que aparecen en el programa, y por tanto, no puede llevar a cabo estas optimizaciones. * Back-End. Es la otra parte fundamental de una CPU. Compuesto por las unidades de ejecución, que realizan los cálculos y los movimientos de datos que piden las instrucciones. Una vez que las instrucciones han sido elegidas para empezar a ejecutarse, la CPU las desvía a zonas concretas del Back-End, encargadas de un cierto tipo de tarea. Si la instrucción pide una operación de multiplicación de dos números enteros, entonces se llevará a la unidad de ejecución de enteros, o a una de ellas, si es que la CPU dispone de más de una, lo cual es muy habitual. Si en cambio la instrucción solicita un dato de memoria RAM, entonces una unidad de ejecución de carga se ocupará de ello. Hay bastantes tipos de unidades de ejecución, en función de la operación que realizan. Por tanto, cuando una CPU dispone de más unidades de ejecución, es, en teoría, capaz de hacer más operaciones, si es capaz de mantenerlas ocupadas continuamente. Por cierto, puede que antes de entrar las instrucciones en las unidades de ejecución, vayan a otro pequeño buffer, donde se le someterá a otra planificación final entre todas las instrucciones del mismo tipo, que compiten por la misma unidad de ejecución. Esto optimiza aún más el uso de los recursos y aumenta la potencia de la ejecución fuera de orden. Pipeline. Este es el último concepto que voy a explicar, pero es de una importancia muy notable, y me va a permitir profundizar más cuando entremos en harina. Venga, intentaré una vez más que sea ameno (si es que alguna vez lo fue, jeje). Las instrucciones no se ejecutan de golpe. Ala, en un sólo ciclo de reloj. Ni de coña. El cauce de ejecución de una CPU se divide en etapas, y cada etapa se realiza en un ciclo de reloj. Si por ejemplo, en un mundo feliz e ideal, un microprocesador tiene un cauce de 5 etapas, y corre a 200MHz, podrá ejecutar un máximo de 40 millones de instrucciones por segundo (o 40 MIPS), pues cada una requiere 5 ciclos para ser completada. Vamos, 200 / 5 = 40. Si conseguimos que esta CPU necesite sólo 4 etapas, tendrémos algo como lo que sigue.

La instrucción roja va recorriendo las distintas etapas, hasta que acaba y entra la siguiente. Así funcionaron las CPU durante sus comienzos, y un rato más. Si no necesitamos más rendimiento, eso está bien. Pero sino, ¿cómo mejoramos la velocidad de este micro? Podemos fabricarlo en una escala de integración más pequeña, para que se caliente menos y responda antes, y así poder subir los MHz. Podemos añadirle un bus de datos más ancho, más caché, o más unidades de ejecución, que no valdrían para nada, y todas las respuestas serían incorrectas. Bien, el meollo de la cuestión es que este esquema es muy mejorable. No se trata de aumentar los recursos, sino de aprovechar todos esos recursos que están sin usar continuamente. Es fácil ver que en cada momento, una de las etapas trabaja, pero las otra 3 están ociosas (las que en la imagen están en rosa). Vamos, uno trabaja y el resto mira (que familiar suena eso). Pipeline es como se llama al cauce de instrucciones cuando está preparado para que todas sus etapas trabajen simultánemanete. Y el ejemplo gráfico, que vale más que mil palabras, y si son mías, pues unas dos mil quinientas.

¿Por qué esperar a lanzar la instrucción verde hasta que la roja acabe? La verde necesita la etapa 1 para empezar, y la roja la deja libre al siguiente ciclo de haber empezado. Así pues, vayamos pasando como por una cadena de montaje. El impacto de esto es brutal. Ahora, una instrucción sigue tardando 4 ciclos en ser completada. Pero, una vez que el pipeline está lleno (algo que ocurre al 4º ciclo, en la imagen superior), el ritmo de finalización de instrucciones es de un sólo ciclo! Es decir, que la CPU de 200 MHz puede ahora acabar 200 millones de instrucciones por segundo. Esto sí que es la caña, e? Y si alargamos el pipeline? Si dividimos el pipeline en más etapas, cada una de ellas hará una menor parte del trabajo. Por tanto cada etapa acabará antes su trabajo. Con ello, podremos aumentar los MHz sin hacer más modificaciones (aunque esto de por sí ya es una moficiación importante). Por ejemplo, si diseñamos una versión de 8 etapas de la CPU virtual que he presentado, podríamos hacerla funcionar a 400 MHz en lugar de a 200 MHz. No es ningún truco, el reloj va al doble de velocidad, pero también se requieren el doble de pasos para completar una instrucción, así que cada instrucción tardará más o menos lo mismo en ser completada. Pero el truco aquí está en que una vez el pipeline esté lleno, cada ciclo de reloj acabará una instrucción, y si el reloj va al doble de frecuencia, se podría llegar a alcanzar hipotéticamente el doble de rendimiento, aunque como veremos luego, no siempre es posible mantener el pipeline lleno y abastecido con instrucciones. Pero en cualquier caso, casi con toda seguridad nuestra CPU de 8 etapas ganará en todos los aspectos a su predecesora de 4, si no tocamos nada más de su microarquitectura. Entonces, una CPU con 28000 etapas será la hostia no? No. 🙂 Ni de coña. Cierto es que el rendimiento suele aumentar con una profundización del pipeline, pero hay un limite. Por ejemplo, una de las CPUs más famosas con pipeline largo es el Pentium 4. Ha habido muchos modelos, con longitudes de pipeline distintas, pero en cualquier caso eran de longitud más agresiva que sus competidoras. Acabó teniendo 31 etapas. Y en cambio, es una de las CPUs modernas que peor aprovecha cada MHz. Casi cualquier CPU a igual MHz rinde más que un Pentium 4 en la mayoría de situaciones. Un Athlon de AMD ha sido siempre superior a igual velocidad, con 15 etapas. ¿Por qué? ¿No nos has dicho que el pipeline es la caña? ¿Mientes? Pocas veces, pero en este caso no miento 🙂 Como antes dejé caer, no siempre es posible mantener la cadena de montaje llena y en buen funcionamiento. Se suceden continuamente paradas, bloqueos, conflictos y vaciamientos, técnicamente hablando, hazards (riesgos) y stalls (paradas), y cada vez que ocurren, aparece una penalización para poder devolver todo el tinglao a un estado totalmente operativo. Cuanto más largo el pipe, cuantas más etapas, más costosa es esta acción. No quiere esto decir que el Pentium 4 fuera un micro mal diseñado. La estrategia de los ingenieros de Intel era proyectar un micro que permitiera un aumento salvaje de la frecuencia de reloj, es decir, hacer CPUs que funcionarán a altos MHz, para competir en el mercado. Al final, por cierto, abandonaron la llamada arquitectura sobre la que se construye, Netburst, y el sucesor del Pentium 4, el Core 2 Duo, es una evolución de la arquitectura P6, es decir, el linaje de los Pentium 3. Lo que es la vida 🙂 Obviamente las cosas no se anuncian de esta forma, pues la cantidad masiva de ignorantes consumidores no comprarian un microprocesador que viene del Pentium 3, si ya ha habido un Pentium 4, pensando que tal vez a Intel se le ha ido la olla al volver hacia atrás. Pues no, no es eso, jeje. Aunque sería muy interesante profundizar, hacer un breve análisis, y tocar un par más de cosas, me lo voy a saltar y dar paso a la chicha del artículo, pues sino va a ser un artículo muy interesante, pero que no va a leer mucha gente, más que un par de frikis como yo. VOLVIENDO A LA CPU DE WII Como ya comenté, finalmente todo apunta a que es similar, sino idéntica, a la de Gamecube, pero funcionando a 729 MHz, en lugar de 486 MHz. Al igual que todas las CPUs de la anterior y presente generación de consolas, el Broadway es un procesador superescalar, es decir, capaz de lanzar más de una instrucción en el mismo ciclo de reloj, o lo que es lo mismo, simultaneamente. Después, esas instrucciones, en la Wii, van recorriendo un corto pipeline de 4 etapas. Erróneamente, aunque sin constituir un gran delito, se podría decir que el Broadway no es más potente que el procesador de la primera Xbox, un Pentium III modificado que funciona a 733 MHz. Pero los MHz raramente hablan por sí mismos. Sino me equivoco, la CPU de la Xbox tiene un pipeline de 10 etapas. Con un pipe de más del doble de profundidad, es muy fácil alcanzar frecuencias de reloj bastante más elevadas. Si el Broadway empleara 10 etapas, podría facilmente alcanzar los 1,6 GHz, y si se quisiera, seguramente los 2 GHz. Esta comparación la podemos ver de otro modo. Aunque los relojes de ambos procesadores son casi idénticos, las instrucciones en la Xbox necesitan 10 ciclos como mínimo para ser concluídas. En la Wii tan sólo 4 ciclos. Es decir, menos de la mitad de tiempo. De hecho, un ciclo de reloj en la CPU de la Xbox dura 1,36 ns (nanosegundos), mientras que en la Wii 1,37 ns. La diferencia es despreciable, por lo que podríamos suponer que duran lo mismo. Estos números se obtienen sin más que hacer la inversa de la frecuencia, es decir, tiempo de ciclo en microsegundos = 1 / MHz ( para la Xbox, 1 / 733 = 0,00136 ) Y de aquí sabemos que una instrucciones en Xbox tardará 10 * 1.36 = 13,6 nanosegundos en ser ejecutada. En Wii, este tiempo se reduce a sólo 4 * 1,37 = 5,48 nanosegundos. Ahora mismo podríais decir «guau», pero no. 🙂 Hay que recordar que una vez que el pipeline está lleno de instrucciones, cada ciclo de reloj finaliza una de ellas, en concreto, la que ocupaba la última etapa. Luego en esta circustancia, ambas CPUs concluyen la ejecución de una instrucción cada 1,36 ns aproximadamente. Por lo tanto, examinando superficialmente el pipeline, observamos una mejora en Wii, pero no para tirar cohetes, pues la situación ideal que intenta conseguirse es que el pipe esté lleno el mayor tiempo posible. Y obviamente cuando esto no sea posible, la Wii tendrá penalizaciones mucho más bajas, y rendirá bastante mejor. El back-end…. Pasando a otra cosa, el del Broadway tiene en total 6 unidades de ejecución, cada una encargada de una tarea más o menos concreta. Entre ellas hay dos unidades de ejecución de enteros (IU), que le permiten operar en paralelo con números no decimales, o de coma fija, una unidad de ejecución de coma flotante (FPU), otra que se encarga de los saltos o ramificación del código (BPU), y otra de cargas y almacenamiento en memoria (LSU). Una de las mejoras introducidas en las CPUs de Wii y Gamecube respecto al PowerPC 750 original, es la modificación de la unidad de coma flotante. En su forma primigenia, era capaz de operar con precisión simple (32 bits) o doble (64 bits), haciendo una operación entre dos números cada vez, y completándola en 3 ciclos de reloj. Eso de por sí no estaba mal para una CPU del año 1997 para aplicaciones sin mucha carga en coma flotante. La modificación para Nintendo añadió la posibilidad de hacer, humildemente, operaciones vectoriales, o SIMD, de precisión simple.

Para hacer memoria, una operación escalar es la que se realiza con 2 números. Las de toda la vida. Por ejemplo 2 + 9. Una unidad escalar (en verde en la imagen de arriba), genera un sólo resultado, o flujo de datos. Por eso se llama SISD (Single Instruction, Single Data), que significa una úinica instrucción genera ún solo dato. En camibio, una unidad vectorial, o SIMD (Single Instruction, Multiple Data), realiza la misma operación sobre varios conjuntos de números. En la imagen de arriba vemos una unidad de 4 vías (en rojo). Por tanto, podría hacer 4 multiplicaciones en paralelo, o cualquier otra operación que soportara, como la famosa MADD, que implica la multiplicación de los 4 conjuntos de número que entran, y la suma de los resultados, muy usada en tareas de manipulación de polígonos, geometrías, etc… Y dije humildemente, porque aunque lo normal en unidades de ejecución SIMD «bien hechas» es hacer 4 operaciones en paralelo, de números de precisión simple, en la unidad de coma flotante de Gamecube y Wii, sólo es posible hacer 2 operaciones de precisión simple. Es decir, la mitad. Pero sigue siendo posible hacerlas en el mismo tiempo, y por lo tanto, va a elevar sensiblemente el rendimiento del procesador en este apartado, respecto a su versión original. Además, se pueden cargar números enteros o de coma fija sin penalización en el rendimiento, pues la CPU es capaz de realizar la conversión a coma flotante en tiempo real. Es interesante comentar que a rasgos generales, la arquitectura del PowerPC es bastante cojonuda, y ha alimentado durante mucho tiempo el debate de la superioridad de los Mac (que han usado PowerPC durante mucho tiempo) frente a los PC, cuyos procesadores, como el linaje Pentium, se han caracterizado por su no tan buen diseño/rendimiento, entre otros motivos porque deben mantener una retrocompatibilidad con procesadores muy viejos, pero que es una historia muy larga que no viene a cuento, pero muy interesante. Volvamos al front-end…. Cuando una CPU es capaz de ejecutar instrucciones fuera de orden, dispone de un buffer especial, una pequeña memoria que almacena un cierto número de instrucciones, las cuales puede analizar y reordenar, y que son candidatas para ser iniciadas. A esto se le llama «ventana de ejecución». Sólo pueden ser ejecutadas fuera de orden aquellas instrucciones que estén dentro de esta ventana. Por cierto, al buffer que guarda estas instrucciones no siempre se le llama igual. En los procesadores de Intel se le suele llamar ROB, ReOrdering Buffer, en los de AMD suele ser ICU, Instruction Control Unit, etc… pero lo importante es que suele ser bastante pequeño. Hay que recordar que toda memoria interna a la CPU es costosa, y si además, como es este caso, debe ser endiabladamente rápida, pues hay que dejarse los cuartos pero que muy bien. Fijaros que esta memoria está dentro de lo que se podría llamar camino crítico, o lo que es lo mismo, el procesador no puede funcionar más rápido de lo que le permita esta memoria, pues requiere escribir y leer las instrucciones ahí antes de poder lanzarlas a ejecución. En el caso de la Wii, su capacidad es de sólo 6 instrucciones. En el caso de la Xbox hay espacio para 40. Pero como el pipeline de la CPU de Wii es muy corto, no es un hecho muy penalizador. Cuanto más largo sea un pipeline, más rendimiento puede ofrecer al procesador, pero también mayores penalizaciones cuando se toman decisiones equivocadas en la ejecución de instrucciones, y por tanto una mayor inteligencia se debe emplear para evitar que esto suceda. Además, al contrario que una super CPU como la de Xbox 360 o Playstation 3, si una instrucción no puede ejecutarse, o necesita detenerse a la espera de algún dato, el pipeline no tiene porqué detenerse. Puede elegirse otra instrucción aunque no se sigua el orden original, y los recursos de la CPU siguen trabajando. En resumen, la CPU de Wii es un procesador sencillo, con unas carácteristicas de rendimiento/coste/consumo muy elevadas. Aunque no se disponen, que yo sepa, al menos de forma pública, imagenes del die del Broadway, la siguiente es una foto de un die de PowerPC 750, donde pueden verse las principales parte que he comentado.

En rojo las cachés L1 de datos e instrucciones, en amarillo, naranja y azul, las principales unidades de ejecución, y en verde, gran parte de la lógica necesaria del pipeline y ejecución fuera de orden. A esta imagen habría que añadir los 256 Kb de caché L2, que en el die de la imagen superior debe ir colocada en la placa base, en un chip a parte, mientras que tanto en la Gamecube como en la Wii va integrada en el procesador mismo, lo cual aumenta sus prestaciones. Por cierto, esta caché L2 ocuparía un area cercana a la que ocupa el procesador en sí, o en otras palabras, el die de la imagen casi doblaría su tamaño. Esto se puede deducir viendo el die de un Athlon XP, en el que sus 256 Kb de caché L2 (marcada en verde) ocupa alrededor de un tercio del area total del chip.

La CPU de Wii, sin tener en cuenta cachés, podría rondar la tercera parte de la de un Athlon XP (unos 8 y unos 23 millones de transistores respectivamente. Las imagenes no están a escala), luego, se podría esperar que la L2 de la CPU de Gamecube y Wii ocupara más o menos la mitad del chip. Esto es algo bastante habitual en procesadores modernos, como podemos ver en un die de Athlon 64 con 1Mb de caché L2.

VISIÓN GENERAL DE LA WII

Pocas cosas han cambiado del esquema de la Gamecube. El único componente añadido es la memoria GDDR3 que se ve en la imagen superior. De momento vamos a hacer como si no estuviera. Sí, eso quiere decir que hay que hacer como si el bloque amarillo no existiera. Para evitar confusiones, imaginad que no existe dicho color, y si estáis comiendo un platano, dejadlo a parte para evitar que vuestro cerebro entre en conflicto 😉 Para entender la base principal del aumento de velocidad en la Wii, hay que entender los multiplicadores. En ambas consolas existe una frecuencia de reloj base, sobre la que se calculan el resto. La GPU trabaja a la misma velocidad que el reloj base, por tanto tiene un multiplicador 1x. La memoria principal trabajar al doble de volocidad que el reloj base, por tanto, con un multiplicador 2x. La CPU trabaja al triple, usando por tanto un multiplicador de 3x. En cuanto a los buses, el que une la CPU con la GPU usa un multiplicador 1x, el que une la GPU con la memoria principal, 2x. La diferencia es que la Gamecube usa un reloj base de 162 MHz, y la Wii usa una frecuencia un 50% superior, de 243 MHz. Si multiplica este reloj por el multiplicador correspondiente, se obtiene la velocidad a la que funciona el componente. Por tanto, como el reloj base en la Wii es un 50% más elevado, todo funciona un 50% más rápido. Vuelvo a recordar, que una cosa es que algo funcine más rápido, es decir, a más MHz, y otra muy distinta, que el rendimiento sea mayor. Si hablamos del mismo chip, entonces se cumple, pero sino, aunque habitualmente da una idea de potencia, no nos habla de cúan eficiente es aprovechando esos ciclos de reloj, y por tanto, no nos ofrece información contundente. En el caso de la Wii, parace que no ha habido cambios en la microarquitectura ni de la CPU ni de la GPU, y por tanto, cabe esperar que el 50% de aumento en MHz, se traduzca en un 50% de aumento bruto del rendimiento, pues los buses también han incrementado su ancho de banda en un 50%, evitando así hacer de cuello de botella (o más bien, favoreciendo el que no hagan de cuello de botella). Ahora es cuando el amarillo vuelve a nuestras vidas. En la Wii, se ha incorporado un nuevo componente, una memoria GDDR3 del mismo tipo que la empleada en la Xbox 360 y en la memoria gráfica de la Playstation 3, pero que trabaja a una frecuencia bastante menor. En cualquier caso, ofrece un ancho de banda similar al de la memoria principal 1T-SRAM. Dicha memoria 1T-SRAM era la que montaba la Gamecube, pero, como todo, un 50% más rápida. En la Wii, aprovechando el avance tecnológico para algo distinto a construir consolas-calefactoras (es coña), se ha colocado la 1T-SRAM en el mismo encapsulado que la GPU, lo que, a simple vista, debe mejorar la latencia entre ellas.

Este es el aspecto del chip tal y como viene montado en la consola. Como ya es habitual, el circuito integrado de silicio está protegido por una chapa metálica, que además permite una mayor superficie de contacto con el disipador térmico que va colocado sobre él para refrigerarlo. Y abajo podemos ver, una vez retirada dicha chapa, los dos dies que están encapsulados en el mismo chip. Uno de ellos, el de forma cuadrada y ligeramente menor, contiene la GPU, con su memoria embebida, el northbridge y un controlador de memoria DDR2. El otro die son los 24 Mb de memoria 1T-SRAM que ya existína en la Gamecube, y ahora se han minituarizado aún más, hasta permitir colocarlo en el mismo chip que la GPU, Por cierto, el die de la memoria 1T-SRAM, el grande, también contiene un DSP, es decir, un procesador digital de señal, usado para el audio.

Es posible que el haber elegido integrar ambos chips en un mismo encapsulado sea también un tema de abaratamiento de coste, y de ahorro de espacio de la placa de la consola. De paso, veamos el chip de la GPU al lado del de la CPU, para admirar ese contraste un tanto abrupto de tamaños.

Y para acabar, como siempre, la tablita de turno.

	Wii	Gamecube	Xbox
Ancho de banda CPU-RAM	1,9 Gb/s	1,3 Gb/s	1 Gb/s
Ancho de banda GPU-RAM	3,9 Gb/s + 4 Gb/s	2,6 Gb/s	6,4 Gb/s
Ancho de banda CPU-GPU	1,9 Gb/s	1,3 Gb/s	1 Gb/s

MEMORIA: NADA DE UN 50% MÁS POTENTE Como ya hemos visto, las velocidades en MHz han sido elevadas un 50%, ya que todos los dispositivos trabajan basandose en un reloj base. Pero al llegar al sistema de memoria de la Wii, vemos cosas interesantes. Por ejemplo, casi se ha triplicado la memoria útil para tareas de alto rendimiento, en la Gamecube 24 Mb de 1T-SRAM, en la Wii esa misma cantidad, colocada en el mismo encapsulado que la GPU, pero apoyada por un nuevo chip muy majo de 64 Mb de memoria GDDR3, este sí, externo, que según los datos actuales, ofrecería un ancho de banda similar a la 1T-SRAM, aunque seguramente con una mayor latencia. Es decir, que aunque para trasferir bloques secuenciales de datos puedan mover la misma cantidad de información, la GDDR3 tardaría un poco más en responder y empezar a leer o escribir. La latencia es precisamente eso, el tiempo que ha de transcurrir desde que se le solicita algo a la memoria, hasta que reacciona. Algo que, por cierto, no es instantaneo. La circuitería del chip de memoria ha de reconocer a qué dirección se quiere acceder, y si se trata de una lectura, realizar dicha lectura y colocar el dato en el bus. En aplicaciones reales, mayor latencia se traduce en un peor aprovechamiento del ancho de banda. La memoria GDDR3 es una modificación de la memoria más usada hoy en día en los ordenadores personales, la DDR2. Esta, a su vez, es la evolución de la DDR, la cual aún emplean muchos PCs. Es interesante saber al menos el funcionamiento básico y las diferencias entre estas memorias. Venga, que este va a ser la última parte de la serie de artículos, así que a darle cañita. Las memorias de PC pertenecen a la famila de las DRAM, o memorias dinámicas. Lo de dinámico quiere decir que si no se lee su contenido muy frecuentemente, éste se pierde. Para evitarlo, existe un circuito llamado «controlador de memoria» que se encarga de refrescarla, es decir, renovarla, regenerarla, continuamente. Este refresco reduce el tiempo que la memoria está a disposición del sistema. Y además, el controlador es un circuito que puede llegar a alcanzar cierta complejidad. Parece un tinglao, y lo es. De hecho, la otra gran familia de memorias RAM es la SRAM, o memoria estática, que no requiere refresco, y mantiene el contenido integro mientras no se corte el suministro eléctrico. Usada, por cierto, en la inmensa mayoría de cartuchos de consolas de 8 y 16 bits, para retener las partidas salvadas. Y esto puede llevar a preguntar, ¿por qué usar DRAM entonces? Bueno, una de las ventajas de la DRAM es que es mucho más barata que la SRAM, y se pueden fabricar chips de mucha mayor capacidad y menor consumo. Estos «mucho» que he acabo de mencionar son realmente «MUCHO». Lo suficiente como para consolidar a la DRAM como memoria principal de la practica totalidad de sistemas informáticos desde hace bastantes años. En el terreno consolero aparecieron en la generación de los 32 bits. Anteriormente no tenía sentido usarla. La Super Nintendo, una de las consolas con mayor memoria RAM de la generación de los 16 bits, con unos flamantes 128 Kb, usaba SRAM, pues para una cantidad tan pequeña no compensaba introducir un controlador de memoria. Vale, dentro de las DRAM, la reina absoluta es la SDRAM. Sí, otra letrita más. Significa memoría dinámica y síncrona. Es decir, que funciona con una señal de reloj como una CPU, y por tanto a un determinado número de MHz, que marcan la velocidad de transferencia. Las memorias asíncronas no usan ningún reloj, y por tanto, aunque más versatil, suele implicar una menor velocidad punta en la práctica, y mayor complejidad en la comunicación (realmente hay otro motivos, pero no me voy a meter porque sino me envalo). En los PC se empezó a usar habitualmente en la época de los Pentium MMX y los K6, alrededor del 1996, y en las consolas, cabe destacar que la Dreamcast usaba una memoria SDRAM de 100 MHz, muy popular en su momento. A esta memoria se le acabó llamando SDR (single data rate), en las que se transmite información cuando llega el flanco de subida del reloj, como es lo normal. Así, para saber el ancho de banda basta con multiplicar los ciclos de reloj por el número de bits del bus de datos. Para un bus de 8 bits a 100 MHz, serán 800 Mbits/s, o 100 Mb/s. En cambio, la DDR (double data rate), y atención para quien se haya dormido/perdido, que llego a lo que interesa, transfiere información en ambos flancos de reloj, el de subida y el de bajada. Por tanto, permite el doble de ancho de banda. Realmente la lectura sigue siendo en un solo flanco, como es habitual en todo circuito digital síncrono. El truco está en que internamente la memoria DDR incorpora una electrónica adicional y un buffer en el que se pueden leer dos datos simultáneamente, y luego envíar uno en el flanco de subida, y otro en el de bajada. Por tanto, la memoria SDR de la Dreamcast, de 100 MHz, seguiría teniendo un reloj de 100MHz si fuera DDR, pero tendría el doble de ancho de banda efectivo, es decir, en la práctica sería como una SDR de 200 MHz. Y eso mola, obviamente. El siguiente dibujo va a intentar aclarar estos conceptos. El cuadrado gris es el chip de memoria RAM. Dentro, el verde, representa las celdas de memoria, donde se guardan los datos, y el amarillo el buffer donde se leen antes de mandarlos por el bus, cuando se realizan lecturas. La flecha que sale del area gris es el bus de datos del sistema, que va a una CPU, GPU, DSP, o lo que sea. Sobre cada elemento, el reloj que emplea, marcando en rojo los flancos donde realmente se hace algo. En los que permanecen en negro no hay actividad. Una SDR sería como sigue.

Una memoria DDR, como se ve abajo, carga dos datos a la vez en el buffer, y así el bus puede transmitir en ambos flancos, sin necesidad de emplear memorias más rápidas. Lo importante aquí es ver que las celdas de memoria DDR a 200 MHz funcionan en realidad a 100 MHz, o lo que es lo mismo, igual de rápida que en una SDR a 100 MHz, pero con la velocidad de una a 200MHz.

El último paso es la DDR2, y la GDDR3, usada en la Wii, y también en la Playstation 3 y Xbox 360. Aqui se riza el rizo. Se vuelve a duplicar el ancho de banda efectivo. En el caso anterior de la Dreamcast, si esa memoria SDR de 100 MHz fuera DDR2 o GDDR3, sería equivalente a una SDR a 400 MHz (100MHz * 2 * 2). Internamente se leen cuatro datos simultáneamente con el mismo reloj de 100 MHz, pero luego se transfieren al doble de frecuencia (200 MHz) en ambos flancos, de subida y de bajada. Lo que permite mover los cuatro datos antes del siguiente flanco de 100 MHz de las celdas. O dicho de otra manera, obtenemos la velocidad de una memoria de 400 MHz con celdas de 100 MHz, lo que, como ya imaginareis, es cojonudo. Un dibujito le salvará a más de uno.

Las celdas de memoria siguen trabajando a la misma velocidad que en los casos anteriores. Pero como ahora se cargan cuatro datos a la vez, se pueden transferir cuatro datos antes de que la celda reciba su siguiente flanco. El buffer ahora se sincroniza al doble de frecuencia que las celdas, pues debe compartir el mismo reloj que el bus al que va conectada la memoria. Básicamente hace más obvia la estrategia de la DDR; cargar varios datos a través de un canal ancho, para mandarlos por el bus, de menos anchura, a mayor velocidad. Finalmente la 1T-SRAM que emplea Nintendo, que es una especie de híbrido. Internamente es una SDRAM SDR, pero rodeada de una circuitería que la hace funcionar de cara al sistema como una SRAM. Es decir, no hay que refrescarla, pues lo hace ella misma. Permite altas capacidades, como las DRAM, con rendimientos cercanos a la SRAM, según su fabricante. Además, parece tener una latencia muy baja, y por tanto, seguramente sea la preferencia número uno en la Wii como memoria de video. De hecho es el tema de la latencia donde la 1T-SRAM parece interesante. En la Gamecube tenía una latencia de unos 10 ns. Cualquier SDRAM debería caer por detrás en este apartado. De hecho un problema de la DDR y DDR2/GDDR3, es que aunque una RAM con celdas de sólo 100 MHz puedan ofrecer anchos de banda de 200 y 400 MHz, respectivamente, las latencias no mejoran. Siguen, a grandes rasgos, siendo las que caracterizan a la celda de 100 MHz, que al fin y al cabo es la que debe reaccionar y operar. La mejora de estas memorias se aplican a la velocidad de transferencia, pero no a las latencias. Y no, paso de currarme otro dibujo para la 1T-SRAM, 🙂 Aqui os dejo para compensar la gran perdida, una imagen de la GDDR3 de Wii.

Con nuevos conocimientos, y puede que algunos con más sueño, volvamos al ajo. Vale, la Wii pasa de tener 24 Mb de RAM a 88 Mb. Esta cantidad es casi la única que a primera vista ofrece una mejora superior al 50% (de hecho es más del triple de cantidad de memoria). Por cierto, también retiene los 16 Mb de RAM «lenta» que había enb la Gamecube, dedicada a tareas poco prioritarias. La adición de la memoria GDDR3 abre la posibilidad a mejorar bastante la calidad gráfica de los juegos, en cuanto a texturas se refiere. Obviamente no va a permitir mostrar más polígonos en pantalla, al menos no si queremos que se muevan, y esas cosas, porque el cuello de botella en este apartado, es claramente la capacidad para calcularlos y transferirlos de la memoria al buffer, es decir, una limitación de potencia de la CPU y GPU, y anchos de banda de los buses y las memorias. Vete tú a saber quien es el culpable. Dependería del caso, seguramente. Pero el aumento de memoria permitiría usar más texturas, más grandes y de mejor calidad. En el apartado de los gráficos ya hablaremos de ello, ahora sólo comentar las posibilidades que puede abrir. A tener en cuenta es el modo en que el Hollywood, y en concreto el controlador de memoria, gestionan las transferencias de ambas memorias, uno de los pocos apartados novedosos en la arquitectura del sistema. Por ejemplo, estaría bien saber si es posible leer de forma sostenida de ambas memorias a la vez. Si ese fuera el caso, se podría considerar que la Wii no sólo está limitada a un 50% más del ancho de banda de la Gamecube, sino que podría llegar a triplicarlo. Los 3,8 Gb/s de la 1T-SRAM colodada al lado de la GPU, y los 4 Gb/s de la GDDR3, juntas rozarían los teoricos e hipoteticos 8 Gb/s, lejos de los 2,6 Gb/s de «Cube». Esta posibilidad no es nada descabellada, pues aunque requiere un sistema más complejo, con casi toda seguridad la 1T-SRAM tiene su propia conexión con el northbridge, ya que comparten encapsulado, y la GDDR3 se comunicaría a través de un bus externo. Los detalles exactos de las frecuencias de reloj y anchura de los buses no está en mis manos, aunque todas las fuentes que he consultado corroboran los datos que he dado, y estimo que ambos buses podrían ser de 64 bits. Es una solución considerada hoy en día como «económica», ya que actualmente se estilan los buses de 128 bits para buses de alta velocidad, e incluso los 256 bits. Hay que recordar que el número de bits de un bus representa el número de bits que es capaz de mandar simultáneamente cada ciclo de reloj (o dos veces por ciclo, como en los buses DDR). Pero cada bit de un bus es en realidad una línea en la placa de circuito impreso. O sea que el diseño del trazado de las pistas se vuelve más complejo, ocupa mayor area, y es por tanto, más caro. Además hay otros problemas tecnológicos. Por mencionar algunos, para quien esté interesado, si un chip usa un bus de 256 bits, esas 256 pistas hay que conectarlas a pines o pads de conexión de ese chip. Y además hay otras muchas líneas necesarias que hay que conectar (bus de direcciones, señales de control, alimentación, …). A veces el elevado número de uniones dificulta el empleo en encapsulados de pequeño tamaño, pues hay un espacio físicamente muy reducido para ello. Para dar una visión más clara, la imagen de abajo muestra una hilera de pines metálicos que corresponden a un lado de un pequeño chip de un reproductor MP3. Las pistas son los trazados verde claro, que es una capa protectora bajo la cual hay un conductor, habitualmente cobre. El pin marcado en rojo es conectado a un terminal de un condensador (color marrón) y a uno de los terminales de un botón (que en la imagen no se ve), encuadrados también en rojo. El pin del chip indicado con violeta, lleva a una «via», que es una especie de agujero que sale por la otra cara de la placa, y sirve precisamente para eso, para llevar una señal que recorre uno de los lados de la placa, a la otra, bien porque el componente al que debe ir reside en la cara opuesta, o bien para poder cruzar una serie de obstáculos, etc…

Si el controlador de memoria de Wii no es capaz de leer de forma sostenida de la 1T-SRAM y la GDDR3, entonces el ancho de banda quedaría en un 50% más que la Gamecube. Y aunque nos pusieramos en el caso optimista de que sí se pudiera hacer, hay que recordar que la Wii sigue empleando un bus bastante lento para la CPU, que no llega a los 2 Gb/s (repito la imagen del esquema de la consola aqui abajo para que se vea más claro sin ir «parriba» y «pabajo»). Esto por ejemplo, impediría transferir a la CPU un caudal de datos superior a los 2 Gb/s (entre ir y venir). Y esto es a duras penas la mitad del ancho de banda de cada una de las memorias. Aunque no es un problema muy severo, y no considero que desequilibre un sistema como la Wii, hay que tenerlo en cuenta. Lo normal es que la GPU tenga más hambre de datos, y es a quien hay que mimar más, si queremos que la consola nos de poligonitos, efectos, y esas cosas que todos sabemos que hacen buenos a los juegos (yo desde luego no 😛 ).

Si queremos ser un poco más prácticos, aunque se pudiera leer de ambas memorias a la vez, en aplicaciones reales no creo que se superara nunca el 75% del aprovechamiento del ancho de banda. ¿Por qué? Vamos a meternos un poco a ver esto, que me parece interesante. Vamos a hacer un sencillo análisis ingenieril. Aviso que a partir de aquí, son razonamientos y suposiciones mías, sin demostración científica avalada por ninguna universidad de Cánada o Estados Unidos, simplemente para mostrar un breve análisis. Supongamos que la GPU está haciendo pleno uso de su memoria 1T-SRAM, leyendo y escribiendo téxturas, polígonos, etc. Esto ocuparía los 3,9 Gb/s de ancho de banda de la 1T-SRAM. Dificilmente la GPU podría estar usando simultáneamente la GDDR3, pues el Hollywood trabaja internamente a sólo 243 MHz. Cada ciclo de reloj suyo, le llegan 16 bytes (3900 / 243). Internamente, dispone de 2Mb de memoria embebida para usar como buffers, y 1 Mb para texturas. Estas memorias son muy rápidas (Seguramente podría alcanzar los 11.5 Gb/s y 15.6 Gb/s respectivamente), y lo más eficiente es tirar de ellas siempre que sea posible. Pero como son bastante pequeñas, hay que ir recargando su contenido continuamente. A un ritmo de 16 bytes por ciclo, un bus de 64 bits hacia cada memoria interna, permitiría llevar 8 de esos 16 bytes a cada una. Es decir, se podrían llenar desde la 1T-SRAM externa a una velocidad aproximada de casi 2 Gb/s, cada una, y cuando su contenido se reutilizase, acceder a él a una velocidad muy superior, de entre 11.5 y 15.6 Gb/s. Sí, claro, aquí está el diagrama (velocidades aproximadas, realmente a la entrada serían 3,9 Gb/s y 1,95Gb/s).

Es posible que el Hollywood no sea capaz de recargarlas a mayor velocidad de la que he comentado, y por tanto, no tendría sentido llegar a usar la GDDR3, pues no sería capaz de dar uso a un mayor caudal de datos. La GDDR3 quedaría, en este hipotético caso, para la CPU. Pero el Broadway sólo puede recibir datos de la memoria a través del northbridge, integrado en el Hollywood, a través de su bus de 1,94 Gb/s. Como la GDDR3 permite 4 Gb/s, a penas el 50% de su capacidad estaría siendo utilizada. El tema sería este.

La pregunta es… ¿la CPU va a estar siempre leyendo o escribiendo en RAM a tanta velocidad? Digamos que 1,94 Gb/s sería el máximo. ¿Y el mínimo? El mínimo sería el tráfico generado por las instrucciones que se están ejecutando, cuando no hay otros movimientos de datos. El Broadway es capaz de lanzar a ejecución hasta dos instrucciones por ciclo. En el caso optimista de que así sea, debe leer esas dos instrucciones de memoria, y llevarlas a su front-end para ser decodificadas, planificadas y lanzadas. Si suponemos en este hipotético caso, que las instrucciones, leídas previamente del DVD del juego, residen en la GDDR3, entonces, habría que leer dos instrucciones por ciclo, y como cada una es de 32 bits, o lo que es lo mismo, 4 bytes, resulta que para poder lanzar dos instrucciones por ciclo de CPU, habría que leer 8 bytes cada uno de esos ciclos. O lo que es igual, más de 5,8 Gb/s (2 * 4 * 729). Que sorpresa, ¿no? Este resultado nos indica que el Broadway no es capaz de lanzar dos instrucciones a la vez de forma sostenida, pues sólo dispone de un tercio del ancho de banda requerido para ello. Ni siquiera sería capaz de lanzar una por ciclo, pues eso ya significaría un ancho de banda de casi 2,9 Gb/s (4 * 729). Luego, vemos que el mínimo ancho de banda para ejecutar una instrucción por ciclo desde memoria RAM, es ya más del que dispone la CPU. Hecho que me sorprendió mucho cuando lo vi por primera vez, hace ya tiempo, al estudiar otro sistema. Es fácil pensar que la velocidad a la que se comunica la CPU con el sistema es necesaria para mover datos. Y es fácil olvidarse del tráfico que generan las instrucciones, así que cuando te das cuenta de casos como el de Wii, te preguntas, ¿que el ancho de banda de la CPU ni siquiera fuera capaz de suministrar instrucciones? Vaya mierda. Pero no lo es tanto. Puede que a muchos les parezca pues, que de nada sirve que el Broadway sea una CPU superescalar, capaz de lanzar hasta dos instrucciones por ciclo. Pero desde luego sirve, pues he dejado intencionalmente un detalle fuera de este análisis. La caché L1 y L2. Sí, todo empieza a tener sentido, para los que aún no se han dormido, jeje. El Broadway simplemente no es capaz de trabajar al máximo rendimiento con instrucciones que debe traer de la RAM, pero todas las que trae se almacenan en la caché L1 de instrucciones, y antes de desaparecer, en la L2. Cuando se vuelve a requerir alguna que ya está en caché, su recuperación es mucho más rápida. Así pues, el Broadway sí es capaz de lanzar dos instrucciones por ciclo, si éstas están en caché. Y por tanto, parece muy razonable pensar que el limitado bus de la CPU, de sólo 1,94 Gb/s va a estar facilmente ocupado, cercana a su máxima capacidad. Pues aún sin requerir datos, lo cual no sucede casi nunca, solo a base de instrucciones, Broadway sólo es capaz de recibir 2/3 de una instrucción por ciclo, y eso que podría lanzar dos de ellas en ese mismo periodo de tiempo. Los datos viajan por el mismo bus, y por tanto, cuando son necesarios y se están transfiriendo, ninguna instrucción puede leerse, y viceversa. Todo esto nos clarifica la tremenda importancia de las caches L1 y L2 de los procesadores. Terminando el análisis de este hipotético caso, el Hollywood estaría usando 3,9 Gb/s y el Broadway 1,94 Gb/s, sumando un total de 5,84 Gb/s, y en otras palabras, un 124% del disponible en Gamecube (el doble y un cuarto). Y para poner la guindilla, y ver otro ejemplo de análisis real, imaginemos que sólamente el 60% del tiempo se mantienen estás velocidades en la Wii. El otro 40%, la CPU va tirando de instrucciones en caché, y la GPU de sus memorias embebidas, bajando el tráfico externo, y reduciéndose el ancho de banda total empleado de 5,84 Gb/s a, digamos, unos 3,5 Gb/s. Hay una formula muy famosa en informática, que en una de sus expresiones nos permite calcular el ancho de banda efectivo resultante. (0.6 * 5,84) + (0.4 * 3,5) = 4,904 Gb/s Y si se quiere saber cual es la mejora respecto a la Gamecube, con 2,6 Gb/s correspondientes a su única memoria externa 1T-SRAM. ((0.6 * 5,84) + (0.4 * 3,5)) / 2.6 Gb/s = 1,886 O lo que Wii estaría siendo un 88,6 % más rápida. A este factor se le suele llamar «speed-up», que genéricamente se refiere al aumento de las prestaciones de determinado sistema frente a otro. Hasta aquí mis elucubraciones. UN RESPIRO Y de momento hasta aquí hemos llegado. Este 7º artículo lo voy a publicar en dos tandas, porque menuda gaita 🙂 Espero que haya resultado instructivo, y que todos paseis unas felices fiestas. Solo con haber leído este artículo ya os lo merecéis, jeje. Nos vemos pronto. Continuará…