Resolución de riesgos de Segmentación: MIPS

Antes de comenzar con las explicaciones detalladas de las técnicas de resolución, debería explicar brevemente en que consiste la Segmentación. Básicamente es una técnica que permite solapar la ejecución de instrucciones, dividiendolas en etapas. En las arquitecturas MIPS clásicas son:

1. Búsqueda de la instrucción en memoria. IF
2. Lectura de registros mientras se decodifica la instrucción. ID
3. Ejecución de la operación o cálculo de una dirección. EX
4. Acceso a un operando en memoria. MEM
5. Escritura del resultado en memoria. WB

Estas etapas son ejecutadas por separado realizando la ejecución de las instrucciones del siguiente modo:

Pero la segmentación trae consigo problemas:

1. Riesgos estructurales (Instrucciones que utilizan los mismos recursos a la vez)
2. Riesgos de datos (Necesidad de datos que aun se están calculando)
3. Riesgos de control (Problemas al controlar los saltos en un código)

Existen técnicas para resolver estos riesgos. A continuación voy a explicar las que se utilizan en los procesadores tipo MIPS clásicos:

ESTRUCTURALES. En este caso se ha decidido duplicar los recursos. Por ejemplo, en cierto código la etapa de IF de una operación se ejecuta al mismo tiempo que la MEM de otra (como en la imagen anterior). Esto crea un conflicto ya que ambas etapas acceden a memoria. En MIPS se ha separado la memoria de datos y de instrucciones, de esta manera se evitan todos estos conflictos.

DE DATOS. Supongamos en este caso que tenemos una instrucción add seguida de una instrucción sub:
add $s0, $t0, $t1
sub $t2, $s0, $t3
En este caso la segunda instrucción se verá obligada a esperar antes de la etapa EX hasta que la primera escriba en memoria. La arquitectura MIPS lo soluciona con cortocircuitos o anticipación. Esta técnica consiste en unir la ALU (Unidad Aritmético Lógica, en español) perteneciente a la ejecución de la etapa EX de la primera instrucción, con la entrada de datos de la etapa EX de la segunda instrucción, evitando así el acceso a memoria.

DE CONTROL. Cuando la instrucción a ejecutar se trata de un salto, no se sabe si la siguiente instrucción será la que se debe ejecutar. Esto trae muchos problemas de espera ya que en los códigos es muy común instrucciones de tipo if o while. Existen soluciones como bloquear la ejecución, predecir el salto o retardar la decisión. Esta última es la utilizada en los procesadores MIPS.
Su funcionamiento es sencillo, mientras se decide si el salto se debe tomar o no, el procesador pone como siguiente instrucción a ejecutar una que no dependa de la decisión del salto. Todo el proceso de que instrucción colocar es "invisible" para el programador, el procesador se encarga de ello de manera automática.

Como detalle bibliográfico, todas estas técnicas vienen especialmente bien explicadas en el libro Estructura y diseño de computadores de D.A. Patterson y J.L. Hennessy, Volumen 2. Me ha sido especialmente útil y los ejemplos sobre la segmentación comparada al proceso del lavado de ropa es muy fácil de ver.

RISC vs. CISC

Antes de meternos a comparar voy a explicar brevemente uno y otro tipo de arquitectura de CPU:
-CISC (complex instruction set computer): Como su propio nombre implica, son CPUs de una variedad muy amplia de instrucciones y que permiten operaciones muy complejas con registros, esto conlleva instrucciones de tamaño grande y que tardan varios ciclos de reloj en ejecutarse, pero a cambio da una gran potencia al microprocesador.
Uno de los contras (bajo mi punto de vista personal) es la dificultad de aplicar mejoras al rendimiento de la CPU como el paralelismo de instrucciones, es decir, cuesta mucho poder ejecutar varias instrucciones al mismo tiempo.
Por otro lado la arquitectura CISC ayuda al desarrollo software, ya que al tener un juego de instrucciones tan amplio y potente las aplicaciones son mas fáciles de desarrollar y los compiladores dejan mucha carga de trabajo a la CPU, no son tan complejos.

-RISC (reduced instruction set computer): Son la filosofía contraria a los CISC, en ellos el conjunto de instrucciones es reducido y de tamaño fijo, por lo tanto toman menos tiempo en ejecutarse. Además dejan la carga del acceso a memoria sobre dos instrucciones.
El hecho de que las instrucciones sean fijas y de código de operaciones simples facilita la estructuración de las operaciones y que se pueda decodificar la operación mientras se accede a los registros de memoria. Todas las mejoras facilitan el uso de segmentación y paralelismo.
Las pegas de los procesadores RISC tienen mucho que ver con el software. Ofrecen un peor soporte para la programación en lenguajes de alto nivel, los compiladores son mas complejos y difíciles de crear.A parte, si un programa en CISC se podía escribir con 2 instrucciones, en RISC ocuparían muchas mas y por lo tanto el programa seria mas largo y tardaría mas en ejecutarse aunque las operaciones tardasen menos ciclos.

En conclusión final, cada uno tiene sus ventajas, pero creo que la elección de un tipo u otro de procesador al final viene por sopesar el coste y las aplicaciones que se utilizarán.

Análisis de hardware: SPECviewperf 10.0

Tal y como se comentó en clase he llevado a cabo un test de SPECviewperf. A parte de intentar comprender los resultados que me da la aplicación, he decidido comparar los resultados de mi tarjeta gráfica algunos ordenadores que nos proporciona la facultad.
A continuación los resultados de mi PC, ATI Radeon X800 GTO de 256 MB:
Previamente había realizado ya las pruebas en un PC de la facultad y me llevé una grata sorpresa, ya que pensaba que mi tarjeta gráfica (comprada hace casi 5 años) no rendiría en comparación.
A continuación los resultados del PC de la facultad, nVIDIA Riva TNT2 64 MB:
Visto esto, además de informarme sobre que pone a prueba cada una de las aplicaciones, si tengo que realizar cualquier practica que necesite respuesta del PC utilizaré el mio propio. No es una queja, ni mucho menos, a los medios de la facultad, ya que solo he puesto a prueba un puesto normal de acceso a internet, me quedaría poder examinar un PC del laboratorio.
Por otro lado, buscando información sobre el benchmarks en cuestión, me he dado cuenta que es una herramienta más utilizada de lo que creía. Tanto en foros de juegos, del mundo 3D o de noticias tecnológicas sobre rendimientos del PC, se utiliza bastante esta herramienta para comparar hardware. Aunque a veces simplemente examinan bajo la regla de "mientras más grande mejor"

Evolución de las consolas: Nintendo

Tenía pensado hacer un post sobre la evolución de los videojuegos, pero voy a centrarme en consolas, dado que la asignatura es más hardware que software. Concretamente voy a analizar la história de Nintendo en las consolas de sobremesa.

-NES (Nintendo Entertainment System): Lanzada en Japón en 1983 fue la consola mas exisota de su época, y con diferencia. La consola contaba con una CPU de 8 bits y una memoria RAM interna de 2 KB. Además ya incorporaba un procesador que se dedicaba exclusivamente a las imágenes, era capaz de mostrar 52 colores en pantalla y conseguir una resolución de 256x240 píxeles.

-Super Nintendo: 7 años después llegó al mercado la siguiente consola, en 1990, con una serie de mejoras muy vistosas. En este caso la CPU de 16 bits contaba con una ampliación de memoria muy relevante de 2 a 128 KB. Por otro lado el procesador de imágenes era capaz de mostrar 32,768 colores y llegar a una resolución de 512x448, que por otra parte rara vez utilizaban los juegos.

-Nintendo 64: Solo 6 años después hizo acto de presencia la siguiente generación de Nintendo. Esta consola no solo traía consigo un salto muy grande de hardware, CPU de 64 bits de arquitectura RISC y Procesador de Video (GPU) con, por ejemplo, anti-aliasing y corrección de perspectiva. Claramente era la primera consola de Nintendo centrada en el 3D y gracias a su I+D para llevarla a cabo, Sony pudo dar lugar a su famosa PlayStation.

-Game Cube: Otros 5 años mas tarde Nintendo lanzó su nuevo Hardware. Tanto el procesador gráfico como la memoria dedicada a los gráficos se aumentó bastante y el hardware de la consola en general fue bastante bueno en su momento, siendo de los mejores (si no el mejor) de su generación de consolas. A parte de estas mejoras gráficas, la Game Cube traia consigo la lecutara de disco en vez de cartucho como soporte de los videojuegos.

-Wii: Actual consola de Nintendo, vio la luz en 2006. En comparación con los avances de las anteriores generaciones Wii casi no llegó a "subir un escalón". Casi todo el hardware tiene muy poco avance en comparación a su predecesora, y eso se nota en la calidad visual de sus juegos. Pero aun siendo la consola con menos "potencia" gráfica, ha sido un superventa por su detección de movimiento y el buen marketing de la compañía al abrir el mundo de los videojuegos a un público mucho mas amplio.

Historia y Evolución de APIs: OpenGL

A principios de los 90 las aplicaciones 3D no estabana a la orden del día, pero ya existia una competitividad en el mercado hardware. IBM y HP, entre otros, competian con Silicon Graphics Inc. en este mercado. SGI, por su parte, utilizaba una API llamada IrisGL que, aunque considerada mejor y más sencilla que las usadas por la competencia, perdía valor poco a poco frente a estas. Debido a esto SGI decidio abrir esta API de programación para que se adoptase como estándar, dando vida a OpenGL.
En 1995 Microsoft lanzó Direct3D que a partir de ese momento se convirtió en el competidor directo de OpenGL. En 1999 SGI tuvo que abandonar el proyecto por restricciones y poco apoyo indrustrial, pero hoy en día siguen desarrollando versiones:

-En 3Dlabs se desarrollo la version OpenGL 2.0, continuando con el desarrollo de la API, y creando el estandar GLSL, o lenguaje de sombreado de OpenGL
-En 2006 se publicó OpenGL 2.1, compatible con versiones anteriores, soporte de especificacion de matrices no cuadradas, Pixel buffer para acelerar el tráfico de imágenes y texturas sRGP
-Entre 2008 y 2009 se han dado a conocer las versiones 3.0, 3.1 y 3.2. Con aportes como revisiones del lenguaje GLSL, texturas, render buffers y Z-buffer en coma flotante 32-bits, Soporte de Geometría Shader.

Para más detalles se puede encontrar información muy interesante en la pagina oficial, en la serie de libros Rojo, Azul, Verde, Alpha y Naranja u otros igual de interesantes y en páginas como NEHE, donde tienen una colección de ejemplos básicos y no tan básicos para programar con OpenGL