La risposta è abbastanza semplice: la memoria principale è glacialmente lenta rispetto alla CPU. Per citare da un'altra domanda in un'area correlata , velocità approssimative per una CPU moderna sono:
L1 CACHE hit, ~4 cycles
L2 CACHE hit, ~10 cycles
L3 CACHE hit, line unshared ~40 cycles
L3 CACHE hit, shared line in another core ~65 cycles
L3 CACHE hit, modified in another core ~75 cycles remote
L3 CACHE ~100-300 cycles
Quindi, fai i conti con la DRAM contro una CPU da 2.5GHz: per un singolo ciclo gli 800MHz stai parlando di ~ 3-4 cicli della CPU. L'effettiva tempistica dell'accesso alla memoria è più complessa , ma si somma a molto. La RAM da 800 MHz ci sarà qualcosa come 5-5-5-16, o 124 cicli di CPU.
Anche questo è ancora in un mondo ideale: una volta aggiunta la larghezza di banda del bus, la contesa della memoria da accessi multipli agli stessi chip, overheads della cache e tutto ciò che si sta parlando dell'accesso alla memoria principale è da trenta a cinquanta volte più lento di accedere ai dati nella cache.
Il disco è, ovviamente, follemente più lento. Nell'analisi di questo problema, la domanda è se il costo delle prestazioni - RAM che è del 75% la velocità - valga il vantaggio - mettere in cache ~ 70% dei dati prima del disco.
Per rispondere alla domanda su dove altro ti imbatti in questo: il posto più comune sarebbe la tua scheda grafica, dove la larghezza di banda della memoria è uno dei limiti significativi nella velocità di riempimento generale. I miglioramenti là aiutano sostanzialmente ad aumentare il numero complessivo di poligoni nei giochi, ecc.
Altrimenti, ti imbatti in questo ogni giorno, ma solo in piccoli modi. Si paga quel costo di 30 volte per scrivere dati in DRAM e si può assolutamente vedere e misurare che in tutti i tipi di software che finiscono per mostrare un enorme calo di prestazioni all'aumentare della dimensione di input. La compressione video e l'elaborazione delle immagini sono luoghi comuni in cui questa considerazione può comportare cambiamenti visibili delle prestazioni.