Ricordo che supponendo che un hit della cache L1 sia di 1 ciclo (cioè identico al tempo di accesso al registro) nella mia classe di architettura, ma è vero per i moderni processori x86?Cicli/costi per L1 Cache hit vs. Registrati su x86?
Quanti cicli ha colpito una cache L1? Come si confronta per registrare l'accesso?
Ecco un grande articolo sul tema:
http://arstechnica.com/gadgets/reviews/2002/07/caching.ars/1
Per rispondere alla tua domanda: sì, un riscontro nella cache ha all'incirca lo stesso costo dell'accesso al registro. E, naturalmente, una miss cache è abbastanza costoso;)
PS:
Le specifiche possono variare, ma questo link ha alcune buone cifre approssimative:
Approximate cost to access various caches and main memory?
Core i7 Xeon 5500 Series Data Source Latency (approximate)
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
Local DRAM ~30 ns (~120 cycles)
Remote DRAM ~100 ns
PPS:
Queste cifre rappresentano molto CPU più vecchie e più lente, ma i rapporti in pratica contengono:
http://arstechnica.com/gadgets/reviews/2002/07/caching.ars/2
Level Access Time Typical Size Technology Managed By
----- ----------- ------------ --------- -----------
Registers 1-3 ns ?1 KB Custom CMOS Compiler
Level 1 Cache (on-chip) 2-8 ns 8 KB-128 KB SRAM Hardware
Level 2 Cache (off-chip) 5-12 ns 0.5 MB - 8 MB SRAM Hardware
Main Memory 10-60 ns 64 MB - 1 GB DRAM Operating System
Hard Disk 3M - 10M ns 20 - 100 GB Magnetic Operating System/User
Come è possibile che l'accesso alla cache L3 possa richiedere 100-300 cicli, mentre l'accesso alla DRAM locale richiede solo 120 cicli. Ciò significa che la cache L3 può essere più di due volte più lenta della DRAM, che viene utilizzata nella memoria principale? – user2316602
@ user2316602: anche a me sembra fasullo, a meno che la riga della tabella non sia destinata alla cache L3 di una CPU in un socket diverso. (Si tratta di un sistema Nehalem Xeon, quindi la memoria principale e L3 sono NUMA.) –
Se ricordo correttamente sono circa 1-2 cicli di clock ma questa è una stima e le cache più recenti potrebbero essere più veloci. Questo è fuori da un libro di architettura del computer che ho e questo è l'informazione per AMD, quindi Intel potrebbe essere leggermente diversa, ma la collegherei tra 5 e 15 cicli di clock che mi sembrano una buona stima.
EDIT: Ops L2 è di 10 cicli con accesso TAG, L1 richiede da 1 a due cicli, il mio errore: \
realtà il costo della cache hit L1 è quasi la stessa di un costo di accesso registro. È stato sorprendente per me, ma questo è vero, almeno per il mio processore (Athlon 64). Qualche tempo fa ho scritto una semplice applicazione di test per valutare l'efficienza dell'accesso ai dati condivisi in un sistema multiprocessore. Il corpo dell'applicazione è una variabile di memoria semplice che si incrementa durante il periodo di tempo predefinito. Per fare un confronto, all'inizio ho confrontato la variabile non condivisa. E durante quell'attività ho catturato il risultato, ma poi durante il disassemblaggio dell'applicazione ho scoperto che il compilatore aveva ingannato le mie aspettative e applicato l'ottimizzazione indesiderata al mio codice. Inserisce semplicemente una variabile nel registro della CPU e la incrementa iterativetly nel registro senza accesso alla memoria. Ma la vera sorpresa è stata raggiunta dopo che ho forzato il compilatore a utilizzare la variabile in memoria invece della variabile di registro. Nell'applicazione aggiornata ho ottenuto quasi gli stessi risultati di benchmarking. Il degrado delle prestazioni è stato davvero trascurabile (~ 1-2%) e sembra correlato ad alcuni effetti collaterali.
Come risultato:
1) Penso che si può considerare la cache L1 come un processore non gestito registra piscina.
2) Non vi è alcun motivo per applicare l'ottimizzazione brutale di assambly forzando l'archivio del compilatore accedendo frequentemente ai dati nei registri del processore. Se si accede molto frequentemente, vivranno nella cache L1 e, a causa di questo, avranno lo stesso costo di accesso del registro del processore.
Il benchmark era sbagliato, quindi, o stretto di collo su qualcos'altro. 'inc [mem]' ha latenza 6c su Intel Haswell e simili su AMD. 'inc eax' ha 1 ciclo di latenza su tutte le moderne CPU x86. Questa è la latenza di forwarding del negozio, non la latenza di L1. La latenza di caricamento L1 è più simile a 4 cicli. Vedi il pdf del microarch di Agner Fog e altri link sul [wiki dei tag x86] (http://stackoverflow.com/tags/x86/info). –
Per ulteriori dettagli sul ciclo di conteggio e sull'esecuzione fuori servizio, vedere Agner Fog's microarch pdf e altri collegamenti nello x86 tag wiki.
La latenza di caricamento L1 di Intel Haswell è di 4 cicli, tipica delle moderne CPU x86. cioè quanto velocemente mov eax, [eax] può essere eseguito in un ciclo, con un puntatore che punta a se stesso. (O in una piccola lista collegata a circuito chiuso).
La latenza di utilizzo del carico è 1 ciclo superiore per i vettori SSE/AVX nelle CPU Intel.
Store-reload latenza è 5 cicli, e non è correlato al riscontri cache o perdere (è store-forwarding, non L1 cache).
Come commentato da harold, l'accesso al registro è di 0 cicli. Così, ad esempio:
inc eax ha 1 ciclo latenza (solo l'operazione ALU)inc dword [mem] ha 6 ciclo latenza finché un carico da dword [mem] sarà pronto. (ALU + store-forwarding). per esempio. mantenere un contatore di loop in memoria limita un loop a un'iterazione per 6 cicli.mov rax, [rsi] ha latenza 4 ciclo da rsi essere pronto per essere pronto rax su un colpo L1 (carico L1-uso latenza.)http://www.7-cpu.com/cpu/Haswell.html ha una tabella di latenza per cache (che io copia qui) e alcuni altri numeri sperimentali, inclusa la latenza di hit L2-TLB (su una miss L1DTLB).
Intel i7-4770 (Haswell), 3,4 GHz (Turbo Boost spento), 22 nm. RAM: 32 GB (PC3-12800 cl11 cr2).
- L1 Cache dati = 32 KB, 64 B/linea, 8-VIE.
- Cache di istruzioni L1 = 32 KB, 64 B/linea, 8-WAY.
- cache L2 = 256 KB, 64 B/linea, 8 VIE
L3 cache = 8 MB, 64 B/linea
L1 cache dati Latenza = 4 cicli per semplice accesso tramite puntatore (
mov rax, [rax])- Latenza cache dati L1 = 5 cicli per l'accesso con calcolo dell'indirizzo complesso (
mov rax, [rsi + rax*8]).- L2 cache latency = 12 cicli
- L3 Cache Latenza = 36 cicli
- RAM Latenza = 36 cicli + 57 ns
La pagina di riferimento di primo livello è http://www.7-cpu.com/utils.html, ma ancora doesn' t davvero spiegare cosa significano le diverse dimensioni di test, ma il codice è disponibile. I risultati del test includono Skylake, che è quasi lo stesso di Haswell in questo test.
La risposta di @ paulsm4 ha una tabella per un Nehalem Xeon multi-socket, inclusi alcuni numeri di memoria/L3 remoti (altri socket).
Varia a seconda del processore, ma non so di dove sia * abbastanza * veloce come un registro - circa 1 a 5 orologi più lento è abbastanza tipico. –
Non conosco nessuna architettura in cui L1 ha una latenza a ciclo singolo. Inoltre, non conosco architetture x86 in cui l'accesso al registro abbia una latenza misurabile di per sé (una certa latenza può essere percepita a causa di altri fattori). – harold
Vedere http://www.7-cpu.com/cpu/Haswell.html: alcuni numeri di latenza per-cache e per-TLB e alcuni numeri sperimentali. Vedi anche [pdf microarch di Agner Fog] (http://agner.org/optimize/), e altri link nella [wiki dei tag x86] (http://stackoverflow.com/tags/x86/info). La latenza di caricamento L1 di Haswell è di 4 cicli, tipica delle moderne CPU x86. La latenza di ricarica del negozio è di 5 cicli, e non correlata alla cache in caso di errore (è il forwarding del negozio, non la cache). Come dice harold, l'accesso al registro è di 0 cicli (ad es. 'Inc eax' ha una latenza di 1 ciclo,' inc [mem] 'ha una latenza di 6 cicli (ALU + store-forwarding) –