Barrapunto

Y tanto que está mejorado:

- De 8/16KB (la PS2 tiene una VU con 8KB y otra con 16) de memoria local a 256KB por VU del Cell.
- De 16 registros de enteros y 32 de coma flotante (128 bits/registro) de cada VU del EE de la PS2, a 128 registros por unidad vectorial del Cell.
- Transferencias por DMA similares, pero mejoradas, pues no se frenan entre las diferentes unidades vectoriales (en la PS2 se saturan los buses si no se va con ojo, aunque nunca he dedicado el suficiente tiempo como para hablar, ni de lejos, como experto con el "Emotion Engine").
- Las VUs de la PS2 eran MIMD ("Multiple Instruction Multiple Data"), lanzaban dos instrucciones, explícitamente, por ciclo, si querías ejecutar sólo una le tenías que colocar tú el "nop" a mano (!), mientras que las intrucciones que usan las SPEs del Cell guardan cierto "parecido" con la elegancia del juego de instrucciones de PPC, siendo las instrucciones SIMD similares.

De hecho, que las SPEs del Cell no puedan acceder a la memoria principal de manera directa, no es una limitación "grave", pues de poder hacerlo implicaría el uso de mucha area del chip para controlar la coherencia, mientras que por DMA resulta trivial. 256KB de memoria local es *mucha* memoria.

- De 8/16KB (la PS2 tiene una VU con 8KB y otra con 16) de memoria local a 256KB por VU del Cell.

Pero sigue estando el problema de que las unidades solo pueden acceder a esa memoria ridícula de 256KB. Lo cual es insuficiente y supone un problema para la gran mayoría de los problemas. Luego han paliado un problema, pero sigue existiendo.

- De 16 registros de enteros y 32 de coma flotante (128 bits/registro) de cada VU del EE de la PS2, a 128 registros por unidad vectorial del Cell.

Eso ni era un problema entonces ni lo es ahora.

- Transferencias por DMA similares, pero mejoradas, pues no se frenan entre las diferentes unidades vectoriales (en la PS2 se saturan los buses si no se va con ojo, aunque nunca he dedicado el suficiente tiempo como para hablar, ni de lejos, como experto con el "Emotion Engine").

Eso sí que es un problema que han solucionado, pero no por lo que tu dices. Ahora las transferencias de DMA se pueden iniciar desde las SPUs, y eso supone solucionar un problema muy grave que había antes y que se agrava si tienes más unidades vectoriales: mantener alimentadas las VU suponía un trabajo importante para el procesador principal. Ahora también cuesta (porque son más y son más rápidas, pero la memoria no ha crecido en la misma proporción), pero el modelo ha aguantado y todavía queda un poquillo más de tiempo para la PPU.

Las VUs de la PS2 eran MIMD ("Multiple Instruction Multiple Data")

NO. Vamos a ver que me parece que te falla un concepto elemental. Un computador MIMD es un computador paralelo en array. Es decir, si SIMD es hacer una suma a la vez en 2 parejas de 4 elementos (por ejemplo), en MIMD podrías coger 2 parejas de 4 elementos y multiplicar la primera pareja, sumar la segunda, restar la tercer y dividir la cuarta, todo a la vez. Eso es MIMD. Las VUs de la PS2 eran VLIW un poco raras, tenías dos pipelines de ejecución, izquierdo y derecho, y cada uno te servía para una cosa distintas. Curiosamente, esto sigue pasando en el Cell. La única diferencia es que el compilador ahora es mejor y él solito se encarga de planificar las instrucciones por ti. Pero en ese sentido sigue siendo igual que la VU del EE.

En cuanto a esto, otra cosa chunga que tiene el Cell es que si no vectorizas el código, esos 216 GFLOPs *pico* quedan necesariamente divididos por 4, acercándolos mucho a los GFLOPs pico que tiene un Core2Duo, por ejemplo.

De hecho, que las SPEs del Cell no puedan acceder a la memoria principal de manera directa, no es una limitación "grave", pues de poder hacerlo implicaría el uso de mucha area del chip para controlar la coherencia

No si se hace bien. Las GPUs pueden acceder directamente a la memoria, y no se preocupan de la coherencia. Las caches son solo de lectura y te dan una scratch pad al estilo del LS que si te va bien utilizas y si no, no. Se puede jugar mucho con la arquitectura aquí.

mientras que por DMA resulta trivial. 256KB de memoria local es *mucha* memoria.

Meter explícitamente todas las transferencias de DMA no tiene nada de trivial. Hace el código mucho más complejo y además es el punto en el que siempre flojea el Cell, el equilibrio entre transferencia y cómputo que hay que hacer manual. Y sí, 256KB no es que sea poco, es que es una puta mierda. Aunque fuese solo memoria para el programa (que no lo es, se comparte con los datos), es poquísimo. No conozco a nadie (tú eres el primero que oigo) que esté contento con la memoria de las SPU. Siempre es de lo primero que se queja la gente.