RUMOR: Problemas CPU CELL, mas lento de lo esperado

Archivado
1, 2
A cosas como estas me refiero cuando digo que sony son unos charlatanes que prometen falsas promesas.
Se estan dando cuenta que mucho fliparse para competir contra microsoft les esta dando problemas.
f5inet escribió:yo creo que el problema principal del CELL es su arquitectura... (siempre que hablamos de procesamiento general y/o aplicados a videojuegos). matematicamente, CELL es un monstruo de gigaflops... el problema es que por arquitectura (que me corrija ELOHE si me equivoco) el PPU no es mas que un mayordomo que se encarga mantener ocupados a los SPU, o sea, que ocupar la PPU en procesamiento generico y atascar asi a los SPU provoca una caida de rendimiento... por decirlo asi, los SPU no pueden comunicarse directamente con el mundo exterior al CELL. para eso, el PPU debe coger de la RAM el 'microprograma' (<256KBs), cargarlo en la SPU y darle entrada para que la SPU empieze a procesar. y eso debe hacerlo la PPU con cada uno de los 7 SPU. si, al final 7 procesadores de un calculo vectorial bestial yendo cada uno por su lado... y la PPU en plan mayordomo sirviendo los accesos a memoria de los SPU y haciendo alguna tareita menor, como controlando el acceso a los perifericos y ejecutando algun codigo que por su simplicidad no merezca la pena ser cargado en la SPU y ejecutado...

por supuesto, el problema es que los programadores no estan acostumbrados a escribir codigo vectorial, estan acostumbrados a escribir codigo aritmetico, con lo cual deben aprender otra forma de programar, o tener un BUEN compilador que les haga el trabajo... como demostracion: llevamos varios años en X86 con extensiones como 3DNow!, MMX y SSE... y yo he visto realmente POCO software que usen esas extensiones... los programadores prefieren usar la FPU para calculos en coma flotante y sobrecargar la pila de la FPU que aprender a usar 30 nuevas instrucciones... (mas vale malo conocido...)

Ya lo dije otra vez pero el PPU no interviene en el acceso a memoria de los SPU, que una tarea lenta se pueda convertir en un cuello de botella es un problema que vas a tener siempre que uses multicore, si tienes que sincronizarlo todo pues si no lo haces bien pues estas apañado.

Los SPU son independientes durante la ejecucion, el acceso a memoria por DMA no se ejecuta nada en el PPU, puedes tener problemas si de lo que estas haciendo depende otra tarea y esta mal sincronizado si no no pasa nada (como el sonido por ejemplo).
Lo curioso es que hasta Carmack diga que la PS3 es 'marginalmente mas potente'....

Ademas, si no me equivoco los SPU si pueden acceder directamente a memoria sin hacerlo a traves de la PPU...eso si, de forma mas lenta...

De todas formas hablamos de un concepto nuevo...demosle un poco mas de tiempo para ver lo que puede dar de si... [oki]
si, los SPU pueden acceder a RAM directamente... el problema es que el mini-programa de menos de 256KB DEBE SER CARGADO por el PPU, o sea, que se comportan como microcontroladores. el PPU uplodea al SPU el bloque de codigo de menos de 256KB y resetea el SPU. a partir de ahi, el SPU empieza a ejecutar el codigo almacenado y empieza a acceder a la RAM para trabajar... pero el uplodeo del codigo lo debe hacer el PPU. y si tienes varios procesos compitiendo por los SPU al final la PPU se queda en eso... en un mayordomo para mantener alimentados a los SPU...

PD: vamos, esto es al menos lo que yo tengo entendido, por supuesto, puedo estar equivocado
f5inet escribió:si, los SPU pueden acceder a RAM directamente... el problema es que el mini-programa de menos de 256KB DEBE SER CARGADO por el PPU, o sea, que se comportan como microcontroladores. el PPU uplodea al SPU el bloque de codigo de menos de 256KB y resetea el SPU. a partir de ahi, el SPU empieza a ejecutar el codigo almacenado y empieza a acceder a la RAM para trabajar... pero el uplodeo del codigo lo debe hacer el PPU. y si tienes varios procesos compitiendo por los SPU al final la PPU se queda en eso... en un mayordomo para mantener alimentados a los SPU...

PD: vamos, esto es al menos lo que yo tengo entendido, por supuesto, puedo estar equivocado

Eso no es cierto, en los foros de IBM uno de los tecnicos dijo que lo unico que hay que hacer es usar en el PPU una funcion que crea el thread del SPU usando una peticion DMA para que se trasmita el codigo inicial (no pasa por la cache y tampoco tiene que ser muy grande), a partir de ahi puede le SPU seguir cargando más codigo a su memoria local dinamicamente segun lo necesite, es completamente autonomo si quieres que lo sea.

Todo depende de como quieras utilizar el hardware, nada te obliga a utilizarlo de una manera concreta, desde luego utilizar los SPU no te impide utilizar el PPU y tienes total libertad para organizar como quieras lo que hacen los SPU ya sea haciendo una tarea fija, un conjunto de tareas sucesibas o esperar a que el PPU diga que hace falta hacer.
takeda escribió:Lo curioso es que hasta Carmack diga que la PS3 es 'marginalmente mas potente'....

Ademas, si no me equivoco los SPU si pueden acceder directamente a memoria sin hacerlo a traves de la PPU...eso si, de forma mas lenta...

De todas formas hablamos de un concepto nuevo...demosle un poco mas de tiempo para ver lo que puede dar de si... [oki]


Pues en eso estamos, que marginalmente más potente significa más potente, pero por poco.
f5inet escribió:si, los SPU pueden acceder a RAM directamente... el problema es que el mini-programa de menos de 256KB DEBE SER CARGADO por el PPU, o sea, que se comportan como microcontroladores. el PPU uplodea al SPU el bloque de codigo de menos de 256KB y resetea el SPU. a partir de ahi, el SPU empieza a ejecutar el codigo almacenado y empieza a acceder a la RAM para trabajar... pero el uplodeo del codigo lo debe hacer el PPU. y si tienes varios procesos compitiendo por los SPU al final la PPU se queda en eso... en un mayordomo para mantener alimentados a los SPU...

PD: vamos, esto es al menos lo que yo tengo entendido, por supuesto, puedo estar equivocado


casi ni he leido info del CELL, pero no creo que el PPE sea el "mayordomo" de los SPU, tal como el EE no es "mayordomo" de las VU en la PS2.

Me imagino que el esquema no variara mucho con la PS2, donde el EE genera la cadena que indica que cosas deben ser movidas por el DMAC a los perifericos, el EE solo pone un par de tags y da la instruccion al DMAC, quien actua de manera independiente.

El DMAC no manda un stream directamente a las VUs sino que las manda a las VPUs (las VUs son un elemento de las VPUs, pero no son lo mismo, tal como las SPU lo son a los SPE) donde son recibidas por los VIFs que se encargan de alimentar a las VUs con microcodigo y datos, sin dejarles tiempo ocioso alguno. Ademas el VIF pude desempacar datos desde muchos formatos de entrada, pude mantener el control de un doble buffer (o triple, etc), mientras el EE corre en paralelo casi despreocupado de que tal van las VUs.

Si es que el modelo del CELL fuera parecido a la PS2 yo lo veo como un gran salto cuantitativo ya que la VU0 tiene 4KB de micromemoria (+4KB de VU-MEM), la VU1 tiene 16KB de micromemoria (+16KB de VU-MEM) y cada SPU tiene 256KB que sirven indistintamente para Codigo o Datos.

Alguien conoce el rol del SMF que existe en cada SPE?, por lo que lei se encarga de las funciones de DMA y MMU.

saludos
entonces habra que hacer caso a carmack, PS3 sera mas potente en conjunto que X360, pero solo 'marginalmente' mas potente...
57 respuestas
Archivado
1, 2
Volver a General