La carrera de los bits y los megahercios, segunda parte

Videoconsolas y PC

Las consolas clásicas en un vistazo

Las primeras videoconsolas de cierta potencia, capaces de mostrar un plano de scroll y sprites con un mínimo de detalle, como la NES o la Master System, eran en su esencia muy parecidas a los ordenadores de la época, como el Spectrum, Amstrad o Commodore, y estaban constituidas principalmente por:

• Una CPU de modesta potencia (hoy día, de ínfima potencia, desde luego)
• Una pequeña cantidad de memoria RAM, de la cual parte estaba dedicada a tareas gráficas y parte estaba dedicada a propósitos generales
• Uno o varios coprocesadores diseñados para realizar tareas relativas al juego (vídeo y audio, generalmente). Sin esta ayuda, la CPU hubiera sido incapaz de manejar los juegos que lo hacían estas consolas. Tendrían que haber sido más sencillos, como los de Atari o Amstrad. Pero hasta la fecha los videojuegos han tendido al perfeccionamiento, y éste fue un paso importante.

Una Master System, por ejemplo, sin coprocesadores tendría una potencia equivalente a un Spectrum+, y no creo que pudiera mover juegos mejores que los que salieron para el Speccy (nombre cariñoso del popular ordenador de Sinclair). La única ventaja sería que no tendría tiempos de carga, al usar cartucho en vez de cinta, y que podría manejar juegos más grandes, porque la Master System usaba mapeadores para generar la ilusión de que la memoria era más grande de lo que era. (Si el término mapeador no te es familiar, tal vez quieras echarle un vistazo a mis tutoriales en Consolas para siempre, apartado de documentación, “Lo + básico de NES”, “Lo + básico de Master System”). Echemos un breve vistazo por encima a la NES y la Master System. Valores aproximados, no es mi intención dar una especificación exhaustiva:

	NES	Master System	PC modesto de la época (1990)
CPU	6502 8 bits 1.7MHz	Z80 8 bits 3.5MHz	386 32 bits 25MHz
RAM principal	2Kb	8Kb	4Mb
RAM de vídeo	2Kb	16Kb	512Kb
Procesador de vídeo	PPU Chip diseñado en exclusiva	VDP Chip diseñado en exclusiva	VGA (con suerte)
Procesador de audio	No disponible*	Integrado en el VDP	–
Tamaño máximo de memoria manejable	64Kb	64Kb	4Gb**
Tamaño máximo de un juego	1Mb	512Kb	En principio, mucho :-)***
Otros	–	–	–

De momento vemos que nuestras 8 bits en poco o nada se pueden comparar a un PC actual, cuya CPU ronda los 2GHz, y tiene una memoria RAM de al menos 512Mb. Supongo que esto se veía venir (espero). Más interesante es saber que eran máquinas mucho menos potentes que un PC de la época, en cuanto a los números al menos. Pero ya sabemos que el término potencia depende mucho de a qué nos refiramos, y de cómo la manejemos. De momento diré que eran arquitecturas muy distintas, orientadas a tareas muy diferentes.

Las consolas de 16 bits: el auge de las 2D

Las consolas de 16 bits, Mega Drive y Super Nintendo, pueden verse como una evolución de la arquitectura de sus predecesoras más que como una revolución. No constituyen en sí un cambio radical de concepto, sino que amplían el esquema de las 8 bits con más potencia. Con ellas llegamos a la época dorada de los juegos en 2D.

	SNES	Mega Drive	PC modesto de la época (1993)
CPU	65816 16 bits 3.5MHz	Motorola 68000 16 bits 7.5MHz	486DX2 32 bits 50MHz
RAM principal	128Kb	64Kb	8Mb
RAM de vídeo	64Kb	64Kb	1Mb
Procesador de vídeo	2 PPU* Chips diseñados en exclusiva	VDP** Chip diseñado en exclusiva	VGA o SVGA
Procesador de audio	Dos chips de Sony, con capacidad de sonido digital	Un chip de Yamaha Otro chip integrado en el VDP***	Sound Blaster 16
Tamaño máximo de memoria manejable	16Mb	16Mb	4Gb
Tamaño máximo de un juego	4Mb	4Mb	–
Otros	–	Coprocesador Z80 a 3.5MHz	–

De acuerdo; como se puede ver y ya adelanté, todavía no hay por dónde coger al PC. En los años que pasaron entre las 8 y las 16 bits, los ordenadores personales evolucionaron bastante. Pero es precisamente ahora cuando llegamos al punto interesante de este articulo.

Llegan las 3D: entendiendo el cambio que ello supone

A partir de ahora me referiré a las videoconsolas de 32 bits en adelante, es decir, las de la era 3D.

Aplicaciones estáticas y aplicaciones multimedia.

En primer lugar, un videojuego no es más que un programa. Software. Muy similar al resto de programas que usas en tu ordenador, pero concebido para entretener. No obstante, hay diferencias entre un programa estático típico, como tu procesador de textos o tu navegador, y una aplicación multimedia o dinámica, como los videojuegos. Y estas diferencias son cruciales para entender el rendimiento y la potencia de una videoconsola y un ordenador frente al juego.

Primera diferencia: operaciones en coma flotante

La mayoría de los programas estáticos realizan casi todas sus operaciones con números enteros (positivos y negativos, sin decimales). Por ejemplo, 5, 2, -3, 37, etc. En cambio, las aplicaciones dinámicas hacen un uso más o menos intensivo de operaciones en coma flotante (números positivos y negativos, con un número variable de decimales). Como mínimo habrás oído hablar de este tipo de operaciones. Para quien no sepa a qué me refiero, daré unos ejemplos.

Notación científica	2×103	-5×106	3,5×10-4	3,38×10-1
Representación estándar	2000	-5000000	0,0035	0,338

Los números en notación científica se forman por un número que multiplica a una base elevada a un exponente. Por ejemplo:

• El primer número de la tabla es un 2, por base 10 elevada a 3. Significa es que al 2 hay que multiplicarlo 3 veces por 10.
• El segundo número es un -5 por base 10 elevada a 6. Al -5 hay que multiplicarlo 6 veces por 10.
• El tercer número, como tiene exponente negativo, hay que dividirlo 4 veces por 10.
• El cuarto número te lo dejo a ti

Básicamente, se trata de escribir el número y correr la coma hacia la derecha tantas veces como indique el exponente del 10, si éste es positivo (añadiendo ceros si es necesario), o hacia la izquierda, si dicho exponente es negativo. Un número en notación científica que se almacena en binario en un computador siguiendo una serie de normas, forma un número en coma flotante. Las operaciones en coma flotante son más lentas y requieren un hardware más complejo que las operaciones con enteros. ¿La ventaja? A veces son imprescindibles. Hay aplicaciones que necesitan manejar un número variable de decimales, cosa muy útil e interesante por ejemplo para cálculos matemáticos o físicos que hay tanto en programas científicos como de simulación. También las aplicaciones de compresión de vídeo o audio, y por supuesto los videojuegos en 3D, hacen un uso intensivo de operaciones en coma flotante.

Segunda diferencia: datos e instrucciones. Entendiendo cada cosa

Los programas están formados por una secuencia de instrucciones que la CPU va ejecutando una tras otra. Estas instrucciones operan a su vez con datos, ya estén éstos almacenados en el propio programa (por ej. en una ROM), en la memoria de la máquina (RAM), en la caché o en los registros de la CPU. En un sistema mínimamente complejo existe una jerarquía de memoria. La memoria secundaria es un almacén masivo de datos (ej. disco duro, CD o DVD). Todos los datos aquí guardados deben ser cargados en memoria RAM antes de poder ser usados por la CPU. De ahí que los “loading” aparecieran con las consolas de CD. Lo que hace el “loading” es cargar información en la memoria RAM, es decir, subir por la jerarquía de memoria. La RAM es mucho más rápida que la memoria secundaria, pero es mucho más cara. Por ello, para mejorar el rendimiento del sistema se usa una pequeña cantidad de RAM en combinación con una memoria secundaria mucho mayor. Así, en la PlayStation o en la Saturn podíamos tener juegos de hasta 650Mb, con una memoria RAM de sólo 2Mb. De esta manera, se puede “virtualmente” cargar todo el CD, pero en fracciones de 2Mb. Cuando se requiera otra información (ej, pasamos de nivel), habrá que remplazar los datos de la RAM por otros nuevos. Es decir, la RAM se usa como buffer (almacén temporal). Aunque son técnicas muy diferentes, a efectos prácticos es similar a lo que conseguían los mapeadores en las 8 bits: dar la ilusión de tener una memoria más grande, haciendo visible a la CPU una pequeña porción del juego en cada momento. Pero con los mapeadores no existía una desventaja muy relevante, que sí aparece en la era CD: los tiempos de carga. En los cartuchos no había pantallas de carga porque los juegos estaban almacenados en memoria ROM, que es tan rápida como la RAM y permite ejecutar directamente desde ella. Pero ya podemos ver la desventaja de esto: el coste. La ROM es mucho más cara que un CD o un disco duro. Por eso, cuando aumentaron las necesidades de tamaño, se pasó a otro soporte de menos coste por byte.

La caché va más allá

La idea de la caché es añadir a la jerarquía de memoria un nivel más rápido que la RAM. Todo lo que la CPU va requiriendo se carga en la caché. Ésta tiene una capacidad muy pequeña, pero su velocidad es endiablada y su cometido es guardar los datos e instrucciones que la CPU ha necesitado recientemente. Así pues, en la caché se almacena un conjunto muy pequeño de información con la que está trabajando la CPU. La ventaja es que mientras lo que queramos esté en la caché podremos disponer de ello muy rápidamente porque no habrá necesidad de traerlo de nuevo de la RAM, que lleva mucho más tiempo. Y por lo tanto, es lo mismo que cargar del CD a la RAM. Lo que ya está en la RAM no hay que leerlo del CD. Pero la caché va más allá, porque permite que la CPU trabaje mucho más eficientemente, y cuando funciona bien, imprime una mejora masiva de rendimiento. En una aplicación dinámica (por ejemplo, un videojuego), donde una serie de operaciones tienen que hacerse en un tiempo determinado, es vital que todo se haga lo más rápido posible (y si no, pues ya se sabe, el juego se ralentiza, da trompicones y esas cosas). Todo el rollo de la caché sirve para entender lo que viene a continuación. Una aplicación estática suele operar con un conjunto de datos más o menos definido, pero siguiendo un flujo de instrucciones en principio desconocido, que varía constantemente. Algunos os preguntaréis de dónde saco esto. Fíjate en que este tipo de programas suelen tener muchas opciones distintas al alcance del usuario. Por ejemplo, en un procesador de textos podría crear tablas, pasar el corrector ortográfico, hacer una conversión… tareas variopintas a las que el usuario puede acceder cuando quiera, pero que operan sobre unos mismos datos (el documento). Una aplicación dinámica suele operar con un volumen muy elevado de datos. Un juego requiere procesar continuamente las posiciones de los objetos, la rotación de los polígonos, la física… y todo eso es un chorro constante de datos que vuelan a toda velocidad hacia la CPU. En cambio, muy a menudo este procesamiento es llevado a cabo por porciones pequeñas de código con unas pocas instrucciones que se repiten muchas veces. Esto es muy importante, porque va a condicionar enormemente el rendimiento de la caché.

Cuadro resumen del uso de las cachés

Los diagramas que siguen muestran la caché como un almacén, con dos “cañerías” para meter y sacar información. La parte coloreada de la cañería simboliza el caudal que entra y sale, y los bloques coloreados de dentro de la caché, la cantidad de información que se reutiliza, o en otras palabras, que beneficia al rendimiento. La caché suele estar dividida en caché de instrucciones y caché de datos. Básicamente, las aplicaciones estáticas hacen buen uso de la caché de datos y malo de la de instrucciones, y las aplicaciones dinámicas todo lo contrario, aunque tal vez peor, porque el pésimo uso de la caché de datos está agravado por el elevado ritmo y la masiva cantidad de datos que se mueve. El tema de la caché es mucho más complejo, y he ocultado detalles para no enfarragar. En futuros artículos tal vez retome el tema. De momento no quiero perder el hilo.

Tercera diferencia: ancho de banda

El ancho de banda es la capacidad de un canal para transmitir información. En nuestro caso, el ancho de banda será el número de bits por segundo que se pueden transferir. Este flujo de datos se envía casi siempre por medio de buses. Un bus es un canal de comunicación compartido. A él van conectados distintos dispositivos, de los que sólo uno puede emitir, mientras el resto escuchan. Cuando muchos quieren emitir a la vez, se debe esperar y se degrada el rendimiento. En la imagen de abajo se ve un ejemplo ficticio. Las líneas de color oscuro son buses. Como puede verse, hay un bus ancho entre la CPU y la memoria RAM y otro más estrecho que comunica la CPU, un procesador de entrada/salida (I/O) y un coprocesador (Cop). Mientras que la CPU puede enviar y recibir datos de la RAM cuando quiera por medio de su bus dedicado, sólo puede comunicarse con el procesador de entrada/salida si ni éste ni el otro coprocesador están enviando datos. El ancho de banda de un bus es el número de bits que se pueden trasmitir por él cada segundo. Siempre que no sea imprescindible, un bus se comparte por varios dispositivos, ahorrando así tener que conectarlos individualmente, uno por uno. Por tanto, un bus debe verse como una autopista de datos usada por muchos contribuyentes, respetando la norma de que sólo uno esté enviando información en cada momento. Así que todos se comportan amigablemente, y por tanto, si yo quiero mandar algo y otro está en posesión del bus, debo esperar.

A veces esto no es tolerable, porque se necesita asegurar un cierto caudal de datos, así que se utilizan buses dedicados para conectar dos dispositivos, como la CPU y la RAM del dibujo. Así se evitan esperas innecesarias y ralentizaciones debido al tráfico de otros elementos del sistema. Por ejemplo, se podría haber hecho esto: Así no habría ningún tipo de espera por incordio del vecino. Pero esto que a priori parece razonable, no suele ser común. Resulta mucho más caro, sobre todo porque en un sistema real hay muchas conexiones que hacer. No son esquemas tan sencillos. Y el coste adicional es en dinero, y también en superficie de circuito. Más conexiones implica trazar más pistas, y siempre interesa mantener todo lo más pequeño posible. Una aplicación estática suele trabajar bien con grandes cachés, donde quepan la mayor parte de los datos e instrucciones que se necesitan. De este modo, no se requiere un gran ancho de banda entre la CPU y el sistema porque los accesos a memoria no son continuos, la comunicación con dispositivos externos (como una memoria USB) consume muy pocos recursos, y además no suele haber una restricción muy fuerte de velocidad. Es decir, menos rendimiento implica esperar unos segundos más a que el procesador de textos exporte nuestro documento a otro formato, por ejemplo, pero nada más. Una aplicación dinámica no puede apoyarse únicamente en más caché. El torrente de datos es masivo, y se requiere cambiar el enfoque de diseño si queremos hacer consolas potentes. Y no basta tampoco con hacer una súper-CPU, como muchos creen, porque lo más importante es mantener esta súper-CPU alimentada continuamente de datos e instrucciones que deben traerse de la memoria a gran velocidad. Si no, la súper-CPU se pasará la mayor parte de su super tiempo sin hacer nada, desperdiciando su potencia y los millones de euros que costó su desarrollo. Para el rendimiento de una videoconsola, el ancho de banda entre la CPU y el resto de dispositivos, en especial la memoria, es vital.

Requisitos de una consola 3D

Una consola 3D está concebida casi exclusivamente para ejecutar aplicaciones dinámicas, por lo que para ser potente y poder mover juegos más complejos deberá:

• Ser muy rápida haciendo operaciones en coma flotante
• Conseguir paliar el efecto del pésimo uso de la caché de datos
• Manejar una alta tasa de transferencia de bits entre la CPU y el sistema.

Hablaré de lo primero más adelante. El resto lo ilustraré con un ejemplo. Imagina que eres el dueño de una fábrica que necesita de materia prima para elaborar un producto. Todo es transportado por camiones, que traen los materiales desde distintos lugares y llevan tu producto para ser vendido. Podrías pensar en usar camiones de gran tonelaje, que una vez por semana te abastecen, y en construir un enorme almacén en tu fabrica, para guardar toda la mercancía. De este modo, con buena organización, tu ritmo de producción sería constante a la máxima velocidad que te permitiera tu maquinaria, tus operarios, etc. Pero este esquema no es adecuado para todas las tareas. Imagina que tu fabrica usa productos perecederos, que no pueden ser almacenados mucho tiempo, y los consume muy rápido. Estos productos requieren condiciones especiales. Te resultaría muy caro usar camiones grandes, adaptados, a lo que habría que sumar además el coste del gran almacén. Con la solución esbozada anteriormente, lo único que podrías hacer es traer cuantos más productos fuera posible en los camiones, apilar todo lo que puedas en tu gran almacén, y empezar a rezar para que:

• Nada se estropeé, o se eche a perder
• El rápido ritmo de producción no consuma todas tus reservas antes del siguiente envío

No es una solución muy interesante; intentemos mejorarla. Para empezar, vamos mejorar los accesos a nuestra fabrica y nuestra logística, de manera que haya muchos más envíos. Vamos a usar más camiones, que lleguen más a menudo. Y nos vamos a ahorrar el gran almacén: construiremos un pequeño local que servirá de almacenamiento temporal, que contendrá los productos que acaban de llegar y esperan a ser procesados en nuestra fábrica. Asegurándonos un suministro constante y abundante tendremos nuestra fábrica funcionando al máximo de su capacidad. Ésta es la forma de trabajar de una consola. Un gran ancho de banda (muchos camiones, muchos envíos) que mueve el enorme flujo de datos por el sistema, y una memorias no muy grandes (pequeño almacén temporal), que no buscan guardar muchos datos, sino permitir un movimiento veloz y continuado, abasteciendo a la CPU y los coprocesadores con materia prima fresca.

Primera comparación entre consolas y PC

Ordenador PC
Aplicaciones	Son máquinas pensadas para ejecutar razonablemente bien un conjunto muy amplio de programas, y principalmente aplicaciones estáticas.
Coma flotante	Aunque cada vez se le presta más atención, y los Pentium 4 y Athlon se han esforzado en mejorarlo, los PC se han caracterizado por un rendimiento en coma flotante mediocre en comparación con otros sistemas. Procesadores un poco más antiguos, como el Pentium y el K6, eran bastante lentos en este tipo de operaciones, lo que constituía uno de los principales limitantes en aplicaciones que se apoyaban en coma flotante, entre ellos los videojuegos.
Memoria y caché	Suelen tener una cantidad generosa de memoria RAM y una memoria caché lo más grande posible, aspirando a mantener la mayor cantidad de información retenida y apoyándose en ello para alcanzar un elevado rendimiento.
Ancho de banda	La comunicación de la CPU con la memoria se hace a través de un bus principal, muy rápido (FSB). Para el resto de componentes se usan otros buses de menos ancho de banda: Uno dedicado para la tarjeta gráfica (AGP). Otro para las ranuras de expansión PCI. Otros para los discos duros, USBs, puertos paralelo y serie…

Videoconsola
Aplicaciones	Están pensadas para ejecutar un conjunto reducido de aplicaciones pero haciéndolo muy bien, principalmente aplicaciones dinámicas.
Coma flotante	Es un aspecto al que se le da mucha prioridad, y normalmente tienen un elevado rendimiento en este aspecto aspirando a hacer cuantos más cálculos sea posible, lo que se traduce en más polígonos y una física más compleja.
Memoria y caché	Suelen tener mucha menos memoria que un PC, y cachés más pequeñas, aspirando más a transportar la información muy rápido que a almacenar una gran cantidad, apoyándose en esto para alcanzar un elevado rendimiento.
Ancho de banda	La comunicación entre la CPU y los distintos dispositivos está optimizada para alcanzar altas velocidades de transferencia, distribuyendo el tráfico a través de multitud de buses independientes estratégicamente colocados, que garantizan un alto rendimiento.

Todo esto es mucho más fácil de diseñar en una máquina como una consola, cuyo objetivo es muy concreto. Un PC es el blanco de un abanico de aplicaciones muy extenso, que complica su optimización, porque ya se sabe, no puede llover a gusto de todos. En la Dreamcast, el bus que comunica la CPU con la memoria tiene un ancho de banda de 800Mb/s. Por ese bus podría mandarse una cantidad de información equivalente a la que cabe en un CD, en menos de un segundo. Es mucha velocidad, sobre todo para su época (1997). Y por si 800Mb/s pareciese mucho, dentro de la CPU el bus que comunica la caché con las unidades de coma flotante tiene un ancho de banda de 3.2Gb/s. Parece que se busca hacer muchas operaciones en coma flotante. ¿Será casualidad? Como nota diré que este canal de 3.2Gb/s, que es sin lugar a dudas rapidísimo (y monstruoso para su época), no puede ser exprimido al 100% en aplicaciones reales ya que está limitado a la comunicación caché-unidades de cálculo, y la cache requiere ser rellenada, como es obvio. Los accesos a la RAM para refrescar el contenido de la caché echa abajo parte del rendimiento máximo teórico de la consola, que aun así es muy respetable. En la PlayStation 2, la memoria RDRAM tiene un ancho de banda de 3,2Gb/s (dos canales de 16 bits a 800MHz, o sea (2*16*800millones) / 8). Los buses internos del Emotion Engine pueden transportar hasta 2,4Gb/s, y la consola es mucho más potente que la Dreamcast en coma flotante, aunque hay que decir que los cálculos de rendimiento de SONY son, cuanto menos, muy optimistas en todos los aspectos. Eso de que la PlayStation es capaz de mover 60 millones de poligonos… jejej. Ni en sus sueños más salvajes, vamos. Claro, así los seis millones de polígonos que daba Nintendo para su GameCube parecía poca cosa. Pero en cambio, en aplicaciones reales no creo que la Play pase los 20 millones de polígonos (y creo que estoy siendo optimista), mientras que parece que la GameCube es capaz de sobrepasar los 12 millones de polígonos. Bueno, a lo que iba. Estaba hablando del rendimiento en coma flotante. El máximo teórico de la Dreamcast es 1,4GFLOPS. El máximo teórico de la PlayStation 2 es de 6,2GFLOPS. En la vida real, la Dreamcast puede alcanzar los 0,9GLOPS. En la vida real, la PlayStation 2 puede alcanzar los 2GFLOPS. Aviso de que todo esto es muy difícil de medir, y depende en gran parte de la aplicación, el detalle y la maestría de los programadores. Además, la PlayStation 2 tiene una arquitectura un poco extraña y difícil de manejar. En teoría es una mala bestia, pero en la práctica casi depende más de la habilidad de exprimir y usar eficientemente esa potencia. Más sobre esto pronto.

La comparación que sí vale

Ya presenté al principio un cuadro comparativo de las retroconsolas de 8 y 16 bits con los PCs de su época, pero ahora llega el momento de comparar una consola 3D, a la que se aplica todo lo que hemos hablado, y discutir los resultados.

	Dreamcast	PlayStation 2	PC modesto de la época (1999)
CPU	Hitachi SH4 32 bits 200MHz	Emotion Engine* 64 bits 300MHz	AMD Athlon 32 bits 700MHz
Caché	8Kb (instrucciones) 16Kb (datos)	40Kb (instrucciones)** 32Kb (datos)**	64Kb (L1) 512Kb (L2)***
RAM principal	16Mb	32Mb	128Mb
RAM de vídeo	8Mb	4Mb (embebida)	32Mb
Procesador de vídeo	PowerVR2	Graphics Synthesizer Diseñado en exclusiva	GeForce 256
Tamaño máximo de un juego	1Gb	4Gb	–
Otros	Usa un ARM7 como coprocesador de audio	El procesador de I/O lleva «integrada» una PSX	–

Como puede verse, y espero que no sea ninguna sorpresa, las especificaciones del PC siguen sobrepasando en todo y por bastante —aunque no tanto como antes— a las de una consola, o al menos eso parece. Se aprecia como las memorias son más pequeñas en las consolas, algo de lo que ya hemos hablado. Así que con toda esta información, pasaré a dar un breve repaso sobre la manera en la que procesan videojuegos un PC y una consola. Cuál es su estrategia, planteamiento, y cómo se las apañan para exprimir el máximo número de polígonos. A ver si consigo unir todo lo que he explicado en este articulo y dar una visión de conjunto que permita entender de dónde sale el rendimiento de nuestra consola.

En el próximo artículo… ¡Enfrentaremos nuestra PS2 al PC! 🙂 Hagan sus apuestas. Por cierto, iba a hacer una comparación Dreamcast vs PC, porque la de PlayStation vs PC es más típica, pero es muy didáctica y además supongo que captará más interés. Aunque si surge la posibilidad, escribiré sobre la Dreamcast 😉