LA CARRERA DE LOS BITS Y MEGAHERCIOS.   2ª PARTE.

Videoconsola y PC.

Por David Senabre Albujer. Julio de 2006.

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 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.

- Parte estaba dedicada a propósitos generales.

- Uno o varios coprocesadores; diseñados para realizar tareas relativas al juego (video y audio, generalmente). Sin esta ayuda, la CPU sería incapaz de manejar los juegos que se hacían para 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 este fue un paso importante.

Una Master System, por ejemplo, sin coporocesadores, tendría una potencia equivalente a un Spectrum+, y no creo que pudiera hacer 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: http://www.consolasparasiempre.net. 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 exhaustiva especificación).

• * La CPU se encargaba de esta tarea, para lo que se modificó la CPU 6502 original.
• ** Máxima cantidad de memoria RAM que puede usar (sin contar memoria virtual).
• *** Limitado por el tamaño máximo de memoria virtual, que es 1 Terabyte. Lógicamente, la verdadera limitación era el tamaño del disco duro y la memoria RAM instalada. En aquella época los discos duros rondarían los 100 o 200 Mb. Y sobra decir que ningún juego de entonces ocupaba esa monstruosidad.

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 termino 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 distintas.

LAS CONSOLAS DE 16 BITS. EL AUJE DE LOS 2D 

Las consolas de 16 bits, por seguir con el hilo anterior, la Megadrive y la 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.

• * Se llaman igual que el de la NES, pero no tienen nada que ver. PPU significa chip de imagen (picture processor unit), y así es como lo llamó Nintendo. En la SNES son mucho más potentes.
• ** Igual, es una versión mejorada y ampliada del VDP de la Master System. VDP es el nombre que eligió SEGA para el chip gráfico y significa Video Display Processor.
• *** El que está integrado da la funcionalidad de sonido que tenía ya la Master System. El Yamaha es el que expande la potencia sonora de la Megadrive.

De acuerdo, como se puede ver, y ya adelanté, todavía no hay por donde 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 llego 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. Igual que el resto de programas que usas en tu ordenador, pero que ha sido concebido para entretener. Pero hay más 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.

1ª 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 quién no lo sepa, daré unos breves ejemplos.

Notación científica
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. Lo que 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, físicos, que hay tanto en programas científicos, como de simulación. También las aplicaciones de compresión de video, audio, por ejemplo, y por supuesto los videojuegos en 3D, hacen un uso intensivo de operaciones en coma flotante.

2ª 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 (p 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 “loading” 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.

Sólo unos pocos bloques de los que están en la RAM se guardan en la caché.

Los bloques grises son bloques usados pero que no están en la caché.

Los blancos son bloques vacíos. Es sólo un ejemplo.

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 (ej, 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 sino, 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 que esto de donde lo saco. Fíjate que este tipo de programas suelen tener muchas opciones distintas al alcance del usuario. Por ejemplo, en un procesador de textos, crear tablas, pasar el corrector ortográfico, hacer una conversión,... tareas variopintas que pueden ser accedidas cuando el usuario 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.

Nota aclaratoria : Los diagramas 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 rehúsa, 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.

3ª 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ían casi siempre por medio de buses.

Un bus es un canal de comunicación compartido. A él van conectados distintos dispositivos. 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 anchas de borde negro 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. Así que 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, por lo que se utilizan buses dedicados para conectar 2 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, sobretodo 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.

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á:

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 del 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 porque:

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. Esta 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 CONSOLA Y PC

Ordenador PC

Videoconsola

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, sobretodo 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 esté 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 aún así es muy respetable.

En la Playstation 2, la memoria RDRAM tiene un ancho de banda de 3,2Gb/s (2 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 muy, cuanto menos, muy   optimistas, en todos los aspectos. Eso de que la Playstation es capaz de mover 60 millones de poligonos... jejej. Ni en los sueños más salvajes, vamos. Claro, así los 6 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 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.

Como anécdota, el ARM7 es la CPU que usa la Gameboy Advance, y el coprocesador de la DS.

• * En el Emotion Engine están integrados la CPU, varios coprocesadores, las cachés y además una memoria especial de 16Kb muy rápida.
• ** Suma total de las cachés de la CPU y los coprocesadores.
• *** Un poco más lenta que la caché L1, pero mucho más rápida que la memoria principal.

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 como 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 ;-)

http://www.consolasparasiempre.net