Blog Personal.

Conceptos Básicos, Futuro

Last Level Cache

El diagrama de abajo es bastante claro no necesita ninguna explicación adicional y no es otra cosa que el añadido de una Cache de Último Nivel en el Northbridge/Data Fabric/Uncore en futuras CPUs y SoCs de AMD.

Lo cual no ocurre en las CPUs y SoC de la actual generación donde dicha cache no existe. El objetivo de ello es poder tener un sistema big.LITTLE como el de los SoC con CPU ARM y el Intel Lakefield donde para poder utilizar los dos tipos de núcleos bajo un mismo conjunto de registros e instrucciones hace falta una cache de último nivel en el Northbridge/Data Fabric/Uncore y esto es lo que se puede ver referenciado en la patente titulada STEERING TAG SUPPORT IN VIRTUALIZED ENVIRONMENTS la cual no comentare en general aquí porque no trata sobre dicha cache y tampoco da una explicación sobre la misma, pero ver dicha cache en un diagrama de una patente de AMD nos dan ciertas pistas hacía donde tienen que ir las cosas.

El caso es que de aplicarse en un SoC con una GPU y otros aceleradores dicha cache no sería accesible solo por la CPU sino que también sería la LCC (Cache de Último Nivel para la GPU). En el diagrama es llamada Cache L4 por el hecho que es mencionada respecto a las caches de la CPU ya que cada CCX de las arquitecturas Zen tiene 3 niveles de cache pero en el caso de un SoC con GPU dicha cache de último nivel también formaría parte de su estructura de caches por lo que es mucho mejor llamarla LLC (Last Level Cache) porque puede ser que la nomenclatura de la GPU sea distinta y la gente termine un poco muy confundida. Por ejemplo en la arquitectura RDNA tenemos Cache L0 (Dentro de la CU), Cache L1 (Dentro del Shader Array) y Cache L2 (Dentro de la unidad GFX) y la Cache LLC de la que hablamos en la entrada y que estaría en el Northbridge/Data Fabric/Uncore de la GPU sería la Cache L3 pero hay que tener en cuenta que dicha Cache L4 de la CPU y la Cache L3 en cuanto a la GPU se trataría de la misma cache y de ahí a llamarla Last Level Cache porque es la cache de último nivel para el SoC en común, de esta manera pues es mucho más claro.

Hay que tener en cuenta que la velocidad de resolución de toda instrucción depende del tiempo en que tarde en realizarse y el mayor cuello de botella es la memoria con la que existe un enorme abismo que ha habido que sortear utilizando la jerarquía de caches para ello. La idea de las caches es que estas almacenan datos cercanos al código que actualmente se esta ejecutando, si no lo encuentran en la primera área de la cache en la jerarquía entonces saltan a la siguiente que es más densa hasta legar al final de la jerarquía de memoria. Cada nuevo nivel en la jerarquía de memoria:

  • Tiene un ancho de banda inferior al nivel anterior pero mejor que el nivel posterior.
  • Tiene una latencia mayor que el nivel anterior porque se le suman todos los tiempos de búsqueda en los niveles anteriores de la jerarquía y los cache miss que se dan cuando no se encuentra un dato en un nivel y se ha de dar el salto
  • Tiene una densidad de almacenamiento mayor que la suma de todas las caches del nivel anterior pero inferior a la del nivel posterior.

Si hablamos de un SoC donde hay una GPU, sería bueno recordar lo que escribí hace unos días y perdón por repetirme con dicha entrada pero es esencial para entender ciertas cosas a futuro, especialmente en lo que a PC se refiere.

A nivel de la GPU, esta tendría su propia jerarquía de caches donde cada nivel delimita cada uno de los conjuntos de la misma pero en el nuevo paradigma desde la visión de la GPU no sería la Cache incluida en el Conjunto C (actualmente la Cache L2 de la GPU) sino la cache en el Conjunto D que en un SoC sería el Northbridge/Uncore/Data Fabric compartido con la CPU en el SoC. De cara al rumor de la división de la GPU en dos partes, la unida GFX (Chiplet GPU) erían los conjuntos C(B(A)) y el MCD en conjunto D que sería el Northbridge/Uncore/Data Fabric común.

En lo primero que vamos a ver esta Cache LLC no va a ser en los SoC heterogéneos sino en CPUs y es muy probable que lo veamos en AMD Milan por primera vez, el cual es el sucesor del AMD Rome que se basará en Zen 3 en vez de Zen 2.

La Cache LLC (L4 en la patente) estaría dentro del chip central más grande (IO Die) que incluye el Northbridge y el Southbridge de todo el procesador. Tenemos unos 16MB por chiplet de la CPU, esto hacen un total de 128MB de Cache L3 por lo que la Cache L4 o LLC tendrá que ser en ese caso como mínimo de 256MB. A nivel de un equivalente en Rome donde solo se tienen unos 2 Chiplets entonces la LLC sería de 64MB y en el caso de los SoC donde la cache L3 es menor la LLC sería también menor pero se ha de tener en cuenta que en ese caso se tiene que tener en cuenta también la cache de la GPU.

¿Parece todo muy bonito no? Nos olvidamos que CPU y GPU acceden a la memoria de diferente manera y debido a que la GPU es tolerante a la latencia pero consume una cantidad ingente de ancho de banda acaba por consumir una gran cantidad del ancho de banda y el espacio de la LLC dejando a la CPU en una situación de desventaja, la cual no pide grandes cantidades de datos sino que los datos lleguen lo suficientemente rápido (latencia) por lo que la solución pasa en darle preferencia a la CPU a la hora de acceder a una parte de los datos en la Cache LLC o simplemente privatizar parte de la misma para accesos solo para la CPU.

¿Pero que ventajas tiene esto? Actualmente las GPU evitan tocar la RAM externa por temas de consumo y trabajan sobre la Cache L2, esto lo hacen haciendo uso del Tile Caching/DSBR pero la contrapartida de hacerlo sobre una cache es que esta no es controlada por el programa y los datos pueden acabar cayendo en el nivel inferior que es la RAM. Pero claro, con la LLC estos datos caerían sobre esta y no en la RAM, obviamente sigue siendo una cache y existe el problema de otro volcado en la RAM pero mucho menor. Pero especialmente esto significa que la mayoría de las operaciones no se solventarán en la RAM sino en una memoria donde las operaciones sobre la misma son de menos pj/bit y por tanto esto en contrapartida permite escalar mejor la GPU en cuanto a la cantidad de núcleos y la velocidad de reloj de estos.

Hay dos factores que marcan muy bien el rendimiento máximo de un núcleo:

  • La capacidad de cálcuilo de sus ALUs
  • El ancho de banda que tiene disponible para realizar dichas operaciones así como la latencia de la misma.

Actualmente el problema principal esta en la memoria y no en la capacidad de cálculo. El coste de realizar una operación en un registro es sumamente barato, pero el coste energético de trasladar los datos hacía el registro es sumamente caro energéticamente hablando, lo idea seria tener la memoria pegada al núcleo como si fuese una cache gigantesca pero por limitaciones físicas no se puede hacer eso. La motivación detrás de la LLC no es otra que llevar una mayor cantidad de memoria al núcleo posible con tal no solo de abaratar el coste energético de las instrucciones sino permitir que estas se puedan solventar más rápido por la menor latencia y creedme que es un truco tan viejo como efectivo pero especialmente lo veo como un truco para poder aumentar la velocidad de reloj media en futuros nodos.

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

5 3 votes
Article Rating
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
IntelCeleronMasterRace

Puede volver un diseño con Cache L4 como el de los Intel Core i5/i7 5xxx? Tienen un rendimiento por nucleo BRUTAL, superando a un Zen 2.

Un Ryzen r9 5/6950x a 5nm (pensando en ddr5) con una jugosa cache L4 o LLC seria….un salto de infarto.