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.
por
pobrecito hablador
el Martes, 03 Junio de 2008, 14:28h
(#1049958)
intuyo que has programado unidades vectoriales;-)
No solo he programado unidades vectoriales, también he programado el EE y el Cell, por eso sé exactamente de qué me estás hablando:-).
Y como digo, todo el rollo del LS, tener que dividir tu programa por trozos y montarte los árboles esos de código para que te quepa algo de código y datos suficientes para hacer un poco de cómputo, las transferencias de DMA... Todo eso hay que meterlo a mano, supone hacer transformaciones muy dramáticas al código que lo hacen más ilegible y difícil de depurar. Lleva muchísimo tiempo aunque tengas experiencia haciéndolo... Y al final, tampoco sueles sacar tanto rendimiento respecto a un procesador normal. Precisamente las tareas que mejor van son aquellas para las que no hay que hacer demasiadas guarradas.
Sin embargo, a la hora de utilizar una GPU (con CUDA), con un esfuerzo cercano a cero puedes fácilmente conseguir una mejora de 4x o 5x. Con un esfuerzo mínimo puedes conseguir hasta 10-15x. Si te lo curras bien, y no estoy hablando ni de lejos de lo que supone currarse un programa a tope en el Cell, puedes conseguir entre 30x y 200x dependiendo de la aplicación.
Vamos, que con todo lo aparentemente peor que pueda parecer una GPU cuando te pones a listar opciones frente al Cell, la relación rendimiento-esfuerzo es muchísimo más alta que en el Cell. Y de hecho, si comparas rendimiento puramente, mi experiencia es que salvo para unas pocas aplicaciones también gana al Cell. El Cell tiene sus ventajas respecto a la GPU, pero si me preguntas "qué es mejor", y no me lanzaría a decir que mejor el Cell. No sé en qué trabajarás exactamente, pero si tienes posibilidades te recomiendo que pruebes CUDA. Si el problema es suficientemente grande (si trabajas con muy poquitos datos ni te molestes), es muy probable que con CUDA te vaya mejor (y no te pienses que te vas a tener que tirar 6 meses entrenándote en CUDA, en una tarde tendrás ya la idea, en la primera semana tendrás versiones más que decentes y en cuestión de 1 a 3 meses, según el problema, tendrás una versión de las buenillas).
Re:Depende de la aplicación... pero no exager
(Puntos:2)( http://www.voluntariado.net/ | Última bitácora: Domingo, 10 Junio de 2012, 21:48h )
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.
Re:Depende de la aplicación... pero no exager
(Puntos:0)No solo he programado unidades vectoriales, también he programado el EE y el Cell, por eso sé exactamente de qué me estás hablando
Y como digo, todo el rollo del LS, tener que dividir tu programa por trozos y montarte los árboles esos de código para que te quepa algo de código y datos suficientes para hacer un poco de cómputo, las transferencias de DMA... Todo eso hay que meterlo a mano, supone hacer transformaciones muy dramáticas al código que lo hacen más ilegible y difícil de depurar. Lleva muchísimo tiempo aunque tengas experiencia haciéndolo... Y al final, tampoco sueles sacar tanto rendimiento respecto a un procesador normal. Precisamente las tareas que mejor van son aquellas para las que no hay que hacer demasiadas guarradas.
Sin embargo, a la hora de utilizar una GPU (con CUDA), con un esfuerzo cercano a cero puedes fácilmente conseguir una mejora de 4x o 5x. Con un esfuerzo mínimo puedes conseguir hasta 10-15x. Si te lo curras bien, y no estoy hablando ni de lejos de lo que supone currarse un programa a tope en el Cell, puedes conseguir entre 30x y 200x dependiendo de la aplicación.
Vamos, que con todo lo aparentemente peor que pueda parecer una GPU cuando te pones a listar opciones frente al Cell, la relación rendimiento-esfuerzo es muchísimo más alta que en el Cell. Y de hecho, si comparas rendimiento puramente, mi experiencia es que salvo para unas pocas aplicaciones también gana al Cell. El Cell tiene sus ventajas respecto a la GPU, pero si me preguntas "qué es mejor", y no me lanzaría a decir que mejor el Cell. No sé en qué trabajarás exactamente, pero si tienes posibilidades te recomiendo que pruebes CUDA. Si el problema es suficientemente grande (si trabajas con muy poquitos datos ni te molestes), es muy probable que con CUDA te vaya mejor (y no te pienses que te vas a tener que tirar 6 meses entrenándote en CUDA, en una tarde tendrás ya la idea, en la primera semana tendrás versiones más que decentes y en cuestión de 1 a 3 meses, según el problema, tendrás una versión de las buenillas).