Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

McPolu (19560)

McPolu
  McPolu@gmail.com
http://mcpolu.blogspot.com/

Pues, desde siempre, ser lúcido y español aparejó gran amargura y poca esperanza.

-- Reading some of the comments to your blog always restores my lack of faith in humanity.
-- Where There is a Will, There is a Way.
-- Cuando los radiadores funcionan y dejan de molestar se conoce la verdadera escencia humana.
-- Unas lágrimas sin compás son un berrinche.
-- Al abrir su andadura se ven los castillos de Arcalaus el maligno, rojos en el fuego del ocaso.
-- In the process of gaining our rightful place, we must not be guilty of wrongful deeds.
-- Sé que los seres humanos y los peces podrán coexistir en paz.
-- Asi es como muere la libertad, con un estruendoso aplauso.
-- Minino de Cheshire, ¿podrias decirme, por favor, qué camino debo seguir para salir de aquí?

Down Kill Up Publicidad

Bitácora de McPolu (19560)

Miércoles, 10 de Agosto 2005

Destripando Cell en la playa

03:27h.
Bitácoras

Me he decidido a escribir un artículo desde la playa acerca del nuevo procesador Cell que, como ya es bien sabido, será el corazón de la futura Play Station 3.

Comenzaré describiendo la macro-arquitectura del procesador para, posteriormente, centrarme en la arquitectura de la unidad de propósito general y finalizar el capítulo arquitectónico describiendo las unidades de proceso vectorial.
Finalmente, hablaré acerca de los diferentes modelos de programación que se han propuesto y expondré mis conclusiones.

1. La macro-arquitectura de Cell

En esta imagen se observa que el procesador está compuesto por los siguientes elementos:

  • Circuitería de gestión de memoria y entrada/salida
  • Una memoria caché de segundo nivel de 512 Kbytes
  • Una unidad de proceso de propósito general llamada Power Processor Element o, abreviadamente, PPE.
  • Ocho unidades de proceso vectorial llamadas rimbombantemente Synergistic Processor Elements o SPEs. Sin embargo, en la PS3 una de ellas estará desactivada, quedando sólo siete funcionales.
  • Un bus que interconecta los elementos anteriormente listados llamado Element Interconnect Bus o EIB.
En esta otra imagen se aprecia con más claridad la macro-arquitectura.

2. La arquitectura de la unidad de propósito general

El PPE es un PowerPC de 64 bits y doble núcleo bastante especial. Sí es un PowerPC en cuanto a que implementa el mismo juego de instrucciones que los PowerPC pero no es un PowerPC en cuanto a su diseño interno. Podríamos decir que visto desde fuera es un PowerPC pero visto por dentro no lo es.

La principal diferencia con los PowerPC tradicionales es que el PPE de Cell es mucho más simple. En el PPE la circuitería de predicción de saltos no va muy allá y carece por completo de ejecución fuera de orden. El PPE es un RISC a la antigua capaz de ejecutar dos instrucciones simultáneamente.

Dos son los motivos que han llevado a este diseño simplista de la unidad de propósito general:

  1. El consumo de potencia: La circuitería necesaria en un procesador con ejecución fuera de orden consume mucho y está activa todo el tiempo. Cell ha sido diseñado teniendo los sistemas empotrados en mente, por lo que el consumo de potencia es un aspecto mucho más relevante que en los procesadores diseñados para equipos de sobremesa.
  2. El número de transistores: Se ha preferido donar los transistores que usualmente se dedican al subsistema de predicción de saltos y a la ejecución fuera de orden a las SPEs

3. La arquitectura de las unidades de proceso vectorial

En esta imagen se aprecian los diferentes elementos que componen una SPE:

  • 128 registros de 128 bits
  • Circuitería de gestión de memoria y entrada/salida
  • 256 Kbytes de caché
  • Circuitería de control y de operaciones aritmetico-lógicas
Hay varias cosas que destacar en esta arquitectura:
  • La memoria caché es pequeña y además no es una caché al uso. No es transparente ni tiene unidad de predicción de acceso a datos, por lo que el software que escribamos (o en su defecto el sistema operativo) debe encargarse de gestionar esta memoria.
  • Tampoco hay ejecución fuera de orden.
  • Se accede a la memoria principal por DMA. Lanzar una petición DMA puede ser muy lento, aunque una vez que comienzan a fluir los datos va muy bien.
  • Los registros de 128 bits permiten ejecución sobre varios datos de menor tamaño en paralelo (SIMD, ejecución vectorial).
  • Es una arquitectura RISC superescalar
  • El juego de instrucciones de las SPEs está inspirado en VMX/Altivec; es muy parecido pero no idéntico.

4. Otras consideraciones arquitectónicas

  • Escalabilidad: Cell está diseñado para facilitar la construcción de sistemas que agrupen varios procesadores Cell. En concreto, un núcleo PPE puede acceder a las SPEs de otros procesadores Cell que convivan en el mismo sistema.
  • DRM en Cell: Cell no implementa un sistema DRM específico; sin embargo sí incluye una característica muy interesante desde el punto de vista de la seguridad y privacidad que podría ser aprovechada por un software de DRM. Dicha característica consiste en la existencia de un modo de ejecución en el que el contenido de la caché de una SPE es privado para esa SPE. Ninguna otra SPE, ni el PPE, ni ningún dispositivo externo al procesador puede leer el contenido de esa memoria.
  • Etiquetas de memoria: Cell soporta el uso de las prehistóricas etiquetas de memoria. El único motivo para incluirlas es poder ejecutar el prehistórico sistema operativo AS/400 que IBM aún mantiene en los mainframes. ¿Estará planeando IBM construir mainframes basados en Cell? No lo creo porque aún hay en producción mucho ensamblador en los mainframes, pero parece que lo han incluido por si acaso.

5. Los modelos de programación

Se han propuesto tres modelos de programación para esta arquitectura:

  • Stream processing: le han dado este nombre por motivos de marketing, ya que será este modelo el que sigan las aplicaciones de proceso de audio/vídeo en los sistemas de Toshiba en los que Cell irá empotrado (DVDs, reproductores digitales de música, etc.). Yo lo habría llamado pipeline processing porque eso es lo que es.
    Consiste en alinear varias SPEs en cascada (en pipeline) para que cada una ejecute una etapa de un proceso complejo. En esta imagen se aprecia con claridad.
  • Cola de tareas: Consiste en que 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. Si algún día vemos un mainframe basado en Cell, éste será el modelo que utilice.
  • Multitarea auto-gestionada: Este es el modelo que está desarrollando Arnd Bergmann de IBM para Linux. El sistema operativo abstrae cada SPE como un dispositivo en el virtual file system y permite comunicarse con él mediante llamadas al sistema. Esencialmente, es un modelo "yo me lo guiso, yo me lo como", porque toda la sincronización entre hilos y la asignación de tareas la tiene que gestionar nuestro software. Es de suponer que los desarrolladores de videojuegos utilizarán sus propias implementaciones de este modelo. Más información sobre el trabajo de Bergmann aquí.

6. Conclusiones

Distinguiré entre mis conclusiones técnicas y las de mercado. Las conclusiones técnicas son bastante evidentes:

  • El software escrito para otras plataformas más convencionales y simplemente recompilado para Cell experimentará una ligera bajada en el rendimiento debido a la ausencia de ejecución fuera de orden y a la predicción de saltos básica.
  • El software escrito para plataformas multihilo/multiprocesador y simplemente recompilado para Cell también sufrirá una bajada de rendimiento en parte debido a las razones del punto anterior y sobre todo porque el PPE sólo puede ejecutar dos hilos simultáneamente, frente a otras arquitecturas que pueden ejecutar muchos más.
  • El software escrito específicamente para Cell y que haga un uso intensivo de las SPEs va a obtener un rendimiento espectacular; muy por encima de lo que estamos acostumbrados a ver. Sin embargo, este software sufrirá gravísimos problemas de portabilidad; siendo necesario reescribir grandes zonas de código para adaptarlo a otros procesadores.

Sin embargo, es bastante más difícil sacar alguna conclusión de mercado; especialmente porque el dichoso chip aún no está a la venta. No obstante, expondré algunos pensamientos:

  • Es el software y no el hardware el que determinará el éxito o el fracaso de Cell.
  • Lo mires por donde lo mires, Cell es difícil de programar. Al incluirlo en la Play Station 3, Sony, IBM y Toshiba se han asegurado una base de futuros programadores bastante grande. Muchos y muy buenos programadores competirán entre sí durante los próximos años para sacarle todo el jugo a este procesador, lo que hará más fácil venderlo en otro tipo de aplicaciones como sistemas empotrados de tratamiento de imágenes (muy presentes en la Bioinformática), sistemas especializados en cálculos financieros e incluso estaciones de trabajo. Es una apuesta arriesgada, pero les puede salir bien.
  • La clave estará en el compilador. Sony aún tiene que terminar la versión de GCC para Cell en la que están trabajando. Al no haber ejecución fuera de orden, es importantísimo el orden en el que el compilador coloque las instrucciones. Hay que recordar que la arquitectura IA64 no está cumpliendo las predicciones que se hicieron sobre ella entre otras cosas porque el hardware confía demasiado en el compilador y éste no cumple las espectativas.
    En cualquier caso, el factor determinante será el soporte que se ofrezca a las SPEs. Idealmente, el propio compilador debería detectar zonas de código propicias para ser ejecutadas en una SPE y adjudicarlas de manera transparente al programador. Casi con toda probabilidad no seremos tan afortunados, ya que no confío nada en que Sony haga un compilador tan bueno. Una posibilidad que supongo sí implementarán serían directivas #pragma con las que el programador pudiera indicar qué zonas de código deben compilarse para ser ejecutadas en una SPE.

7. Referencias

Todos los enlaces listados en los epígrafes References y External links del artículo sobre cell en la Wikipedia en inglés.

Sé que debería haberlos copiado uno por uno, pero espero ser disculpado. Suficiente parrafada llevo escrita ya :D

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.
  • Buen artículo

    (Puntos:1)
    por pezezin (11919) <reversethis-{se.oohay} {ta} {46nizezep}> el Miércoles, 10 Agosto de 2005, 19:26h (#569423)
    ( http://barrapunto.com/ | Última bitácora: Viernes, 17 Noviembre de 2006, 23:39h )
    Pues eso, un buen artículo, interesante, bien escrito, e imparcial.

    Como reflexión personal, no creo que el Cell (al menos en su forma actual) se llegue a usar nunca en mainframes. Tiene muy poca caché, y las unidades vectoriales son inútiles para lo que hace un mainframe.
    --

    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

  • Peazo artículo

    (Puntos:2)
    por Ice_Glacierre (12752) el Miércoles, 10 Agosto de 2005, 19:47h (#569437)
    ( Última bitácora: Lunes, 29 Octubre de 2012, 18:48h )
    Ya podían aprender otros de lo que debería ser una bitácora XD

    Sobre el tema del cell y la PS3, no me extrañaría que al final sony desarrollara un framework para liberar de las tareas más tediosas de concurrencia a los programadores de videojuegos.
    O eso o cada juego va a tardar la de dios en estar listo, pienso yo (o la peor posibilidad, empezarán a salir juegos con unos interbloqueos impredecibles terroríficos)
  • No sé, pero así por encima se me ocurre que para todo lo contrario.

    Dejar fuera un SPE en un procesador para el que hay que programar tan específicamente las SPE's puede impedir la ejecución de código compilado para otros entornos CELL.

    No sé, será una suprema idiotez lo que acabo de decir, pero es mí idiotez :)

    Un saludo!
    [ Padre ]
  • por Killer_Onion (18700) el Miércoles, 10 Agosto de 2005, 17:22h (#569335)
    ( Última bitácora: Jueves, 23 Agosto de 2007, 11:40h )

    la SPE es un procesador vectorial, en vez de escalar, ejecutar instrucciones escalares en uno vectorial es una pérdida de rendimiento, porque éstos son capaces de trabajar con vectores, lo que significa que podrían sumar A+B y dejarlo en C siendo A,B y C vectores.

    Imagina que si son capaces de sumar vectores de 128 elementos (no sé la capacidad de estos), lo hacen del tirón, cosa que con un procesador escalar necesitariamos hacer las 128 sumas, más el movimiento de los datos entre registros.

    Probablemente se utilice DMA para mover los registros entre MP y los registros de las SPEs por la gran cantidad de datos que pretenderán mover a la vez (128registros de 128bits... tremendo!!).

    [ Padre ]
  • por deniel77 (13958) el Miércoles, 10 Agosto de 2005, 18:14h (#569378)
    ( http://public.danielhiga.org.ar/ | Última bitácora: Martes, 05 Febrero de 2013, 21:58h )
    Sony no es Microsoft. Sony gana dinero por el canon que le pagan las empresas creadoras de los videojuegos. Si el juego se consigue gratis, entonces Sony no gana nada.

    Lo que pueda ganar vendiendo la consola es muy poco.

    Tampoco pueden obtener ganancias de cursos oficiales y certificaciones. ¿Donde viste una academia para apreder a jugar en un playstation?
    --
    de cada ocho televidentes cuatro son la mitad
    [ Padre ]
  • por McPolu (19560) <McPolu@gmail.com> el Miércoles, 10 Agosto de 2005, 18:31h (#569392)
    ( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )

    No, los SPE´s son procesadores especializados. Para ciertas aplicaciones son mucho más potentes que el central y para otras son mucho peores.
    El dejar uno deshabilitado parece ser que es por motivos de coste, como se apunta en otro comentario. Si al """imprimir""" el chip hay un fallo en un SPE, se da por válido y a correr.

    --

    En España la mejor manera de guardar un secreto es escribir un libro.

    [ Padre ]
  • por McPolu (19560) <McPolu@gmail.com> el Miércoles, 10 Agosto de 2005, 18:36h (#569396)
    ( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )

    ¡Gracias! :D

    --

    En España la mejor manera de guardar un secreto es escribir un libro.

    [ Padre ]
  • Pues sí, si que va a haber Cell´s de primera y de segunda. En principio los "de segunda" (7 SPE´s) se van a destinar a la PS3 y los "de primera" (8 SPE´s) a otros usos.

    Respecto al rendimiento, depende del modelo de programación que se siga. Un programa escrito según el modelo "Cola de Tareas" sí se vería beneficiado al pasar del un Cell de segunda a un Cell de primera. Programas que sigan los otros modelos no se verían afectados, ya que aunque la octava SPE estuviese ahí, en principio no la usarían.

    Si Cell triunfa y en el futuro hay máquinas "multicelulares" tendría sentido escribir software adaptativo que mirase a ver cuántas SPE´s hay disponibles entre todos los Cell´s del sistema.

    --

    En España la mejor manera de guardar un secreto es escribir un libro.

    [ Padre ]
  • 3 respuestas por debajo de tu umbral de lectura actual.