Perché ci sono cache L1 separate per dati e istruzioni?


Risposte:


28

Ci sono in realtà diverse ragioni.

Innanzitutto e probabilmente soprattutto, i dati memorizzati nella cache delle istruzioni sono generalmente leggermente diversi da quelli memorizzati nella cache dei dati - insieme alle istruzioni stesse, ci sono annotazioni per cose come dove inizia la prossima istruzione, per aiutare i decodificatori. Alcuni processori (ad es. Netburst, alcuni SPARC) utilizzano una "cache di traccia", che memorizza il risultato della decodifica di un'istruzione anziché la memorizzazione dell'istruzione originale nella sua forma codificata.

In secondo luogo, semplifica un po 'i circuiti: la cache dei dati deve gestire le letture e le scritture, ma la cache delle istruzioni si occupa solo delle letture. (Questo è uno dei motivi per cui il codice di auto-modifica è così costoso - invece di sovrascrivere direttamente i dati nella cache delle istruzioni, la scrittura passa attraverso la cache dei dati nella cache L2, quindi la riga nella cache delle istruzioni viene invalidata e ri caricato da L2).

In terzo luogo, aumenta la larghezza di banda: i più moderni processori possono leggere i dati dalla cache delle istruzioni e dalla cache dei dati contemporaneamente. Molti hanno anche delle code all'ingresso della cache, quindi possono effettivamente fare due letture e una scrittura in un dato ciclo.

In quarto luogo, può risparmiare energia. Mentre è necessario mantenere la potenza delle celle di memoria stesse per conservare il loro contenuto, alcuni processori possono / fare spegnere alcuni dei circuiti associati (decodificatori e simili) quando non vengono utilizzati. Con cache separate, possono alimentare questi circuiti separatamente per istruzioni e dati, aumentando le possibilità che un circuito rimanga spento durante un determinato ciclo (non sono sicuro che nessun processore x86 lo faccia - AFAIK, è più un ARM cosa).


3
È anche importante ricordare che il codice e i dati possono presentare diversi modelli di accesso; per esempio, le istruzioni per sommare tutti gli elementi in un array mostrano una località temporale (le stesse istruzioni sono usate spesso (se lo fai con un ciclo)) e i dati nell'array mostrano una località spaziale (i seguenti dati saranno usati successivamente).
gablin,

1
@gablin: sebbene vere, quelle differenze nei modelli spesso favorirebbero una cache unificata. In un ciclo stretto come hai detto, la maggior parte della cache delle istruzioni è inattiva. Una cache unificata sostanzialmente raddoppierebbe la dimensione della cache di dati per la durata del ciclo.
Jerry Coffin,

Non proprio, perché non c'è più il codice dopo che piccolo anello e che è anche probabile di lavorare con l'array. Ciò caratterizza moltissimo codice (ad esempio, la gestione delle stringhe). In effetti, le prime cache nelle CPU erano cache unificate - si trovavano tra l'interfaccia di memoria principale della CPU e il bus esterno, che era un posto semplice per metterle - ma ora usiamo una cache partizionata perché è più veloce nella pratica .
Donal Fellows,

@Donal Fellows: Sì, davvero. Sono ben consapevole di come è stata eseguita la memorizzazione nella cache anticipata e perché sono diventati cache divisa.
Jerry Coffin,

5

Proprio come nel settore immobiliare, l'uso della cache è guidato da tre cose: posizione, posizione, posizione. L'intero punto di avere una cache è che la maggior parte dei programmi mostra schemi di posizione: se accedono al byte 1111111, allora il byte successivo a cui accederanno è probabilmente 1111110 o 1111112, e non così tanto byte 9999999. Tuttavia, la maggior parte dei programmi presenterà molto diversi modelli di posizione per le loro istruzioni e i loro dati. Ciò significa che è improbabile che istruzioni e dati siano in grado di condividere la cache in modo efficiente. Perché le istruzioni e i dati non sono necessariamente vicini l'uno all'altro in memoria. Un accesso ai dati eliminerebbe le istruzioni dalla cache e le istruzioni di caricamento avrebbero annullato i dati dalla cache.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.