Buscar en este blog

Tema 4.d: Modelos de programación para el Cell.


Como ya se ha visto en otros artículos, el Cell es un procesador complejo compuesto de un núcleo central que es un PowerPC llamado PPE y 8 coprocesadores vectoriales llamados SPE. Para comunicar estas unidades hay un bus que puede funcionar hasta a 204.8 Gb/s llamado EIB. En las figuras que hay a continuación puede verse su organización de forma esquemática.


Ahora bien, hemos de tener en cuenta que de los 8 SPEs teóricos sólo tenemos disponibles 6 para programación, tanto los SPEs como el PPE no permiten ejecución fuera de orden pero mientras que el PPE puede ejecutar dos hilos a la vez los SPEs no.

Los principales obstáculos con los que se va a encontrar un programador son la gestión de la memoria y por ende la comunicación de datos entre las distintas unidades, y la división de tareas para sacar el máximo rendimiento a la arquitectura. Como algunos comentan, conseguir que un programa corra en Cell es extremadamente sencillo, conseguir que lo haga de forma eficiente no.


Mucho se ha hablado de la dificultad añadida que supone que estos procesadores vengan con menos elementos de los que solemos encontrar en los procesadores de propósito general de los ordenadores de sobremesa. Por ejemplo no predicen saltos, dejando esa tarea al compilador/programador. También se ha hablado de la dificultad que supone el cambiar de mentalidad para programar enfocándose al multithreading (programar para que haya varios hilos ejecutándose a la vez) pero hay que tener en cuenta que hoy en día casi todos los procesadores son multinúcleo, siendo lo más habitual en ordenadores pensados para jugar el disponer de 4 núcleos. Es decir; Cell nos obliga a hacer lo que tendríamos que haber estado haciendo desde hace al menos dos años. También he leído comentarios que afirman que programar para la PS3 es más fácil que para la PS2.

Para poder organizar mejor la tarea de programar en Cell se pueden plantear “modelos de programación” que son paradigmas que nos ayudan a estructurar nuestra forma de pensar.

El PPE es casi idéntico a un procesador de uso general con lo que gestionando los saltos por software podemos pasar cualquier código “normal” al PPE y que ejecute correctamente. Eso sí; con frecuencia veremos que su rendimiento comparado es menor. Si queremos trabajar con más de un SPE a la vez lo que veremos e que necesitamos al PPE, ya que es el que puede distribuir las tareas y el que puede consultar la memoria local de todos los SPEs.

Así pues lo que parece evidente para un profano es que el PPE es el líder de una colmena formada por 6 obreras que se dedicarán principalmente a realizar pocas operaciones sobre gran cantidad de datos. De esta manera el código que ejecute el PPE será relativamente sencillo, orientado principalmente a distribuir tareas, controlar su ejecución, sincronizarla y manejar las transferencias de datos.

Los modelos de programación más habituales que he encontrado son los siguientes:

-          Programación secuencial: ejecutamos las instrucciones en orden en el PPE, sin optimizaciones de ningún tipo y sin enviar nada a las SPEs. Rendimiento pero que el de un procesador mono núcleo de hace varios años.

-          Programación de dispositivos: los SPEs son vistos desde el PPE como dispositivos en el Virtual File System a los que enviar tareas.

-          Streaming: debido a que los SPEs son del tipo SIMD (single instruction, multiple data) se pueden organizar en cascada de manera que cada SPE realiza una única operación sencilla, que forma parte de un proceso complejo, sobre un mismo paquete de datos que va pasando sucesivamente por cada SPE hasta que se obtiene el resultado final. Para poder gestionar esto de forma eficiente es necesario que cada operación que se realiza en cada SPE tenga la misma duración. Es muy parecido a la segmentación del cauce que se hace dentro del procesador.

-          Memoria compartida: básicamente consiste en que todos los SPEs realicen a la vez la misma operación pero sobre distintos datos que formen parte de un mismo paquete. Paralelizamos el proceso para tardar menos.

-          Cola de tareas: se van poniendo tareas en una cola y un hilo que corre en el PPE las va sacando y asignando dinámicamente a una SPE concreta según vayan quedando libres.

Estas son sólo algunas formas de orientar la programación en Cell, pero la mayor parte de los paradigmas usados para arquitecturas multinúcleo pueden usarse tal cual en el Cell o con pequeñas consideraciones.

Bibliografía:

-          http://www.bsc.es/media/619.pdf

No hay comentarios: