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.
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 (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.
Caché de instrucciones
Las aplicaciones estáticas hacen un uso regular de la caché de instrucciones, porque su eficiencia depende de muchos factores, y habitualmente el flujo de instrucciones es muy variable; esto es, las instrucciones no permanecen mucho tiempo en la caché para ser reutilizadas, sino que son sustituidas por nuevas instrucciones antes de que pueda sacarse un buen provecho.
Las aplicaciones dinámicas hacen un uso muy bueno de la caché de instrucciones porque como ya comenté, los cálculos son a menudo realizados por relativamente pocas instrucciones que se repiten muchas veces.
Caché de datos
Las aplicaciones estáticas hacen un uso razonablemente bueno de la caché de datos, en función del caso, porque a menudo todos los datos que se necesitan intensivamente caben en la caché y el flujo de datos no suele ser muy rápido (la cañería lleva poco caudal).
Las aplicaciones dinámicas hacen un uso pésimo de esta caché, porque el flujo de datos es muy rápido (la cañería lleva mucho caudal), y a menudo la información que entra en la caché no vuelve a usarse, por lo que hay que estar continuamente sacando datos para meter otros a toda pastilla.
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.
Fichas:
neth, Usuario
JakCore, Usuario
patroclus, Usuario
Ikael, Usuario
Tito Almo, Usuario
patroclus, Usuario
Tito Almo, Usuario
SpaceDevil, Usuario
Tolrak, Usuario
patroclus, Usuario
SpaceDevil, Usuario
Por favor identifícate para comentar.