Encontramos el arreglo a este apuro, o por lo menos eso pensamos. Si continuas con preguntas puedes escribirlo en el apartado de comentarios, que con gusto te responderemos
Solución:
El tamaño de Cache-Lines es (típicamente) de 64 bytes.
Además, échale un vistazo a este interesantísimo artículo sobre cachés de procesadores:
Galería de efectos de caché del procesador
Encontrarás los siguientes capítulos:
- Accesos a la memoria y rendimiento
- Impacto de las líneas de caché
- Tamaños de caché L1 y L2
- Paralelismo a nivel de instrucción
- Asociatividad de caché
- Uso compartido de línea de caché falsa
- Complejidades de hardware
En core i7, los tamaños de línea en L1, L2 y L3 son los mismos: eso es 64 Bytes. Supongo que esto simplifica el mantenimiento de la propiedad inclusiva y la coherencia.
Ver página 10 de: https://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf
La técnica más común para manejar el tamaño del bloque de caché en una jerarquía de caché estrictamente inclusiva es usar bloques de caché del mismo tamaño para todos los niveles de caché para los que se aplica la propiedad de inclusión. Esto da como resultado una mayor sobrecarga de etiquetas que si la caché de nivel superior usara bloques más grandes, lo que no solo usa el área del chip, sino que también puede aumentar la latencia, ya que las cachés de nivel superior generalmente usan acceso por fases (donde las etiquetas se verifican antes de acceder a la parte de datos). Sin embargo, también simplifica un poco el diseño y reduce la capacidad desperdiciada de partes no utilizadas de los datos. No se necesita una gran fracción de fragmentos de 64 bytes no utilizados en bloques de caché de 128 bytes para compensar la penalización de área de una etiqueta adicional de 32 bits. Además, el efecto de bloque de caché más grande de explotar una localidad espacial más amplia puede proporcionarse mediante una captación previa relativamente simple, que tiene la ventaja de que no queda capacidad sin usar si el fragmento cercano no está cargado (para conservar el ancho de banda de la memoria o reducir la latencia en una memoria en conflicto). read) y que la captación previa de adyacencia no necesita limitarse a un fragmento alineado más grande.
Una técnica menos común divide el bloque de caché en sectores. Tener el mismo tamaño de sector que el tamaño de bloque para las memorias caché de nivel inferior evita el problema del exceso de invalidación inversa ya que cada sector en la memoria caché de nivel superior tiene su propio bit válido. (Proporcionar todos los metadatos de estado de coherencia para cada sector en lugar de solo la validez puede evitar el uso excesivo del ancho de banda de reescritura cuando al menos un sector en un bloque no está sucio/modificado y algo de sobrecarga de coherencia [e.g., if one sector is in shared state and another is in the exclusive state, a write to the sector in the exclusive state could involve no coherence traffic—if snoopy rather than directory coherence is used].)
Los ahorros de área de los bloques de caché sectorizados fueron especialmente significativos cuando las etiquetas estaban en el chip del procesador pero los datos estaban fuera del chip. Obviamente, si el almacenamiento de datos ocupa un área comparable al tamaño del chip del procesador (lo que no es irrazonable), entonces las etiquetas de 32 bits con bloques de 64 bytes ocuparían aproximadamente un 16 (~6%) del área del procesador mientras que 128- los bloques de bytes tomarían la mitad. (El POWER6+ de IBM, presentado en 2009, es quizás el procesador más reciente que utiliza etiquetas en el chip del procesador y datos fuera del procesador. Almacenar datos en DRAM integrada de mayor densidad y etiquetas en SRAM de menor densidad, como hizo IBM, exagera este efecto.)
Cabe señalar que Intel utiliza “línea de caché” para referirse a la unidad más pequeña y “sector de caché” para la unidad más grande. (Esta es una de las razones por las que utilicé “bloque de caché” en mi explicación). Usando la terminología de Intel, sería muy inusual que las líneas de caché variaran en tamaño entre los niveles de caché, independientemente de si los niveles eran estrictamente inclusivos, estrictamente exclusivos o utilizados. alguna otra política de inclusión.
(La exclusión estricta generalmente usa el caché de nivel superior como caché de víctima donde los desalojos del caché de nivel inferior se insertan en el caché de nivel superior. Obviamente, si los tamaños de bloque fueran diferentes y no se usara la sectorización, entonces un desalojo requeriría el resto de el bloque más grande para ser leído desde algún lugar y invalidado si está presente en el caché de nivel inferior. [Theoretically, strict exclusion could be used with inflexible cache bypassing where an L1 eviction would bypass L2 and go to L3 and L1/L2 cache misses would only be allocated to either L1 or L2, bypassing L1 for certain accesses. The closest to this being implemented that I am aware of is Itanium’s bypassing of L1 for floating-point accesses; however, if I recall correctly, the L2 was inclusive of L1.])