it-swarm.com.de

Zyklen/Kosten für L1-Cache-Treffer vs. Auf x86 registrieren?

Ich erinnere mich, dass ich davon ausgegangen bin, dass ein L1-Cache-Treffer 1 Zyklus (d. H. Identisch mit der Registerzugriffszeit) in meiner Architekturklasse ist, aber trifft das tatsächlich auf moderne x86-Prozessoren zu?

Wie viele Zyklen dauert ein L1-Cache-Treffer? Wie verhält es sich mit dem Registrierungszugriff?

25
Mehrdad

Hier ist ein großartiger Artikel zum Thema:

http://arstechnica.com/gadgets/reviews/2002/07/caching.ars/1

Um Ihre Frage zu beantworten: Ja, ein Cache-Treffer hat ungefähr die gleichen Kosten wie ein Registerzugriff. Und natürlich ist ein Cache-Miss ziemlich kostspielig;)

PS:

Die Besonderheiten variieren, aber dieser Link hat einige gute Zahlen.

Ungefähre Kosten für den Zugriff auf verschiedene Caches und den Hauptspeicher?

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:

Diese Zahlen repräsentieren viel ältere, langsamere CPUs, aber die Verhältnisse gelten im Wesentlichen:

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
34
paulsm4

Weitere Informationen zur Zykluszählung und zur Ausführung außerhalb der Reihenfolge finden Sie unter Agner Fogs microarch pdf und anderen Links im x86-Tag-Wiki .


Die L1-Last-Use-Latenz von Intel Haswell beträgt 4 Zyklen, was für moderne x86-CPUs typisch ist. wie schnell mov eax, [eax] in einer Schleife laufen kann, mit einem Zeiger, der auf sich selbst zeigt. (Oder zu einer kleinen geschlossenen Liste).

Die Last-Use-Latenzzeit ist bei SSE/AVX-Vektoren in Intel-CPUs um einen Zyklus höher.


Die Wartezeit beim Laden/Laden beträgt 5 Zyklen und steht in keinem Zusammenhang mit dem Treffer oder Fehlschlag des Caches (Speicherweiterleitung, nicht L1-Cache).

Wie harold kommentiert, beträgt der Registerzugriff 0 Zyklen. Also zum Beispiel:

  • inc eax hat eine Latenzzeit von 1 Zyklus (nur die ALU-Operation)
  • inc dword [mem] hat eine Latenzzeit von 6 Zyklen, bis ein Laden von dword [mem] fertig ist. (ALU + Speicherweiterleitung). z.B. Das Halten eines Schleifenzählers im Speicher begrenzt eine Schleife auf eine Iteration pro 6 Zyklen.
  • mov rax, [rsi] hat eine Latenz von 4 Zyklen von rsi, die bereit ist, rax für einen L1-Treffer bereit zu sein (L1-Load-Use-Latenzzeit).

http://www.7-cpu.com/cpu/Haswell.html hat eine Tabelle der Latenz pro Cache (die ich hier kopieren möchte) und einige andere experimentelle Zahlen, einschließlich der L2-TLB-Treffer-Latenz ( bei einem L1DTLB-Fehler).

Intel i7-4770 (Haswell), 3,4 GHz (Turbo Boost Off), 22 nm. RAM: 32 GB (PC3-12800 cl11 cr2).

  • L1-Datencache = 32 KB, 64 B/Zeile, 8-WEG.
  • L1-Befehlscache = 32 KB, 64 B/Zeile, 8-WEG.
  • L2-Cache = 256 KB, 64 B/Zeile, 8-WEG
  • L3-Cache = 8 MB, 64 B/Zeile

  • L1 Data Cache Latenz = 4 Zyklen für einfachen Zugriff über Zeiger (mov rax, [rax])

  • L1 Data Cache Latenz = 5 Zyklen für den Zugriff mit komplexer Adressberechnung (mov rax, [rsi + rax*8]).
  • L2-Cache-Latenz = 12 Zyklen
  • L3 Cache-Latenz = 36 Zyklen
  • RAM-Latenz = 36 Zyklen + 57 ns

Die Benchmark-Seite der obersten Ebene lautet http://www.7-cpu.com/utils.html , erklärt jedoch nicht wirklich, was die verschiedenen Testgrößen bedeuten, aber der Code ist verfügbar. Die Testergebnisse beinhalten Skylake , was in diesem Test fast das gleiche wie Haswell ist.

Die Antwort von @ paulsm4 enthält eine Tabelle für einen Nehalem Xeon mit mehreren Sockeln, einschließlich einiger Speicher-/L3-Nummern (andere Sockel).

4
Peter Cordes

Wenn ich mich richtig erinnere, sind es 1-2 Taktzyklen, aber dies ist eine Schätzung und neuere Caches sind möglicherweise schneller. Dies ist aus einem Computerarchitektur-Buch, das ich besitze, und dies sind Informationen für AMD, also könnte Intel etwas anders sein, aber ich würde es zwischen 5 und 15 Taktzyklen einschränken, was mir eine gute Schätzung erscheint.

EDIT: Whoops L2 ist 10 Zyklen mit TAG-Zugriff, L1 dauert 1 bis 2 Zyklen, mein Fehler: \

1
Jesus Ramos

Tatsächlich sind die Kosten des L1-Cache-Treffers fast die gleichen wie die Kosten für den Registerzugriff. Es war überraschend für mich, aber zumindest für meinen Prozessor (Athlon 64). Vor einiger Zeit habe ich eine einfache Testanwendung geschrieben, um die Effizienz des Zugriffs auf die gemeinsam genutzten Daten in einem Multiprozessorsystem zu bewerten. Der Anwendungstext ist eine einfache Speichervariable, die während des vordefinierten Zeitraums inkrementiert wird. Um ein Comapison zu machen, habe ich zunächst eine nicht gemeinsam genutzte Variable verglichen. Während dieser Aktivität habe ich das Ergebnis erfasst, aber während der Demontage der Anwendung habe ich festgestellt, dass der Compiler meine Erwartungen getäuscht hat und unerwünschte Optimierung auf meinen Code anwendet. Es wird lediglich eine Variable in das CPU-Register eingefügt und ohne Speicherzugriff iterativ in das Register inkrementiert. Aber eine wirkliche Überraschung wurde erreicht, nachdem ich den Compiler gezwungen habe, eine In-Memory-Variable anstelle einer Registervariablen zu verwenden. Bei der aktualisierten Anwendung habe ich fast die gleichen Benchmark-Ergebnisse erzielt. Der Leistungsabfall war wirklich vernachlässigbar (~ 1-2%) und scheint mit einigen Nebenwirkungen in Verbindung zu stehen.

Als Ergebnis:

1) Ich denke, Sie können L1-Cache als nicht verwalteten Prozessorregisterpool betrachten. 

2) Es ist nicht sinnvoll, die brutale Assay-Optimierung anzuwenden, indem der Compiler das häufige Abrufen von Daten in Prozessorregistern erzwingt. Wenn auf sie wirklich häufig zugegriffen wird, werden sie im L1-Cache gespeichert und haben daher die gleichen Zugriffskosten wie das Prozessorregister.

0
ZarathustrA