¿Wiimote en PS3?

Evidork escribió:Pero vosotros creeis que ps3 tiene potencia para emular a Wii ?

Evidork escribió:Pero vosotros creeis que ps3 tiene potencia para emular a Wii ?

Beriaru escribió: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 smile_:-p

PD. La mayoria de lo que he escrito lo he hecho de memoria. Si hay algun dato especifico erroneo, mea culpa.

Juan_Garcia escribió:una tarjeta grafica que supongo que sera similar a las que montan los PC con tecnologia mas antigua

fidillo escribió:La ignorancia es muy atrevida:
http://www.elotrolado.net/showthread.php?s=&threadid=664764

rethen escribió:
Directo del foro de Wii, para el que quiera discutir "con tecnicismos". Yo, desde luego, ni idea. Pero parece convincente.

rethen escribió:
Directo del foro de Wii, para el que quiera discutir "con tecnicismos". Yo, desde luego, ni idea. Pero parece convincente.

Beriaru escribió:. Emular la CPU, aunque tengan compatibilidad binaria, es practicamente imposible por las diferencias en arquitectura.

Beriaru escribió:La PPU de la PS3 es bastante cortita. Confia en la potencia de calculo de sus 8 unidades mas que en la suya propia. Por ello es necesario añadir una capa de virtualizacion: La PPU a secas no puede mover un binario para la Wii.

Beriaru escribió:Y las SPU no utilizan una memoria compartida, lo que implica que threads dependientes exigiran tareas de sincronizacion constantes. Lo cual consumira mas ciclos que el propio trabajo ejecutado.

Beriaru escribió:Emular la CPU, aunque tengan compatibilidad binaria, es practicamente imposible por las diferencias en arquitectura.

Beriaru escribió:Y el tema del MAME... es que estan hasta los compiladores de que la pregunta salga una y otra, y otra, y otra vez.

Esta hasta en el faq de MAME: no es, y no sera multithread. Punto pelota.

deathkiller escribió:La PPU sera "cortita" pero es capaz de ejecutar codigo PPC64 (que no esta optimizado/compilado especificamente para su arquitectura interna) a la misma velocidade que un G5 a 1.6Hz aproximadamente, es decir, el PPU de la PS3 ya es más potente (y grande) que la CPU de la Wii entera y si puede ejecutar su codigo binario directamente lo haria a velocidad más que sufciente.

deathkiller escribió:Los SPU pueden leer y escribir en la memoria principal, no necesitan más "sincronización" de la normal y esto no se que tiene que ver con el tema (la sincronización necesaria la marca extrictamente la tarea y nada más).

Beriaru escribió:Me temo que en el mejor de los casos y en una tarea compleja, con la escasa cantidad de memoria que dispone y obligada a paginar como una loca, y con la penalizacion bestial que le supone leer la memoria, podria rendir como mucho al nivel de un G4.

Beriaru escribió:Aunque he de reconocer que pensaba que era bastante mas cortito...
Si no recuerdo mal, los SPU tienen su propia memoria, y la utilizan para procesar su propio thread. Si bien pueden utilizar la memoria principal, su uso implica una penalizacion en ciclos y su uso esta limitado a copiar de su memoria a la principal o viceversa, lo que implicaria que no pueden trabajar directamente sobre la memoria principal (cosa muy logica si quieres prevenir corrupcion de datos).

Desgraciadamente no encuentro ahora mismo la especificacion donde lo comentaba, asi que hablo de memoria...

jotum escribió:Además un PC no esta basado en arquitectura PPC, como si lo están Wii,Cube y PS3

deathkiller escribió:Todas las CPUs tienen penalizacion por usar la memoria principal, la cache te "oculta" ese problema de cara al programador (hace lo mismo que se hace con los SPU, copiar datos de un lado a otro pero de manera automatica) pero no deja de existir. El PPU tiene acceso directo a la memoria pero si intenta usar un dato que no lo tiene la cache el proceso se puede quedar cientos de ciclos parado hasta que se lea (imaginate el daño en el rendimiento que proboca aunque solo pase el 2% de las veces que lees un dato).

La idea es programar para asegurarte que lo que vas a usar ya esta en la memoria del procesador o que mientras llega tengas otra cosa que hacer.

Beriaru escribió:O yo no me explico bien... o no estamos hablando de lo mismo.

jotum escribió:De todos modos, los problemas de los SPU's al acceder a memoria pueden no ser tan graves.Según leí en la página de IBM, uno de los 2 hilos que ejecuta cada SPE se encarga de manejar la memoria, pudiendo de esta manera tener un thread machacando números y otro thread peleándose con la memoria

deathkiller escribió:Los SPU no tienen "dos hilos" puede que te estes confundiendo con las dos pipeline.