Perkiraan biaya untuk mengakses berbagai cache dan memori utama?

178

Adakah yang bisa memberi saya perkiraan waktu (dalam nanodetik) untuk mengakses cache L1, L2 dan L3, serta memori utama pada prosesor Intel i7?

Meskipun ini bukan pertanyaan pemrograman yang spesifik, mengetahui rincian kecepatan seperti ini diperlukan untuk beberapa tantangan pemrograman latensi rendah.

memory latency cpu-cache low-latency Ted Graham
sumber

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

Beachhouse

1

Bagaimana cara mengubah ns menjadi siklus? Jika saya hanya membagi 100 ns dengan 2,3 GHz, saya mendapatkan 230 siklus. Apakah ini benar?

Nathan

5

Saya ingin tahu: Dalam situasi apa cache L3 jarak jauh lebih lambat daripada DRAM jarak jauh? Angka di atas menunjukkan bahwa bisa 1,6x lebih lambat.

netvope

1

Harap jangan mengedit pertanyaan tetapi mengirim jawaban dengan perincian itu. Menjawab sendiri tidak masalah pada SO.

Stijn de Witt

Adakah nilai perkiraan untuk konsumsi energi untuk akses memori dari setiap level?

kanna

74

Berikut ini adalah Panduan Analisis Kinerja untuk jajaran prosesor i7 dan Xeon. Saya harus menekankan, ini memiliki apa yang Anda butuhkan dan lebih (misalnya, periksa halaman 22 untuk beberapa timing & siklus misalnya).

Selain itu, halaman ini memiliki beberapa rincian tentang siklus jam, dll. Tautan kedua menyajikan nomor-nomor berikut:

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:
Yang paling penting adalah pemberitahuan di bawah tabel yang dikutip, mengatakan:

_{"CATATAN: NILAI-NILAI INI SANGAT PENDEKATAN KUNCI . MEREKA BERGANTUNG PADA FREKUENSI INTI DAN UTAMA, KECEPATAN MEMORI, PENGATURAN BIOS, JUMLAH DIMMS , ETC, DLL .. CETAKAN ANDA DAPAT BERVARIASI. "}

EDIT: Saya harus menggarisbawahi bahwa, serta informasi waktu / siklus, dokumen intel di atas membahas lebih banyak (sangat) detail yang berguna dari jajaran prosesor i7 dan Xeon (dari sudut pandang kinerja).

Dave
sumber

1

Seharusnya 'baris tidak digunakan bersama' memiliki latensi lebih banyak daripada 'garis bersama di inti lain' - garis bersama (yaitu 2 bit inti yang valid) berarti dapat diambil langsung dari irisan LLC karena dijamin bersih. 'Lini tidak dibagi' berarti hanya ada satu inti yang valid dan inti tersebut harus diintip untuk memastikan bahwa saluran tersebut eksklusif dan tidak dimodifikasi - jika dimodifikasi maka diubah untuk dibagikan; LLC sekarang menjadi kotor dan dikembalikan ke inti yang meminta sebagai dibagikan. Mungkin saya salah - saya tahu protokol MOESI berbeda.

Lewis Kelsey

1

Tentu saja ini yang terjadi di SnB dan Haswell. Nehalem - yang digunakan Xeon ini - adalah sebelum topologi ring bus dan memiliki cache terpadu tetapi saya tidak melihat mengapa filter snoop akan berperilaku berbeda di Nehalem. Manual pengoptimalan bagian B.3.5.3 memberikan apa yang saya rasakan sebagai deskripsi yang tidak benar (jelas berkaitan dengan Nehalem ketika berbicara tentang Antrian Global yang merupakan fitur Nehalem). Makalah Haswell ini memiliki deskripsi yang lebih baik (kolom kanan atas halaman 5) ( tu-dresden.de/zih/forschung/ressourcen/dateien/… )

Lewis Kelsey

@LewisKelsey: Ini mengejutkan bagi saya juga, karena saya pikir setengah dari titik L3 inklusif adalah bahwa L3 hanya bisa merespons jika memiliki salinan garis yang valid. Tapi ingat, Intel menggunakan MESIF ( en.wikipedia.org/wiki/MESIF_protocol ) untuk NUMA, AMD menggunakan MOESI. Saya pikir dalam satu soket, MESIF sebenarnya bukan sesuatu karena data berasal dari L3, bukan core-> core. Jadi itu mungkin lebih relevan untuk L3 cache-> transfer cache lintas soket. Saya ingin tahu apakah "hit L3 lokal" ini adalah untuk saluran yang digunakan bersama dengan inti di soket lain? Masih tidak masuk akal, valid dalam L3 berarti tidak ada inti yang memiliki E / M

Peter Cordes

@PeterCordes Saya ingat komentar ini dan kembali dan apa yang saya katakan baru saja langsung salah bagi saya. Komentar saya benar dalam perspektif inti ke-3 di mana inti itu dibagi antara 2 inti lain atau hanya eksklusif untuk satu inti lainnya. Tetapi jika Anda berbicara tentang saluran yang tidak dibagi dan itu milik inti yang mencoba mengakses saluran, maka tolok ukurnya benar karena dibagikan memerlukan RFO untuk mendapatkannya secara eksklusif dan eksklusif berarti tidak ada RFO yang diperlukan. Jadi saya tidak tahu apa yang sebenarnya saya katakan.

Lewis Kelsey

@LewisKelsey: Ya, itu semua benar untuk menulis. Saya pikir ini untuk membaca ( Sumber Data Latency), yang lebih sensitif terhadap latensi. Membaca garis tidak pernah membutuhkan RFO, hanya permintaan untuk berbagi. Jadi bukankah seharusnya garis yang sudah dalam keadaan Shared di suatu tempat, tekan saja di L3 soket ini tanpa harus menunggu lalu lintas koherensi? Dan dengan demikian lebih cepat dari DRAM, mirip dengan hit L3 "tidak dibagi".

Peter Cordes

189

Angka yang harus diketahui semua orang

           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|

Dari: Awalnya oleh 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
sumber

11

Tentunya jumlah ini sangat besar, berdasarkan pada desain prosesor, latensi / frekuensi ram, caching hard disk (baik tipe dan ukuran) / rpm dll? Mengutip INTEL (untuk nilai yang dikeluarkan untuk satu CPU tertentu): "CATATAN: Nilai-nilai ini adalah perkiraan kasar. Nilai tersebut bergantung pada Core dan Uncore Frequency, kecepatan memori, pengaturan BIOS, Jumlah DIMMS, dll. . "

Dave

28

@Dave itu benar, tetapi angka ini menunjukkan urutan besarnya

Andrey

8

@Dave, meskipun jenis / kecepatan / arsitektur cpu berbeda, saya percaya waktu relatif kira-kira harus tetap sama, jadi itu hanya panduan kasar untuk mengetahui kapan Anda kode. Analisis yang lebih bermakna harus dilakukan melalui profiler, tentu saja ...

xosp7tom

8

Untuk mengetahui berapa banyak waktu yang dibutuhkan, Wikipedia menyebutkan, "Satu nanodetik untuk satu detik, sementara satu detik adalah 31,7 tahun." en.wikipedia.org/wiki/Nanosecond

Only You

2

@ kernel jika ada cache miss berarti itu akan memerlukan akses cache level yang lebih rendah atau bahkan memori utama. Dalam hal ini akan memakan waktu sesuai dengan waktu akses tingkat itu. Anda dapat mencari data untuk CPU yang lebih baru di sini sisoftware.net/?d=qa&f=ben_mem_latency

Andrey

39

Biaya untuk mengakses berbagai kenangan di halaman yang cantik

Lihat halaman ini menyajikan penurunan latensi memori dari 1990 hingga 2020 .

Ringkasan

Nilai mengalami penurunan tetapi distabilkan sejak 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

Masih ada beberapa perbaikan, prediksi untuk 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)

Lihat juga sumber lainnya

Apa yang harus diketahui oleh setiap programmer tentang memori dari Ulrich Drepper (2007)
Tua namun masih merupakan penjelasan mendalam yang sangat baik tentang interaksi perangkat keras dan perangkat lunak memori.
- PDF lengkap (114 halaman)
  - Mengomentari LWN tentang versi PDF
  - lain yang
- Tujuh pos di LWN + Komentar
Posting Ruang Tak Terbatas Antara Kata-kata di codinghorror.com berdasarkan buku Sistem Kinerja: Perusahaan dan Awan
Klik untuk setiap prosesor yang tercantum di http://www.7-cpu.com/ untuk melihat latensi L1 / L2 / L3 / RAM / ... (mis. Haswell i7-4770 memiliki L1 = 1ns, L2 = 3ns, L3 = 10ns, RAM = 67ns, BranchMisprediction = 4ns)
http://idarkside.org/posts/numbers-you-should-know/

Lihat juga

Untuk pemahaman lebih lanjut, saya merekomendasikan presentasi yang sangat baik dari arsitektur cache modern (Juni 2014) dari Gerhard Wellein , Hannes Hofmann dan Dietmar Fey di Universitas Erlangen-Nürnberg .

Orang-orang berbahasa Perancis dapat menghargai artikel oleh SpaceFox yang membandingkan prosesor dengan pengembang, keduanya menunggu informasi yang diperlukan untuk terus bekerja.

olibre
sumber

pos latensi yang indah. akan lebih baik untuk menambahkan fakta tentang realitas penutupan GPU-latensi (

user3666197

Hai @ user3666197 Sudahkah Anda beberapa sumber tentang latensi memori yang terkait dengan GPU? Cheers :-)

olibre

Tentu saja, ya, @olibre. Lihat [A]posting di bawah ini.

user3666197

1

Mengingat bagaimana ini tentang latensi dan caching, saya merasa ironis bahwa halaman di tautan pertama Anda, dengan slider tahun, tidak menembolok tampilan metrik saat mengubah tahun. Di Firefox, setidaknya, mereka membuat terlalu lambat untuk menyeret selama bertahun-tahun menjadi lancar: /

John Glassmyer

1

Referensi yang bagus, Anda memberi judul dan penulis!

SamB

22

Hanya demi tinjauan 2020 tentang prediksi untuk 2025:

Sekitar 44 tahun terakhir dari teknologi sirkuit terpadu, prosesor klasik (non-kuantum) berevolusi, secara harfiah dan fisik "Per Aspera ad Astra" . Dekade terakhir telah membuktikan, proses klasik telah mendekati beberapa rintangan, yang tidak memiliki jalur fisik yang dapat dicapai.

Number of logical coresdapat dan dapat tumbuh, namun tidak lebih dari yang sulit jika bukan tidak mungkin untuk menembus langit-langit berbasis fisika sudah dapat dan dapat tumbuh, namun kurang dari (daya, kebisingan, "jam") dapat tumbuh, namun masalah dengan distribusi daya & disipasi panas akan meningkat dapat tumbuh, memiliki manfaat langsung dari jejak-cache yang besar dan memori-I / O yang lebih cepat dan lebih luas & manfaat tidak langsung dari pengalihan konteks paksa sistem yang lebih jarang karena kami dapat memiliki lebih banyak inti untuk memisahkan utas / proses lain di antaraO(n^2~3)
Frequency [MHz]
Transistor CountO(n^2~3)
Power [W]
Single Thread Perf

_{(Kredit pergi ke 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|

Hanya demi tinjauan tahun 2015 tentang prediksi untuk tahun 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

Hanya demi perbandingan lanskap latensi CPU dan GPU:

Bukan tugas yang mudah untuk membandingkan bahkan jajaran CPU / cache / DRAM yang paling sederhana (bahkan dalam model akses memori yang seragam), di mana kecepatan DRAM merupakan faktor dalam menentukan latensi, dan memuat latensi (sistem jenuh), di mana yang terakhir memerintah dan sesuatu yang akan dialami aplikasi perusahaan lebih dari sistem yang tidak terisi penuh.

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

Mesin-GPU telah menerima banyak pemasaran teknis, sementara dependensi internal yang dalam adalah kunci untuk memahami kekuatan nyata dan juga kelemahan nyata yang dialami arsitektur ini dalam praktiknya (biasanya jauh berbeda dari pemasaran agresif yang dibayangkan ekspektasi).

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

Memahami internalitas dengan demikian jauh lebih penting, daripada di bidang lain, di mana arsitektur diterbitkan dan banyak tolok ukur tersedia secara bebas. Banyak terima kasih kepada penguji mikro-GPU, yang telah menghabiskan waktu dan kreativitas mereka untuk melepaskan kebenaran dari skema kerja nyata di dalam pendekatan kotak hitam yang menguji perangkat GPU.

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

Permintaan maaf saya untuk "gambaran yang lebih besar", tetapi penghentian latensi juga memiliki batasan utama yang dipaksakan dari kapasitas smREG / L1 / L2 dan chip hit / miss-rates.

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

Garis bawah?

Setiap desain bermotivasi latensi rendah harus merekayasa balik "I / O-hidraulik" (karena 0 1-XFER tidak dapat dikompresi secara alami) dan latensi yang dihasilkan menentukan amplop kinerja untuk setiap solusi GPGPU baik secara komputasional ( baca intensif : di mana biaya pemrosesan sedikit lebih memaafkan XFER latensi buruk ...) atau tidak ( baca : di mana (mungkin mengejutkan seseorang) CPU-s lebih cepat dalam pemrosesan ujung-ke-ujung, daripada kain GPU [kutipan tersedia] ).

pengguna3666197
sumber

7

Saya telah berusaha memahami jawaban Anda. Tampaknya sangat menarik tetapi grafik ASCII tidak mudah dibaca karena keterbatasan tinggi / lebar. Maaf saya tidak tahu bagaimana ini bisa diperbaiki ... Akhirnya saya kehilangan ringkasan (pada akhirnya, saya tidak tahu harus berpikir apa tentang latensi CPU vs. GPU). Semoga Anda dapat meningkatkan jawaban Anda untuk memberikan tampilan mata-permen yang lebih baik dan pemahaman manusia. Keberanian. Cheers :-D

olibre

3

Lihatlah plot "tangga" ini, dengan sempurna menggambarkan waktu akses yang berbeda (dalam hal jam tics). Perhatikan CPU merah memiliki "langkah" tambahan, mungkin karena memiliki L4 (sementara yang lain tidak).

Grafik waktu akses dengan hierarki memori yang berbeda

Diambil dari artikel Extremetech ini.

Dalam ilmu komputer ini disebut "kompleksitas I / O".

Oskar Person
sumber

Perkiraan biaya untuk mengakses berbagai cache dan memori utama?

Jawaban:

Biaya untuk mengakses berbagai kenangan di halaman yang cantik

Ringkasan

Lihat juga sumber lainnya

Lihat juga

Hanya demi tinjauan 2020 tentang prediksi untuk 2025:

Hanya demi tinjauan tahun 2015 tentang prediksi untuk tahun 2020:

Hanya demi perbandingan lanskap latensi CPU dan GPU:

Garis bawah?