¿Cómo puede el caché ser tan rápido?

Aquí hay una captura de pantalla de un punto de referencia de caché:

Resultados del banco de pruebas AIDA64 Cache & Memory

En el punto de referencia, la velocidad de lectura de caché L1 es de aproximadamente 186 GB/s, con una latencia de aproximadamente 3-4 ciclos de reloj. ¿Cómo se logra tal velocidad?

Considere la memoria aquí: la velocidad máxima teórica es 665 MHz (frecuencia de memoria) x 2 (velocidad de datos doble) x 64 bits (ancho de bus), que es de aproximadamente 10,6 GB/s, que está más cerca del valor de referencia de 9,6 GB/s .

Pero con la caché L1, incluso si pudiéramos leer en cada ciclo con el procesador a su máxima frecuencia (3 GHz), necesitaríamos alrededor de 496 líneas de datos para lograr tal rendimiento que suena poco realista. Esto también se aplica a otros cachés.

¿Qué me estoy perdiendo? ¿Cómo calculamos el rendimiento de un caché a partir de sus parámetros?

¿Ha considerado cuán pequeña es la memoria caché L1,2,3 e igualmente dónde reside físicamente? Sugerencia, no necesita preocuparse por un estándar de bus si posee todo el chip
¿Eso significa que realmente hay circuitos con buses tan anchos dentro de una CPU?
Si está en el chip, ¿cuál cree que podría ser el límite en el ancho del bus?
Reside físicamente más cerca de donde se ejecutan los datos. Distancias más cortas para que las señales viajen significan tiempos más cortos para que viajen esa distancia. El caché reside en la CPU y no en la placa base, por lo que el bus de la placa base es irrelevante.
Además: ¿El punto de referencia sabe lo suficiente sobre lo que está haciendo para garantizar que algunos datos con los que prueba no se guarden directamente dentro de un registro?
@rackandboneman: AIDA64 es un punto de referencia muy respetado, ¡no algo que alguien simplemente pirateó en C y dejó que el compilador optimizara algunas cargas! Supongo que las piezas de microbenchmark están escritas en ensamblaje, con versiones SSE o AVX.
@Peter Cordes respuesta satisfactoria - a una pregunta necesaria.
@rackandboneman: sí, de acuerdo. También terminé publicando mi propia respuesta a las preguntas del OP .
Usted habla de un "máximo teórico", pero el objetivo de la memoria caché de la CPU es que es un tipo de hardware físicamente diferente , con su propio tipo de transistor, arquitectura de conexión diferente y velocidades de datos.
Solo para poner las ideas en perspectiva física: en 1,4 nanosegundos, la luz viaja alrededor de un pie y medio. Eso significa que si el caché estuviera ubicado en el otro lado de la placa base, una latencia como esa podría romper la relatividad. O ser un error de medición .
bits por segundo ese número tiene perfecto sentido, L1 corre a la velocidad de la cpu, 64 bits de ancho 3ghz estaría ahí, casi exactamente la velocidad esperada, pero si eso son bytes por segundo, no tiene ningún sentido...
también dice que el FSB es de 100 mhz, ¿qué es esto a fines de la década de 1990?
@old_timer: las CPU modernas se ríen de su insignificante idea de cargar solo una palabra de máquina por reloj desde el caché L1D. ¿No has oído hablar de los vectores SIMD? re: FSB: Realmente no hay un FSB en absoluto (el controlador de memoria está integrado; la comunicación entre la CPU y Southbridge ocurre a través de DMI , que se parece mucho a PCIe). El "reloj FSB" es solo un nombre para el reloj base. La CPU ejecuta sus núcleos en un multiplicador de ese reloj (por ejemplo, 34x). Consulte thinkcomputers.org/intel-ivy-bridge-overclocking-guide . Los relojes PCIe también escalan con eso.
si la memoria caché tiene varios puertos seguro o si el bus tiene 512 bits de ancho seguro... pero si no, no puede sacar mucho provecho de él, el diseño digital elemental no tiene nada que ver con el tipo de conjunto de instrucciones de instrucción, etc. ¿Hace un puñado de años FSB era de 800Mhz y ahora es de 100? Es solo una cuestión de terminología. El reloj de referencia es generalmente de 100 MHz y eso se entiende bien, pero cambiar la definición del término en la dirección incorrecta simplemente se ve mal. y sí, con Sandybridge o tal vez justo antes de eso sacaron lo que solía estar fuera de chip, eliminando así ese autobús. bien entendido.
@PeterCordes Debe pensar en el nivel del chip, no en un nivel alto mágico, los transistores son transistores, los bloques sram son bloques sram. La tecnología usa diferentes materiales y puede hacer las cosas más pequeñas, pero digitalmente no puedes leer mágicamente 8 bits diferentes sobre el mismo rastro en la capa de metal en un ciclo de reloj. SIMD no puede hacer que eso suceda, ni nada más que 8 ciclos de reloj más por bit u 8 rastros y 8 bits. Y eso muy bien puede ser lo que está sucediendo, y/o como con la mayoría de los puntos de referencia, son BS, triviales de ajustar para mostrar algún resultado, o en algún punto intermedio.
@old_timer: Mi punto era que sí, los puertos de carga SIMD son más anchos que 64 bits, porque eso es algo útil para gastar transistores/área de matriz/cables. (Y sí, la memoria caché L1D de Intel también tiene varios puertos). Vea mi respuesta para un diagrama de bloques. (Estoy de acuerdo en que "reloj FSB" es un nombre estúpido. Técnicamente se llama BCLK, y la mayoría de las personas que saben de lo que están hablando lo llaman así. Estaba actuando como un lingüista descriptivo, describiendo cómo se usa el término (en mi opinión incorrectamente). por algunos overclockers.)
@old_timer: Presumiblemente, la GUI de AIDA64 todavía funciona en sistemas que realmente tienen un FSB, y eligieron no tener dos conjuntos diferentes de diseños/etiquetas en la GUI.
@PeterCordes, por supuesto, Intel sigue reutilizando nombres como i3, i7, pentium, etc., quizás para crear confusión o quién sabe... Y esto está etiquetado como una prueba de rendimiento de caché, por lo que está ajustado para tal, claramente 497 o más realistamente 512 bits por ciclo que pueden sacar de L1 (de manera sostenida, podría ser 1024 o 2048 u otros bits posibles, pero no pueden sostener eso en promedio por reloj). Números interesantes, pero hay que reducirlos para su uso en el mundo real (como con cualquier punto de referencia).
@old_timer: en realidad son 2x 128 bits por reloj por núcleo en IvB. En una prueba rápida con contadores de rendimiento para ciclos de reloj de núcleo en Skylake, medí 1,9990 cargas de 256b por reloj de núcleo en un bucle pequeño. Específicamente, 4001,949414 millones de relojes de núcleo para un programa completo que realizó 8000 millones de cargas. No se pierde el caché L1D porque recargué desde las mismas 2 líneas repetidamente, pero lo escribí en asm para que nada esté optimizado en el software. A menudo, también puede estar muy cerca de mantener el ancho de banda L1D máximo teórico en las CPU Intel en casos menos sintéticos, si evita otros cuellos de botella.

Respuestas (5)

Esta CPU tiene...

2 núcleos Una instrucción de 32 KB y un caché de primer nivel de datos de 32 KB (L1) para cada núcleo

Dado que hay dos núcleos, podemos esperar que el punto de referencia ejecute dos subprocesos en paralelo. Sin embargo, su sitio web brinda muy poca información, pero si miramos aquí , las CPU con más núcleos parecen brindar rendimientos L1 correspondientemente más altos. Así que creo que lo que se muestra es el rendimiento total con todos los núcleos trabajando en paralelo. Entonces, para su CPU, debemos dividir por dos para un núcleo y un caché:

Read   93 GB/s
Write  47 GB/s
Copy   90 GB/s

Ahora, el hecho de que "copiar" sea 2 veces más rápido que "escribir" es muy sospechoso. ¿Cómo podría copiar más rápido de lo que puede escribir? Apuesto a que lo que muestra el punto de referencia como "copiar" es la suma del rendimiento de lectura y escritura, y en este caso leería y escribiría a 45 GB/s, pero mostraría 90, porque es un punto de referencia, y ¿Quién diablos confía en los puntos de referencia? Así que ignoremos la "copia".

Read   93 GB/s => 30 bytes/clock
Write  47 GB/s => 15 bytes/clock

Ahora, un registro de 128 bits tiene 16 bytes, lo suficientemente cerca, por lo que parece que este caché puede hacer dos lecturas de 128 bits y una escritura por reloj.

Esto es exactamente lo que le gustaría optimizar realmente esas instrucciones de procesamiento de números SSE: dos lecturas y una escritura por ciclo.

Lo más probable es que esto se implemente con muchas líneas de datos paralelas, que es la forma habitual de transportar muchos datos muy rápido dentro de un chip.

En la página 55 del documento @next-hack se vincula a él dice "Internamente, los accesos son de hasta 16 bytes. [...] Se pueden manejar dos operaciones de carga y una operación de almacenamiento en cada ciclo". Eso explica por qué la lectura es dos veces más rápida: puede hacer dos lecturas en la misma operación mientras también hace una escritura.
Sí, básicamente los ingenieros de Intel saben lo que están haciendo. Hacerlo más rápido que eso sería una pérdida de recursos...
Sí, claramente está contando copia BW = leer y escribir. Eso parece tan válido como la alternativa, ya que es importante que las lecturas y las escrituras se puedan ejecutar en paralelo. Tenga en cuenta que los números de OP para L2/L3 tienen una copia no mucho más alta que la escritura y más baja para la memoria. El bus de memoria DDR3 no es full-duplex: se necesitan las mismas líneas de datos para lectura y escritura. (Para obtener más información sobre el ancho de banda x86 memcpy/memset con tiendas NT frente a tiendas normales, consulte stackoverflow.com/questions/43343231/… ).
Supone que IvyBridge puede hacer 2 lecturas y 1 escritura en el mismo ciclo de reloj. Tienes razón, pero solo en circunstancias muy limitadas. IvB solo tiene 2 puertos AGU, por lo que normalmente está limitado a 2 operaciones de memoria por reloj, hasta una de las cuales puede ser una tienda . Pero las cargas/almacenamiento 256b AVX tardan 2 ciclos en ejecutarse en los puertos de carga/almacenamiento, mientras que solo necesitan la AGU en el primer ciclo. Entonces, una uop de dirección de tienda puede ejecutarse en el puerto 2/3 durante ese segundo ciclo de una carga de 256b sin costar ancho de banda de carga. (Uops de almacenamiento de datos se ejecutan en el puerto 4.) Fuente: agner.org/optimize microarch pdf
Una CPU AMD Bulldozer-family o Ryzen le daría los mismos números de lectura = 2x de escritura, pero en realidad están limitados a 2 operaciones de memoria por reloj (hasta una puede ser una escritura) sin lagunas. leer/escribir/copiar no detecta la diferencia, pero Triad sí puede ( a[i] = b[i] + c[i]). Por cierto, Intel Haswell y versiones posteriores tienen una AGU de almacenamiento en el puerto 7 que puede manejar modos de direccionamiento simples (no indexados), por lo que pueden ejecutar 2 operaciones de carga + 1 de almacenamiento por reloj. (Y la ruta de datos a L1D es 256b, por lo que duplica el ancho de banda de L1D). Consulte el artículo de David Kanter: realworldtech.com/haswell-cpu/5
Escribí una respuesta , ya que no he visto a nadie hablar sobre la latencia L1D, solo el ancho de banda.
@PeterCordes, "No he visto a nadie hablar sobre la latencia L1D"... Hmm... ¿Tal vez porque nadie preguntó?
@AliChen: El OP mencionó explícitamente la latencia de uso de carga de 4 ciclos de IvyBridge justo después del ancho de banda, antes de preguntar cómo puede ser tan rápido.

La respuesta de @peufeu señala que estos son anchos de banda agregados en todo el sistema. L1 y L2 son cachés privados por núcleo en la familia Intel Sandybridge, por lo que los números son el doble de lo que puede hacer un solo núcleo. Pero eso aún nos deja con un ancho de banda impresionantemente alto y una baja latencia.

La memoria caché L1D está integrada directamente en el núcleo de la CPU y está muy estrechamente acoplada con las unidades de ejecución de carga (y el búfer de almacenamiento) . De manera similar, el caché L1I está justo al lado de la parte del núcleo para obtener/decodificar instrucciones. (De hecho, no he mirado un plano de planta de silicio de Sandybridge, por lo que esto podría no ser literalmente cierto. La parte de problema / cambio de nombre del front-end probablemente esté más cerca del caché uop decodificado "L0", que ahorra energía y tiene un mejor ancho de banda que los decodificadores.)

Pero con caché L1, incluso si pudiéramos leer en cada ciclo...

¿Por qué detenerse allí? Intel desde Sandybridge y AMD desde K8 pueden ejecutar 2 cargas por ciclo. Los cachés multipuerto y los TLB son una cosa.

La descripción de la microarquitectura Sandybridge de David Kanter tiene un buen diagrama (que también se aplica a su CPU IvyBridge):

(El "programador unificado" mantiene ALU y uops de memoria esperando que sus entradas estén listas y/o esperando su puerto vmovdqa ymm0, [rdi]de rdiejecución add rdi,32. ejemplo). Intel programa uops a puertos en el momento de emisión/cambio de nombre . Este diagrama solo muestra los puertos de ejecución para uops de memoria, pero las uops de ALU no ejecutadas también compiten por él. La etapa de emisión/cambio de nombre agrega uops al ROB y al planificador Permanecen en el ROB hasta el retiro, pero en el programador solo hasta que se envían a un puerto de ejecución (esta es la terminología de Intel; otras personas usan emitir y enviar de manera diferente)). AMD usa programadores separados para enteros/FP, pero los modos de direccionamiento siempre usan registros de enteros

Diagrama de memoria SnB de David Kanter

Como muestra, solo hay 2 puertos AGU (unidades de generación de direcciones, que toman un modo de direccionamiento similar [rdi + rdx*4 + 1024]y producen una dirección lineal). Puede ejecutar 2 operaciones de memoria por reloj (de 128b / 16 bytes cada una), hasta que una de ellas sea un almacén.

Pero tiene un truco bajo la manga: SnB/IvB ejecuta cargas/almacenamientos AVX de 256b como un único uop que requiere 2 ciclos en un puerto de carga/almacenamiento, pero solo necesita la AGU en el primer ciclo. Eso permite que una uop de dirección de tienda se ejecute en la AGU en el puerto 2/3 durante ese segundo ciclo sin perder el rendimiento de la carga. Entonces, con AVX (que las CPU Intel Pentium/Celeron no admiten :/), SnB/IvB puede (en teoría) soportar 2 cargas y 1 almacenamiento por ciclo.

Su CPU IvyBridge es la versión reducida de Sandybridge (con algunas mejoras en la microarquitectura, como mov-elimination , ERMSB (memcpy/memset) y búsqueda previa de hardware de página siguiente). La generación posterior (Haswell) duplicó el ancho de banda L1D por reloj al ampliar las rutas de datos de las unidades de ejecución a L1 de 128b a 256b para que las cargas AVX 256b puedan sostener 2 por reloj. También agregó un puerto AGU de almacenamiento adicional para modos de direccionamiento simples.

El rendimiento máximo de Haswell/Skylake es de 96 bytes cargados + almacenados por reloj, pero el manual de optimización de Intel sugiere que el rendimiento promedio sostenido de Skylake (todavía suponiendo que no haya fallas de L1D o TLB) es de ~81B por ciclo. (Un bucle entero escalar puede soportar 2 cargas + 1 tienda por reloj de acuerdo con mis pruebas en SKL, ejecutando 7 uops (dominio no fusionado) por reloj a partir de 4 uops de dominio fusionado. Pero se ralentiza un poco con operandos de 64 bits en lugar de 32 bits, por lo que aparentemente hay un límite de recursos de microarquitectura y no se trata solo de programar uops de direcciones de tiendas en el puerto 2/3 y robar ciclos de cargas).

¿Cómo calculamos el rendimiento de un caché a partir de sus parámetros?

No puede, a menos que los parámetros incluyan cifras prácticas de rendimiento. Como se señaló anteriormente, incluso el L1D de Skylake no puede mantenerse al día con sus unidades de ejecución de carga/almacenamiento para vectores 256b. Aunque está cerca, y puede serlo para enteros de 32 bits. (No tendría sentido tener más unidades de carga que los puertos de lectura de la memoria caché, o viceversa. Simplemente omitiría el hardware que nunca podría utilizarse por completo. Tenga en cuenta que L1D podría tener puertos adicionales para enviar/recibir líneas a /desde otros núcleos, así como para lecturas/escrituras desde dentro del núcleo).

Solo mirar los anchos de bus de datos y los relojes no le da toda la historia. El ancho de banda L2 y L3 (y la memoria) puede estar limitado por la cantidad de fallas pendientes que L1 o L2 pueden rastrear . El ancho de banda no puede exceder la latencia * max_concurrency, y los chips con latencia L3 más alta (como un Xeon de muchos núcleos) tienen mucho menos ancho de banda L3 de un solo núcleo que una CPU de dos o cuatro núcleos de la misma microarquitectura. Consulte la sección "plataformas con límite de latencia" de esta respuesta SO . Las CPU de la familia Sandybridge tienen 10 búferes de relleno de línea para realizar un seguimiento de los errores L1D (también utilizados por las tiendas NT).

(El ancho de banda L3/memoria agregado con muchos núcleos activos es enorme en un Xeon grande, pero el código de subproceso único ve un ancho de banda peor que en un núcleo cuádruple a la misma velocidad de reloj porque más núcleos significan más paradas en el bus de anillo y, por lo tanto, mayor latencia L3.)

latencia de caché

¿Cómo se logra tal velocidad?

La latencia de uso de carga de 4 ciclos de la memoria caché L1D es impresionante, pero solo se aplica al caso especial de persecución de punteros (cuando es más importante) . En otros casos, son 5 ciclos, lo que sigue siendo impresionante teniendo en cuenta que tiene que comenzar con un modo de direccionamiento como [rsi + rdi * 4 + 32], por lo que tiene que generar la dirección antes incluso de tener una dirección virtual . Luego tiene que traducir eso a físico para verificar las etiquetas de caché en busca de una coincidencia.

(Consulte ¿Existe una penalización cuando base+offset está en una página diferente a la base? para obtener más información sobre el [base + 0-2047]caso especial cuando el baseregistro proviene de una carga anterior; parece que Intel sondea de manera optimista el TLB en función de la basedirección en paralelo con la adición , y tiene que volver a intentar el uop en el puerto de carga si no funciona.Excelente para nodos de lista/árbol con punteros al principio del nodo.

Consulte también el manual de optimización de Intel , sección Sandybridge 2.3.5.2 L1 DCache. Esto también supone que no se anula ningún segmento y que la dirección base del segmento 0es , lo cual es normal; esos podrían hacerlo peor que 5 ciclos)

El puerto de carga también tiene que sondear el búfer de la tienda para ver si la carga se superpone con las tiendas anteriores. Y tiene que resolver esto incluso si una uop de dirección de tienda anterior (en el orden del programa) aún no se ha ejecutado, por lo que la dirección de la tienda no se conoce (en ese caso, se predice dinámicamente; los errores de predicción causan bombas nucleares en la canalización del orden de la memoria) ). Pero, presumiblemente, esto puede suceder en paralelo con la verificación de un golpe L1D. Si resulta que los datos L1D no eran necesarios porque el reenvío de almacenamiento puede proporcionar los datos del búfer de almacenamiento, entonces no hay pérdida.

Intel usa cachés VIPT (Virtualmente indexadas físicamente etiquetadas) como casi todos los demás, utilizando el truco estándar de tener el caché lo suficientemente pequeño y con una asociatividad lo suficientemente alta como para que se comporte como un caché PIPT (sin alias) con la velocidad de VIPT (puede indexar en paralelo con la búsqueda TLB virtual->física).

Los cachés L1 de Intel son de 32 kiB, asociativos de 8 vías. El tamaño de la página es de 4kiB. Esto significa que los bits de "índice" (que seleccionan qué conjunto de 8 formas pueden almacenar en caché cualquier línea dada) están todos debajo del desplazamiento de página; es decir, esos bits de dirección son el desplazamiento en una página y siempre son los mismos en la dirección virtual y física.

Para obtener más detalles sobre eso y otros detalles de por qué los cachés pequeños/rápidos son útiles/posibles (y funcionan bien cuando se combinan con cachés más grandes y lentos), consulte mi respuesta sobre por qué L1D es más pequeño/más rápido que L2 .

Los cachés pequeños pueden hacer cosas que serían demasiado costosas en energía en cachés más grandes, como obtener matrices de datos de un conjunto al mismo tiempo que obtener etiquetas. Entonces, una vez que un comparador encuentra qué etiqueta coincide, solo tiene que muxar una de las ocho líneas de caché de 64 bytes que ya se obtuvieron de SRAM.

(En realidad, no es tan simple: Sandybridge / Ivybridge usan un caché L1D en bancos, con ocho bancos de fragmentos de 16 bytes. Puede tener conflictos entre caché y banco si dos accesos al mismo banco en diferentes líneas de caché intentan ejecutarse en el mismo ciclo. (Hay 8 bancos, por lo que esto puede suceder con direcciones separadas por un múltiplo de 128, es decir, 2 líneas de caché).

IvyBridge tampoco tiene penalización por acceso no alineado siempre que no cruce un límite de línea de caché de 64B. Supongo que determina qué banco (s) buscar en función de los bits de dirección bajos, y configura cualquier cambio que deba ocurrir para obtener los 1 a 16 bytes de datos correctos.

En las divisiones de línea de caché, sigue siendo solo un único uop, pero tiene múltiples accesos a caché. La penalización sigue siendo pequeña, excepto en divisiones de 4k. Skylake hace que incluso las divisiones de 4k sean bastante económicas, con una latencia de aproximadamente 11 ciclos, lo mismo que una división de línea de caché normal con un modo de direccionamiento complejo. Pero el rendimiento de 4k-split es significativamente peor que cl-split non-split.

Fuentes :

¡Eso es muy claro, exhaustivo y bien escrito! +1!

En las CPU modernas, la memoria caché se encuentra justo al lado de la CPU en el mismo troquel (chip) , está hecha con SRAM , que es mucho, mucho más rápida que la DRAM que se usa para los módulos de RAM en una PC.

Por unidad de memoria (un bit o un byte), la SRAM es mucho más cara que la DRAM. Es por eso que DRAM también se usa en una PC.

Pero como la SRAM está hecha con la misma tecnología que la propia CPU, es tan rápida como la CPU. Además, solo hay buses internos (en la CPU) con los que lidiar, por lo que si necesita ser un bus de 496 líneas de ancho, entonces probablemente lo sea.

Gracias por tu interés. He visto en algunos libros que las velocidades de acceso al registro superan los 300 GB/s, en cuyo caso, para un procesador de 3 GHz, el rendimiento del registro es de 100 B/ciclo, lo que no es posible ya que los registros suelen tener un ancho de 64/128 bits. no podían producir tanto. Esto es lo que me preocupa. Es GB/sa la forma correcta de expresar el rendimiento.
@Knight tenga en cuenta que IvB (como cualquier procesador de alto rendimiento) ejecuta varias instrucciones por ciclo, como 3 operaciones ALU, 2 cargas y 1 almacenamiento. La mayoría de estos pueden tomar 2 entradas (incluso cargas, para direccionamiento indexado) y la carga incluso toma 3. Son 13 registros de 8 bytes cada uno, 104 bytes (podría haber sido el caso de que una combinación tan épica no esté permitida, pero no no hay indicación de que ese sea el caso de IvB, aunque no se puede sostener). Si también considera los registros vectoriales, ese número aumenta aún más.
@harold: relacionado: Haswell y Skylake parecen tener límites en las lecturas de registro por reloj, aunque eso puede estar en el front-end y no afecta una ráfaga de ejecución después de que algunas entradas estén listas. Tal vez sea algún otro límite microarquitectónico, pero encontré cuellos de botella en el código que deberían poder soportar más operaciones por reloj. agner.org/optimize/blog/read.php?i=415#852 . En Haswell, en el mejor de los casos, lee ~6,5 registros enteros por ciclo de reloj (sostenido). También logré obtener 7 uops sostenidos por despacho/ejecución de reloj en Skylake (las tiendas son dirección de tienda + datos de tienda).
@PeterCordes, ese debe ser el front-end, ¿verdad? IIRC ese también fue el problema históricamente (PPro a Core2) y no estoy seguro de cómo los números fraccionarios tienen sentido de otra manera. Aunque mis números estaban un poco apagados de todos modos
@harold: sí, estoy bastante seguro de que es un cuello de botella de algún tipo, probablemente en el cambio de nombre. El cuello de botella de lectura de registro de P6 estaba en registros "fríos" que tenían que leerse del archivo de registro permanente en el ROB en cuestión. Los registros modificados recientemente todavía estaban en el ROB y no había ningún cuello de botella en eso. No investigué mucho con registros fríos vs. calientes en HSW/SKL, ya que por alguna razón no pensé en hacer mi ciclo más grande que 4 uops/idealmente 1c por iteración. ups. IDK cuánta diferencia hay entre el reenvío y las lecturas de PRF (que tienen que ocurrir en el momento de la ejecución, no en el momento de la emisión/cambio de nombre).
@Knight: su CPU tiene AVX deshabilitado, pero en IvyBridge con AVX, los registros tienen un ancho de 256b. Muchas instrucciones vectoriales leen dos y escriben 1, e IvB puede ejecutar 3 instrucciones ALU vectoriales por reloj. (3 GHz * 3 * 32B = 288 GB/s). (La cuarta entrada por reloj podría ser un movimiento reg-reg eliminado por cambio de nombre, o una carga o almacenamiento de 256 cada dos relojes). Podrías medir esto en GB/s, pero eso es una tontería. En ese punto, debe contar uops por reloj y, en general, tratar de minimizar el recuento de uop/instrucciones al optimizar. Contar GB/s hace que una instrucción entera parezca "peor" que una instrucción vectorial.

Las cachés L1 son estructuras de memoria bastante amplias. La arquitectura de las cachés L1 en los procesadores Intel se puede encontrar en este manual (proporcionado por next-hack). Sin embargo, la interpretación de algunos parámetros es incorrecta, el "tamaño de línea de caché" no es el "ancho de datos", es el tamaño del bloque en serie de acceso a datos atómicos.

La Tabla 2-17 (sección 2.3.5.1) indica que en cargas (lecturas), el ancho de banda de caché es 2x16 = 32 Bytes por núcleo por CICLO . Esto solo proporciona un ancho de banda teórico de 96 Gb/s en un núcleo de 3 GHz. No está claro qué informa el punto de referencia citado, parece que mide dos núcleos trabajando en paralelo, por lo que genera 192 Gbps para dos núcleos.

¿Los retrasos en la puerta son qué? 10 picosegundos? Los tiempos de ciclo para todas las operaciones canalizadas son de 333 picosegundos, con varias actividades de decodificación y de bus y captura de datos de flip-flop antes de que comience el siguiente ciclo de reloj.

Espero que la actividad más lenta en la lectura de un caché sea esperar a que las líneas de datos se separen lo suficiente (probablemente sean diferenciales: una referencia y una carga real del bit de lectura) para que se pueda sincronizar un comparador/bloqueo para implementar un positivo- acción de retroalimentación para convertir un pequeño voltaje en una gran oscilación de voltaje de nivel lógico de riel a riel (alrededor de 1 voltio).

Tenga en cuenta que la latencia L1D de 4 ciclos incluye la generación de direcciones (para modos de direccionamiento simples de [reg + 0-2047]), una búsqueda de TLB y una comparación de etiquetas (asociación de 8 vías), y colocar los hasta 16 bytes no alineados resultantes en el puerto de salida de la unidad de carga, para reenvío a otras unidades de ejecución. Es una latencia de 4c para un bucle de persecución de puntero como mov rax, [rax].
¿Cómo puede el caché ser tan rápido?
RespuestasAquíPolítica de privacidad1y, 0v