Esta patente reciente de AMD es realmente interesante y puede tener mucho que ver con el hardware de siguiente generación. El resumen introductorio de la misma dice lo siguiente:

Una unidad de procesamiento incluye una pluralidad de elementos de procesamiento y una o más caches. Un primer hilo ejecuta un programa que incluye una o más instrucciones de prebúsqueda para prebúscar la información en la primera cache.

La prebúsqueda es selectivamente activada cuando e ejecuta el primer hilo en el primer elemento de procesamiento dependiente sobre si uno o más subprocesos ejecutaron previamente el programa en el primer elemento de procesamiento. El primer hilo es entotonces enviado a ser ejecutado en el primer elemento de procesamiento. En algunos casos, el «el lanzador» recibe el primer hilo para enviar al primer elemento de procesamiento. El lanzador modifica la instrucción de prebúsqueda en repsuesta a uno o más hilos secundarios habíendo sido previamente ejecutados.

En estos momentos debéis estar…

La prebúsqueda de instrucciones es una técnica utilizada en los procesadores para acelerar la ejecución de lo programas reduciendo los tiempos de espera. La prebusqueda se da cuando un procesador requiere una instrucción o un bloque de datos desde la memoria principal antes de que sea necesaria. La prebúsqueda es llamada prefetching en inglés, ahora bien, acordáos de lo que os cite hace unos días por la presentación del RDNA en mi entrada especulatoria, concretamente en los drivers del mismo.

En GFX10 la I$ (Cache de instrucciones) esta compuesta por lineas de cache de 4×64 bytes.

Por defecto, el prefetcher mantiene una sola linea de cache detrás y lee dos por adelantado.

GFX10 es RDNA/Navi, tened en cuenta que en una GPU se envian datos o instrucciones+datos (kernels o hilos, dependiendo como los queráis llamar). ¿Como se que la patente es sobre una GPU y no sobre una CPU? Pues porque lo dice la misma patente más adelante, precisamente en la descripción:

Las unidades de procesamiento multi-hilo (como las unidades de procesamiento gráfico, GPU) tipicamente implementan múltiples elementos de procesamiento (o núcleos de proesamiento) que concurremntemente ejecutan múltiples instancias de un solo programa en multiples conjuntos de datos. Las instancias son referridad como hilos u olas. Varias olas ion enviadas a cada elemento de procesamiento en una unidad de procesamiento multihilo y una unidad de procesamiento puede incluir ciertos de elementos de procesamiento de tal manera que miles de olas se ejecuten concurrentemente en la unidad de procesamiento. A medida que las olas se ejecutan, las instrucciones o los datos son tomadas de la memoria para ser utilizada por los elementos de procesamiento. Las instrucciones o los datos más frecuentemente utilizados pueden ser almacenadas en una jeraquía de cache asociada con la unidad de procesamiento. Por ejemplo una GPU puede implementar una jerarquia de cache con una cache (L0) privada para cada elemento de procesamiento, una cache (L1) en grupo que es compartido por un subgrupo de elementos de procesamiento y una cache L2 que es compartida por todos los elementos de procesamiento en la GPU.

Las instrucciones o los datos son tomados (o buscados) desde la memoria a través de la jerarquía de cache. Por ejemplo, un elemento de procesamiento puede acceder a una instrucción dede su cache L0. Si la petición a la cache falla, la petición es enviada a la cache L1 y así sucesivamente hasta que la instrucción es exitosamente localizada en la jerarquía de la cache de la memoria.

La descripción no solamente nos habla de que estamos hablando de una GPU, sino que el concepto de la cache L1 en un grupo de elementos de procesamiento coincide con la descripción de la cache L1 de instrucciones de la arquitectura GCN donde la cache L1 de instrucciones se encuentra compartida por varias Compute Units (Processing Elements en la patente).

Como os comente hace unas entradas en las referencias en los drivers de la GFX10/Navi/RDNA la Cache L0 se encuentra en dicha arquitectura dentro de las Compute Units y es la primera en cumplir con estas condiciones por lo que esta claro de que arquitectura habla la patente. Es decir, la patente nos viene a cuasi-confirmar mis sospechas sobre una cache L0 de instrucciones que comente en la entrada anterior de esta serie.

La jerarquía de caches es descrita en la FIG. 2 de la patente y no tiene mucho secreto realmente.

He estado mirando si la arquitectura GCN tiene una unidad de prebúsqueda/prefetch en cualquiera de sus iteraciones incluyendo la más nueva que es Vega. Precisamente en Polaris fue cuando se añadio la prebúsqueda de instrucciones pero no una cache L0 por lo que esto es una mejora de dicho concepto.

En general, AMD afirma que GCN 4 (a través de RX 480) ofrece una mejora del 15% en la eficiencia de los shaders en comparación con GCN 1.1 (R9 290). Esto viene de dos cambios; prebúsqueda de instrucciones y un búfer de instrucciones mayor. En el caso de los primeros, GCN 4 puede, con la asistencia de los drivers r, intentar pre-buscar futuras instrucciones, algo que GCN 1.1 no pudo hacer. Cuando se hace correctamente, esto reduce / elimina la necesidad de que una ola se detenga para esperar una búsqueda de instrucciones,

Lo que ha hecho AMD con GFX10/Navi/RDNA es mejorar precisamente esa parte y llevarla más allá. Recordemos que la cache L0 ha de poder almacenar en su interior un Workgroup entero (1024 elementos) como mínimo como ya comente y que la unidad de prebúsqueda va al menos tres lineas de cache adelantado para realizar la pre-búsqueda de los datos. Pero lo realmente importante en el caso de P55 es que arquitecturalmente pasaremos de GCN 1.1/GFX7 (no, la Pro no es Polaris) a GFX10 por lo que el salto va a ser bastante espectacular, no va a ser solamente el aumento de IPC de GFX10/Navi/RDNA que anunciaron en la Computex.

Sino lo acumulado en la evolución de las GCN hasta entonces…

Saliendo de la patente pero no del todo os voy a explicar el trasfondo general de todo esto para que lo tengáis mucho más claro el contexto de la patente y de las mejoras.

Un termino que esta muy de moda es el término IPC (Instructions per Cycle) en especial porque el marketing lo esta utilizando mucho ahora. La idea simple es que a igualdad de velocidad de reloj (ciclos), el sistema con mayor rendimiento es el que tiene un mayor IPC.

En realidad no es la velocidad de reloj lo que marca el rendimiento de un procesador sino el IPC en combinación con la velocidad de reloj. Pero la cifra que nos marca el marketing es el escenario ideal y el rendimiento va a depender directamente siempre de cada programa que ejecutemos, obviamente los arquitectos de hardware intentan solventar flecos comunes para aumentar el rendimiento de las aplicaciones. ¿El problema de esta definición? Pues basica y llanamente no es lo mismo estar trabajando en n instruccione que sacar n instrucciones por ciclo y el IPC no no indica cuantas instrucciones puede sacar de media un procesador sino en cuentas esta trabajando. No solo eso, sino que los benchmark suelen ser programas comunes para comparar procesadores en escenarios de prueba muy medidos y en condiciones de igualdad pero a veces la naturaleza de estos benchmarks o pruebas de rendimiento resulta favorable a unas arquitecturas y desfavorable a otras.

El método de medición que tiene más autoridad por autonomasía es el CPI (ciclos por instrucción) que nos indica realmente cuantos ciclos de reloj necesita cada instrucción concreta para resolverse. El CPI dependerá de cada tipo de instrucción en concreto y de donde se encuentren los datos, cuanto más alejado de las unidades de ejecución del procesador esten los datos más altos serán los CPI de esa instrucción en concreto y por tanto peor el rendimiento.

La CPU va buscando los datos a través de la jerarqúía de memoria hasta que los encuentra, lo ideal es que este en lo registros pero no siempre es así, precisamente los registros son la única parte en que no se produce un cache miss si no están los datos, tecnicamente cada vez que buscamos un dato en una memoria inferior se añade un tiempo de búsqueda en que el procesador recorre esa memoria hasta que se encuentra el dato y si no se encuentra entonces se salta al nivel inferior pero ese cambio de memoria produce un cache miss que es un tiempo adicional que se suma por cada nivel aparte del tiempo de búsqueda de los datos.

Hay que tener en cuenta que podemos marcar las instrucciones por lo general, y esto es una sobre-simplificación, y respecto a sus datos de la manera siguiente:

  • instrucciones con el dato a procesar y por tanto no requieren búsqueda.
  • instrucciones que contienen la dirección de memoria donde se encuentra el dato.
  • instrucciones que contienen la dirección de memoria donde se encuentra la dirección de memoria donde se encuentra el dato.

Las caches no forman parte del direccionamiento de memoria sino que las microprocesadores tienen un mecanismo de carga que vuelcan los datos que vam a necesitar en los siguientes ciclos en las caches. Siendo la más rápida la que esta fisicamente más cercana a las unidades de ejecución pero al mismo tiempo la más pequeña. Para que lo entendáis, el direccionamiento de los programas tiene en cuenta la RAM que es general para todos los procesadores y no tiene en cuenta las caches porque el tamaño y la jerarquía de caches será diferente en cada arquitectura e incluso entre miembros de una misma arquitectura.

El segundo tipo de atasco es el que se produce cuando la unidad de predicción de saltos no ha hecho bien su trabajo. La unidad de predicción de saltos busca los potenciales cambios en el contador de programa que pueden haber en un futuro y carga los datos relacionado a ese salto en un búfer aparte. Dicho búfer es llamado «Branch Target Buffer» y si este hace bien su trabajo entonces el tiempo de ajuste del procesador en el salto será menor. El problema de este tipo de atascos es que si estamos en una arquitectura in-order son mortales y si encima tienen un pipeline enormemente largo para alcanzar grandes velocidades de reloj entonces el rendimiento…

Este tipo de atascos eran mortales en las CPUs de la anterior generación de consolas porque tenían un pipeline la mar de largo (la ejecución estaba extremadamente segmentada) y eran in-order con una muy mala predicción de saltos.

El tercer tipo de atascos es menos conocido, se produce en sistemas que funcionan en paralelo pero con el mismo pozo de datos. Ocurre cuando un elemento cambio los datos en un determinado punto de la memoria y los otros no tienen constancia, provocando errores o simplemente que el segundo elemento no encuentre el dato. Por este motivo se implementan mecanismos de coherencia de memoria en los sistemas multinúcleo. Obviamente no toda la memoria es un sistema ha de ser coherente y existen zona de la memoria que no necesitan ser accedidos por un tipo de procesador en concreto porque no se espera que sean manipulados por dicho procesador. Esto ocurre en los sistemas heterogéneos como los SoC que incluyen CPU y GPU donde muchas veces ambos comparten memoria física pero no los mismos espacios de memoria.

Esto nos lleva de paso a una de las mejoras en la arquitectura GCN de PC que esta ausente en las consolas que es la capacidad de hacer que la visión de la memoria sea completamente coherente a través de una serie de cambios en la jeraquía de caches, esto no esta descrito en las patentes pero es una forma de evitar atascos/paradas.

En realidad todas las mejoras de la arquitectura GCN que se acabaran acumulando en su versión final y ampliamente mejorada que es GFX10/RDNA/Navi al no haberse dado en consolas desde 2013 arquitecturalmente será un gran salto.

Pe… pero Urian… ¿Cuantos TFLOPS?

Dejad que los ignorantes hablen de TFLOPS cuando lo que hacen es medir la cantidad de operaciones por segundo que no lo mismo que instrucciones. Cada instrucción tiene diferentes longitudes (tiempo en ciclos) según cada arquitectura y es por eso que la comparación en TFLOPS entre diferentes arquitecturas no resulta. Incluso solo hace falta una pequeña mejora en el rendimiento por instrucción para que el tu a tu en FLOPS deje de tener sentido.

Yo ya os comente que el camino no iba a ser el Moar Cores y More FLOPS como van diciendo por ahí, el camino iba a ser seguir el mismo camino que Nvidia a la hora de mejorar la arquitectura y así ha sido. Por eso considero que los hilos de especulación sobre la next gen que hay en Resetera y demás sitio son de una calidad pauperrima a excepción de gente realmente en la industria que suele postear en esos sitios.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.