2011-12-23 9 views
11

Sto lavorando su un sistema, scritto in C++, in esecuzione su una Xeon su Linux, che deve essere eseguito il più velocemente possibile. C'è una grande struttura dati (fondamentalmente una serie di strutture) conservata nella RAM, oltre 10 GB, e gli elementi di esso devono essere accessibili periodicamente. Voglio rivedere la struttura dei dati per lavorare il più possibile con il meccanismo di caching del sistema.Quanti byte un Xeon porta nella cache per accesso alla memoria?

Attualmente, gli accessi vengono eseguiti in modo casuale in tutta la struttura e ogni volta vengono letti 1-4 indici da 32 bit. È molto prima che un'altra lettura avvenga nello stesso posto, quindi non c'è alcun beneficio dalla cache.

Ora so che quando si legge un byte da una posizione casuale nella RAM, più di quel byte viene portato nella cache. La mia domanda è: quanti byte vengono portati? Sono 16, 32, 64, 4096? Si chiama una linea della cache?

Sto cercando di ridisegnare la struttura dei dati per ridurre al minimo gli accessi RAM casuali e lavorare con la cache anziché contro di essa. Sapendo quanti byte sono tirati nella cache in un accesso casuale informerà le scelte progettuali che faccio.

Aggiornamento (ottobre 2014): Poco dopo aver posto la domanda sopra il progetto è stato messo in attesa. Da allora ha ripreso e sulla base di suggerimenti nelle risposte di seguito, ho eseguito alcuni esperimenti sull'accesso alla RAM, perché sembrava probabile che il thriller TLB stesse accadendo. Ho rivisto il programma per girare con pagine enormi (2 MB anziché lo standard 4KB) e ho osservato una piccola accelerazione, circa il 2,5%. Ho trovato ottime informazioni sulla configurazione di enormi pagine here e here.

+5

Sì, linea cache. Puoi assumere 64 byte fino a quando non hai capito quale dei dozzine di modelli di processori Xeon hai. Anche le cache L2 e L3 hanno un ruolo. Concentrati sugli accessi sequenziali alla memoria e non assumere nulla.Misurare. –

+0

Grazie a tutti per le vostre risposte. –

risposta

7

Le CPU di oggi recuperano memoria in blocchi di (in genere) 64 byte, chiamati linee di cache. Quando leggi una particolare posizione di memoria, l'intera riga della cache viene recuperata dalla memoria principale nella cache.

Maggiori informazioni qui: http://igoro.com/archive/gallery-of-processor-cache-effects/

+0

Articolo collegato molto informativo, @ Michael. +1. –

2

vecchia, quindi domanda che ha alcune informazioni che potrebbe essere utile a voi (in particolare la prima risposta dove cercare informazioni CPU Linux - risponditore non menziona dimensioni della linea corretta, ma "altre informazioni" in aggiunta all'associatività, ecc.). La domanda è per x86, ma le risposte sono più generali. Vale la pena dare un'occhiata.

Where is the L1 memory cache of Intel x86 processors documented?

+0

Suggerimenti utili sulla domanda collegata, @gnometorule. +1. –

3

Una linea di cache per qualsiasi processore Xeon corrente è 64 byte. Un'altra cosa a cui potresti voler pensare è il TLB. Se si stanno davvero facendo accessi casuali su 10 GB di memoria, è probabile che si verifichino molti errori TLB che possono essere altrettanto costosi di quelli della cache. Puoi lavorare su grandi pagine, ma è qualcosa da tenere a mente.

+0

Potrebbe approfondire ulteriormente, @Gabriel? Che cosa significa TLB e come potrebbero aiutare le pagine di grandi dimensioni? –

+0

Traduci Buffer Lookaside: sono coinvolti nel rendere il paging hardware meno lento (lunga storia, google :)). Una pagina, una voce TLB: sono necessarie meno voci TLB se si esegue il mapping della memoria con grandi (4meg o 2meg, in base alla modalità CPU) rispetto alle pagine normali (4kbyte). – snemarch

+0

TLB sta per "translation lookaside buffer". Quando accedi alla memoria devi tradurre l'indirizzo virtuale in un indirizzo fisico. Questo viene fatto a granularità della pagina e la dimensione della pagina tipica per x86 è 4KB. Il TLB memorizza nella cache la traduzione da indirizzo virtuale a indirizzo fisico ma è una struttura relativamente piccola (circa 200 voci). –

1

Si potrebbe voler andare a http://agner.org/optimize/ e prendere i PDF di ottimizzazione disponibili lì - ci sono un sacco di informazioni buone (di basso livello) in là. Piuttosto focalizzato sul livello di linguaggio assembly, ma ci sono lezioni da apprendere anche per i programmatori C/C++.

Volume 3, "La microarchitettura di Intel, AMD e VIA CPU" dovrebbe essere di interesse :-)

Problemi correlati