¿Como se puede programar para el Cell desde Linux?

Pues eso,ahora que ya tengo el Linux y el CellSDK instalado me gustaria empezar a practicar algo de programacion para el Cell,el problema es que no se muy bien por donde empezar(empezar a compilar de cero,no paquetes o librerias precompiladas?
¿Alguien puede ayudarme a empezar?
Un saludo.
Gracias por responder,voy a ver que encuentro ;) .
Un saludo.
te doy un esquema algo resumido:

- create una cuenta en developerworks de IBM: www.ibm.com/developerworks creeme, vas a pasar mucho tiempo en esa pagina y es donde tendras la info mas actualizada y fidedigna. la cuenta es gratuita si mal no recuerdo si es para uso no lucrativo.
- necesitas Fedora Core 9 en la PS3. puedes empezar a programar en tu PC con Fedora Core 9 (o bien, desde windows, con virtualbox/vmware y virtualizando un linux fedora core 9) e instalar el full system simulator (de esto hablaremos mas abajo). en realidad puedes usar cualquier linux, pero IBM recomienda fedora9, puesto que es la distro con la que prueban el SDK (fedora 9 y redhat enterprise linux 5.2, pero la RHEL cuesta un dinerito).
- vete a la pagina de www.ibm.com/developerworks y descargate el IBM MULTICORE ACCELERATION SDK 3.1 (antiguamente se llamaba el CBEA SDK-Cell Broadband Engine Arquitecture SDK), te hace falta tanto la ISO del SDK que son unos 400 megas como el installer, que es un RPM de unos 20 megas (hablo de memoria, puedo fallar en las cantidades).
- instalas FedoraCore9 y el IBM Multicore Acceleration SDK 3.1 como pone el readme (necesitas ingles, lo siento, no recuerdo el proceso exacto)
- dentro del SDK te vendra el Eclipse, que es el IDE (el entorno integrado de desarrollo) que recomiendan en IBM para empezar. no se si esto ha cambiado en el SDK 3.1, y quizas el eclipse venga en el paquete de extras de SDK, de nuevo, leete el readme y la web de developerworks de IBM
- si estas programando directamente en la PS3 (menudo suicidio, vas a tirar de trashing en la PS3 con sus escasos 256MB y las sesiones de compilacion/depuracion a poco que tengas un proyecto mediano van a ser interminables), no necesitas nada mas, sigue un tutorial sobre 'new to multicore acceleration' (si, esta en IBM/developerworks, te dije que la cuenta te ¡ba a hacer falta) sobre la creacion de tu primer proyecto SPU, PPU y el uso del full system simulator.
- a poco que hagas trabajar la PS3, se te hara interminable el constante uso de SWAP, y si metes alguna vez la pata, tendras que reiniciar la maquina si has dejado los SPE en estado inestable (el comando top y spu-top seran tus amigos mucho tiempo para matar procesos) asi que llegara el momento que querras trabajar en una maquina de trabajar de verdad como es un PC con sus buenos 2 GB de ram (eclipse chupa una barbaridad). para esto necesitaras el full system simulator, por el cual 'emularas' un cell a traves de dicho simulador para hacer pruebas en tu PC sin necesidad de tocar la PS3
- si el programa que has desarrollado en el PC corre bien en el full system simulator, pasalo tal cual a la PS3 y ya puedes ejecutarlo. para esto seria recomendable que tanto en el PC como en la PS3 tengas fedora core 9, para no andar liando con problemas de librerias ni nada mas.

puede ser que me deje algo, pero vamos, bucea en el developerworks de IBM, que realmente ahi esta todo...
El post de f5inet debería tener chincheta o estar en la faq tiene información muy valiosa.

f5inet si ya has estado haciendo cosillas con el SDK de IBM ¿qué te parece la programación del Cell, le ves mucho potencial?
Bueno, yo como alternativa al soft de IBM, he tirado del toolchain de ps2dev.org directamente, con el duo spu-gcc y gcc, y la cosa no ha ido del todo mal, aunque para empezar desde 0 como en IBM en ningun lado :)

Cuestión de gustos supongo, pero ps2dev.org es otra web q vas a tener q visitar por narices. Creo que en el foro de dark-alex sección PS3 había un par de tutos (o en la wiki no me acuerdo muy bien) de como empezar con el SDK y demás hecho por Alek...
Gracias por la ayuda,ya me he registrado en la web y ya he descargado el IBM MULTICORE ACCELERATION SDK 3.1 y el installer;el Fedora Core 9 ¿hay que instalarlo por fuerza en la PS3?lo digo por que ya tengo instalado el Yellow Dog 6.1(que esta basado en Fedora)¿no me serviria este mismo?
Voy a bajarme el Fedora Core para el PC a ver que puedo empezar a hacer.
Un saludo.
f5inet escribió:te doy un esquema algo resumido:

- create una cuenta en developerworks de IBM: http://www.ibm.com/developerworks creeme, vas a pasar mucho tiempo en esa pagina y es donde tendras la info mas actualizada y fidedigna. la cuenta es gratuita si mal no recuerdo si es para uso no lucrativo.
- necesitas Fedora Core 9 en la PS3. puedes empezar a programar en tu PC con Fedora Core 9 (o bien, desde windows, con virtualbox/vmware y virtualizando un linux fedora core 9) e instalar el full system simulator (de esto hablaremos mas abajo). en realidad puedes usar cualquier linux, pero IBM recomienda fedora9, puesto que es la distro con la que prueban el SDK (fedora 9 y redhat enterprise linux 5.2, pero la RHEL cuesta un dinerito).
- vete a la pagina de http://www.ibm.com/developerworks y descargate el IBM MULTICORE ACCELERATION SDK 3.1 (antiguamente se llamaba el CBEA SDK-Cell Broadband Engine Arquitecture SDK), te hace falta tanto la ISO del SDK que son unos 400 megas como el installer, que es un RPM de unos 20 megas (hablo de memoria, puedo fallar en las cantidades).
- instalas FedoraCore9 y el IBM Multicore Acceleration SDK 3.1 como pone el readme (necesitas ingles, lo siento, no recuerdo el proceso exacto)
- dentro del SDK te vendra el Eclipse, que es el IDE (el entorno integrado de desarrollo) que recomiendan en IBM para empezar. no se si esto ha cambiado en el SDK 3.1, y quizas el eclipse venga en el paquete de extras de SDK, de nuevo, leete el readme y la web de developerworks de IBM
- si estas programando directamente en la PS3 (menudo suicidio, vas a tirar de trashing en la PS3 con sus escasos 256MB y las sesiones de compilacion/depuracion a poco que tengas un proyecto mediano van a ser interminables), no necesitas nada mas, sigue un tutorial sobre 'new to multicore acceleration' (si, esta en IBM/developerworks, te dije que la cuenta te ¡ba a hacer falta) sobre la creacion de tu primer proyecto SPU, PPU y el uso del full system simulator.
- a poco que hagas trabajar la PS3, se te hara interminable el constante uso de SWAP, y si metes alguna vez la pata, tendras que reiniciar la maquina si has dejado los SPE en estado inestable (el comando top y spu-top seran tus amigos mucho tiempo para matar procesos) asi que llegara el momento que querras trabajar en una maquina de trabajar de verdad como es un PC con sus buenos 2 GB de ram (eclipse chupa una barbaridad). para esto necesitaras el full system simulator, por el cual 'emularas' un cell a traves de dicho simulador para hacer pruebas en tu PC sin necesidad de tocar la PS3
- si el programa que has desarrollado en el PC corre bien en el full system simulator, pasalo tal cual a la PS3 y ya puedes ejecutarlo. para esto seria recomendable que tanto en el PC como en la PS3 tengas fedora core 9, para no andar liando con problemas de librerias ni nada mas.

puede ser que me deje algo, pero vamos, bucea en el developerworks de IBM, que realmente ahi esta todo...


+1000

Subir esta infromación al wiki (un poquito mejorada) sería un detallazo.
Psmaniaco escribió:Gracias por la ayuda,ya me he registrado en la web y ya he descargado el IBM MULTICORE ACCELERATION SDK 3.1 y el installer;el Fedora Core 9 ¿hay que instalarlo por fuerza en la PS3?lo digo por que ya tengo instalado el Yellow Dog 6.1(que esta basado en Fedora)¿no me serviria este mismo?
Voy a bajarme el Fedora Core para el PC a ver que puedo empezar a hacer.
Un saludo.


en la PS3 te valdra el YDL6.1 o cualquiera que tenga las librerias libspe y libspe2 que son de las que vas a tirar en cuanto tengas un poco de soltura. por supuesto, IBM recomienda fedora9 (hace año y medio recomendaban fedora7, con el CBEA SDK 1.0) porque es el que usan internamente.

si te vas a bajar el fedora9 para PC, bajate la version i386, no te bajes la x86-64, porque por lo visto tiene algunas cositas con el SDK 3.1, por supuesto, todo es subsanable con su parche y/o trabajo, pero cuando estas empezando, mientras mas mascaito este todo, mucho mejor.
Muchas gracias,voy a bajarme la Fedora Core 9 para x86 si esta me permite compilar para PPC mejor que mejor;acabo de hacer mis primeras pruebas del Cell en la PS3(algo sencillo por supuesto)lo he sacado de esta web:
http://www-128.ibm.com/developerworks/p ... index.html
y consiste en hacer pruebas con los vectores en la SPU(creo) e hice esto:

segui los pasos cree un archivo de texto llamado vec_test.c con este contenido:
#include <spu_intrinsics.h>

void print_vector(char *var, vector unsigned int val) {
printf("Vector %s is: {%d, %d, %d, %d}\n", var, spu_extract(val, 0),
spu_extract(val, 1), spu_extract(val, 2), spu_extract(val, 3));
}

int main() {
/* Create four vectors */
vector unsigned int a = (vector unsigned int){1, 2, 3, 4};
vector unsigned int b;
vector unsigned int c;
vector unsigned int d;

/* b is identical to a, but the last element is changed to 9 */
b = spu_insert(9, a, 3);

/* c has all four values set to 20 */
c = spu_splats((unsigned int) 20);

/* d has the second value set to to 5, and the others are garbage */
/* (in this case they will all be set to 5, but that should not be relied upon) */
d = spu_promote((unsigned int)5, 1);

/* Show Results */
print_vector("a", a);
print_vector("b", b);
print_vector("c", c);
print_vector("d", d);

return 0;
}
despues crear ese archivo use este comando creo que para crear un ejecutable:
spu-gcc vec_test.c -o vec_test
y despues ejecute el ejecutable con el comando bash:
./vec_test
y me respondio esto:
[root@dhcppc1 include]# ./vec_test
Vector a is: {1, 2, 3, 4}
Vector b is: {1, 2, 3, 9}
Vector c is: {20, 20, 20, 20}
Vector d is: {5, 5, 5, 5}
no se exactamente que es lo que habre hecho pero de momento parece que empiezo por buen camino.
Un saludo.
Psmaniaco escribió:Muchas gracias,voy a bajarme la Fedora Core 9 para x86 si esta me permite compilar para PPC mejor que mejor;acabo de hacer mis primeras pruebas del Cell en la PS3(algo sencillo por supuesto)lo he sacado de esta web:
http://www-128.ibm.com/developerworks/p ... index.html
y consiste en hacer pruebas con los vectores en la SPU(creo) e hice esto:

segui los pasos cree un archivo de texto llamado vec_test.c con este contenido:
#include <spu_intrinsics.h>

void print_vector(char *var, vector unsigned int val) {
printf("Vector %s is: {%d, %d, %d, %d}\n", var, spu_extract(val, 0),
spu_extract(val, 1), spu_extract(val, 2), spu_extract(val, 3));
}

int main() {
/* Create four vectors */
vector unsigned int a = (vector unsigned int){1, 2, 3, 4};
vector unsigned int b;
vector unsigned int c;
vector unsigned int d;

/* b is identical to a, but the last element is changed to 9 */
b = spu_insert(9, a, 3);

/* c has all four values set to 20 */
c = spu_splats((unsigned int) 20);

/* d has the second value set to to 5, and the others are garbage */
/* (in this case they will all be set to 5, but that should not be relied upon) */
d = spu_promote((unsigned int)5, 1);

/* Show Results */
print_vector("a", a);
print_vector("b", b);
print_vector("c", c);
print_vector("d", d);

return 0;
}
despues crear ese archivo use este comando creo que para crear un ejecutable:
spu-gcc vec_test.c -o vec_test
y despues ejecute el ejecutable con el comando bash:
./vec_test
y me respondio esto:
[root@dhcppc1 include]# ./vec_test
Vector a is: {1, 2, 3, 4}
Vector b is: {1, 2, 3, 9}
Vector c is: {20, 20, 20, 20}
Vector d is: {5, 5, 5, 5}
no se exactamente que es lo que habre hecho pero de momento parece que empiezo por buen camino.
Un saludo.


Vector a is: {1, 2, 3, 4}
/* Create four vectors */
vector unsigned int a = (vector unsigned int){1, 2, 3, 4};

correcto

Vector b is: {1, 2, 3, 9}
/* b is identical to a, but the last element is changed to 9 */

correcto

Vector c is: {20, 20, 20, 20}
/* c has all four values set to 20 */

correcto

Vector d is: {5, 5, 5, 5}
/* d has the second value set to to 5, and the others are garbage */
/* (in this case they will all be set to 5, but that should not be relied upon) */

correcto

consejo: lee los comentarios, no te veo demasiado puesto en C, y que conste que no es una falta de respeto, sino una observacion. quizas deberias aprender algo mas de lenguaje C antes de tirarte a la piscina del cell.

PREGUNTA: ¿has programado algo en x86 usando MMX/SSE/3DNOW? te lo digo porque si no captas la esencia de la programacion SIMD te sera muy dificil programar las SPU, puesto que el principio es el mismo.
Pues no,no estoy muy puesto en la programacion en C,respecto a programar en x86 usando MMX/SSE/3DNOW pues no,nunca he compilado nada,de hay que no me aclare¿Que me recomiendas hacer?
Un saludo.
Psmaniaco escribió:Pues no,no estoy muy puesto en la programacion en C,respecto a programar en x86 usando MMX/SSE/3DNOW pues no,nunca he compilado nada,de hay que no me aclare¿Que me recomiendas hacer?
Un saludo.


vale, ok, empezaremos por el principio:

quizas tu estas acostumbrado a programar procesadores escalares o superescalares (los x86, los PC), en los cuales estas acostumbrado a una algoritmia del tipo 'compara un valor, y dependiendo del resultado, haz una cosa u otra'. bien, eso, aunque valido desde el punto de vista de los procesadores escalares y superescalares, no es del todo valido en los procesadores VECTORIALES como los SPU. los procesadores escalares (como el PPU/PPE del CELL o los pentium/athlon y toda la gama x86 y la amplia mayoria de las CPU actuales) son buenos manejando una algoritmia del tipo 'pregunta/decision' como he expuesto antes, y esta algoritmia es buena a la hora de resolver la gran mayoria de problemas de computacion actuales, sin embargo flaquean, y mucho, cuando se requiere un flujo ('stream', vete acostumbrando a esta palabreja) constante de datos de entrada y salida, como por ejemplo, efectos en un video en tiempo real, o animacion 3D (que es generacion de un mundo 3D en tiempo real, o sea, tomando un 'stream' de entrada como es la arquitectura 3D de una escena, generar un 'stream' de salida como es un frame de video).

cuando los procesadores escalares 'no llegan', se usan dispositivos especializados, como por ejemplo, DSPs (digital signal procesor, las tarjetas de sonido son DSP especializados con un DAC, DigitalAnalogConverter, que tomando un 'stream' de entrada como datos digitales de sonido, ofrecen un 'stream' de salida ya sea estereofonico, 5.1 o lo que sea) o GPUs (para el 3D antes hablado) que no son mas que DSPs MUY ESPECIALIZADAS.

¿cual es el problema de los DSP? pues que son dispositivos hardware que no admiten 'reprogramacion', o sea, que si en algun momento, quisieramos hacer algo con ese DSP para lo que se hubiese pensado, no nos valdria, tendriamos que usar otro DSP (que seria otro dispositivo hardware)

aqui entran en juego los procesadores VECTORIALES, y las extensiones vectoriales a los procesadores escalares. los procesadores vectoriales son buenos tomando una serie de datos 'stream' de entrada y ofreciendo un 'stream' de salida constante. por ejemplo, las extensiones MMX, son capaces de multiplicar dos 'streams' de 8 numeros entre si y guardar el resultado en otro stream de 8 numeros en unos ciclos de reloj (normalmente menos de 50, incluyendo cargas internas), mientras que en un procesador escalar, dicho proceso llevaria unos 500 ciclos, incluyendo cargas, computo y retiradas de resultados. como puedes comprobar, en calculo bruto, son las extensiones MMX/SSE/3DNOW/Altivec las que debes usar, puesto que usar el calculo escalar para eso es 'desperdiciar el tiempo'.

por supuesto, esta mejora de rendimiento no es gratuita: a cambio de ofrecer esa potencia bruta, las extensiones vectoriales, o los procesadores vectoriales en si, NO OFRECEN INSTRUCCIONES DE CONTROL DE SALTO, o sea, no te posibilitan los habituales 'if/then/else', o si te los ofrecen, son muy limitados y con MUCHISIMA PENALIZACION. recuerda que la algoritmia decisoria no es su fuerte, su fuerte es el tratamiento bruto de datos, por lo cual, un salto condicional echa al traste gran parte de sus caches internas y ya no digamos si no tienen ejecucion out-of-order y el pipeline es largo (wikipedia es tu amiga, aprenderas mucho).

en fin, despues del ladrillo, solo decirte que el CELL se compone de un PPE con dos hilos de ejecucion (al estilo de los P4 hiperthreading) y extensiones vectoriales (Altivec/velocity engine/VMX) y 8 SPE (en linux PS3 solo son accesibles 6 de ellos por diversos motivos) que son procesadores absolutamente VECTORIALES con una unidad de salto condicional muy rudimentaria (tan rudimentaria, que muchas veces, en saltos/decisiones complejos, el compilador 'hace un apaño' con el PPE para que sea el PPE el que realice la decision y envie el resultado de vuelta al SPE)

esa es la clase por hoy chicos, en futuras entregas, 'porque los SPU son mis amigos' y 'no sin mis vectores'...

PD: ¿alguien se encarga de meterlo al wiki?
Muy interesante f5inet, pero me gustaría hacerte una puntualización. Yo trabajo habitualmente con DSPs, y eso de generalizar diciendo que no son programables es un error. Hay DSPs muy poco flexibles que tienen poca o ninguna capacidad de reprogramación, pero hay MOGOLLÓN de DSPs totalmente reprogramables. Yo he trabajado con las familias C5000 y C6000 de Texas Instruments, y son DSPs para los que tienes que desarrollar un programa en lenguaje de ensamble/C/C++, compilarlo, enlazarlo y cargarlo para que el DSP lo ejecute. También además de los de Texas Instruments, son muy conocidos los DSPs de Freescale (antes Motorola) y un poco menos los de Cirrus Logic y Analog Devices. Todos estos fabricantes tienen DSPs 100% programables.
doragasu, si mal no he entendido, tu me estas hablando de CPLD y FPGA, que son DSPs desde el punto estricto de la palabra, o sea, se 'programan' y solo ejecutan el programa cargado. esos CPLD/FPGA tienen algun tipo de bios/firmware que les carga el software en el arranque, configurando internamente el DSP para realizar cierto tipo de tarea.

desde el punto puramente tecnico, los DSP puros dejaron de existir hace tiempo, porque un simple error de diseño en el chip, hacia que hubiera que tirar a la basura miles de dolares en chips defectuosos. hoy dia la logica compleja de los DSP se ha movido al terreno del 'firmware'.

si embargo, tu afirmacion es correcta, hoy dia los DSP son mucho mas 'programables' que antaño, pero no admiten la flexibilidad que admiten las CPUs, que son de un procesamiento mucho mas generico. como todo, aqui se trata de elegir entre flexibilidad 100% (procesador escalar) y potencia 100% (DSP 100% hardware), y por enmedio hay diversos compromisos entre flexibilidad y potencia como los procesadores vectoriales, los CPLD/FPGAs reprogramables y los DSP con carga de valores 'on-boot'
Bufff,por lo visto es complicado de manejar las SPU,a ver que se puede conseguir.
Un saludo.
Creo que esta es de las pocas (o la única) discursión que puede haber interesante a dia de hoy en este foro. Gracias a f5inet y doragasu x la info, yo en mi caso he programado siempre bajo linux en C, pero nunca algo tan específico como lo que decís... Veo que queda mucho por recorrer :)
Joder, con tanta y tan detallada información me están dando ganas de ponerme a programar para Cell ein?
Espero que esta informacion se ponga en el Wiki,ya que nos sera de utilidad a la hora de programar el Cell,yo voy a ver si encuentro mas informacion que nos pueda ser util.
Un saludo.
f5inet, creo que no he sido suficientemente explícito y por eso me has malinterpretado. Yo te estoy hablando de DSPs y no de lógica programable (CPLD, FPGA). Un ejemplo de DSP que yo he utilizado bastante en mi trabajo es por ejemplo el TMS320C6713B de Texas Instruments. Este DSP es muy similar a una un SPU del CELL. Tiene su juego de instrucciones, incluyendo instrucciones de comparación, salto (muy poco eficientes), etc... una arquitectura VLIW para manejo de vectores, etc. Cuando digo que hay que PROGRAMARLO, no me refiero a programarlo como se programan las FPGAs, a las que se les reconfigura la disposición de la lógica en el chip, sino que me refiero a que hay que desarrollar un PROGRAMA que el DSP ejecutará.

Para el DSP se desarrolla un programa en un lenguaje de programación, se compila, se enlaza y el DSP lo ejecuta.
Para una FPGA, se desarrolla una descripción del hardware en un lenguaje de descripción hardware (p.e. VHDL o Verilog), se SINTETIZA y se programa en la FPGA.
ok doragasu, desconocia que los DSP habian llegado a ese punto. el hecho de que fueran en el pasado dispositivos estaticos me habian hecho ignorarlos por completo a la hora de interesarme por cosas que aprender.

gracias por la aclaracion, sabiendo que los DSP ya han llegado a ese punto, creo que a partir de ahora me interesare bastante mas en ellos.

¿existe algun DSP en el mercado capaz de realizar sumas/restas/multiplicaciones en registros de 512/1024/2048 bits? o sea, bichos raros capaces de hacer calculos con numeros enormemente grandes...
21 respuestas