Barrapunto

Eso es cierto en casi todas las arquitecturas. Y digo casi porque hay algunas que no usan caché, como los superordenadores Tera MTA [cray.com]

(Una de las ventajas del multithreading es que reduce la necesidad de la caché)

> Yo creo que la medida más importante de un procesador, después de la velocidad en Mhz y el CPI/Tc, es el tamaño de su caché

Estoy de acuerdo, pero ten en cuenta también al aumentar mucho el tamaño de la caché no se obtienen aumentos significativos en el rendimiento.

Si haces una gráfica en las que las X es el tamaño de la caché y en la Y la mejora obtenida en porcentaje verás que te sale una función creciente con una asíntota horizontal en el 100% y otra vertical en los 0KB. Al principio crece muy deprisa, pero al llegar a un punto se pasa a crecer muy despacio.

Los ingenieros que lo diseñan en este caso, prefieren abaratar los costes poniendo memorias cachés ajustadas a ese punto en el que el rendimiento crece más despacio. Por eso aún añadiría que además del tamaño de la caché sería interesante la propia velocidad de la caché.

Cada dato que existe en caché significa que la CPU puede tenerlo en 1 ciclo

Eso depende del micro, en un procesador como el PIV, con una segmentación de 20 etapas, es fácil que 2 o 3 (todo sería mirarlo para salir de dudas, pero me da pereza ahora) sean de fetch.

Cuanta más caché, más probabilidad hay de que exista el dato en ella, y por lo tanto pasaremos de 100 ciclos a 1

Y cuanta más cache, más compleja es y más lento es el acceso a cache. Y la cache tampoco lo es todo, depende de el tipo de aplicación que utilices, los procesadores DSP van sin cache porque hace más mal que bien.

Ahora mismo, con la manía que tienen de supersegmentar los micros, lo realmente importante es el predictor de saltos.

Para hacernos una idea, la relación de saltos/instrucción es de 1/6. En el PIV tenemos 20 etapas así que es fácil encontrarse con 3 o 4 saltos a la vez en el pipe. Si no sabemos si vamos a tomar el salto hasta la etapa 5 (por poner un ejemplo), estamos especulando 4 instrucciones. Si el predictor falla demasiado te encuentras en la situación de que tienes ocupadas tan solo 6 etapas de las 20 y pierdes los otros 14 ciclos. Es decir, estarías aprovechando tan solo el 30% de los ciclos de reloj.

Ahora imagínate la misma situación con los famosos Pentium nuevos, los Prescott, que tienen 31 etapas (o 40, no me acuerdo). El problema se multiplica enormemente.

Además del predictor de saltos, cosas como el prefetching por hardware pueden multiplicar el rendimiento del micro.

No es que la cache no sea importante, pero como tú has dicho, tienen un hit-rate del 99% actualmente, ahora mismo las caches hacen todo lo que pueden hacer por mejorar los tiempos de acceso a RAM, por ese lado el problema está superado.

Es más importante tener un predictor de saltos bueno que te evite perder instrucciones por especulación (que es un problema que no se puede solventar tan bien como el que se solventa con las caches), o un controlador de prefetch que se vaya trayendo instrucciones antes de que se pidan para acelerar aún más el tiempo de acceso a la memoria (aunque creo que este también es un problema resuelto y que los últimos sistemas de prefetch automático funcionan de lujo, que es incluso contraproducente utilizar las instrucciones de prefetch, es mejor dejar hacer al micro).