Coût approximatif pour accéder à divers caches et à la mémoire principale?

Question 1

Quelqu'un peut-il me donner le temps approximatif (en nanosecondes) pour accéder aux caches L1, L2 et L3, ainsi qu'à la mémoire principale sur les processeurs Intel i7?

Bien que ce ne soit pas spécifiquement une question de programmation, connaître ces types de détails de vitesse est nécessaire pour certains défis de programmation à faible latence.

Question 2

Voici un guide d'analyse des performances pour la gamme de processeurs i7 et Xeon. Je dois insister sur le fait que cela a ce dont vous avez besoin et plus (par exemple, consultez la page 22 pour certains horaires et cycles par exemple).

De plus, cette page contient des détails sur les cycles d'horloge, etc. Le deuxième lien servait les numéros suivants:

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:
Le plus important est l'avis sous le tableau cité, disant:

_{"REMARQUE: CES VALEURS SONT DES APPROXIMATIONS BRUTES . ILS DÉPENDENT DES FRÉQUENCES NOYAU ET NON COEUR, DES VITESSES DE LA MÉMOIRE , DES PARAMÈTRES DU BIOS, DU NOMBRE DE DIMMS , ETC, ETC. VOTRE KILOMÉTRAGE PEUT VARIER. "}

EDIT: Je dois souligner que, en plus des informations de synchronisation / cycle, le document Intel ci-dessus traite beaucoup plus de détails (extrêmement) utiles de la gamme de processeurs i7 et Xeon (d'un point de vue des performances).

Question 3

Des chiffres que tout le monde devrait connaître

           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: À l'origine par 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

Question 4

Coût pour accéder à divers souvenirs dans une jolie page

Voir cette page présentant la diminution de la latence mémoire de 1990 à 2020 .

Sommaire

Valeurs en baisse mais stabilisées depuis 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

Encore quelques améliorations, prévision pour 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)

Voir aussi d'autres sources

Ce que tout programmeur devrait savoir sur la mémoire par Ulrich Drepper (2007)
Ancienne mais toujours une excellente explication approfondie sur l'interaction entre le matériel mémoire et le logiciel.
- PDF complet (114 pages)
  - Commentaires sur LWN sur la version PDF
  - Un autre les
- Sept articles sur LWN + Commentaires
Publiez l' espace infini entre les mots dans codinghorror.com basé sur le livre Systems Performance: Enterprise and the Cloud
Cliquez sur chaque processeur répertorié sur http://www.7-cpu.com/ pour voir les latences L1 / L2 / L3 / RAM / ... (par exemple, Haswell i7-4770 a L1 = 1ns, L2 = 3ns, L3 = 10 ns, RAM = 67 ns, erreur de branche = 4 ns)
http://idarkside.org/posts/numbers-you-should-know/

Voir également

Pour une meilleure compréhension, je recommande l'excellente présentation des architectures de cache modernes (juin 2014) de Gerhard Wellein , Hannes Hofmann et Dietmar Fey de l' Université Erlangen-Nürnberg .

Les francophones apprécieront peut-être un article de SpaceFox comparant un processeur à un développeur en attente des informations nécessaires pour continuer à travailler.

Question 5

Juste pour le plaisir de l'examen de 2020 des prévisions pour 2025:

Au cours des 44 dernières années de la technologie des circuits intégrés, les processeurs classiques (non quantiques) ont évolué, littéralement et physiquement "Per Aspera ad Astra" . La dernière décennie a démontré que le processus classique s'est rapproché de certains obstacles, qui n'ont pas de chemin physique réalisable.

Number of logical corespeut et peut croître, mais pas plus que ce qui est difficile, voire impossible à contourner, le plafond basé sur la physique déjà atteint peut et peut croître, mais moins que (puissance, bruit, "horloge") ne peut augmenter, mais des problèmes de distribution d'énergie et de dissipation thermique augmentera peut augmenter, ayant des avantages directs de grandes empreintes de cache et des E / S mémoire plus rapides et plus larges et des avantages indirects de la commutation de contexte moins souvent forcée par le système, car nous pouvons avoir plus de cœurs pour diviser d'autres threads / processus entreO(n^2~3)
Frequency [MHz]
Transistor CountO(n^2~3)
Power [W]
Single Thread Perf

_{(Les crédits reviennent à 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|

Juste pour le plaisir de l'examen de 2015 des prévisions pour 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

Juste pour comparer le paysage de latence CPU et GPU:

Ce n'est pas une tâche facile de comparer même les files d'attente CPU / cache / DRAM les plus simples (même dans un modèle d'accès mémoire uniforme), où la vitesse de la DRAM est un facteur pour déterminer la latence, et la latence chargée (système saturé), où cette dernière règle et est quelque chose que les applications d'entreprise connaîtront plus qu'un système inactif entièrement déchargé.

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

Les moteurs GPU ont reçu beaucoup de marketing technique, tandis que de profondes dépendances internes sont essentielles pour comprendre à la fois les forces réelles et les réelles faiblesses que ces architectures rencontrent dans la pratique (généralement très différentes des attentes du marketing agressif sifflé).

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

Comprendre les internalités est donc bien plus important que dans d'autres domaines, où les architectures sont publiées et de nombreux benchmarks disponibles gratuitement. Un grand merci aux micro-testeurs GPU, qui ont consacré leur temps et leur créativité à révéler la vérité sur les véritables schémas de travail à l'intérieur des périphériques GPU testés par l'approche de la boîte noire.

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

Mes excuses pour une "vue d'ensemble", mais le démasquage de la latence a également des limites cardinales imposées par les capacités smREG / L1 / L2 sur puce et les taux de réussite / échec.

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

La ligne du bas?

Toute conception motivée à faible latence doit plutôt rétroconcevoir «l'hydraulique d'E / S» (car les 0 1-XFER sont incompressibles par nature) et les latences qui en résultent régissent l'enveloppe de performance de toute solution GPGPU, qu'elle soit gourmande en calcul ( lire : où les coûts de traitement pardonnent un peu plus une mauvaise latence XFER ...) ou pas ( lire : où (peut-être à la surprise de quelqu'un) les CPU sont plus rapides dans le traitement de bout en bout, que les tissus GPU [citations disponibles] ).

Question 6

Regardez ce tracé "en escalier", illustrant parfaitement les différents temps d'accès (en termes de tics d'horloge). Remarquez que le processeur rouge a une "étape" supplémentaire, probablement parce qu'il a L4 (alors que d'autres ne le font pas).

Graphiques des temps d'accès avec différentes hiérarchies de mémoire

Tiré de cet article Extremetech.

En informatique, cela s'appelle la "complexité des E / S".

Answer 1

182

Quelqu'un peut-il me donner le temps approximatif (en nanosecondes) pour accéder aux caches L1, L2 et L3, ainsi qu'à la mémoire principale sur les processeurs Intel i7?

Bien que ce ne soit pas spécifiquement une question de programmation, connaître ces types de détails de vitesse est nécessaire pour certains défis de programmation à faible latence.

memory latency cpu-cache low-latency Ted Graham
la source

mechanical-sympathy.blogspot.com/2013/02/...

Beachhouse

1

Comment convertir des ns en cycles? Si je divise simplement 100 ns par 2,3 GHz, j'obtiens 230 cycles. Est-ce correct?

Nathan

5

Je suis curieux: dans quelle situation le cache L3 distant est-il plus lent que la DRAM distante? Le nombre ci-dessus indique qu'il peut être 1,6 fois plus lent.

netvope

1

Veuillez ne pas modifier la question, mais publier une réponse avec ces détails. L'auto-réponse est ok sur SO.

Stijn de Witt

Existe-t-il des valeurs approximatives de consommation d'énergie pour l'accès à la mémoire à partir de chaque niveau?

kanna

Answer 2

mechanical-sympathy.blogspot.com/2013/02/...

Beachhouse

Answer 3

1

Comment convertir des ns en cycles? Si je divise simplement 100 ns par 2,3 GHz, j'obtiens 230 cycles. Est-ce correct?

Nathan

Answer 4

5

Je suis curieux: dans quelle situation le cache L3 distant est-il plus lent que la DRAM distante? Le nombre ci-dessus indique qu'il peut être 1,6 fois plus lent.

netvope

Answer 5

1

Veuillez ne pas modifier la question, mais publier une réponse avec ces détails. L'auto-réponse est ok sur SO.

Stijn de Witt

Answer 6

Existe-t-il des valeurs approximatives de consommation d'énergie pour l'accès à la mémoire à partir de chaque niveau?

kanna

Answer 7

79

Voici un guide d'analyse des performances pour la gamme de processeurs i7 et Xeon. Je dois insister sur le fait que cela a ce dont vous avez besoin et plus (par exemple, consultez la page 22 pour certains horaires et cycles par exemple).

De plus, cette page contient des détails sur les cycles d'horloge, etc. Le deuxième lien servait les numéros suivants:

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:
Le plus important est l'avis sous le tableau cité, disant:

_{"REMARQUE: CES VALEURS SONT DES APPROXIMATIONS BRUTES . ILS DÉPENDENT DES FRÉQUENCES NOYAU ET NON COEUR, DES VITESSES DE LA MÉMOIRE , DES PARAMÈTRES DU BIOS, DU NOMBRE DE DIMMS , ETC, ETC. VOTRE KILOMÉTRAGE PEUT VARIER. "}

EDIT: Je dois souligner que, en plus des informations de synchronisation / cycle, le document Intel ci-dessus traite beaucoup plus de détails (extrêmement) utiles de la gamme de processeurs i7 et Xeon (d'un point de vue des performances).

Dave
la source

1

«Ligne non partagée» ne devrait pas avoir plus de latence que «ligne partagée dans un autre cœur» - une ligne partagée (c'est-à-dire 2 bits de base valides) signifie qu'elle peut être prise directement à partir de la tranche LLC car elle est garantie d'être propre. «Ligne non partagée» signifie qu'il n'y a qu'un seul bit valide de noyau et que ce noyau doit être surveillé pour s'assurer que la ligne est exclusive et non modifiée - si elle est modifiée, elle est changée en partagée; LLC devient maintenant sale et il est renvoyé au noyau demandeur comme partagé. Peut-être que je me trompe - je sais que le protocole MOESI est différent.

Lewis Kelsey

1

C'est certainement le cas chez SnB et Haswell. Nehalem - que ce Xeon utilise - était avant la topologie du bus en anneau et avait un cache unifié, mais je ne vois pas pourquoi le filtre snoop se comporterait différemment dans Nehalem. La section B.3.5.3 du manuel d'optimisation donne ce que je pense être une description incorrecte (elle concerne clairement Nehalem car elle parle de la file d'attente globale qui est une fonctionnalité de Nehalem). Cet article de Haswell a une meilleure description (colonne en haut à droite de la page 5) ( tu-dresden.de/zih/forschung/ressourcen/dateien/… )

Lewis Kelsey

@LewisKelsey: Cela me surprend aussi, car je pensais que la moitié du point de L3 inclusif était que L3 pouvait simplement répondre s'il avait une copie valide d'une ligne. Mais rappelez-vous, Intel utilise MESIF ( en.wikipedia.org/wiki/MESIF_protocol ) pour NUMA, AMD utilise MOESI. Je pense que dans un seul socket, cependant, MESIF n'est pas vraiment une chose parce que les données proviennent de L3, pas de core-> core. C'est donc probablement plus pertinent pour les transferts de cache L3> cache entre les sockets. Je me demande si ce "hit L3 local" est pour une ligne partagée avec un noyau dans un autre socket? Cela n'a toujours pas de sens, valide en L3 signifie qu'aucun noyau n'a E / M

Peter Cordes

@PeterCordes Je me suis souvenu de ce commentaire et je suis revenu et ce que j'ai dit m'a tout de suite semblé faux. Mon commentaire est correct dans la perspective d'un 3ème noyau où il est partagé entre 2 autres cœurs ou simplement exclusif à un autre noyau. Mais si vous parlez de ligne non partagée et qu'elle appartient au noyau qui essaie d'accéder à la ligne, alors le point de référence est correct car partagé nécessite un RFO pour l'obtenir de manière exclusive et exclusive, ce qui signifie qu'aucune RFO n'est requise. Donc je ne sais pas vraiment ce que je disais.

Lewis Kelsey

@LewisKelsey: Oui, tout est vrai pour l'écriture. Je pensais que c'était pour la lecture (Data Source Latency), qui est plus sensible à la latence. La lecture d'une ligne ne nécessite jamais un RFO, juste une demande de partage. Donc, une ligne qui est déjà dans l'état partagé quelque part ne devrait-elle pas simplement toucher L3 de cette socket sans avoir à attendre le trafic de cohérence? Et donc être plus rapide que DRAM, similaire à un hit L3 "non partagé".

Peter Cordes

Answer 8

1

«Ligne non partagée» ne devrait pas avoir plus de latence que «ligne partagée dans un autre cœur» - une ligne partagée (c'est-à-dire 2 bits de base valides) signifie qu'elle peut être prise directement à partir de la tranche LLC car elle est garantie d'être propre. «Ligne non partagée» signifie qu'il n'y a qu'un seul bit valide de noyau et que ce noyau doit être surveillé pour s'assurer que la ligne est exclusive et non modifiée - si elle est modifiée, elle est changée en partagée; LLC devient maintenant sale et il est renvoyé au noyau demandeur comme partagé. Peut-être que je me trompe - je sais que le protocole MOESI est différent.

Lewis Kelsey

Answer 9

1

C'est certainement le cas chez SnB et Haswell. Nehalem - que ce Xeon utilise - était avant la topologie du bus en anneau et avait un cache unifié, mais je ne vois pas pourquoi le filtre snoop se comporterait différemment dans Nehalem. La section B.3.5.3 du manuel d'optimisation donne ce que je pense être une description incorrecte (elle concerne clairement Nehalem car elle parle de la file d'attente globale qui est une fonctionnalité de Nehalem). Cet article de Haswell a une meilleure description (colonne en haut à droite de la page 5) ( tu-dresden.de/zih/forschung/ressourcen/dateien/… )

Lewis Kelsey

Answer 10

@LewisKelsey: Cela me surprend aussi, car je pensais que la moitié du point de L3 inclusif était que L3 pouvait simplement répondre s'il avait une copie valide d'une ligne. Mais rappelez-vous, Intel utilise MESIF ( en.wikipedia.org/wiki/MESIF_protocol ) pour NUMA, AMD utilise MOESI. Je pense que dans un seul socket, cependant, MESIF n'est pas vraiment une chose parce que les données proviennent de L3, pas de core-> core. C'est donc probablement plus pertinent pour les transferts de cache L3> cache entre les sockets. Je me demande si ce "hit L3 local" est pour une ligne partagée avec un noyau dans un autre socket? Cela n'a toujours pas de sens, valide en L3 signifie qu'aucun noyau n'a E / M

Peter Cordes

Answer 11

@PeterCordes Je me suis souvenu de ce commentaire et je suis revenu et ce que j'ai dit m'a tout de suite semblé faux. Mon commentaire est correct dans la perspective d'un 3ème noyau où il est partagé entre 2 autres cœurs ou simplement exclusif à un autre noyau. Mais si vous parlez de ligne non partagée et qu'elle appartient au noyau qui essaie d'accéder à la ligne, alors le point de référence est correct car partagé nécessite un RFO pour l'obtenir de manière exclusive et exclusive, ce qui signifie qu'aucune RFO n'est requise. Donc je ne sais pas vraiment ce que je disais.

Lewis Kelsey

Answer 12

@LewisKelsey: Oui, tout est vrai pour l'écriture. Je pensais que c'était pour la lecture (Data Source Latency), qui est plus sensible à la latence. La lecture d'une ligne ne nécessite jamais un RFO, juste une demande de partage. Donc, une ligne qui est déjà dans l'état partagé quelque part ne devrait-elle pas simplement toucher L3 de cette socket sans avoir à attendre le trafic de cohérence? Et donc être plus rapide que DRAM, similaire à un hit L3 "non partagé".

Peter Cordes

Answer 13

194

Des chiffres que tout le monde devrait connaître

           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: À l'origine par 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
la source

11

Sûrement ces quantités très ÉNORMES, basées sur la conception du processeur, la latence / fréquence de la RAM, la mise en cache du disque dur (à la fois le type et la taille) / rpm, etc. Pour citer INTEL (pour les valeurs qu'ils ont publiées pour un processeur spécifique): "REMARQUE: Ces valeurs sont des approximations approximatives. Elles dépendent des fréquences Core et Uncore, des vitesses de mémoire, des paramètres du BIOS, du nombre de DIMMS, etc. . "

Dave

29

@Dave c'est vrai, mais ces chiffres montrent l'ordre de grandeur

Andrey

8

@Dave, même si le type / la vitesse / l'architecture du processeur est différent, je pense que le timing relatif devrait rester à peu près le même, c'est donc juste une indication approximative pour savoir quand vous codez. Une analyse plus significative devrait être faite via le profileur bien sûr ...

xosp7tom

9

Pour avoir une idée du temps écoulé, Wikipédia mentionne «Une nanoseconde équivaut à une seconde comme une seconde à 31,7 ans». en.wikipedia.org/wiki/Nanosecond

Only You

2

@kernel si le cache manque, cela signifie qu'il faudra accéder au cache de niveau inférieur ou même à la mémoire principale. Dans ce cas, cela prendra du temps en fonction du temps d'accès de ce niveau. Vous pouvez rechercher des données pour les processeurs plus récents ici sisoftware.net/?d=qa&f=ben_mem_latency

Andrey

Answer 14

11

Sûrement ces quantités très ÉNORMES, basées sur la conception du processeur, la latence / fréquence de la RAM, la mise en cache du disque dur (à la fois le type et la taille) / rpm, etc. Pour citer INTEL (pour les valeurs qu'ils ont publiées pour un processeur spécifique): "REMARQUE: Ces valeurs sont des approximations approximatives. Elles dépendent des fréquences Core et Uncore, des vitesses de mémoire, des paramètres du BIOS, du nombre de DIMMS, etc. . "

Dave

Answer 15

29

@Dave c'est vrai, mais ces chiffres montrent l'ordre de grandeur

Andrey

Answer 16

8

@Dave, même si le type / la vitesse / l'architecture du processeur est différent, je pense que le timing relatif devrait rester à peu près le même, c'est donc juste une indication approximative pour savoir quand vous codez. Une analyse plus significative devrait être faite via le profileur bien sûr ...

xosp7tom

Answer 17

9

Pour avoir une idée du temps écoulé, Wikipédia mentionne «Une nanoseconde équivaut à une seconde comme une seconde à 31,7 ans». en.wikipedia.org/wiki/Nanosecond

Only You

Answer 18

2

@kernel si le cache manque, cela signifie qu'il faudra accéder au cache de niveau inférieur ou même à la mémoire principale. Dans ce cas, cela prendra du temps en fonction du temps d'accès de ce niveau. Vous pouvez rechercher des données pour les processeurs plus récents ici sisoftware.net/?d=qa&f=ben_mem_latency

Andrey

Answer 19

Coût pour accéder à divers souvenirs dans une jolie page

Voir cette page présentant la diminution de la latence mémoire de 1990 à 2020 .

Sommaire

Valeurs en baisse mais stabilisées depuis 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

Encore quelques améliorations, prévision pour 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)

Voir aussi d'autres sources

Ce que tout programmeur devrait savoir sur la mémoire par Ulrich Drepper (2007)
Ancienne mais toujours une excellente explication approfondie sur l'interaction entre le matériel mémoire et le logiciel.
- PDF complet (114 pages)
  - Commentaires sur LWN sur la version PDF
  - Un autre les
- Sept articles sur LWN + Commentaires
Publiez l' espace infini entre les mots dans codinghorror.com basé sur le livre Systems Performance: Enterprise and the Cloud
Cliquez sur chaque processeur répertorié sur http://www.7-cpu.com/ pour voir les latences L1 / L2 / L3 / RAM / ... (par exemple, Haswell i7-4770 a L1 = 1ns, L2 = 3ns, L3 = 10 ns, RAM = 67 ns, erreur de branche = 4 ns)
http://idarkside.org/posts/numbers-you-should-know/

Voir également

Pour une meilleure compréhension, je recommande l'excellente présentation des architectures de cache modernes (juin 2014) de Gerhard Wellein , Hannes Hofmann et Dietmar Fey de l' Université Erlangen-Nürnberg .

Les francophones apprécieront peut-être un article de SpaceFox comparant un processeur à un développeur en attente des informations nécessaires pour continuer à travailler.

Answer 20

un joli poteau de latence. serait bon d'ajouter les faits sur la réalité de masquage de latence GPU (

user3666197

Answer 21

Salut @ user3666197 Avez-vous des sources sur la latence de la mémoire liée au GPU? Cheers :-)

olibre

Answer 22

Certainement, oui, @olibre. Vérifiez le [A]posté ci-dessous.

user3666197

Answer 23

1

Compte tenu de la latence et de la mise en cache, je trouve ironique que la page de votre premier lien, avec le curseur d'année, ne cache pas l'affichage de la métrique lors du changement d'année. Dans Firefox, au moins, le rendu est trop lent pour être fluide au

fil

Answer 24

1

Belles références, vous avez donné des titres et des auteurs!

SamB

Answer 25

Juste pour le plaisir de l'examen de 2020 des prévisions pour 2025:

Au cours des 44 dernières années de la technologie des circuits intégrés, les processeurs classiques (non quantiques) ont évolué, littéralement et physiquement "Per Aspera ad Astra" . La dernière décennie a démontré que le processus classique s'est rapproché de certains obstacles, qui n'ont pas de chemin physique réalisable.

Number of logical corespeut et peut croître, mais pas plus que ce qui est difficile, voire impossible à contourner, le plafond basé sur la physique déjà atteint peut et peut croître, mais moins que (puissance, bruit, "horloge") ne peut augmenter, mais des problèmes de distribution d'énergie et de dissipation thermique augmentera peut augmenter, ayant des avantages directs de grandes empreintes de cache et des E / S mémoire plus rapides et plus larges et des avantages indirects de la commutation de contexte moins souvent forcée par le système, car nous pouvons avoir plus de cœurs pour diviser d'autres threads / processus entreO(n^2~3)
Frequency [MHz]
Transistor CountO(n^2~3)
Power [W]
Single Thread Perf

_{(Les crédits reviennent à 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|

Juste pour le plaisir de l'examen de 2015 des prévisions pour 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

Juste pour comparer le paysage de latence CPU et GPU:

Ce n'est pas une tâche facile de comparer même les files d'attente CPU / cache / DRAM les plus simples (même dans un modèle d'accès mémoire uniforme), où la vitesse de la DRAM est un facteur pour déterminer la latence, et la latence chargée (système saturé), où cette dernière règle et est quelque chose que les applications d'entreprise connaîtront plus qu'un système inactif entièrement déchargé.

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

Les moteurs GPU ont reçu beaucoup de marketing technique, tandis que de profondes dépendances internes sont essentielles pour comprendre à la fois les forces réelles et les réelles faiblesses que ces architectures rencontrent dans la pratique (généralement très différentes des attentes du marketing agressif sifflé).

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

Comprendre les internalités est donc bien plus important que dans d'autres domaines, où les architectures sont publiées et de nombreux benchmarks disponibles gratuitement. Un grand merci aux micro-testeurs GPU, qui ont consacré leur temps et leur créativité à révéler la vérité sur les véritables schémas de travail à l'intérieur des périphériques GPU testés par l'approche de la boîte noire.

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

Mes excuses pour une "vue d'ensemble", mais le démasquage de la latence a également des limites cardinales imposées par les capacités smREG / L1 / L2 sur puce et les taux de réussite / échec.

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

La ligne du bas?

Toute conception motivée à faible latence doit plutôt rétroconcevoir «l'hydraulique d'E / S» (car les 0 1-XFER sont incompressibles par nature) et les latences qui en résultent régissent l'enveloppe de performance de toute solution GPGPU, qu'elle soit gourmande en calcul ( lire : où les coûts de traitement pardonnent un peu plus une mauvaise latence XFER ...) ou pas ( lire : où (peut-être à la surprise de quelqu'un) les CPU sont plus rapides dans le traitement de bout en bout, que les tissus GPU [citations disponibles] ).

Answer 26

8

J'ai essayé de comprendre votre réponse. Cela semble très intéressant mais les graphes ASCII ne sont pas faciles à lire en raison des limitations de grande / largeur. Désolé je ne sais pas comment cela pourrait être amélioré ... Enfin il me manque un résumé (à la fin, je ne sais pas quoi penser des latences CPU vs GPU). J'espère que vous pourrez améliorer votre réponse pour offrir un meilleur look et une meilleure compréhension humaine. Courage. Cheers :-D

olibre

Answer 27

Regardez ce tracé "en escalier", illustrant parfaitement les différents temps d'accès (en termes de tics d'horloge). Remarquez que le processeur rouge a une "étape" supplémentaire, probablement parce qu'il a L4 (alors que d'autres ne le font pas).

Graphiques des temps d'accès avec différentes hiérarchies de mémoire

Tiré de cet article Extremetech.

En informatique, cela s'appelle la "complexité des E / S".

Coût approximatif pour accéder à divers caches et à la mémoire principale?

Réponses:

Coût pour accéder à divers souvenirs dans une jolie page

Sommaire

Voir aussi d'autres sources

Voir également

Juste pour le plaisir de l'examen de 2020 des prévisions pour 2025:

Juste pour le plaisir de l'examen de 2015 des prévisions pour 2020:

Juste pour comparer le paysage de latence CPU et GPU:

La ligne du bas?