Historias
Slashboxes
Comentarios
 
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • 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").

    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.

    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.

    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.

    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.

    [ Padre ]
    Puntos de inicio:    1  punto
    Modificador por Bonus-Karma   +1  

    Total marcador:   2  
  • Muchas gracias por la explicación, le echaré un ojo al CUDA. Un saludo.
    [ Padre ]
  • 1 respuesta por debajo de tu umbral de lectura actual.