Blog Personal.

AMD, Conceptos Básicos, Especulación, Futuro, Intel

big.Little: Explicación, el «problema» de Lakefield y Zen Lite.

Una de las particularidades que trae consigo el Intel Tiger Lake y que hace tiempo que vemos en los dispositivos Post-PC es la configuración big.LITTLE donde se utiliza una configuración heterogénea de núcleos en un mismo SoC bajo el mismo conjunto de registros e instrucciones.

La idea es que para tareas poco pesadas en la que la potencia del núcleo más potente (Big) no es una ventaja se utilice un núcleo mucho más ligero (Little), esto esta pensado para aumentar la vida de la batería útil en los dispositivos PostPC pero para ello es necesario tener un sistema que monitorice por completo las cargas de trabajo que van a ejecutarse y se encargue de ir distribuyendo estas a los diferentes núcleos según sea necesario.¿Parece fácil no? Pues no lo es dado que para ello es necesario una cache de ultimo nivel que unifique todos los clusters de las CPUs, tanto los clusters con núcleo de baja potencia como los de alta potencia.

Para hacerlo lo que hace ARM es colocar una Cache adicional en el Northbridge a la que llama System Cache.

De cara al Tiger Lake, Intel ha hecho lo mismo como se puede ver en el siguiente diagrama:

En el Lakefield tenemos un Uncore/Northbridge con 4MB de Cache LLC (Ultimo Nivel) por lo que Intel ha tomado el mismo camino que ARM. El motivo es que sin la Cache de último nivel entonces para la comunicación es que los núcleos se han de encontrar en la RAM y esto no es lo más eficiente del mundo especialmente en sistemas de bajo consumo ya que como hemos visto varias veces cuanto más cerca están unos datos al procesador menos consumo energético consumen dichas instrucciones.

El problema de todo esto es muy bonito pero… ¿Quien y como maneja el uso de los diferentes núcleos según la carga de trabajo? Para empezar hemos de tener en cuenta que una CPU no entiende de programas sino de hilos de ejecución y los sistemas operativos utilizan un mecanismo llamado semaforo para darle preferencia a un hilo u otro cuando tienen que utilizar un recurso compartido en el hardware y necesitan acceder a él y se le llama semáforo por el hecho que en cada hilo de ejecución se controla según su preferencia en la ejecución:

  • Activo: El hilo se esta ejecutando. (Semaforo en Verde)
  • Listo: No se ejecuta pero será el siguiente en la lista en ejecutarse. (Semaforo en Naranja)
  • Esperando: No se ejecuta pero esta esperando a hacerlo. (Semaforo en rojo)
  • Inactivo: El hilo ni tan siquiera esta a la espera, por lo que se descarta y se envía a la RAM donde se mantiene a la espera para ser invocado.

¿Y quien hace este trabajo? Por lo general y en el caso de las CPUs es el Sistema Operativo y por tanto no es una pieza de hardware sino un programa dentro del kenel del mismo que sirve para gestionar los diferentes hilos en un entorno multitarea, es más, los semáforos son los encargados de asignar a que núcleo va cada hilo. En una GPU el funcionamiento es distinto, pero para no liar la cosa vamos a obviar las GPUs que son un mundo aparte.

Obviamente para repartir los diferentes hilos las CPUs tienen que tener un mecanismo interno a la hora de copiar de la cache global y último nivel a las caches intermedias que son caches compartidas entre varios núcleos homogéneos. Dicho mecanismo interno es invocado por el Sistema Operativo a la hora de escoger a donde va el hilo de ejecución. Y si, lo estoy simplificando mucho.

¿Pero como sabe a que conjunto de núcleos ha de ir en un sistema big.LITTLE? Pues por dos métodos, el primero es que durante la programación podemos asignarle un valor determinado que decida que tipo de núcleo va a ejecutar ese recurso, el segundo es que cada instrucción tiene un presupuesto energético y por tanto a partir del presupuesto energético global si tenemos una pieza de hardware que mida el presupuesto del código de antemano pues puede ir enviando los diferentes hilos según sea necesario a los diferentes clusters/conjuntos de núcleos.

Ambas soluciones son válidas y ambas representan una batalla entre los ingenieros de software y los de hardware:

El primer método es el ideal para los ingenieros de hardware porque les quita el problema de encima y les permite gastar el presupuesto en puertas lógicas y memoria en otras cosas dentro del diseño. El segundo es ideal para los ingenieros de software ya que el hecho que tengamos que utilizar un mecanismo de este tipo es alargar la sub-etapa de captación de instrucciones y afecta a todo eldiseño de una CPU que puede ser de decenas por no decir cientos de millones mientras que la primera opción es solo colocar una variable adicional en cada hilo de ejecución del programa con un coste mucho menor pero ha de existir la conciencia por parte de los desarrolladores que se de dicho fenómeno y en PC donde históricamente no se han utilizado núcleos big.LITTLE esto no ocurre.

Los benchmarks de Lakefield de hace un mes que se filtraron fueron decepcionantes, el motivo de ello es que los programas y el sistema operativo no están diseñados para este tipo de configuraciones porque no son habituales en PC ya que ni AMD ni Intel habían tomado por una configuración big.LITTLE en sus procesadores hasta ahora y por tanto Windows tampoco. ¿El resultado? Algo que dio para muchos memes pero que realmente no es culpa de Intel.

Básicamente los programas interpretan los 5 núcleos como simétricos (como si fuesen el mismo) e interpreta los 4 núcleos pequeños como los núcleos 0, 1 2, y 3 mientras que al núcleo grande como el núcleo 5. ¿Las consecuencias de ello? El núcleo 5 apenas es invocado y su rendimiento apenas se utiliza por lo que hay un desaprovechamiento total de este mientras que los pequeños van ahogados incluso haciendo tareas en las que no son lo suficientemente buenos debido a que no hay una asignación en los hilos de los programas para escoger que tipo de núcleo es el ideal.

Otro caso flagrante de esto es la Nintendo Switch…

El SO se asigna para si mismo el Core 0 del A57 del Tegra X1 y deja al juego con los 3 núcleos restantes… ¿Pero acaso no hay unos 4 núcleos A53 en otro Cluster?

En realidad este diagrama es falso, el motivo de ello es que el Tegra X1 carace de un Northbridge/Uncore/Data Fabric con Cache de Último Nivel (LLC).

Contrariamente a la creencia inicial, Nvidia no utiliza los ocho núcleos en la configuración ARM big.LITTLE. En cambio, los dispositivos que utilizan el Tegra X1 siempre muestran que solo tienen cuatro núcleos ARM Cortex-A57 disponibles. El sistema operativo no puede acceder a los otros cuatro núcleos ARM Cortex-A53, no se utilizan en dispositivos conocidos y Nvidia los ha eliminado de versiones posteriores de la documentación técnica, lo que implica que una errata de silicio impide su uso normal.

Por lo que los núcleos A53 están ahí para ocupar espacio y nada más, para hacer bulto. Lo cual es sorprendente porque para tareas en segundo plano de poca potencia iría muy bien y permitirían un aumento de la vida de la batería y descargar el trabajo del A57 aumentando así el rendimiento del sistema. El problema es que en estos momentos ningún juego lo aprovecharía si se pudiesen activar pero si para funciones del sistema operativo en segundo plano. Por ejemplo Nintendo podría haber integrado un sistema de chat de voz en los A53.

Volviendo al PC… ¿Vamos a ver big.LITTLE en PC o lo de Lakefield es un experimento fallido? Yo creo que si, incluso sabemos que AMD se va a sumar al carro con un núcleo de bajo consumo derivado de los Zen aunque oficialmente no este anunciado, más que nada por ciertos diagramas en ciertas patentes de AMD.

Por lo que vamos a verlo como una realidad a corto/medio plazo donde al igual que ha ocurrido en Android e iOS los programas en PC se optimicen para el uso del big.LITTLE. Pero lo importante de todo es que AMD podría estar trabajando en un Zen Lite que bien podría ir de maravilla para una eventual consola portátil de Sony o Microsoft, totalmente compatible con el catálogo de su consola de la actual generación (PS4 o Xbox One), pero eso ya es harina de otro costal y va para otra entrada.

Esto es todo, tenéis los comentarios de esta misma entrada para comentar y no olvideis que tenemos Discord.