Memoria Retos de diseño.

Presentación del tema: "Memoria Retos de diseño."— Transcripción de la presentación:

1 Memoria Retos de diseño

2 Fallas de caché Las fallas de caché disminuyen conforme se incrementa la asociatividad. Universidad de Sonora Arquitectura de Computadoras

3 Origen de las fallas Las 3 Cs:
Fallas obligatorias (compulsory misses). Son causadas por el primer acceso a un dato que nunca ha estado en el caché. También llamadas cold-start misses. Fallas de capacidad (capacity misses). Son causadas cuando el caché no puede guardar todos los bloques necesarios para correr un programa. Por ejemplo, necesitar un bloque que acaba de ser reemplazado. Universidad de Sonora Arquitectura de Computadoras

4 Origen de las fallas Fallas de conflicto (conflict misses). Ocurren en cachés de mapeo directo o set associative cuando múltiples bloques compiten por el mismo conjunto. También llamadas fallas de colisión. Universidad de Sonora Arquitectura de Computadoras

5 Origen de las fallas Las fallas de conflicto son 0.0006%
Universidad de Sonora Arquitectura de Computadoras

6 Origen de las fallas Tasa de fallas relativa. Universidad de Sonora
Arquitectura de Computadoras

7 Reto del diseño Tres mejoras: Reducir la tasa de fallas
Reducir el castigo por fallas Reducir el tiempo de éxito Se pueden escoger solo 2 Universidad de Sonora Arquitectura de Computadoras

8 Algoritmos y el caché Un algoritmo puede tener un comportamiento distinto a su comportamiento teórico debido a la presencia del caché. En teoría, Radix Sort es mejor que Quicksort para arreglos grandes. Universidad de Sonora Arquitectura de Computadoras

9 Algoritmos y el caché Comportamiento teórico Universidad de Sonora
Arquitectura de Computadoras

10 Algoritmos y el caché Comportamiento real Universidad de Sonora
Arquitectura de Computadoras

11 Algoritmos y el caché Motivo: fallas de caché. Universidad de Sonora
Arquitectura de Computadoras

12 Solución Diseñar algoritmos que hagan uso efectivo del caché (principio de locality espacial y/o locality temporal). Universidad de Sonora Arquitectura de Computadoras

13 Ejemplo Optimización del software por bloqueo (blocking).
Agrupar los datos en bloques. Idealmente el tamaño de un bloque de datos es igual al tamaño de bloque del caché. El rendimiento de la memoria se mejora si se toma ventaja del locality espacial. Universidad de Sonora Arquitectura de Computadoras

14 Desventajas de optimizar
El rendimiento puede variar en otro sistema. Solución: algoritmos adaptables (“autotuning”). Hay que sopesar si vale la pena invertir tiempo en optimizar. “Premature optimization is the root of all evil.” (Donald Knuth) Universidad de Sonora Arquitectura de Computadoras

15 Reglas de Pike Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) For example, binary trees are always faster than splay trees for workaday problems. Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures. The following data structures are a complete list for almost all practical programs: array  linked list  hash table  binary tree Of course, you must also be prepared to collect these into compound data structures. For instance, a symbol table might be implemented as a hash table containing linked lists of arrays of characters. Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self­ evident. Data structures, not algorithms, are central to programming.  (See Brooks p. 102.) Rule 6. There is no Rule 6. --- Rob Pike, Notes on Programming in C ( Universidad de Sonora Arquitectura de Computadoras