Memoria Retos de diseño

Universidad de SonoraArquitectura de Computadoras2 Fallas de caché Las fallas de caché disminuyen conforme se incrementa la asociatividad.

Universidad de SonoraArquitectura de Computadoras3 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 SonoraArquitectura de Computadoras4 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 SonoraArquitectura de Computadoras5 Origen de las fallas Las fallas de conflicto son %

Universidad de SonoraArquitectura de Computadoras6 Origen de las fallas Tasa de fallas relativa.

Universidad de SonoraArquitectura de Computadoras7 Reto del diseño Reducir la tasa de fallas, Reducir el castigo por fallas o Reducir el tiempo de éxito.

Universidad de SonoraArquitectura de Computadoras8 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 SonoraArquitectura de Computadoras9 Algoritmos y el caché Comportamiento teórico

Universidad de SonoraArquitectura de Computadoras10 Algoritmos y el caché Comportamiento real

Universidad de SonoraArquitectura de Computadoras11 Algoritmos y el caché Motivo: fallas de caché.

Universidad de SonoraArquitectura de Computadoras12 Solución Diseñar algoritmos que hagan uso efectivo del caché (principio de locality). Problema: el rendimiento puede variar de un sistema a otro. El reto es diseñar algoritmos adaptables.

Optimización de software por bloqueo Bloqueo (blocking) agrupar por bloques. Al usar arreglos, el rendimiento de la memoria se mejora si el acceso a los arreglos es secuencial (locality espacial). Hay dos formas de almacenar un arreglo bidimensional: Por renglón Por columna Universidad de SonoraArquitectura de Computadoras13

Renglón / Columna Dada la matriz: A =a00 a01 a02 a10 a11 a12 Por renglón: V1: [a00, a01, a02, a10, a11, a12] index = i * n + j (n es el número de columnas) Por columna: V2: [a00, a10, a01, a11, a02, a12] index = i + j * n (n es el número de renglones) Universidad de SonoraArquitectura de Computadoras14

Multiplicación de matrices Universidad de SonoraArquitectura de Computadoras15

Acceso a la memoria Universidad de SonoraArquitectura de Computadoras16

Acceso a la memoria Lee todos los N x N elementos de B. Lee N elementos de A (una columna). Escribe un renglón de N elementos en C. Las fallas de capacidad dependen de N y del tamaño del caché. Si en el caché caben 3 matrices de N x N no hay problema. Universidad de SonoraArquitectura de Computadoras17

Acceso a la memoria ¿Qué pasa si al caché le cabe una matriz de N x N y un renglón de N elementos? Al menos el renglón i de A y toda B se pueden quedar en el caché. En otro caso se van a generar fallas por C y por B. El peor caso: 2N 3 + N 2 palabras accesadas por N 3 operaciones. La solución es hacer la multiplicación por submatrices. Se define un factor de bloqueo (blocking factor) Universidad de SonoraArquitectura de Computadoras18

Algoritmo con bloqueo Universidad de SonoraArquitectura de Computadoras19

Acceso a la memoria Universidad de SonoraArquitectura de Computadoras20 Número de accesos: 2N 3 / BLOCKSIZE + N 2

Rendimiento con bloqueo Universidad de SonoraArquitectura de Computadoras21

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 SonoraArquitectura de Computadoras22

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 Rob Pike, Notes on Programming in C ( Universidad de SonoraArquitectura de Computadoras23