Profundizando un poco más en el diseño big.LITTLE

Después de haber hablado un poco sobre el SoC Exynos 5410 de Samsung y de explicar algunas cosas que son más bien cosa de ese SoC que del planteamiento big.LITTLE, me gustaría profundizar un poco más en este tema. Este diseño puede resultar muy prometedor de cara al futuro y por eso yo creo que es importante dejar las cosas claras desde un principio para evitar que los típicos bulos que circulan por internet se expandan demasiado.

Esto de los 8 núcleos, emparejar núcleos de bajo consumo con otros de alto rendimiento y demás no es algo de Samsung. El planteamiento big.LITTLE es un trabajo de ARM y esta compañía puede licenciar su trabajo a otras. En este caso se habla mucho de Samsung porque es la compañía que antes ha conseguido sacarlo al mercado, pero hay otras como Renesas que también están trabajando en este campo.

Un punto a tener en cuenta en este diseño es el de aprovechar las capacidades de bajo consumo del cortex a7, el cual tiene una eficiencia energética muy buena, con la arquitectura cortex a15 que es muy potente, pero tiene el problema del consumo y la temperatura. El problema que tienen los cortex a15 es que con los procesos de fabricación que se usan hoy en día su consumo es demasiado elevado.

El propósito es el de aprovechar lo mejor de los dos mundos. Otros fabricantes como Qualcomm lo que han hecho es desarrollar núcleos potentes pero no tanto como los cortex a15, como son los krait. Con este diseño pudieron controlar el consumo y la temperatura pero claro, también tuvieron que recortar en rendimiento y eso se nota en el IPC. Como punto a su favor parece ser que el rendimiento por watio de los krait es mejor que el de los cortex a15. A medida que se mejoran los procesos de fabricación lo que hace Qualcomm es ir mejorando los krait para que la inferioridad en rendimiento con los cortex a15 se vaya recortando poco a poco. Así, nos encontramos con los krait 200 del snapdragon s4 pro, los krait 300 del snapdragon 600, los krait 400 del snapdragon 800…  Las mejoras son pocas, como permitir un mayor aumento de la velocidad de reloj o detalles como el prefetcher de la memoria caché, pero poco a poco los cambios se van notando.

Esto nos deja, en términos de rendimiento de menor a mayor rendimiento con algo similar a esto:

Pero en términos de rendimiento por watio la cosa sería, de mayor a menor:

Cortex a7……los krait y el cortex a9………cortex a15

Una comparativa en rendimiento en general y en rendimiento por watio la hizo ARM hace un tiempo y la puse también en el artículo del Exynos 5410 porque creo que explica bastantes cosas

Si hacemos la media simplemente para hacernos una idea, vemos que el cortex a15 rinde 2,2 veces más en este conjunto de pruebas pero cuando entra en juego el consumo vemos que el cortex a7 es 3,2 veces más eficiente que el cortex a15. De aquí se puede sacar la ventaja en rendimiento por watio del cortex a7 y la ventaja del rendimiento en general pero con un coste de consumo mayor en proporción del cortex a15.

El tamaño que ocupan ambos procesadores en el DIE también deja entrever todo esto:

Los 4 cortex a7 ocupan la cuarta parte que los 4 cortex a15.

¿Cómo se hace el cambio entre procesadores?

el IKS o In-kernel switcher es el que se encarga de esta tarea. En términos efectivos siempre se va a hablar del manejo de un procesador de 4 núcleos virtuales. Cada procesador cortex a15 de su cluster está emparejado con un procesador cortex a7 del otro cluster. Esto no tiene por qué verse reflejado en el tema hardware. Quiero decir, que el hecho de emparejar un cortex a15 con un cortex a7 no quiere decir que tengan que estar uno al lado del otro, o con conexiones especiales entre ellos.

El IKS hace un trabajo similar al de los governors de CPU, pero en vez de saltar de una frecuencia de CPU a otra según la carga, salta de un procesador a otro:

 

 

 

 

 

 

 

 

En términos efectivos estás saltando de una curva rendimiento/consumo a otra.

A día de hoy la implementación que te puedes encontrar en aparatos comerciales es la de meter un driver a nivel del núcleo del sistema operativo que mide la carga y actúa más o menos como un governor de CPU. En este vídeo se puede ver el salto de unos núcleos a otros y cómo funciona el emparejamiento entre un cortex a7 y un cortex a15:

Se puede ver que los cortex a7 son usados para tareas más ligeras y que el cambio al cortex a15  cuando las tareas son más pesadas se hace de forma prácticamente instantánea.

¿Se podrán usar alguna vez todos los núcleos a la vez?

La respuesta es HMP o Heterogeneous Multi-Processing.

Esta es la otra forma que hay de implementar el diseño big.LITTLE. El problema es que es exponencialmente más complejo de implementar porque el mecanismo de funcionamiento es también exponencialmente más complicado. Hoy en día estamos acostumbrados a ver procesadores de varios núcleos y que el sistema operativo los reconozca y maneje todos sin problemas, pero el SMP(Symmetric Multi-Processing) es mucho más simple porque todos los núcleos son iguales.

En este caso el sistema operativo debe saber diferenciar entre los cortex a7 y cortex a15 puesto que a ser sus capacidades distintas, su exigencia también debe ser distinta. Actualmente el kernel de linux no es capaz de diferenciarlos y trata a todos los núcleos como iguales.

El grupo Linaro, que salieron hace poco presentando sus trabajos para android, tiene ya terminada su primera implementación del HMP añadiendo una serie de parches al kernel 3.8. Consiguieron hacer el scheduler lo suficientemente inteligente como para identificar las cargas de los procesos y así poder asignarlos a los cortex a15 o cortex a7 según la carga.

Resumiendo, voy a poner una serie de puntos tratando de explicar errores que ya hay circulando por internet:

• No hace falta tener los 8 núcleos funcionando a la vez. De hecho solo 4 núcleos van a poder estar activos a la vez (excepto el día en el que se meta el HMP que de momento tiene pinta de ir para largo y de no ser algo enfocado a teléfonos)
• No se hace el cambio de todo el grupo de cortex a7 a todo el grupo de cortex a15 y viceversa. Puede haber por ejemplo un núcleo cortex a15 funcionando, dos cortex a7 funcionando y la otra pareja de procesadores offline en el mismo lapso de tiempo.
• Los dos grupos de procesadores son capaces de funcionar a frecuencias de reloj distintas, y de hecho lo normal va a ser eso. Los cortex a15 con una frecuencia máxima de X mhz y los cortex a7 con una frecuencia máxima de Y mhz.
• Realmente el procesador sí es de 8 núcleos, el problema es que solo se podrán usar los 8 a la vez con el HMP, y por eso muchos hablamos de 4+4,también para hacer énfasis en el hecho de que son dos grupos de 4 procesadores distintos.

Y bueno, este tema se espera que también sea válido con los futuros cortex a53 y cortex a57 de ARM hacia el año que viene. El cortex a53 hará el papel de cortex a7 y el a57 hará el papel de cortex a15, pero el planteamiento big.LITTLE será básicamente el mismo, supongo que con alguna optimización extra:

Solo me queda dar las gracias a desarrolladores como AndreiLux y otros por dedicar tiempo a explicar dudas de la gente en este tipo de temas.

También a ARM por dejar información bastante clara y bien explicada en su página web, como por ejemplo documentos como este.

Y creo que esto es todo. Si aún hay dudas puedes preguntar en los comentarios y te intentaré responder cuando pueda 🙂