Custo aproximado para acessar vários caches e memória principal?

178

Alguém pode me dar o tempo aproximado (em nanossegundos) para acessar os caches L1, L2 e L3, bem como a memória principal nos processadores Intel i7?

Embora isso não seja especificamente uma questão de programação, conhecer esses tipos de detalhes de velocidade é necessário para alguns desafios de programação de baixa latência.

memory latency cpu-cache low-latency Ted Graham
fonte
Mechanical-sympathy.blogspot.com/2013/02/…
Beachhouse
1
Como faço para converter ns em ciclos? Se eu simplesmente dividir 100 ns por 2,3 GHz, recebo 230 ciclos. Isso está correto?
Nathan
5
Estou curioso: em que situação o cache L3 remoto é mais lento que o DRAM remoto? O número acima indica que pode ser 1,6x mais lento.
Netvope
1
Não edite a pergunta, mas poste uma resposta com esses detalhes. A resposta automática está correta no SO.
Stijn de Witt
Existem valores aproximados para o consumo de energia para acesso à memória de cada nível?
kanna

Respostas:

74

Aqui está um Guia de Análise de Desempenho para os processadores i7 e Xeon. Devo enfatizar, isso tem o que você precisa e muito mais (por exemplo, consulte a página 22 para alguns horários e ciclos, por exemplo).

Além disso, esta página possui alguns detalhes sobre ciclos de relógio etc. O segundo link exibia os seguintes números: 

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:
O mais importante é o aviso abaixo da tabela citada, dizendo:

"NOTA: ESTES VALORES SÃO APROXIMADOS ÁSPEROS . DEPENDEM DE FREQÜÊNCIAS PRINCIPAIS E INCORPORADAS, VELOCIDADES DE MEMÓRIA, CONFIGURAÇÕES DO BIOS, NÚMEROS DE DIMMOS , ETC, ETC .. SUA MILHA PODE VARIAR. "

EDIT: Devo destacar que, além das informações de tempo / ciclo, o documento intel acima aborda detalhes muito mais (extremamente) úteis dos processadores i7 e Xeon (do ponto de vista do desempenho).

Dave
fonte
1
'Linha não compartilhada' não deve ter mais latência do que 'linha compartilhada em outro núcleo' - uma linha compartilhada (ou seja, dois bits válidos no núcleo) significa que pode ser obtida diretamente da fatia da LLC, pois é garantido que está limpo. 'Linha não compartilhada' significa que existe apenas um bit válido do núcleo e esse núcleo deve ser espionado para garantir que a linha seja exclusiva e não seja modificada - se for modificada, será alterada para compartilhada; A LLC agora fica suja e é retornada ao núcleo solicitante como compartilhado. Talvez eu esteja errado - eu sei que o protocolo MOESI é diferente.
Lewis Kelsey
1
Certamente este é o caso de SnB e Haswell. O Nehalem - que esse Xeon usa - estava antes da topologia do barramento em anel e tinha um cache unificado, mas não vejo por que o filtro snoop se comportaria de maneira diferente no Nehalem. A seção do manual de otimização B.3.5.3 fornece uma descrição incorreta (ela se refere claramente a Nehalem, pois fala sobre a Fila Global, que é um recurso da Nehalem). Este papel Haswell tem uma melhor descrição (topo da coluna da direita da página 5) ( tu-dresden.de/zih/forschung/ressourcen/dateien/... )
Lewis Kelsey
@LewisKelsey: Isso também é surpreendente para mim, porque pensei que metade do ponto do L3 inclusivo era que o L3 poderia simplesmente responder se tivesse uma cópia válida de uma linha. Mas lembre-se, a Intel usa o MESIF ( en.wikipedia.org/wiki/MESIF_protocol ) para NUMA, a AMD usa o MOESI. Acho que dentro de um único soquete, porém, o MESIF não é realmente uma coisa, porque os dados vêm do L3, não do core-> core. Portanto, é provavelmente mais relevante para o cache L3-> transferências de cache entre soquetes. Gostaria de saber se este "hit L3 local" é para uma linha compartilhada com um núcleo em outro soquete? Ainda não faz sentido, válida em L3 significa nenhum núcleo tem E / M
Peter Cordes
@ PeterCordes Lembrei-me deste comentário e voltei, e o que eu disse me pareceu imediatamente errado. Meu comentário está correto na perspectiva de um terceiro núcleo, onde é compartilhado entre dois outros núcleos ou apenas exclusivo para outro núcleo. Mas se você está falando sobre uma linha não compartilhada e ela pertence ao núcleo que está tentando acessá-la, a referência é certa porque o compartilhamento exige que uma RFO a obtenha e é exclusiva e exclusiva significa que não existe uma RFO necessária. Então, eu realmente não sei o que estava dizendo.
Lewis Kelsey
@LewisKelsey: Sim, isso é verdade para a escrita. Eu pensei que era para leitura ( latência da fonte de dados ), que é mais sensível à latência. Ler uma linha nunca requer uma solicitação de cotação, apenas uma solicitação para compartilhar. Portanto, uma linha que já não está no estado Compartilhado em algum lugar, deve ser inserida no L3 desse soquete sem ter que esperar pelo tráfego de coerência? E, portanto, seja mais rápido que a DRAM, semelhante a um hit L3 "não compartilhado".
Peter Cordes
189

Números que todos deveriam saber

           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|

De: Originalmente por 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

uma comparação visual

Andrey
fonte
11
Certamente eles se importam com quantidades ENORMES, com base no design do processador, latência / frequência da RAM, cache do disco rígido (tipo e tamanho) / rpm etc etc? Para citar a INTEL (para valores lançados para uma CPU específica): "NOTA: Esses valores são aproximações aproximadas. Eles dependem das frequências Core e Uncore, velocidade da memória, configurações do BIOS, número de DIMMS, etc. Sua milhagem pode variar .. . "
Dave
28
@ Dave isso é verdade, mas estes números mostram a ordem de grandeza
Andrey
8
@ Dave, mesmo que o tipo / velocidade / arquitetura da CPU seja diferente, acredito que o tempo relativo deve permanecer aproximadamente o mesmo, portanto, é apenas uma orientação para saber quando você codifica. Uma análise mais significativa deve ser feito via profiler é claro ...
xosp7tom
8
Para se ter uma idéia de quanto tempo leva, a Wikipedia menciona "Um nanossegundo é um segundo e um segundo é 31,7 anos". en.wikipedia.org/wiki/Nanosecond
Only You
2
@kernel se houver falta de cache, significa que será necessário acessar o cache de nível inferior ou até a memória principal. Nesse caso, levará tempo de acordo com o nível de tempo de acesso. Você pode olhar para os dados para CPUs mais recentes aqui sisoftware.net/?d=qa&f=ben_mem_latency
Andrey
39

Custo para acessar várias memórias em uma página bonita

Resumo

  1. Valores que diminuíram, mas estão estabilizados desde 2005

            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. Ainda algumas melhorias, previsão para 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)

Veja também outras fontes

Veja também

Para um entendimento mais aprofundado, recomendo a excelente apresentação das arquiteturas de cache modernas (junho de 2014) de Gerhard Wellein , Hannes Hofmann e Dietmar Fey na Universidade Erlangen-Nürnberg .

As pessoas que falam francês podem apreciar um artigo da SpaceFox comparando um processador com um desenvolvedor, aguardando as informações necessárias para continuar funcionando.

olibre
fonte
uma adorável postagem de latência. seria bom para adicionar os fatos sobre a realidade mascaramento GPU latência (
user3666197
Olá @ user3666197 Você tem algumas fontes sobre a latência de memória relacionada à GPU? Cheers :-)
olibre
Certamente, sim, @olibre. Confira o [A]post abaixo.
user3666197
1
Dado que se trata de latência e cache, acho irônico que a página no seu primeiro link, com o controle deslizante de ano, não armazene em cache a exibição da métrica ao alterar o ano. No Firefox, pelo menos, eles renderizam muito devagar para arrastar ao longo dos anos para que sejam suaves: /
John Glassmyer
1
Boas referências, você deu títulos e autores!
SamB 14/12
22

Apenas para uma revisão de 2020 das previsões para 2025:

Nos últimos 44 anos da tecnologia de circuitos integrados, os processadores clássicos (não quânticos) evoluíram literal e fisicamente "Per Aspera ad Astra" . A última década evidenciou que o processo clássico chegou perto de alguns obstáculos, que não têm um caminho físico viável à frente.

Number of logical corespode e pode crescer, mas não mais do que dificilmente, se não impossível, contornar o teto baseado na física já atingido pode e pode crescer, ainda menos do que (potência, ruído, "relógio") pode crescer, ainda que problemas com a distribuição de energia e a dissipação de calor o aumento pode crescer, tendo benefícios diretos com grandes pegadas de cache e benefícios de E / S de memória mais rápidos e amplos e benefícios indiretos da troca de contexto forçada pelo sistema com menos frequência, pois podemos ter mais núcleos para dividir outros threads / processos entreO(n^2~3)
Frequency [MHz]
Transistor CountO(n^2~3)
Power [W]
Single Thread Perf

Os créditos vão para Leonardo Suriano e Karl Rupp
(Os créditos vão para Leonardo Suriano e 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|

Apenas para uma revisão de 2015 das previsões para 2020:

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

Apenas para comparar o cenário de latência de CPU e GPU:

Não é uma tarefa fácil comparar até mesmo as mais simples linhas de CPU / cache / DRAM (mesmo em um modelo uniforme de acesso à memória), em que a velocidade da DRAM é um fator na determinação da latência e da latência carregada (sistema saturado), onde o último governa e é algo que os aplicativos corporativos experimentarão mais do que um sistema ocioso e totalmente descarregado.

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

Acesso uniforme à memória

Os mecanismos de GPU receberam muito marketing técnico, enquanto profundas dependências internas são fundamentais para entender os pontos fortes reais e também os pontos fracos reais que essas arquiteturas experimentam na prática (geralmente muito diferentes das expectativas assobiadas pelo marketing agressivo). 

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

Portanto, entender as internalidades é muito mais importante do que em outros campos, onde as arquiteturas são publicadas e vários benchmarks disponíveis gratuitamente. Muito obrigado aos microtestadores de GPU, que gastaram seu tempo e criatividade para revelar a verdade dos verdadeiros esquemas de trabalho dentro da abordagem de caixa preta dos dispositivos de GPU testados.

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

Peço desculpas por uma "imagem maior", mas o excesso de latência também tem limites cardinais impostos pelas capacidades smREG / L1 / L2 e taxas de acerto / erro do chip.

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

A linha inferior?

Qualquer projeto motivado por baixa latência precisa fazer engenharia reversa da "hidráulica de E / S" (como 0 1-XFERs são incompressíveis por natureza) e as latências resultantes governam o envelope de desempenho para qualquer solução de GPGPU, seja intensivamente computacional ( leia-se : onde os custos de processamento estão perdoando um pouco mais os XFERs de baixa latência ...) ou não ( leia-se : (onde pode ser a surpresa de alguém) Os CPU-s são mais rápidos no processamento de ponta a ponta do que os tecidos GPU [citações disponíveis] )

user3666197
fonte
7
Eu tentei entender sua resposta. Parece muito interessante, mas os gráficos ASCII não são fáceis de ler devido a limitações de largura / largura. Desculpe, não sei como isso poderia ser melhorado ... Finalmente, estou com falta de um resumo (no final, não sei o que pensar sobre latências de CPU vs. GPU). Espero que você possa melhorar sua resposta para fornecer uma melhor aparência atraente e compreensão humana. Coragem. Cheers :-D
olibre
3

Veja este gráfico de "escadaria", ilustrando perfeitamente diferentes tempos de acesso (em termos de tiques do relógio). Observe que a CPU vermelha possui uma "etapa" adicional, provavelmente porque possui L4 (enquanto outras não).

Gráficos de tempos de acesso com diferentes hierarquias de memória

Retirado deste artigo da Extremetech.

Na ciência da computação, isso é chamado de "complexidade de E / S".

Pessoa de Oskar
fonte