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

178

Kann mir jemand die ungefähre Zeit (in Nanosekunden) geben, um auf L1-, L2- und L3-Caches sowie auf den Hauptspeicher von Intel i7-Prozessoren zuzugreifen?

Obwohl dies keine spezielle Programmierfrage ist, ist es für einige Programmierprobleme mit geringer Latenz erforderlich, diese Art von Geschwindigkeitsdetails zu kennen.

memory latency cpu-cache low-latency Ted Graham
quelle
mechanisch-sympathy.blogspot.com/2013/02/…
Beachhouse
1
Wie konvertiere ich ns in Zyklen? Wenn ich einfach 100 ns durch 2,3 GHz dividiere, erhalte ich 230 Zyklen. Ist das richtig?
Nathan
5
Ich bin gespannt: In welcher Situation ist der Remote-L3-Cache langsamer als der Remote-DRAM? Die obige Zahl gibt an, dass es 1,6-mal so langsam sein kann.
Netvope
1
Bitte bearbeiten Sie die Frage nicht, sondern geben Sie eine Antwort mit diesen Details ein. Selbstantwort ist auf SO in Ordnung.
Stijn de Witt
Gibt es ungefähre Werte für den Energieverbrauch für den Speicherzugriff auf jeder Ebene?
Kanna

Antworten:

74

Hier finden Sie ein Handbuch zur Leistungsanalyse für die Prozessoren i7 und Xeon. Ich sollte betonen, dass dies das hat, was Sie brauchen und mehr (siehe beispielsweise Seite 22 für einige Zeitabläufe und Zyklen).

Darüber hinaus enthält diese Seite einige Details zu Taktzyklen usw. Der zweite Link enthielt die folgenden Nummern: 

Core i7 Xeon 5500 Series Data Source Latency (approximate)               [Pg. 22]

local  L1 CACHE hit,                              ~4 cycles (   2.1 -  1.2 ns )
local  L2 CACHE hit,                             ~10 cycles (   5.3 -  3.0 ns )
local  L3 CACHE hit, line unshared               ~40 cycles (  21.4 - 12.0 ns )
local  L3 CACHE hit, shared line in another core ~65 cycles (  34.8 - 19.5 ns )
local  L3 CACHE hit, modified in another core    ~75 cycles (  40.2 - 22.5 ns )

remote L3 CACHE (Ref: Fig.1 [Pg. 5])        ~100-300 cycles ( 160.7 - 30.0 ns )

local  DRAM                                                   ~60 ns
remote DRAM                                                  ~100 ns

EDIT2:
Das wichtigste ist der Hinweis unter der zitierten Tabelle:

„Hinweis: Diese Werte sind grobe Annäherungen. Sie hängen von Kern und Nicht - Kern - FREQUENZEN, Speichertakt, BIOS - Einstellungen, DIE ANZAHL DER DIMMS , ETC, ETC .. Ihre Ergebnisse können variieren. “

BEARBEITEN: Ich möchte hervorheben, dass das obige Intel-Dokument neben Zeit- / Zyklusinformationen viel mehr (äußerst) nützliche Details der i7- und Xeon-Prozessoren enthält (unter Leistungsgesichtspunkten).

Dave
quelle
1
Sollte "nicht freigegebene Leitung" nicht länger dauern als "gemeinsam genutzte Leitung in einem anderen Kern" - eine gemeinsam genutzte Leitung (dh 2 gültige Kernbits) bedeutet, dass sie direkt aus dem LLC-Slice entnommen werden kann, da sie garantiert sauber ist. 'Nicht freigegebene Leitung' bedeutet, dass nur ein gültiges Kernbit vorhanden ist und dieser Kern beschnüffelt werden muss, um sicherzustellen, dass die Leitung exklusiv ist und nicht geändert wird. Wenn sie geändert wird, wird sie in freigegeben geändert. LLC wird jetzt schmutzig und wird als freigegeben an den anfordernden Kern zurückgegeben. Vielleicht irre ich mich - ich weiß, dass das MOESI-Protokoll anders ist.
Lewis Kelsey
1
Dies ist sicherlich bei SnB und Haswell der Fall. Nehalem - das dieser Xeon verwendet - befand sich vor der Ringbustopologie und hatte einen einheitlichen Cache, aber ich verstehe nicht, warum sich der Snoop-Filter in Nehalem anders verhalten würde. Das Optimierungshandbuch in Abschnitt B.3.5.3 enthält meiner Meinung nach eine falsche Beschreibung (es bezieht sich eindeutig auf Nehalem, da es sich um die globale Warteschlange handelt, bei der es sich um eine Nehalem-Funktion handelt). Dieses Haswell-Papier hat eine bessere Beschreibung (obere rechte Spalte von Seite 5) ( tu-dresden.de/zih/forschung/mengen/dateien/… )
Lewis Kelsey
@ LewisKelsey: Das ist auch für mich überraschend, weil ich dachte, der halbe Punkt von inklusive L3 sei, dass L3 einfach antworten könnte, wenn es eine gültige Kopie einer Zeile hätte. Aber denken Sie daran, Intel verwendet MESIF ( en.wikipedia.org/wiki/MESIF_protocol ) für NUMA, AMD verwendet MOESI. Ich denke jedoch, dass MESIF innerhalb eines einzigen Sockets keine wirkliche Sache ist, da Daten von L3 stammen, nicht von Core-> Core. Daher ist es wahrscheinlich relevanter für L3-Cache-> Cache-Übertragungen über Sockets. Ich frage mich, ob dieser "lokale L3-Treffer" für eine Leitung ist, die mit einem Kern in einem anderen Socket geteilt wird. Immer noch nicht sinnvoll, gültig in L3 bedeutet, dass kein Kern E / M hat
Peter Cordes
@PeterCordes Ich erinnerte mich an diesen Kommentar und kam zurück und was ich sagte, kam mir sofort als falsch vor. Mein Kommentar ist in der Perspektive eines dritten Kerns richtig, in dem er zwischen zwei anderen Kernen geteilt wird oder nur exklusiv für einen anderen Kern. Wenn es sich jedoch um eine nicht gemeinsam genutzte Leitung handelt und diese zu dem Kern gehört, der versucht, auf die Leitung zuzugreifen, ist der Benchmark richtig, da für die gemeinsame Nutzung ein RFO erforderlich ist, um sie exklusiv und exklusiv zu erhalten. Dies bedeutet, dass kein solches RFO erforderlich ist. Ich weiß also nicht, was ich wirklich gesagt habe.
Lewis Kelsey
@ LewisKelsey: Ja, das gilt alles für das Schreiben. Ich dachte , dies war für das Lesen (Data Source - Latency), die mehr Latenz empfindlich ist. Das Lesen einer Zeile erfordert niemals eine RFO, sondern nur eine Aufforderung zum Teilen. Sollte also eine Leitung, die sich bereits irgendwo im freigegebenen Zustand befindet, nicht einfach in die L3 dieser Buchse drücken, ohne auf Kohärenzverkehr warten zu müssen? Und damit schneller als DRAM, ähnlich einem "ungeteilten" L3-Treffer.
Peter Cordes
189

Zahlen, die jeder kennen sollte

           0.5 ns - CPU L1 dCACHE reference
           1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance
           5   ns - CPU L1 iCACHE Branch mispredict
           7   ns - CPU L2  CACHE reference
          71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
         100   ns - MUTEX lock/unlock
         100   ns - own DDR MEMORY reference
         135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
         202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
         325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
      10,000   ns - Compress 1K bytes with Zippy PROCESS
      20,000   ns - Send 2K bytes over 1 Gbps NETWORK
     250,000   ns - Read 1 MB sequentially from MEMORY
     500,000   ns - Round trip within a same DataCenter
  10,000,000   ns - DISK seek
  10,000,000   ns - Read 1 MB sequentially from NETWORK
  30,000,000   ns - Read 1 MB sequentially from DISK
 150,000,000   ns - Send a NETWORK packet CA -> Netherlands
|   |   |   |
|   |   | ns|
|   | us|
| ms|

Von: Ursprünglich von Peter Norvig:
- http://norvig.com/21-days.html#answers
- http://surana.wordpress.com/2009/01/01/numbers-everyone-should-know/ ,
- http://sites.google.com/site/io/building-scalable-web-applications-with-google-app-engine

ein visueller Vergleich

Andrey
quelle
11
Sicherlich sind diese sehr RIESIGEN Beträge, basierend auf Prozessordesign, RAM-Latenz / Frequenz, Festplatten-Caching (sowohl Typ als auch Größe) / U / min usw. usw.? Um INTEL zu zitieren (für Werte, die für eine bestimmte CPU freigegeben wurden): "HINWEIS: Diese Werte sind grobe Näherungswerte. Sie hängen von den Core- und Uncore-Frequenzen, den Speichergeschwindigkeiten, den BIOS-Einstellungen, der Anzahl der DIMMS usw. usw. ab. Ihre Meile kann variieren. . "
Dave
28
@ Dave das stimmt, aber diese Zahlen zeigen die Größenordnung
Andrey
8
@ Dave, obwohl Typ / Geschwindigkeit / Architektur der CPU unterschiedlich ist, sollte das relative Timing meiner Meinung nach ungefähr gleich bleiben, daher ist es nur eine grobe Richtlinie, zu wissen, wann Sie codieren. Eine aussagekräftigere Analyse sollte natürlich über den Profiler erfolgen ...
xosp7tom
8
Um eine Vorstellung davon zu bekommen, wie viel Zeit es ist, erwähnt Wikipedia: "Eine Nanosekunde entspricht einer Sekunde, eine Sekunde 31,7 Jahre." en.wikipedia.org/wiki/Nanosecond
Nur Sie
1
@kernel Wenn ein Cache-Fehler auftritt, bedeutet dies, dass der Zugriff auf den Cache der unteren Ebene oder sogar auf den Hauptspeicher erforderlich ist. In diesem Fall dauert es entsprechend dieser Zugriffszeit einige Zeit. Sie können hier nach Daten für neuere CPUs suchen. Sisoftware.net/?d=qa&f=ben_mem_latency
Andrey
39

Kosten für den Zugriff auf verschiedene Speicher auf einer hübschen Seite

Zusammenfassung

  1. Die Werte sind gesunken, haben sich aber seit 2005 stabilisiert

            1 ns        L1 cache
        3 ns        Branch mispredict
        4 ns        L2 cache
       17 ns        Mutex lock/unlock
      100 ns        Main memory (RAM)
    2 000 ns (2µs)  1KB Zippy-compress

  2. Noch einige Verbesserungen, Prognose für 2020

       16 000 ns (16µs) SSD random read (olibre's note: should be less)
  500 000 ns (½ms)  Round trip in datacenter
2 000 000 ns (2ms)  HDD random read (seek)

Siehe auch andere Quellen

Siehe auch

Zum besseren Verständnis empfehle ich die exzellente Präsentation moderner Cache-Architekturen (Juni 2014) von Gerhard Wellein , Hannes Hofmann und Dietmar Fey an der Universität Erlangen-Nürnberg .

Französisch sprechende Menschen mögen einen Artikel von SpaceFox zu schätzen wissen , in dem ein Prozessor mit einem Entwickler verglichen wird, der auf Informationen wartet, die für die weitere Arbeit erforderlich sind.

olibre
quelle
ein schöner Latenzbeitrag. Es wäre gut, die Fakten über die Realität der GPU-
Latenzmaskierung
Hi @ user3666197 Haben Sie einige Quellen zur Speicherlatenz im Zusammenhang mit der GPU? Prost :-)
Olibre
Sicher, ja, @olibre. Überprüfen Sie die [A]unten angegebenen.
user3666197
1
Angesichts der Tatsache, dass es um Latenz und Caching geht, finde ich es ironisch, dass die Seite unter Ihrem ersten Link mit dem Jahresregler die Metrikanzeige beim Ändern des Jahres nicht zwischenspeichert. Zumindest in Firefox rendern sie zu langsam, als dass sie über die Jahre gezogen werden
könnten
1
Schöne Referenzen, Sie gaben Titel und Autoren!
SamB
21

Nur um der Überprüfung der Prognosen für 2025 im Jahr 2020 willen:

In den letzten 44 Jahren der integrierten Schaltungstechnologie haben sich die klassischen (Nicht-Quanten-) Prozessoren buchstäblich und physikalisch "Per Aspera ad Astra" entwickelt . Das letzte Jahrzehnt hat gezeigt, dass der klassische Prozess einigen Hürden nahe gekommen ist, die keinen erreichbaren physischen Weg vorwärts haben.

Number of logical coreskann und kann wachsen, aber nicht mehr als schwer, wenn nicht unmöglich, die bereits getroffene physikbasierte Decke zu umgehen, kann und kann wachsen, aber weniger als (Leistung, Rauschen, "Uhr") kann wachsen, aber Probleme mit der Energieverteilung und Wärmeableitung Der Anstieg wird möglicherweise zunehmen und hat direkte Vorteile durch große Cache-Footprints und schnellere und umfassendere Speicher-E / A sowie indirekte Vorteile durch weniger häufig erzwungene Systemumschaltungen, da wir mehr Kerne haben können, um andere Threads / Prozesse aufzuteilenO(n^2~3)
Frequency [MHz]
Transistor CountO(n^2~3)
Power [W]
Single Thread Perf

Credits gehen an Leonardo Suriano & Karl Rupp
(Credits gehen an Leonardo Suriano & Karl Rupp)

2020: Still some improvements, prediction for 2025
-------------------------------------------------------------------------
             0.1 ns - NOP
             0.3 ns - XOR, ADD, SUB
             0.5 ns - CPU L1 dCACHE reference           (1st introduced in late 80-ies )
             0.9 ns - JMP SHORT
             1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance -- will stay, throughout any foreseeable future :o)
?~~~~~~~~~~~ 1   ns - MUL ( i**2 = MUL i, i )~~~~~~~~~ doing this 1,000 x is 1 [us]; 1,000,000 x is 1 [ms]; 1,000,000,000 x is 1 [s] ~~~~~~~~~~~~~~~~~~~~~~~~~
           3~4   ns - CPU L2  CACHE reference           (2020/Q1)
             5   ns - CPU L1 iCACHE Branch mispredict
             7   ns - CPU L2  CACHE reference
            10   ns - DIV
            19   ns - CPU L3  CACHE reference           (2020/Q1 considered slow on 28c Skylake)
            71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
           100   ns - MUTEX lock/unlock
           100   ns - own DDR MEMORY reference
           135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
           202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
           325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
|Q>~~~~~ 5,000   ns - QPU on-chip QUBO ( quantum annealer minimiser 1 Qop )
        10,000   ns - Compress 1K bytes with a Zippy PROCESS
        20,000   ns - Send     2K bytes over 1 Gbps  NETWORK
       250,000   ns - Read   1 MB sequentially from  MEMORY
       500,000   ns - Round trip within a same DataCenter
?~~~ 2,500,000   ns - Read  10 MB sequentially from  MEMORY~~(about an empty python process to copy on spawn)~~~~ x ( 1 + nProcesses ) on spawned process instantiation(s), yet an empty python interpreter is indeed not a real-world, production-grade use-case, is it?
    10,000,000   ns - DISK seek
    10,000,000   ns - Read   1 MB sequentially from  NETWORK
?~~ 25,000,000   ns - Read 100 MB sequentially from  MEMORY~~(somewhat light python process to copy on spawn)~~~~ x ( 1 + nProcesses ) on spawned process instantiation(s)
    30,000,000   ns - Read 1 MB sequentially from a  DISK
?~~ 36,000,000   ns - Pickle.dump() SER a 10 MB object for IPC-transfer and remote DES in spawned process~~~~~~~~ x ( 2 ) for a single 10MB parameter-payload SER/DES + add an IPC-transport costs thereof or NETWORK-grade transport costs, if going into [distributed-computing] model Cluster ecosystem
   150,000,000   ns - Send a NETWORK packet CA -> Netherlands
  |   |   |   |
  |   |   | ns|
  |   | us|
  | ms|

Nur um die Überprüfung der Prognosen für 2020 im Jahr 2015 zu überprüfen:

Still some improvements, prediction for 2020 (Ref. olibre's answer below)
-------------------------------------------------------------------------
   16 000 ns ( 16 µs) SSD random read (olibre's note: should be less)
  500 000 ns (  ½ ms) Round trip in datacenter
2 000 000 ns (  2 ms) HDD random read (seek)

In 2015 there are currently available:
========================================================================
      820 ns ( 0.8µs)     random read from a SSD-DataPlane
    1 200 ns ( 1.2µs) Round trip in datacenter
    1 200 ns ( 1.2µs)     random read from a HDD-DataPlane

Nur zum Vergleich der CPU- und GPU-Latenzlandschaft:

Es ist keine leichte Aufgabe, selbst die einfachsten CPU- / Cache- / DRAM-Aufstellungen (selbst in einem einheitlichen Speicherzugriffsmodell) zu vergleichen, bei denen die DRAM-Geschwindigkeit ein Faktor für die Bestimmung der Latenz ist, und die geladene Latenz (gesättigtes System), bei der letztere regiert und gilt Etwas, das die Unternehmensanwendungen mehr als ein vollständig entladenes System im Leerlauf erleben werden.

                    +----------------------------------- 5,6,7,8,9,..12,15,16 
                    |                               +--- 1066,1333,..2800..3300
                    v                               v
First  word = ( ( CAS latency * 2 ) + ( 1 - 1 ) ) / Data Rate  
Fourth word = ( ( CAS latency * 2 ) + ( 4 - 1 ) ) / Data Rate
Eighth word = ( ( CAS latency * 2 ) + ( 8 - 1 ) ) / Data Rate
                                        ^----------------------- 7x .. difference
******************************** 
So:
===

resulting DDR3-side latencies are between _____________
                                          3.03 ns    ^
                                                     |
                                         36.58 ns ___v_ based on DDR3 HW facts

Einheitlicher Speicherzugriff

GPU-Engines haben viel technisches Marketing erhalten, während tiefe interne Abhängigkeiten der Schlüssel sind, um sowohl die wirklichen Stärken als auch die wirklichen Schwächen zu verstehen, die diese Architekturen in der Praxis erfahren (in der Regel ganz anders als die Erwartungen des aggressiven Marketings). 

   1 ns _________ LETS SETUP A TIME/DISTANCE SCALE FIRST:
          °      ^
          |\     |a 1 ft-distance a foton travels in vacuum ( less in dark-fibre )
          | \    |
          |  \   |
        __|___\__v____________________________________________________
          |    |
          |<-->|  a 1 ns TimeDOMAIN "distance", before a foton arrived
          |    |
          ^    v 
    DATA  |    |DATA
    RQST'd|    |RECV'd ( DATA XFER/FETCH latency )

  25 ns @ 1147 MHz FERMI:  GPU Streaming Multiprocessor REGISTER access
  35 ns @ 1147 MHz FERMI:  GPU Streaming Multiprocessor    L1-onHit-[--8kB]CACHE

  70 ns @ 1147 MHz FERMI:  GPU Streaming Multiprocessor SHARED-MEM access

 230 ns @ 1147 MHz FERMI:  GPU Streaming Multiprocessor texL1-onHit-[--5kB]CACHE
 320 ns @ 1147 MHz FERMI:  GPU Streaming Multiprocessor texL2-onHit-[256kB]CACHE

 350 ns
 700 ns @ 1147 MHz FERMI:  GPU Streaming Multiprocessor GLOBAL-MEM access
 - - - - -

Das Verständnis von Internalitäten ist daher viel wichtiger als in anderen Bereichen, in denen Architekturen veröffentlicht werden und zahlreiche Benchmarks frei verfügbar sind. Vielen Dank an die GPU-Mikrotester, die ihre Zeit und Kreativität aufgewendet haben, um die Wahrheit über die tatsächlichen Arbeitsschemata im Black-Box-Ansatz der getesteten GPU-Geräte zu erfahren.

    +====================| + 11-12 [usec] XFER-LATENCY-up   HostToDevice    ~~~ same as Intel X48 / nForce 790i
    |   |||||||||||||||||| + 10-11 [usec] XFER-LATENCY-down DeviceToHost
    |   |||||||||||||||||| ~  5.5 GB/sec XFER-BW-up                         ~~~ same as DDR2/DDR3 throughput
    |   |||||||||||||||||| ~  5.2 GB/sec XFER-BW-down @8192 KB TEST-LOAD      ( immune to attempts to OverClock PCIe_BUS_CLK 100-105-110-115 [MHz] ) [D:4.9.3]
    |                       
    |              Host-side
    |                                                        cudaHostRegister(   void *ptr, size_t size, unsigned int flags )
    |                                                                                                                 | +-------------- cudaHostRegisterPortable -- marks memory as PINNED MEMORY for all CUDA Contexts, not just the one, current, when the allocation was performed
    |                        ___HostAllocWriteCombined_MEM / cudaHostFree()                                           +---------------- cudaHostRegisterMapped   -- maps  memory allocation into the CUDA address space ( the Device pointer can be obtained by a call to cudaHostGetDevicePointer( void **pDevice, void *pHost, unsigned int flags=0 ); )
    |                        ___HostRegisterPORTABLE___MEM / cudaHostUnregister( void *ptr )
    |   ||||||||||||||||||
    |   ||||||||||||||||||
    |   | PCIe-2.0 ( 4x) | ~ 4 GB/s over  4-Lanes ( PORT #2  )
    |   | PCIe-2.0 ( 8x) | ~16 GB/s over  8-Lanes
    |   | PCIe-2.0 (16x) | ~32 GB/s over 16-Lanes ( mode 16x )
    |
    |   + PCIe-3.0 25-port 97-lanes non-blocking SwitchFabric ... +over copper/fiber
    |                                                                       ~~~ The latest PCIe specification, Gen 3, runs at 8Gbps per serial lane, enabling a 48-lane switch to handle a whopping 96 GBytes/sec. of full duplex peer to peer traffic. [I:]
    |
    | ~810 [ns]    + InRam-"Network" / many-to-many parallel CPU/Memory "message" passing with less than 810 ns latency any-to-any
    |
    |   ||||||||||||||||||
    |   ||||||||||||||||||
    +====================|
    |.pci............HOST|

Ich entschuldige mich für ein "größeres Bild", aber die Latenz-Demaskierung hat auch grundlegende Grenzen, die sich aus den smREG / L1 / L2-Kapazitäten auf dem Chip und den Treffer- / Fehlerraten ergeben.

    |.pci............GPU.|
    |                    | FERMI [GPU-CLK] ~ 0.9 [ns] but THE I/O LATENCIES                                                                  PAR -- ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| <800> warps ~~ 24000 + 3200 threads ~~ 27200 threads [!!]
    |                                                                                                                                               ^^^^^^^^|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [!!]
    |                                                       smREGs________________________________________ penalty +400 ~ +800 [GPU_CLKs] latency ( maskable by 400~800 WARPs ) on <Compile-time>-designed spillover(s) to locMEM__
    |                                                                                                              +350 ~ +700 [ns] @1147 MHz FERMI ^^^^^^^^
    |                                                                                                                          |                    ^^^^^^^^
    |                                                                                                                       +5 [ns] @ 200 MHz FPGA. . . . . . Xilinx/Zync Z7020/FPGA massive-parallel streamline-computing mode ev. PicoBlazer softCPU
    |                                                                                                                          |                    ^^^^^^^^
    |                                                                                                                   ~  +20 [ns] @1147 MHz FERMI ^^^^^^^^
    |                                                             SM-REGISTERs/thread: max  63 for CC-2.x -with only about +22 [GPU_CLKs] latency ( maskable by 22-WARPs ) to hide on [REGISTER DEPENDENCY] when arithmetic result is to be served from previous [INSTR] [G]:10.4, Page-46
    |                                                                                  max  63 for CC-3.0 -          about +11 [GPU_CLKs] latency ( maskable by 44-WARPs ) [B]:5.2.3, Page-73
    |                                                                                  max 128 for CC-1.x                                    PAR -- ||||||||~~~|
    |                                                                                  max 255 for CC-3.5                                    PAR -- ||||||||||||||||||~~~~~~|
    |
    |                                                       smREGs___BW                                 ANALYZE REAL USE-PATTERNs IN PTX-creation PHASE <<  -Xptxas -v          || nvcc -maxrregcount ( w|w/o spillover(s) )
    |                                                                with about 8.0  TB/s BW            [C:Pg.46]
    |                                                                           1.3  TB/s BW shaMEM___  4B * 32banks * 15 SMs * half 1.4GHz = 1.3 TB/s only on FERMI
    |                                                                           0.1  TB/s BW gloMEM___
    |         ________________________________________________________________________________________________________________________________________________________________________________________________________________________
    +========|   DEVICE:3 PERSISTENT                          gloMEM___
    |       _|______________________________________________________________________________________________________________________________________________________________________________________________________________________
    +======|   DEVICE:2 PERSISTENT                          gloMEM___
    |     _|______________________________________________________________________________________________________________________________________________________________________________________________________________________
    +====|   DEVICE:1 PERSISTENT                          gloMEM___
    |   _|______________________________________________________________________________________________________________________________________________________________________________________________________________________
    +==|   DEVICE:0 PERSISTENT                          gloMEM_____________________________________________________________________+440 [GPU_CLKs]_________________________________________________________________________|_GB|
    !  |                                                         |\                                                                +                                                                                           |
    o  |                                                texMEM___|_\___________________________________texMEM______________________+_______________________________________________________________________________________|_MB|
       |                                                         |\ \                                 |\                           +                                               |\                                          |
       |                                              texL2cache_| \ \                               .| \_ _ _ _ _ _ _ _texL2cache +370 [GPU_CLKs] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | \                                   256_KB|
       |                                                         |  \ \                               |  \                         +                                 |\            ^  \                                        |
       |                                                         |   \ \                              |   \                        +                                 | \           ^   \                                       |
       |                                                         |    \ \                             |    \                       +                                 |  \          ^    \                                      |
       |                                              texL1cache_|     \ \                           .|     \_ _ _ _ _ _texL1cache +260 [GPU_CLKs] _ _ _ _ _ _ _ _ _ |   \_ _ _ _ _^     \                                 5_KB|
       |                                                         |      \ \                           |      \                     +                         ^\      ^    \        ^\     \                                    |
       |                                     shaMEM + conL3cache_|       \ \                          |       \ _ _ _ _ conL3cache +220 [GPU_CLKs]           ^ \     ^     \       ^ \     \                              32_KB|
       |                                                         |        \ \                         |        \       ^\          +                         ^  \    ^      \      ^  \     \                                  |
       |                                                         |         \ \                        |         \      ^ \         +                         ^   \   ^       \     ^   \     \                                 |
       |                                   ______________________|__________\_\_______________________|__________\_____^__\________+__________________________________________\_________\_____\________________________________|
       |                  +220 [GPU-CLKs]_|           |_ _ _  ___|\          \ \_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ \ _ _ _ _\_ _ _ _+220 [GPU_CLKs] on re-use at some +50 GPU_CLKs _IF_ a FETCH from yet-in-shaL2cache
       | L2-on-re-use-only +80 [GPU-CLKs]_| 64 KB  L2_|_ _ _   __|\\          \ \_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ \ _ _ _ _\_ _ _ + 80 [GPU_CLKs] on re-use from L1-cached (HIT) _IF_ a FETCH from yet-in-shaL1cache
       | L1-on-re-use-only +40 [GPU-CLKs]_|  8 KB  L1_|_ _ _    _|\\\          \_\__________________________________\________\_____+ 40 [GPU_CLKs]_____________________________________________________________________________|
       | L1-on-re-use-only + 8 [GPU-CLKs]_|  2 KB  L1_|__________|\\\\__________\_\__________________________________\________\____+  8 [GPU_CLKs]_________________________________________________________conL1cache      2_KB|
       |     on-chip|smREG +22 [GPU-CLKs]_|           |t[0_______^:~~~~~~~~~~~~~~~~\:________]
       |CC-  MAX    |_|_|_|_|_|_|_|_|_|_|_|           |t[1_______^                  :________]
       |2.x   63    |_|_|_|_|_|_|_|_|_|_|_|           |t[2_______^                  :________] 
       |1.x  128    |_|_|_|_|_|_|_|_|_|_|_|           |t[3_______^                  :________]
       |3.5  255 REGISTERs|_|_|_|_|_|_|_|_|           |t[4_______^                  :________]
       |         per|_|_|_|_|_|_|_|_|_|_|_|           |t[5_______^                  :________]
       |         Thread_|_|_|_|_|_|_|_|_|_|           |t[6_______^                  :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[7_______^     1stHalf-WARP :________]______________
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[ 8_______^:~~~~~~~~~~~~~~~~~:________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[ 9_______^                  :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[ A_______^                  :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[ B_______^                  :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[ C_______^                  :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[ D_______^                  :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           |t[ E_______^                  :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|       W0..|t[ F_______^____________WARP__:________]_____________
       |            |_|_|_|_|_|_|_|_|_|_|_|         ..............             
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[0_______^:~~~~~~~~~~~~~~~\:________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[1_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[2_______^                 :________] 
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[3_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[4_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[5_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[6_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[7_______^    1stHalf-WARP :________]______________
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[ 8_______^:~~~~~~~~~~~~~~~~:________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[ 9_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[ A_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[ B_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[ C_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[ D_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|           ............|t[ E_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|       W1..............|t[ F_______^___________WARP__:________]_____________
       |            |_|_|_|_|_|_|_|_|_|_|_|         ....................................................
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[0_______^:~~~~~~~~~~~~~~~\:________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[1_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[2_______^                 :________] 
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[3_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[4_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[5_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[6_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[7_______^    1stHalf-WARP :________]______________
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[ 8_______^:~~~~~~~~~~~~~~~~:________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[ 9_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[ A_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[ B_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[ C_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[ D_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|          ...................................................|t[ E_______^                 :________]
       |            |_|_|_|_|_|_|_|_|_|_|_|tBlock Wn....................................................|t[ F_______^___________WARP__:________]_____________
       |
       |                   ________________          °°°°°°°°°°°°°°°°°°°°°°°°°°~~~~~~~~~~°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
       |                  /                \   CC-2.0|||||||||||||||||||||||||| ~masked  ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
       |                 /                  \  1.hW  ^|^|^|^|^|^|^|^|^|^|^|^|^| <wait>-s ^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|
       |                /                    \ 2.hW  |^|^|^|^|^|^|^|^|^|^|^|^|^          |^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^|^
       |_______________/                      \______I|I|I|I|I|I|I|I|I|I|I|I|I|~~~~~~~~~~I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|I|
       |~~~~~~~~~~~~~~/ SM:0.warpScheduler    /~~~~~~~I~I~I~I~I~I~I~I~I~I~I~I~I~~~~~~~~~~~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I~I
       |              \          |           //
       |               \         RR-mode    //
       |                \    GREEDY-mode   //
       |                 \________________//
       |                   \______________/SM:0__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:1__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:2__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:3__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:4__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:5__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:6__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:7__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:8__________________________________________________________________________________
       |                                  |           |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:9__________________________________________________________________________________
       |                                ..|SM:A      |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:B      |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:C      |t[ F_______^___________WARP__:________]_______
       |                                ..|SM:D      |t[ F_______^___________WARP__:________]_______
       |                                  |_______________________________________________________________________________________
       */

Das Endergebnis?

Jedes Design mit geringer Latenzzeit muss die "E / A-Hydraulik" (da 0 1-XFERs von Natur aus inkompressibel sind) eher rückentwickeln, und die daraus resultierenden Latenzen bestimmen den Leistungsumfang für jede GPGPU-Lösung, sei es rechenintensiv ( Lesen) : Wo Verarbeitungskosten etwas mehr XFERs mit schlechter Latenz verzeihen ...) oder nicht ( lesen Sie : Wo (könnte zu einer Überraschung sein) CPUs in der End-to-End-Verarbeitung schneller sind als GPU-Fabrics [Zitate verfügbar] ).

user3666197
quelle
7
Ich habe versucht, Ihre Antwort zu verstehen. Es scheint sehr interessant zu sein, aber ASCII-Diagramme sind aufgrund von Einschränkungen in Bezug auf hohe / breite Breite nicht leicht zu lesen. Entschuldigung, ich weiß nicht, wie dies verbessert werden könnte ... Schließlich fehlt mir eine Zusammenfassung (am Ende weiß ich nicht, was ich über CPU- oder GPU-Latenzen denken soll). Ich hoffe, Sie können Ihre Antwort verbessern, um ein besseres Aussehen und eine bessere Verständlichkeit für den Menschen zu erzielen. Mut. Prost :-D
olibre
3

Schauen Sie sich dieses "Treppenhaus" -Diagramm an, das die verschiedenen Zugriffszeiten (in Bezug auf die Uhrzeit) perfekt darstellt. Beachten Sie, dass die rote CPU einen zusätzlichen "Schritt" hat, wahrscheinlich weil sie L4 hat (während andere dies nicht tun).

Diagramme der Zugriffszeiten mit unterschiedlichen Speicherhierarchien

Entnommen aus diesem Extremetech-Artikel.

In der Informatik wird dies als "E / A-Komplexität" bezeichnet.

Oskar Person
quelle