PPUs

Actualmente todos los ordenadores tienen algún tipo de GPU que permite liberar a la CPU de los cálculos necesarios para generar gráficos 3D, se han propuesto añadir más hardware de propósito específico, especialmente para juegos.

La propuesta más importante ha sido la de un coprocesador físico normalmente conocido como PPU (Physics Processing Unit).

Los primeros diseños de hardware especializado (SPARTA y posteriormente HELLAS) fueron fruto de la investigación académica. En febrero de 2006 se comercializó la primera PPU bajo el nombre de PhysX, diseñado por la compañía Ageia.


La arquitectura de esta tarjeta está basada en un procesador RISC, acompañado de procesadores vectoriales con almacenamiento local (no es memoria caché) y la lógica necesaria para intercomunicar los distintos procesadores. El hardware iba acompañado de la correspondiente API. Esta tecnología la compró nVidia en 2008. En la actualidad, nVidia ha hecho público el API, pero no va a comercializar el hardware sino que mediante un driver, utiliza la potencia de cálculo de las GPUs actuales para acelerar el cálculo de la física.



El principal competidor de PhysX es Havok FX. Se trata de una modificación de Havok, una API y motor de física muy populares, que permite utilizar tarjetas gráficas tanto de AMD como de nVidia para acelerar ciertos cálculos. Estos se implementan como shaders que se ejecutan en la GPU, siguiendo la estrategia actual de nVidia con PhysX. Sin embargo esta tecnología parece estar abandonada desde que Intel compró Havok.

La tendencia actual parece hacer innecesario el uso de hardware específico para el cálculo de la física. De hecho el diseño de la PPU PhysX recuerda al diseño de procesadores modernos como Cell de Sony/IBM/Toshiba o a las tarjetas gráficas modernas que como se ha visto comienzan a utilizarse para dicho fin. Esto hace pensar que en el futuro bastará con el hardware ya existente. Es mucho más probable que se vuelva algo normal el uso de una 2ª tarjeta gráfica como co-procesador que pueda realizar diversos cálculos (entre ellos la física) usando CUDA, OpenCL o DirectCompute. Por ejemplo, los nuevos MacBook Pro de 17" tienen 2 tarjetas gráficas. Esto ha coincidido con el lanzamiento de CUDA para Mac por parte de nVidia y el anuncio de soporte para PhysX en Mac en un futuro, el apoyo de Apple a OpenCL y el uso de GPGPU por parte de Adobe en su programa Photoshop en su última versión.

Patxi Astiz

HyperTransport

HyperTransport (HT) es actualmente el bus con mejores prestaciones en ordenadores de consumo. El estándar lo define un grupo de fabricantes llamado "HyperTransport Consortium". La versión 1.0 se publicó en 2001 y la utilizó AMD para interconectar sus procesadores Opteron y siguientes. La última versión (3.1) se ha publicado en 2008. El funcionamiento básico de un bus HT es el mismo en todas las versiones.

Esta tecnología se basa en un enlace half-duplex de un bit que usa señalización diferencial de bajo voltaje. A partir de este elemento básico, se establecen buses con un número variable de enlaces (entre 2 y 32, normalmente potencias de 2). A la hora de establecer un enlace, las 2 partes negocian el número de lineas a utilizar en cada sentido (puede ser un enlace asimétrico). La comunicación se realiza de manera asíncrona y es DDR, es decir se transmite 2 veces por ciclo.

Los sucesivos estándares han añadido ciertas funcionalidades, pero sobre todo han aumentado la frecuencia de funcionamiento. En la primera versión, HT funcionaba a un máximo de 800 MHz lo que supone, 12.8 GB/s para un enlace de 32 bits. Esta velocidad ha crecido hasta 3.2 GHz en el estándar 3.1, con lo que se pueden conseguir tasas de transferencia de 51.2 GB/s.

La comunicación se realiza mediante paquetes, siguiendo un protocolo parecido a los utilizados en redes de comunicaciones. Los dispositivos tienen asignadas direcciones de 40 bits. Un paquete está formado por un conjunto de palabras de 32 bits. Los paquetes pueden ser de control o de datos. Los paquetes de control contienen comandos y los parámetros que sean necesarios. Después de un paquete de control puede transmitirse si se desea un paquete de datos, como en el siguiente ejemplo:


HyperTransport está pensado para utilizarse como método de señalización y paso de mensajes para controlar un sistema, generar interrupciones y lógicamente transferencia de datos con o sin confirmación por parte del otro extremo de la comunciación. Tiene muchas características interesantes como que está diseñado para poder mapear fácilmente PCI, PCI-X y PCI-Express a partir de la versión 2.0, permite conectar y desconectar elementos en caliente (desde la versión 3.0) y se puede ajustar dinámicamente el ancho y la frecuencia de un enlace (también desde la versión 3.0), entre otras.

Este tipo de bus suele utilizarse para interconectar varios elementos dentro de un sistema. Como ya se ha comentado, AMD lo utiliza pra interconectar sus procesadores y como sustituto del FSB. También puede implementarse en los últimos FPGAs de Altera y Xilinx, por lo que algunas compañías los usan como coprocesadores, que se comunican con el procesador usando este estándar. Hay 2 especificaciones de conectores de tipo slot en el estándar por lo que puede utilizarse como sustituto de PCI-Express a la hora de añadir slots de expansión a una placa base.

Patxi Astiz

Itanium

Los procesadores Itanium fueron desarrollados por Intel y HP entre los años 1989 y 2000. El lanzamiento se produjo finalmente en el año 2001 y en 2002 se lanzó al mercado Itanium 2 que corregía la jerarquía de memoria del primer diseño, que se mostró ineficiente, además de añadir más unidades funcionales. Esta versión ha tenido revisiones en las que se ha mejorado el proceso de fabricación, aumentado el tamaño de la memoria caché, añadido núcleos y algunas características como soporte para virtualización o multithreading.

El objetivo del diseño del itanium era conseguir una arquitectura que maximice el número de instrucciones por ciclo. A esta arquitectura se le conoce con el nombre EPIC (Explicitly Parallel Instruction Computing). La base de este diseño es utilizar instrucciones muy largas (128 bits) que en realidad contienen 3 instrucciones de 41 bits que pueden ejecutarse simultáneamente. Esta agrupación la realiza el compilador, que es el que tiene toda la responsabilidad en lugar de la lógica del procesador como sucede en los procesadores x86 más comunes, que pueden ejecutar fuera de orden.

Este es un esquema de bloques del procesador Itanium original:

Como hemos dicho, el objetivo del diseño es ejecutar el mayor número posible de instrucciones en paralelo. Por ello tiene un gran número de unidades funcionales en 11 grupos diferentes:

• 6 ALUs de propósito general
• 2 unidades de enteros
• 1 unidad de desplazamiento de bits
  
• 4 unidades de acceso a caché
• 6 unidades de cálculo multimedia
• 2 unidades de desplazamiento de bits en paralelo
• 1 unidad de multiplicación en paralelo
• 1 unidad de "population count" (número de bits a 1 en un registro)
• 2 unidades de coma flotante de 82 bits
• 2 unidades de coma flotante SIMD
• 3 unidades de cómputo de saltos

Cada grupo de unidades puede ejecutar un subconjunto de instrucciones, dependiendo del tipo que sean. Las instrucciones más comunes pueden ser ejecutadas por más de 1 tipo de unidades. Cada instrucción pertenece a uno de los siguientes tipos:

• A: números enteros (ALU)
  
• I: números enteros (no ALU)
• M: acceso a memoria
• F: Punto flotante
• B: Salto
• L+X: Tipo extendido, dependiendo del subtipo se ejecuta en distintas unidades.
  

Por ejemplo las instrucciones de tipo A pueden ejecutarse en las unidades de enteros, en las ALUs de propósito general y en las de cálculo multimedia.

El procesador tiene una gran cantidad de unidades disponibles y reparte el trabajo según el tipo de instrucción entre ellas, mediante estaciones de reserva siguiendo la estrategia del algoritmo de Tomasulo. Si nos fijamos, un conjunto de 3 instrucciones ocupa 41*3=123 bits. Los 5 bits que faltan hasta 128 bits indican al procesador que combinación de tipos de instrucciones hay. Por ejemplo, 00001 indica que la primera instrucción es de tipo M, mientras que la 2ª y 3ª son de tipo I. Además de una gran cantidad de unidades funcionales, también tiene una gran cantidad de registros. Hay 128 registros de proposito general de 64 bits, 128 registros de coma flotante de 82 bits y 64 registros de predicación de 1 bit.

Para mantener las unidades funcionales activas, el procesador implementa varias técnicas conocidas. En primer lugar, emite dos instrucciones por ciclo de reloj. Teniendo en cuenta que cada una es un paquete con 3 instrucciones, son 6 las instrucciones efectivas que puede llegar a emitir. Otra técnica de la que hace uso este procesador es la predicción de saltos. El procesador tiene 2 predictores, uno de ellos es un buffer de predicción de salto, mientras que el 2º es un predictor de 2 niveles. También implementa un predictor de dirección de retorno para las llamadas a funciones. Lo más distintivo de este procesador es que el compilador puede añadir sugerencias sobre los saltos, haciendo que el procesador lo evalúe de manera dinámica (utilizando los predictores) o de manera estática (haciendo caso a la recomendación del compilador).

El procesador también tiene la capacidad de especular y también implementa una técnica que no es común en los procesadores actuales, que es la predicación. Al usar esta técnica, el procesador ejecuta las 2 ramas de un salto y descarta la que no se toma una vez conocido el resultado de la instrucción de salto. Esta técnica encaja con la gran cantidad de registros y unidades funcionales del procesador. Esto es especialmente práctico en el caso de saltos condicionales que ejecutan pocas instrucciones. El compilador puede elegir qué debe realizar el procesador. Para ello, cada instrucción tiene 6 bits reservados para indicar que registro de predicación indica si la instrucción se debe ejecutar o no. Hay un registro cuyo valor es siempre verdadero, por lo que se puede usar para ejecutar instrucciones sin predicción. El funcionamiento de esta técnica se puede ver en este esquema:

En el caso de usar predicación, se evalúa que r1 valga 5 y el resultado se asigna a los registros de predicación qp1 y la negación a qp2. A continuación se ejecutan ambas ramas, solo que las operaciones cada una están asociadas un registro de predicación. El resultado de las ramas se utilizará o se desechará según el resultado final de la instrucción test. Otra vez más, es el compilador el que tiene la responsabilidad de utilizar la predicación adecuadamente.

La jerarquía de memoria está dividida en 3 niveles. La memoria de primer nivel está separada en 2, una para instrucciones y otra para datos. Ambas son asociativas por conjuntos (4) y tienen un tamaño de 16 KB cada una. La memoria de nivel 2 ha sufrido varios cambios. Inicialmente era una memoria asociativa por conjuntos (6) con un tamaño de 96 KB, compartida para código y datos. Con los procesadores Itanium II aumentaron el tamaño hasta 256 KB y la asociatividad a 8. Desde mediados del 2006 la memoria caché de nivel 2 está separada en una caché de datos de 256 KB y una de instrucciones de 1 MB. La memoria caché de nivel 3 se accedía a través del FSB en el caso de los primeros Itanium y consistía de una caché asociativa por conjuntos (2) de 2 ó 4 MB. Al revisar la jerarquía de memoria con los Itanium II se incluyó memoria caché asociativa por grupos (2 ó 4) de nivel 3 en el mismo integrado. El tamaño varía según el modelo desde 1.5 MB hasta 24 MB en los últimos modelos con 2 núcleos (12 por núcleo).


Este tipo de procesadores está orientado a la computación de alto rendimiento. La arquitectura Itanium consigue un rendimiento altísimo en cálculo en coma flotante y de hecho ha sido muy utilizada en supercomputadores.

Patxi Astiz

Sega Dreamcast

Antes del lanzamiento de la consola Sony PlayStation 2, Sega comercializó a finales de 1998 la Dreamcast. Desafortunadamente la compañía decició abandonar la producción de hardware de entretenimiento para uso domestico y se dedicó exclusivamente al software y a las máquinas recreativas, con lo que abandonó la producción de su última consola. Vamos a hacer un repaso de sus características técnicas.


Empezaremos con un diagrama de bloques de los diferentes elementos que la componen:

Como se puede ver hay 2 bloques principales, que son la CPU y la GPU en la que además han integrado el chipset que permite a la consola comunicarse con el resto de dispositivos y periféricos de la consola. Como puede verse en el diagrama, hay 3 memorias diferenciadas. En primer hay 16 MB SDRAM que son la memoria principal a la que pueden acceder tanto la CPU como la GPU a través de un bus compartido. Este bus tiene un ancho de 64 bits y una frecuencia de 100 MHz, consiguiento un máximo de 800 MB/s. Un bus con las mismas características une la GPU con la memoria de video que en este caso son 8 MB. Por último, el chip de sonido (un ARM7 junto con un DSP) tiene su propia memoria (2MB) a la que puede acceder mediante un bus de 16 bits de ancho y una frecuencia de 66MHz.

Veamos con más detalle la CPU de la Dreamcast. Se trata de un procesador SH-4 diseñado y fabricado por Hitachi. Es un procesador RISC superescalar de 32 bits. Está segmentado en 5 etapas y funciona a 200 MHz. Tiene una caché de instrucciones de 8 KB. y una caché de datos de 16 KB. Ambas usan mapeo directo. Este procesador tiene un rendimiento (medido usando el benchmark Dhrystone 1.1) de 360 MIPS.


Como se puede ver en la imagen del chip del procesador SH-4, una parte importante del circuito integrado se dedica a la unidad de FPU y al motor de gráficos vectoriales. Esta última es una unidad SIMD. Está pensado especialmente para realizar productos de vectores y matrices para gráficos en 3D. El procesador puede realizar 4 multiplicaciones y 4 sumas en coma flotante de precisión simple simultaneamente. Esto da un máximo teórico de 1.4 GFLOPS aunque en la práctica es imposible alimentar la CPU con datos suficientes para llegar a obtener este rendimiento y el máximo ronda los 0.9 GFLOPS.

La GPU PowerVR 2 fabricada por NEC y diseñada por Imagination Technologies, funciona a una frecuencia de 100 MHz y tiene ciertas peculiaridades sobre las GPUs habituales. No realiza las tareas de transformación de polígonos cuyo cálculo realiza el procesador (gracias a la unidad de gráficos vectoriales). Tampoco utiliza un buffer-z, que se basa en una tecnología llamada tile-rendering. Consiste en dividir la escena en una cuadrícula y renderizarlas una por una independientemente. Como se renderiza solo una pequeña parte de la escena, la información necesaria se puede almacenar en una pequeña memoria local a la que le procesador accede rápidamente. La técnica utilizada es parecida al trazado de rayos y consigue decidir qué polígono está más cerca de la camara, con lo que nunca se dibujan polígonos que están por detrás de otros (evitando completamente el overdraw) y permite utilizar transparencias correctamente independientemente del orden en que se dibujen los polígonos. Aunque la velocidad y la tasa de relleno de esta GPU no sean muy elevadas, el hecho de que no haya overdraw hace que se aproveche al 100% obteniendo un rendimiento muy bueno.

En general el diseño del hardware de la consola no es especialmente novedoso, pero sí que está bastante equilibrado y el funcionamiento global con juegos 3D en tiempo real era muy bueno para los estándares de la época, siendo capaz de renderizar más de 5 millones de polígonos por segundo con iluminación y texturas. Además introdujo varias novedades, como el modem incorporado con la posibilidad de jugar por red o el uso de tarjetas de memoria externas en las que salvar el progreso de las partidas que incluso incluían una pequeña pantalla y controles con los que poder jugar a mini-juegos.

Patxi Astiz

Análisis "ClarkDale's Efficiency"

Hay varias páginas web que realizan análisis y comparativas de hardware de consumo como procesadores, memoria, tarjetas gráficas, placas base, etc, etc. Una de las más famosas es Tom's Hardware.

Vamos a fijarnos en el siguiente artículo. En él se compara el rendimiento del procesador Intel Core i5-661 frente a los procesadores AMD Phenom II X2 550, AMD Athlon II X2 240e e Intel Core 2 Duo E8600.


El árticulo comienza con dando detalles de la arquitectura de la familia de procesadores Core i5 que Intel ha lanzado recientemente. Una de las novedades más importantes de estos es que en el mismo empaquetado se encuentra el procesador, el controlador de memoria y una GPU. En el caso de los demás procesadores, se han escogido placas base con GPUs integradas.


En este tipo de análisis hay muchísimos factores que influyen en el resultado final y resulta casi imposible aislar el rendimiento del procesador. Por ello se suelen realizar una gran cantidad de pruebas de distinto tipo, tanto sintéticas como pruebas de rendimiento con aplicaciones o juegos de uso común. En este artículo se utilizan los benchmarks SiSoftware Sandra 2009, PCMark y 3DMark y se utilizan aplicaciones muy exigentes con la CPU o con la GPU, desde juegos como Far Cry o Left for Dead hasta aplicaciones audio/video, compresión de datos, antivirus y modelado 3D entre otros. El conjunto de tests es variado y permite hacerse una idea del rendimiento que ofrece el sistema en bastantes de las tareas más comunes.

Este árticulo hay ciertos aspectos criticables. En primer lugar, los sistemas elegidos para comparar son muy diferentes. Mientras que el procesador Core i5 tiene la GPU empaquetada junto con el procesador, los demás la tienen integrada en la placa base. Además estas GPUs integradas, son más antiguas y todas, excepto las de los procesadores AMD son diferentes entre sí, por lo que en algunos test las diferencias de rendimiento no se sabe en que medida se deben a la CPU o a la GPU. Quizás habría sido más acertado comparar los diferentes modelos de la misma familia de procesadores o no incluir benchmarks en los que la GPU tenga un papel importante, si el objetivo era evaluar solo la CPU.

Otro aspecto a destacar es que se está comparando un procesador con un diseño muy reciente (Core i5) y fabricado en una tecnología de 32nm, (más capacidad de integración y menor consumo) con diseños menos actuales con una tecnología peor (45 nm.). De hecho teniendo en cuenta el precio de venta de los procesadores, algunos de ellos ni siquiera se podría considerar que sean de la misma gama.

Algunas diferencias entre los procesadores escogidos para comparar son especialmente importantes. Por ejemplo, el procesador Core i5 tiene un motor que acelera el cifrado/descifrado AES, lo que le da una ventaja enorme en los test que lo utilizan. Además, en la parte final del artículo se ejecutan una serie de aplicaciones y se compara la potencia eléctrica consumida para realizar el mismo trabajo, suponiendo que la mayor parte de la potencia consumida se debe al procesador. De aquí se saca una medida de la eficiencia eléctrica del procesador. Esta es una medida interesante, pero esta influenciada por demasiados factores, como la tecnología de fabricación antes mencionada, el consumo del resto de elementos del sistema, la calidad del PFC de la fuente de alimentación, etc.

En resumen, el análisis examina el rendimiento de un sistema con Core i5 en pruebas muy diferentes, ayudando a tener una idea del rendimiento que podemos esperar de este procesador. Sin embargo al comparar con otros procesadores, hay demasiadas diferencias (en tecnología y en precio) entre los sistemas escogidos y las comparaciones en algunos aspectos pierden valor. Habría sido más ilustrativo el enfrentar distintas versiones del mismo procesador o simplemente analizar el Core i5 sin compararlo con otros.

Patxi Astiz

Programación del Cell

Como ya hemos visto, el procesador Cell tiene una arquitectura que exige un esfuerzo extra al programador a la hora de adecuar el programa a las peculiaridades del hardware. Esto es importante si se quiere aprovechar la capacidad del procesador y para ello hay varios modelos de programación que se pueden seguir.

En primer lugar se puede programar para Cell como si fuera un procesador de propósito general, al tener un núcleo PowerPC con VMX. Este modelo es muy sencillo pero obviamente desaprovecha la mayor parte de la potencia de cálculo del procesador. Sin embargo para tareas en las que esta potencia no es realmente necesaria compensa el menor tiempo y coste de desarrollo.

El siguiente paso en cuanto a complejidad consiste en utilizar un SPE para realizar ciertas tareas concretas. Mientras que el programa se ejecuta en el PPE, parte del algoritmo puede que se beneficie de la potencia de cálculo de los SPE. En ese caso se programa y compila para un SPE y desde el PPE se encarga de configurar el procesador para que se ejecute cuando haga falta. Este modelo de programación utiliza los SPEs como una ayuda en momentos puntuales. Esto introduce una dificultad añadida que es la gestión de la memoria. Cada SPE tiene una memoria local de 256 KB y puede acceder a la memoria principal mediante DMA. En caso de que los datos y el código no quepan en la memoria local hay que incluir código que gestione los datos de la memoria local y el acceso a memoria principal para que el SPE no se quede parado a la espera de los datos que necesite.

Para aprovechar al máximo los recursos que nos ofrece el procesador hay que utilizar modelos de programación paralela. Los modelos clásicos pueden adaptarse a este procesador, como por ejemplo el modelo de memoria compartida. Los SPE pueden procesar los datos en memoria compartida mientras que el PPE les facilita los servicios propios del sistema operativo, como acceso a la memoria, a sistemas de entrada/salida, etc.



Además del modelo de memoria compartida hay otros, como establecer una cola de trabajos de forma que se va repartiendo trabajo a los SPEs según van solicitándolo al unirse a dicha cola. Esta cola la gestiona el PPE y va asignando datos a procesar y espacio en memoria en la que dejar los resultados a los SPEs que estén bloqueados en la cola. Otra posibilidad es formar un pipeline con los SPEs, de manera que van realizando parte del trabajo y pasando el resultado al siguiente SPE que lo continuará, al estilo de una cadena de montaje.

Teniendo memoria compartida, esta puede utilizarse para implementar los métodos habituales de comunicación entre procesos como mutexes, semáforos o paso de mensajes y aprovecharlos para ejecutar varios hilos en paralelo en distintos SPEs.

Otra forma de gestionar los recursos del procesador es mediante el propio sistema operativo, en lugar de hacerlo el desarrollador de la aplicación. Esto se puede realizar de 2 maneras. La primera consiste en considerar los SPEs como un recurso al que se puede acceder representándolo mediante un sistema de ficheros. La segunda estrategia consiste en que el sistema operativo sea capaz de diferenciar entre hilos que deben ejecutarse en el PPE e hilos para los SPEs. En este caso es el kernel del sistema operativo el que se encarga de planificar los hilos y enviarlos a ejecutar a la unidad que corresponda del procesador. El programador puede crear y destruir hilos o tareas para los SPEs mediante llamadas al sistema. Este modelo es el que utiliza el kernel de Linux.

Patxi Astiz

Cell vs. Xenon

La última generación de consolas ha traído 2 procesadores que han introducido cambios importantes en la forma de diseñar procesadores de proposito general que se ha mantenido hasta ahora. Por una parte, el procesador de la Xbox360 (Xenon), al que hemos dedicado una entrada en esta blog y por otra el procesador Cell desarrollado por IBM, Sony y Toshiba. Este es el aspecto que tiene el Cell:


Como puede verse el diseño es muy diferente al del procesador Xenon, ya que aunque tiene varios núcleos, estos son heterogéneos. Sin embargo, el objetivo de los 2 procesadores no es tan diferente.

El PPE (Power Processor Element) del procesador Cell es muy parecido a un núcleo del Xenon. Ejecuta instrucciones en orden y puede ejecutar 2 hilos simultáneamente. También está basado en la tecnología PowerPC y funciona a la misma velocidad. También tiene la tecnología VMX. La memoria caché del PPE también tiene 2 niveles, con 32 KB para instrucciones y 32 KB para datos en la caché de nivel 1 y 512 KB en la de nivel 2. Como se puede ver este núcleo es bastante similar a un núcleo del procesador Xenon.

El diseño del procesador de la Xbox está pensado para ejecutar aplicaciones que procesan grandes cantidades de datos y para ello se han dispuesto 3 núcleos que funcionan a velocidades de reloj elevadas con unidades vectoriales potentes pero que no dejan de ser procesadores de propósito general. En el Cell el objetivo es el mismo, proporcionar mucha potencia de calculo para este tipo de aplicaciones pero para ello se han añadido al diseño procesadores mucho más especializados. Estos son los llamados SPE (Synergistic Processing Elements).


Los núcleos SPE tienen ciertas características que los hacen especialmente potentes para algunos cálculos a cambio de simplificar al máximo su diseño. Cada uno de estos nucleos tiene 128 registros de 128 bits y es capaz de hacer 4 operaciones de coma flotante de precisión simple en un ciclo de reloj. Un SPE tiene una memoria local de 256 KB , ejecutan las instrucciones en orden, carecen de caché y de predicción de saltos. Una unidad tiene un pico teórico de 25.6 GFLOPS, sin embargo el rendimiento con (por ejemplo) código con muchos saltos condicionales se reduce drásticamente. Este tipo de código debería ejecutarse en el PPE.

En ambos casos los procesadores dejan bastante responsabilidad al programador y al compilador que deben asegurarse de generar código paralelizado que utilice los recursos del procesador en cuestión adecuadamente. En el caso del Cell el hecho de tener núcleos heterogéneos y en el caso de los SPEs muy especializados en cierto tipo de cálculos, obliga a un esfuerzo mayor a la hora de decidir cómo realizar la división y adaptación de un programa en hilos, teniendo en cuenta en qué tipo de núcleo deben ejecutarse. Mientras tanto en el Xenon todos los núcleos son iguales y la división y adaptación es más sencilla. A cambio, el procesador Cell puede conseguir un rendimiento altísimo si se programa adecuadamente para él.

Patxi Astiz