Barrapunto

- 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.

Gracias por las precisiones, intuyo que has programado unidades vectoriales ;-)

Tienes razón en lo de MIMD, metí la pata, tenía que haber puesto, como indicas VLIW (en el caso concreto de las VUs de la PS2, "superescalar explícito de dos vías").

Respecto a la capacidad de cálculo de un Core2Duo y un Cell, hombre, ¿qué gracia tiene un procesador vectorial si no vectorizas? Además, dependiendo de la tarea, igual no te interesa vectorizar, igual que un x86 no estás haciendo todo el rato SIMD -SSEx-. En mi experiencia, el problema no es ni siquiera de capacidad de cálculo, sino de saturación de los buses; en la arquitectura de Intel, o incluso la de AMD con el HyperTransport, si bien son muy flexibles y permiten el direccionamiento transparente, tienen poco throughput cuando se consumen datos en paralelo, además de no tener "scratchpad" locales que eviten saturar el mecanismo de coherencia de las caches.

Los 256KB de los SPEs del Cell se te pueden quedar cortos igual que se podían quedar cortos los 8/16KB en las VUs del EE de la PS2, todo depende del problema que estés tratando. Dependiendo del problema tendrás que usar más espacio para el doble buffering o para código. Lo incómodo de que no te quepa el trabajo en una SPE es que lo tienes que "partir" en el procesador principal, pero eso tampoco me parece un drama (p.e. en el caso de un codec JPEG, que trabaja línea a línea, puedes aplicar la codificación Huffman en la CPU principal y la cuantización + DCT en un SPE). Donde estás limitado es, por ejemplo, en implementar un compresor que trabaje con diccionario, pero para eso también hay soluciones, las cuales, no te puedo comentar ;-)

La libertad es siempre una responsabilidad, a modo de curiosidad, incluso te puedes montar incluso algo parecido a caché de datos por software, usando una parte de los registros a modo de "tags", operando de manera bastante transparente. No recomiendo lo de la caché "por software" para cosas "serias", pues pierdes un 20% del rendimiento del bus de memoria.