Ciclos / costo para hit Caché L1 vs. Registro en x86?

Recuerdo haber asumido que un golpe de caché L1 es 1 ciclo (es decir, idéntico al tiempo de acceso de registro) en mi clase de arquitectura, pero ¿es realmente cierto en los procesadores x86 modernos?

¿Cuántos ciclos toma un golpe de caché L1? ¿Cómo se compara con el acceso de registro?

Author: artless noise, 2012-04-23
Source

4 answers

Aquí hay un gran artículo sobre el tema:

Http://arstechnica.com/gadgets/reviews/2002/07/caching.ars/1

Para responder a su pregunta - sí, un golpe de caché tiene aproximadamente el mismo costo que un acceso de registro. Y por supuesto un cache miss es bastante costoso;)

PS:

Los detalles variarán, pero este enlace tiene algunas buenas cifras:

Costo aproximado para acceder a varios cachés y principales la memoria?

Core i7 Xeon 5500 Series Data Source Latency (approximate)
L1 CACHE hit, ~4 cycles
L2 CACHE hit, ~10 cycles
L3 CACHE hit, line unshared ~40 cycles
L3 CACHE hit, shared line in another core ~65 cycles
L3 CACHE hit, modified in another core ~75 cycles remote
L3 CACHE ~100-300 cycles
Local DRAM ~30 ns (~120 cycles)
Remote DRAM ~100 ns

PPS:

Estas cifras representan mucho CPU más antiguas y lentas, pero las proporciones básicamente se mantienen:

Http://arstechnica.com/gadgets/reviews/2002/07/caching.ars/2

Level                    Access Time  Typical Size  Technology    Managed By
-----                    -----------  ------------  ---------     -----------
Registers                1-3 ns       ?1 KB          Custom CMOS  Compiler
Level 1 Cache (on-chip)  2-8 ns       8 KB-128 KB    SRAM         Hardware
Level 2 Cache (off-chip) 5-12 ns      0.5 MB - 8 MB  SRAM         Hardware
Main Memory              10-60 ns     64 MB - 1 GB   DRAM         Operating System
Hard Disk                3M - 10M ns  20 - 100 GB    Magnetic     Operating System/User
 32
Author: paulsm4,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:34:32

Para más detalles sobre el conteo de ciclos y la ejecución fuera de orden, vea El microarch pdf de Agner Fog, y otros enlaces en el wiki de etiquetas x86.

La latencia de uso de carga L1 de Intel Haswell es de 4 ciclos, lo que es típico de las CPU x86 modernas. es decir, qué tan rápido mov eax, [eax] puede ejecutarse en un bucle, con un puntero que apunta a sí mismo. (O a una pequeña lista enlazada de bucle cerrado).

La latencia de uso de carga es 1 ciclo mayor para vectores SSE / AVX en Intel CPU.

La latencia de recarga de la tienda es de 5 ciclos, y no está relacionada con el éxito o error de la caché (es el reenvío de la tienda, no la caché L1).

Como Harold comentó, el acceso al registro es 0 ciclos. Así, por ejemplo:

  • {[1] } tiene latencia de 1 ciclo (solo la operación ALU)
  • inc dword [mem] tiene una latencia de 6 ciclos hasta que una carga de dword [mem] esté lista. (ALU + store-forwarding). por ejemplo, mantener un contador de bucle en la memoria limita un bucle a una iteración por 6 ciclos.
  • mov rax, [rsi] tiene latencia de 4 ciclos desde rsi estar listo hasta rax estar listo en un golpe L1 (latencia de uso de carga L1.)

Http://www.7-cpu.com/cpu/Haswell.html tiene una tabla de latencia por caché (que copiaré aquí), y algunos otros números experimentales, incluida la latencia de éxito L2-TLB (en un error L1DTLB).

Intel i7-4770 (Haswell), 3.4 GHz (Turbo Boost apagado), 22 nm. RAM: 32 GB (PC3-12800 cl11 cr2).

  • Caché de datos L1 = 32 KB, 64 B/línea, 8-WAY.
  • Caché de instrucciones L1 = 32 KB, 64 B/línea, 8 VÍAS.
  • Caché L2 = 256 KB, 64 B/línea, 8 VÍAS

  • Caché L3 = 8 MB, 64 B/línea

  • Latencia de caché de datos L1 = 4 ciclos para un acceso sencillo a través del puntero (mov rax, [rax])

  • Latencia de caché de datos L1 = 5 ciclos para el acceso con cálculo de direcciones complejas (mov rax, [rsi + rax*8]).
  • Latencia de caché L2 = 12 ciclos
  • Latencia de caché L3 = 36 ciclos
  • Latencia RAM = 36 ciclos + 57 ns

La página de referencia de nivel superior es http://www.7-cpu.com/utils.html , pero todavía no explica lo que significan los diferentes tamaños de prueba, pero el código está disponible. Los resultados de la prueba incluyen Skylake , que es casi el mismo que Haswell en esta prueba.

La respuesta de@paulsm4 tiene una tabla para un Nehalem Xeon multi-socket, incluyendo algunos números de memoria / L3 remotos (otros sockets).

 4
Author: Peter Cordes,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:17:58

Si recuerdo correctamente, se trata de 1-2 ciclos de reloj, pero esto es una estimación y las cachés más nuevas pueden ser más rápidas. Esto es de un libro de arquitectura de computadora que tengo y esta es información para AMD, por lo que Intel puede ser ligeramente diferente, pero lo enlazaría entre 5 y 15 ciclos de reloj, lo que me parece una buena estimación.

EDITAR: Whoops L2 es 10 ciclos con acceso de ETIQUETA, L1 toma 1 a dos ciclos, mi error: \

 1
Author: Jesus Ramos,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-23 03:15:28

En realidad, el costo de la visita a la caché L1 es casi el mismo que el costo del acceso al registro. Fue sorprendente para mí, pero esto es cierto, al menos para mi procesador (Athlon 64). Hace algún tiempo escribí una aplicación de prueba simple para comparar la eficiencia del acceso a los datos compartidos en un sistema multiprocesador. El cuerpo de la aplicación es una variable de memoria simple que se incrementa durante el período de tiempo predefinido. Para hacer un comapison, al principio comparé la variable no compartida. Y durante esa actividad Capturé el resultado, pero luego, durante el desensamblado de la aplicación, descubrí que el compilador engañó mis expectativas y aplicó una optimización no deseada a mi código. Se acaba de poner variable en el registro de la CPU y aumentar iterativetly en el registro sin acceso a la memoria. Pero la verdadera sorpresa fue lograda después de forzar a compliler a usar la variable en memoria en lugar de la variable de registro. En la aplicación actualizada obtuve casi los mismos resultados de benchmarking. La degradación del rendimiento fue realmente negligente (~1-2%) y parece relacionado con algún efecto secundario.

Como resultado:

1) Creo que puede considerar la caché L1 como un grupo de registros de procesador no administrado.

2) No hay ningún sentido para aplicar la optimización brutal assambly forzando el almacenamiento del compilador a acceder con frecuencia a los datos en los registros del procesador. Si realmente se accede con frecuencia, vivirán en la caché L1, y debido a esto tendrán el mismo costo de acceso que el registro del procesador.

 0
Author: ZarathustrA,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-12-05 10:18:53