¿Cómo Volkov y Demmel determinan experimentalmente las latencias, los tamaños de línea y los tamaños de página de una GPU?

En "Factorizaciones LU, QR y Cholesky usando capacidades vectoriales de GPU", de Vasily Volkov y James Demmel , hay una forma interesante de interpretar las latencias, tamaños de línea y tamaños de página de un caché desde un gráfico como este:

Aparentemente, el tamaño de la línea es donde el caché comienza a estabilizarse (aproximadamente 32 bytes en este ejemplo). De donde vino eso?

¿Y cómo sabemos que el tamaño de página es donde comienza la segunda meseta para la memoria global?

Además, ¿por qué las latencias finalmente disminuyen con una longitud de zancada lo suficientemente grande? ¿No deberían seguir aumentando?

Si esto realmente funciona, y parece, sería increíble porque podemos obtener muchos datos indocumentados sobre el caché de una GPU.

Si esto realmente funciona, y parece, sería increíble porque podemos obtener muchos datos indocumentados sobre el caché de una GPU.

Un aspecto frustrante de la investigación en computación de alto rendimiento es excavar a través de todos los conjuntos de instrucciones indocumentadas y las características de la arquitectura al intentar ajustar el código. En HPC, la prueba está en el punto de referencia, ya sea High Performance Linpack o STREAMS. No estoy seguro de que esto sea "asombroso", pero definitivamente es cómo se evalúan y evalúan las unidades de procesamiento de alto rendimiento.

Aparentemente, el tamaño de la línea es donde el caché comienza a estabilizarse (aproximadamente 32 bytes en este ejemplo). De donde vino eso?

Parece estar familiarizado con los conceptos de rendimiento de la jerarquía de caché, descritos como la "montaña de memoria" en Bryant y O'Hallaron's Computer Systems: A Programmer's Perspective , pero su pregunta indica una falta de comprensión profunda de cómo cada nivel de caché en sí mismo trabajos.

Recuerde que un caché contiene "líneas" de datos, es decir, tiras de memoria contigua que están armonizadas con una ubicación de memoria en algún lugar de la tienda principal. Al acceder a la memoria dentro de una línea, tenemos un "hit" de caché, y la latencia asociada con la recuperación de esta memoria se llama latencia para esa caché en particular. Por ejemplo, una latencia de caché L1 de 10 ciclos indica que cada vez que la dirección de memoria solicitada ya está en una de las líneas de caché L1, esperamos recuperarla en 10 ciclos.

Como puede ver en la descripción del puntero que persigue el punto de referencia, toma pasos de una longitud fija a través de la memoria. NB: este punto de referencia NO funcionaría como se esperaba en las muchas CPU modernas que cuentan con unidades de captación previa de "detección de flujo" que no se comportan como cachés simples.

Tiene sentido, entonces, que la primera meseta de rendimiento notable (comenzando desde el paso 1), es un paso que no se reutiliza a partir de errores anteriores de caché. ¿Cuánto tiempo tiene que pasar un paso antes de que pase completamente la línea de caché recuperada anteriormente? ¡La longitud de la línea de caché!

¿Y cómo sabemos que el tamaño de página es donde comienza la segunda meseta para la memoria global?

Del mismo modo, la próxima meseta de ir más allá de la reutilización será cuando la página de memoria administrada por el sistema operativo tenga que intercambiarse con cada acceso a la memoria. El tamaño de la página de memoria, a diferencia del tamaño de la línea de caché, normalmente es un parámetro que el programador puede configurar o administrar.

Además, ¿por qué las latencias finalmente disminuyen con una longitud de zancada lo suficientemente grande? ¿No deberían seguir aumentando?

Esta es definitivamente la parte más interesante de su pregunta, y explica cómo los autores postulan la estructura de la caché (asociatividad y número de conjuntos) en función de la información que obtuvieron previamente (tamaño de las líneas de caché) y el tamaño del conjunto de trabajo de datos que están avanzando. Recuerde de la configuración experimental que los pasos "envuelven" la matriz. Para una zancada lo suficientemente grande, la cantidad total de datos de la matriz que debe mantenerse en la memoria caché (el llamado conjunto de trabajo) es menor porque se omiten más datos de la matriz. Para ilustrar esto, puede imaginar a una persona corriendo continuamente hacia arriba y hacia abajo por un conjunto de escaleras, solo dando cada 4to paso. Esta persona toca menos pasos totales que alguien que toma cada 2 pasos. Esta idea está un tanto torpemente establecida en el artículo:

Cuando la zancada es muy grande, el conjunto de trabajo disminuye hasta que vuelve a encajar en la memoria caché, esta vez produciendo errores si la memoria caché no es completamente asociativa.

Como Bill Barth menciona en su respuesta, los autores declaran cómo hacen estos cálculos en el documento:

Los datos de la Fig. 1 sugieren un TLB de 16 entradas totalmente asociativo (sin sobrecarga de TLB para una matriz de 128 MB, 8 MB de zancada), un caché L1 asociativo de 20 vías (matriz de 20 KB en zancadas de 1 KB en L1) y una de 24 vías establecer caché L2 asociativo (volver a la latencia de hit L2 para una matriz de 768 KB, zancada de 32 KB). Estos son los números efectivos y la implementación real puede ser diferente. Seis cachés L2 asociativos por conjuntos de 4 vías también coinciden con estos datos.

Diría que el párrafo en la página 3 que comienza "Una latencia mayor indica más errores de caché". explica bastante bien lo que estás preguntando.