Przybliżony koszt dostępu do różnych pamięci podręcznych i pamięci głównej?

178

Czy ktoś może podać mi przybliżony czas (w nanosekundach) uzyskania dostępu do pamięci podręcznych L1, L2 i L3, a także pamięci głównej na procesorach Intel i7?

Chociaż nie jest to konkretnie kwestia programowania, znajomość tego rodzaju szczegółów dotyczących prędkości jest konieczna w przypadku niektórych wyzwań programistycznych o niskim opóźnieniu.

memory latency cpu-cache low-latency Ted Graham
źródło

Mechanical-sympathy.blogspot.com/2013/02/…

Beachhouse

1

Jak zamienić ns na cykle? Jeśli po prostu podzielę 100 ns przez 2,3 GHz, otrzymam 230 cykli. Czy to jest poprawne?

Nathan

5

Jestem ciekawy: w jakiej sytuacji zdalna pamięć podręczna L3 jest wolniejsza niż zdalna pamięć DRAM? Powyższa liczba wskazuje, że może być 1,6 razy wolniejsza.

netvope

1

Nie edytuj pytania, zamiast tego opublikuj odpowiedź z tymi szczegółami. Samoodbieranie się jest w porządku w trybie SO.

Stijn de Witt

Czy są jakieś przybliżone wartości zużycia energii na dostęp do pamięci z każdego poziomu?

kanna

74

Oto przewodnik po analizie wydajności dla serii procesorów i7 i Xeon. Powinienem podkreślić, że ma to, czego potrzebujesz, a nawet więcej (na przykład sprawdź na stronie 22 niektóre czasy i cykle na przykład).

Dodatkowo ta strona zawiera szczegółowe informacje na temat cykli zegarowych itp. Drugi link służył do obsługi następujących numerów:

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:
Najważniejsza jest notatka pod cytowaną tabelą o treści:

_{"UWAGA: TE WARTOŚCI SĄ PRZYBLIŻENIAMI. ZALEŻĄ OD CZĘSTOTLIWOŚCI RDZENIA I NIEBEZPIECZEŃSTWA, PRĘDKOŚCI PAMIĘCI, USTAWIEŃ BIOSU, LICZB DIMMS , ITP. ITP. PRZEBIEG MOŻE SIĘ RÓŻNIĆ. "}

EDYCJA: Powinienem podkreślić, że oprócz informacji o czasie / cyklu, powyższy dokument Intel odnosi się do znacznie bardziej (niezwykle) przydatnych szczegółów dotyczących procesorów i7 i Xeon (z punktu widzenia wydajności).

Dave
źródło

1

Czy „linia nieudostępniona” nie powinna mieć większego opóźnienia niż „linia współdzielona w innym rdzeniu” - linia współdzielona (tj. 2 prawidłowe bity rdzenia) oznacza, że można ją pobrać bezpośrednio z wycinka LLC, ponieważ gwarantuje się, że jest czysty. „Linia niewspółdzielona” oznacza, że jest tylko jeden ważny bit rdzenia i ten rdzeń musi być przeszukany, aby upewnić się, że linia jest wyłączna i nie jest modyfikowana - jeśli jest modyfikowana, jest zmieniana na współdzieloną; LLC staje się teraz brudna i jest zwracana do rdzenia żądającego jako współdzielona. Może się mylę - wiem, że protokół MOESI jest inny.

Lewis Kelsey

1

Z pewnością tak jest w przypadku SnB i Haswell. Nehalem - którego używa ten Xeon - był przed topologią magistrali pierścieniowej i miał zunifikowaną pamięć podręczną, ale nie rozumiem, dlaczego filtr snoop zachowywałby się inaczej w Nehalem. Sekcja podręcznika optymalizacji B.3.5.3 podaje, jak czuję, nieprawidłowy opis (wyraźnie odnosi się do Nehalem, ponieważ mówi o Global Queue, która jest funkcją Nehalem). Ten artykuł Haswell ma lepszy opis (prawa górna kolumna strony 5) ( tu-dresden.de/zih/forschung/ressourcen/dateien/… )

Lewis Kelsey,

@LewisKelsey: To również jest dla mnie zaskakujące, ponieważ myślałem, że połowa celu włączenia L3 była taka, że L3 może po prostu odpowiedzieć, jeśli ma prawidłową kopię wiersza. Ale pamiętaj, Intel używa MESIF ( en.wikipedia.org/wiki/MESIF_protocol ) dla NUMA, AMD używa MOESI. Myślę jednak, że w jednym gnieździe MESIF tak naprawdę nie jest rzeczą, ponieważ dane pochodzą z L3, a nie core-> core. Więc jest to prawdopodobnie bardziej odpowiednie dla transferów L3 cache-> cache przez gniazda. Zastanawiam się, czy to „lokalne trafienie L3” dotyczy linii współdzielonej z rdzeniem w innym gnieździe? Nadal nie ma sensu, ważny w L3 oznacza, że żaden rdzeń nie ma E / M

Peter Cordes

@PeterCordes Zapamiętałem ten komentarz i wróciłem, a to, co powiedziałem, wydało mi się natychmiast błędne. Mój komentarz jest poprawny z perspektywy trzeciego rdzenia, w którym jest on dzielony między 2 inne rdzenie lub po prostu wyłączny dla jednego innego rdzenia. Ale jeśli mówisz o linii niewspółdzielonej i należy ona do rdzenia, który próbuje uzyskać dostęp do linii, to test porównawczy jest właściwy, ponieważ współdzielony wymaga RFO, aby uzyskać wyłączność i wyłączność, co oznacza, że nie jest wymagane takie RFO. Więc nie wiem, co naprawdę powiedziałem.

Lewis Kelsey

@LewisKelsey: Tak, to wszystko prawda, jeśli chodzi o pisanie. Myślałem, że dotyczy to odczytu ( opóźnienie źródła danych ), które jest bardziej wrażliwe na opóźnienia. Czytanie linii nigdy nie wymaga RFO, tylko prośby o udostępnienie. Czy zatem linia, która jest już gdzieś w stanie Shared, nie powinna po prostu trafić w L3 tego gniazda bez konieczności czekania na ruch koherencyjny? A zatem być szybszym niż DRAM, podobnie jak „niewspółdzielone” trafienie L3.

Peter Cordes

189

Liczby, które każdy powinien znać

           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|

Od: Pierwotnie 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

Andrey
źródło

11

Z pewnością dbają o bardzo DUŻE ilości, w oparciu o konstrukcję procesora, opóźnienie / częstotliwość pamięci RAM, buforowanie dysku twardego (zarówno typ, jak i rozmiar) / rpm itp. Itp.? Cytując firmę INTEL (dla wartości wydanych dla jednego konkretnego procesora): „UWAGA: Te wartości są przybliżonymi wartościami. Zależą one od częstotliwości rdzenia i uncore, szybkości pamięci, ustawień BIOS, liczby pamięci DIMMS itp. Itp. PRZEBIEG MOŻE SIĘ RÓŻNIĆ. . ”

Dave

28

@Dave to prawda, ale te liczby pokazują rząd wielkości

Andrey

8

@Dave, chociaż typ / prędkość / architektura procesora są różne, uważam, że względne czasy powinny z grubsza pozostać takie same, więc jest to tylko przybliżona wytyczna, aby wiedzieć, kiedy kodujesz. Bardziej znacząca analiza powinna być oczywiście przeprowadzona za pomocą profilera ...

xosp7tom

8

Aby dowiedzieć się, ile to czasu, Wikipedia wspomina: „Jedna nanosekunda to jedna sekunda, a jedna sekunda to 31,7 lat”. en.wikipedia.org/wiki/Nanosecond

Only You

2

@kernel jeśli brakuje pamięci podręcznej, oznacza to, że będzie wymagał dostępu do pamięci podręcznej niższego poziomu lub nawet do pamięci głównej. W takim przypadku zajmie to trochę czasu zgodnie z czasem dostępu do tego poziomu. Możesz poszukać danych dotyczących nowszych procesorów tutaj sisoftware.net/?d=qa&f=ben_mem_latency

Andrey

39

Koszt dostępu do różnych wspomnień na ładnej stronie

Zobacz tę stronę przedstawiającą spadek latencji pamięci w latach 1990-2020 .

Podsumowanie

Wartości spadły, ale ustabilizowały się od 2005 r

        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

Jeszcze kilka ulepszeń, prognozy na 2020 rok

   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)

Zobacz także inne źródła

Co każdy programista powinien wiedzieć o pamięci od Ulricha Dreppera (2007)
Stare, ale wciąż doskonałe, głębokie wyjaśnienie dotyczące interakcji pamięci i oprogramowania.
- Cały PDF (114 stron)
  - Komentarze do LWN o wersji PDF
  - kolejne z nich
- Siedem postów na LWN + Komentarze
Opublikuj Nieskończoną przestrzeń między słowami na stronie codinghorror.com na podstawie książki Systems Performance: Enterprise and the Cloud
Kliknij każdy procesor wymieniony na http://www.7-cpu.com/, aby zobaczyć opóźnienia L1 / L2 / L3 / RAM / ... (np. Haswell i7-4770 ma L1 = 1ns, L2 = 3ns, L3 = 10ns, RAM = 67ns, BranchMisprediction = 4ns)
http://idarkside.org/posts/numbers-you-should-know/

Zobacz też

Dla dalszego zrozumienia polecam doskonałą prezentację nowoczesnych architektur pamięci podręcznej (czerwiec 2014) autorstwa Gerharda Welleina , Hannesa Hofmanna i Dietmara Feya z University Erlangen-Nürnberg .

Osoby francuskojęzyczne mogą docenić artykuł SpaceFox, w którym porównuje procesor z deweloperem oczekującym na informacje potrzebne do dalszej pracy.

olibre
źródło

piękny post z opóźnieniem. dobrze byłoby dodać fakty dotyczące rzeczywistości maskowania opóźnień GPU (

user3666197

Cześć @ user3666197 Czy masz jakieś źródła informacji o opóźnieniach pamięci związanych z GPU? Pozdrawiam :-)

olibre

Z pewnością tak, @olibre. Sprawdź [A]zamieszczone poniżej.

user3666197

1

Biorąc pod uwagę, jak to jest z opóźnieniem i buforowaniem, uważam za ironiczne, że strona pod twoim pierwszym linkiem, z suwakiem roku, nie buforuje wyświetlania metryki podczas zmiany roku. Przynajmniej w Firefoksie renderują się zbyt wolno, aby przeciągać przez lata, aby były płynne: /

John Glassmyer,

1

Niezłe referencje, podaliście tytuły i autorów!

SamB

22

Ze względu na przegląd prognoz na rok 2025 na 2020 rok:

W ciągu ostatnich około 44 lat technologii układów scalonych, klasyczne (niekwantowe) procesory ewoluowały, dosłownie i fizycznie „Per Aspera ad Astra” . Ostatnia dekada pokazała, że klasyczny proces zbliżył się do pewnych przeszkód, które nie mają możliwej do osiągnięcia fizycznej ścieżki naprzód.

Number of logical coresmoże i może rosnąć, ale nie więcej niż trudno, jeśli nie niemożliwe do obejścia pułapu opartego na fizyce, który już uderzył, może i może wzrosnąć, ale może wzrosnąć mniej niż (moc, hałas, „zegar”) , ale problemy z dystrybucją energii i rozpraszaniem ciepła wzrośnie, może wzrosnąć, mając bezpośrednie korzyści z dużych rozmiarów pamięci podręcznej i szybszego i szerszego we / wy pamięci i pośrednich korzyści z rzadszego wymuszanego przełączania kontekstu, ponieważ możemy mieć więcej rdzeni do podziału innych wątków / procesów międzyO(n^2~3)
Frequency [MHz]
Transistor CountO(n^2~3)
Power [W]
Single Thread Perf

_{(Kredyty należą do Leonardo Suriano i Karla Ruppa)}

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|

Ze względu na przegląd prognoz na rok 2020 z 2015 roku:

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

Dla porównania krajobrazu opóźnień CPU i GPU:

Porównanie nawet najprostszych układów CPU / cache / DRAM (nawet w jednolitym modelu dostępu do pamięci) nie jest łatwym zadaniem, w którym prędkość DRAM jest czynnikiem określającym opóźnienie, a opóźnienie załadowane (system nasycony), gdzie to ostatnie rządzi i jest coś, czego aplikacje korporacyjne będą doświadczać bardziej niż bezczynny, całkowicie rozładowany system.

                    +----------------------------------- 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

Silniki GPU otrzymały wiele technicznego marketingu, podczas gdy głębokie wewnętrzne zależności są kluczem do zrozumienia zarówno prawdziwych mocnych stron, jak i prawdziwych słabości, których te architektury doświadczają w praktyce (zazwyczaj znacznie różnią się od oczekiwań agresywnego marketingu).

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

Zrozumienie wewnętrznych aspektów jest zatem znacznie ważniejsze niż w innych dziedzinach, w których publikowane są architektury i liczne testy porównawcze dostępne bezpłatnie. Wielkie podziękowania dla mikrotesterów GPU, którzy poświęcili swój czas i kreatywność, aby ujawnić prawdę o prawdziwych schematach pracy w testowanych urządzeniach GPU metodą czarnej skrzynki.

    +====================| + 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|

Przepraszam za "szerszy obraz", ale demaskowanie opóźnień ma również kardynalne ograniczenia wynikające z pojemności smREG / L1 / L2 na chipie i współczynników trafień / błędów.

    |.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__:________]_______
       |                                  |_______________________________________________________________________________________
       */

Podsumowanie?

Każdy projekt oparty na małych opóźnieniach musi raczej poddawać inżynierii wstecznej "I / O-hydraulikę" (ponieważ 0 1-XFER są z natury nieściśliwe), a wynikające z nich opóźnienia rządzą obwiednią wydajności dowolnego rozwiązania GPGPU, niezależnie od tego, czy jest ono wymagające obliczeniowo ( czytaj : gdzie koszty przetwarzania wybaczają nieco bardziej słabe opóźnienia XFER ...) lub nie ( czytaj : gdzie (może być czyjeś zdziwienie) procesory są szybsze w przetwarzaniu end-to-end, niż struktury GPU [dostępne cytaty] ).

user3666197
źródło

7

Próbowałem zrozumieć twoją odpowiedź. Wydaje się to bardzo interesujące, ale wykresy ASCII nie są łatwe do odczytania z powodu ograniczeń dużej / szerokości. Przepraszam, nie wiem, jak można by to poprawić ... Wreszcie brakuje mi podsumowania (na koniec nie wiem, co myśleć o opóźnieniach CPU w porównaniu z GPU). Mam nadzieję, że możesz poprawić swoją odpowiedź, aby zapewnić lepszy efektowny wygląd i zrozumiałość dla ludzi. Odwaga. Pozdrawiam :-D

olibre

3

Spójrz na ten wykres "klatki schodowej", doskonale ilustrujący różne czasy dostępu (pod względem tików zegara). Zauważ, że czerwony procesor ma dodatkowy „krok”, prawdopodobnie dlatego, że ma L4 (podczas gdy inne nie).

Wykresy czasów dostępu z różnymi hierarchiami pamięci

Zaczerpnięte z tego artykułu Extremetech.

W informatyce nazywa się to „złożonością we / wy”.

Oskar Person
źródło