Como ahora tengo un poco de tiempo, vamos a explicar como funciona la ejecucion en tiempo real, y la importancia de un buen compilador.
Cuando programas un pedazo de codigo, lo que haces es escribir instrucciones y comandos uno detras de otro. La programacion es absolutamente secuencial. Empieza por un lado, y termina por el otro.
Incluso si arrancasemos un debugger para ver como nuestro procesador ejecuta nuestro codigo una vez compilado, veriamos que se trata de una sucesion -secuencial- de comandos de ensamblador.
Eso es la verdad para los antiguos 8086, 286, 386 o incluso el 486.
Con el Pentium y el PowerPC (no se si los antiguos 68000 de Motorola tambien) las cosas empezaron a cambiar. La 'secuencialidad' ya no interesa. Los nuevos micros son capaces de ejecutar varias instrucciones por ciclo, y limitarse a ejecutar una es perder rendimiento.
Ahora viene lo complicado: si tienes que sumar dos cantidades y multiplicar dicha suma por otra cantidad... no puedes hacer ambas operaciones simultaneamente!
La simultaneidad solo se da cuando dos o mas operaciones son independientes entre si. Para ver si realmente esas operaciones son independientes, nuestros procesadores llevan una unidad que 'predice' unos cuantos ciclos por delante de la linea de ejecucion si una operacion afectara a otra o no.
Fallar en una prediccion significa descartar la cola de codigo y datos que esta esperando a entrar en el procesador, y volver a empezar desde el error. Intel descubrio demasiado tarde las limitaciones de los Pentium4 basados en Netburst. Sus laaaargas colas de proceso se iban al garete cuando la unidad de prediccion se equivocaba... y eso implicaba una penalizacion de ciclos demasiado grande.
Como evitar esos 'errores'? Con un compilador inteligente. Un compilador que, a la hora de compilar, sin prisas, con tiempo, con la posibilidad de leer y releer el codigo, de ir hacia delante y hacia atras en el codigo, pueda examinar que operaciones son y no son independientes, ordenandolas para que lleguen al procesador de una manera ordenada y optimizada.
Parece complicado? Pues aun estamos hablando de un solo procesador!!
Cuando hablamos de multiprocesador las cosas se complican exponencialmente. ya no hablamos de operaciones simultaneas... sino de PROCESOS simultaneos.
En un ordenador de sobremesa ejecutando programas de oficina la cosa esta sencilla: el Word es un proceso, el Firefox es otro, y ambos no tienen mucho que ver entre si. Por lo tanto pueden estar ejecutandose en procesadores diferentes con toda confianza.
En un juego las cosas se ponen peliagudas. La musica es independiente de los graficos? El motor de emulacion de fisica es independiente del interfaz de usuario?
Cuando un proceso es independiente de otro?
Esta vez ningun modulo en nuestros procesadores nos ayudara. Un monoprocesador puede 'predecir' con mayor o menor fortuna las operaciones independientes en un codigo no optimizado... pero en un sistema multiprocesadoro esta optimizado en la compilacion, o se correra en un solo procesador con la consiguiente merma en rendimiento.
El compilador ha de examinar con lupa todo el proyecto, marcando que procesos son independientes, cuales dependen de quien, cuando, como y por que, separando hilos y evaluando que carga tendra cada uno de los procesadores para que no tengan que esperar parados el resultado de uno de ellos sobrecargado de trabajo.
Todo eso ha de hacerse en el momento de la compilacion, y cuanto mejor se haga, mejor sera el rendimiento del procesador.
Por eso, cuando los años pasan y las consolas van llegando al final de su vida antes del reemplazo, los juegos cada vez son mejores. Una parte es achacable a los programadores y la experiencia, pero en su mayor parte es achacable a los entornos de desarrollo y compiladores que cada vez hacen mejor su trabajo. Donde en un primer momento solo eran capaces de mover una escena con 3 millones de poligonos, al final son capaz de hacer bailar con soltura a 5 (por decir alguna cifra).
Y ahora llega el problema de la emulacion.
Primero: Tienes un binario. Olvidate del codigo fuente.
Segundo: Esta complilado para otra arquitectura, con toda su optimizacion para esa arquitectura en cuestion.
Esa optimizacion... olvidate. La has perdido. Acabas de perder entre un 10 y un 30% del rendimiento. Esa perdida viene de perder la optimizacion original, y la incapacidad de optimizar el codigo para el procesador que va a ejecutar la emulacion.
Y ahora llega la gracia: si tienes un sistema multiprocesador?
Pues si, si la optimizacion en compilacion no contemplaba la separacion de procesos para multiprocesador, el emulador no la podra implementar. No, Niet, LaJodimosCarlinos.
Y que quiere decir eso?
Eso quiere decir, ni mas ni menos, que se ejecutara en modo monoprocesador.
O hablando de Wii y PS3, eso quiere decir que el Cell no podra usar ninguna de sus 8 unidades para ejecutar el proceso de emulacion. Solo podra usar el PPC cortito, simplon y bastante mermado que es su unidad de control.
Y ahi no hay chicha para mover los juegos de la Wii, y menos sin la optimizacion especifica para el micro (aunque sean PPC, el de la PS3 no tiene la misma cantidad de pipelines que el de la Wii).
Espero que haya quedado claro
PD. La mayoria de lo que he escrito lo he hecho de memoria. Si hay algun dato especifico erroneo, mea culpa.
)
![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
