Komputasi GPU yang Harus Diketahui Semua Developer

 (codeconfessions.substack.com)
5 poin oleh GN⁺ 2023-10-22 | 1 komentar | Bagikan ke WhatsApp
  • GPU memiliki arsitektur yang memprioritaskan throughput paralel skala besar dibanding latensi rendah untuk satu instruksi, sehingga unggul untuk pekerjaan yang melakukan banyak operasi sejenis seperti deep learning, grafis, dan komputasi numerik
  • CPU mengurangi latensi eksekusi berurutan dengan pipelining, out-of-order execution, speculative execution, dan cache bertingkat, sedangkan GPU menyembunyikan latensi dengan banyak ALU dan thread untuk meningkatkan throughput
  • Berdasarkan presisi 32-bit, Nvidia Ampere A100 mencapai 19,5 TFLOPS, sementara prosesor Intel 24-core tahun 2021 mencapai 0,66 TFLOPS; kesenjangan throughput komputasi numerik terus melebar
  • Kernel CUDA dijalankan dengan host code di CPU yang menyiapkan eksekusi dan device code di GPU yang berjalan dalam struktur grid·block·thread; thread dikelompokkan dalam satuan 32 bernama warp dan diproses dengan pendekatan SIMT
  • Performa nyata sangat bergantung pada bagaimana register SM, shared memory, slot block, dan slot thread dibagi; jika occupancy rendah, latensi sulit disembunyikan dan throughput puncak mungkin tidak tercapai

Perbedaan tujuan desain CPU dan GPU

  • CPU terutama dirancang untuk memproses eksekusi instruksi berurutan dengan cepat
    • Untuk mengurangi latensi eksekusi instruksi, CPU menggunakan fitur seperti instruction pipelining, out-of-order execution, speculative execution, dan multilevel cache
    • Untuk satu operasi seperti menjumlahkan dua angka, atau alur operasi yang pendek, CPU dapat memprosesnya dengan latensi lebih rendah daripada GPU
  • GPU dirancang dengan fokus pada paralelisme skala besar dan throughput tinggi
    • Pekerjaan yang perlu menjalankan banyak operasi aljabar linear dan numerik dengan cepat, seperti video game, grafis, komputasi numerik, dan deep learning, sangat cocok dengan arsitektur ini
    • Pada jutaan hingga miliaran operasi sejenis, GPU dapat memproses jauh lebih cepat daripada CPU berkat paralelisme skala besar
  • Performa komputasi numerik diukur dengan FLOPS, yaitu jumlah operasi floating-point per detik
    • Nvidia Ampere A100 menyediakan throughput 19,5 TFLOPS pada presisi 32-bit
    • Per tahun 2021, prosesor Intel 24-core berada di sekitar 0,66 TFLOPS pada presisi 32-bit
    • Kesenjangan throughput antara GPU dan CPU semakin besar dari tahun ke tahun

Cara GPU menyembunyikan latensi

  • Meski latensi instruksi individual tinggi, GPU memperoleh toleransi latensi dengan memanfaatkan banyak thread dan resource komputasi
  • Saat suatu thread menunggu hasil instruksi, GPU menjalankan thread lain yang tidak sedang menunggu
  • Berkat penjadwalan ini, unit komputasi dapat terus bekerja sebisa mungkin dan mempertahankan throughput tinggi

Arsitektur komputasi GPU

  • GPU terdiri dari susunan beberapa streaming multiprocessor (SM)
  • Setiap SM mencakup beberapa streaming processor, core, dan thread
    • Nvidia H100 memiliki 132 SM, dengan 64 core per SM, sehingga totalnya 8.448 core
  • Setiap SM memiliki memori on-chip terbatas yang dipakai bersama oleh semua core
    • Memori ini disebut shared memory atau scratchpad
  • Resource unit kontrol pada SM juga dipakai bersama oleh core
  • Setiap SM dilengkapi thread scheduler berbasis hardware untuk mengeksekusi thread
  • Bergantung pada workload, GPU juga dapat mencakup unit fungsi khusus atau unit komputasi terakselerasi seperti tensor core dan ray tracing unit

Hierarki memori GPU

  • Register

    • Setiap SM memiliki banyak register
    • Nvidia A100 dan H100 memiliki 65.536 register per SM
    • Register dipakai bersama oleh core dan dialokasikan secara dinamis sesuai kebutuhan thread
    • Register yang dialokasikan ke thread tertentu saat eksekusi bersifat khusus untuk thread tersebut, sehingga thread lain tidak dapat membaca atau menulisnya

  • constant cache

    • Menyimpan cache data konstanta yang digunakan oleh kode yang berjalan di SM
    • Programmer harus secara eksplisit mendeklarasikan objek sebagai konstanta di dalam kode agar GPU dapat menyimpannya di constant cache

  • shared memory

    • SRAM on-chip kecil, cepat, berlatensi rendah, dan dapat diprogram yang ada di setiap SM
    • Dipakai bersama oleh thread block yang berjalan pada SM yang sama
    • Saat beberapa thread menggunakan potongan data yang sama, satu thread saja dapat membacanya dari global memory lalu membagikannya ke thread lain, sehingga load duplikat berkurang
    • Juga digunakan sebagai mekanisme sinkronisasi antar-thread di dalam thread block

  • L1 cache dan L2 cache

    • Setiap SM memiliki L1 cache yang menyimpan cache data yang sering diakses dari L2 cache
    • L2 cache dipakai bersama oleh semua SM dan mengurangi latensi dengan menyimpan cache data yang sering diakses dari global memory
    • L1 dan L2 cache bekerja secara transparan bagi SM, sehingga dari sudut pandang SM data tampak diterima dari global memory

  • global memory

    • GPU memiliki global memory off-chip, yaitu DRAM berkapasitas besar dan bandwidth tinggi
    • Nvidia H100 memiliki HBM 80GB dan bandwidth 3000GB/s
    • global memory berada jauh dari SM sehingga latensinya tinggi, tetapi hierarki memori on-chip dan banyak unit komputasi membantu menyembunyikan latensi ini

Kernel CUDA dan struktur thread

  • CUDA adalah antarmuka pemrograman untuk menulis program bagi GPU Nvidia
  • Komputasi yang akan dijalankan di GPU direpresentasikan sebagai kernel, dalam bentuk yang mirip fungsi C/C++
    • Contohnya adalah kernel penjumlahan vektor yang menerima dua vektor sebagai input, menjumlahkannya per elemen, lalu menulis hasilnya ke vektor ketiga
  • Saat kernel dijalankan, beberapa thread dimulai, dan seluruh kumpulan ini disebut grid
    • grid terdiri dari satu atau lebih thread block
    • setiap thread block terdiri dari satu atau lebih thread
  • Jumlah block dan jumlah thread bergantung pada ukuran data dan paralelisme yang diinginkan
    • Pada penjumlahan vektor berdimensi 256, satu block berisi 256 thread dapat dibuat sehingga setiap thread memproses satu elemen vektor
    • Pada masalah yang lebih besar, jumlah thread yang tersedia di GPU bisa tidak mencukupi, sehingga setiap thread dapat dibuat memproses beberapa titik data
  • Implementasi CUDA dibagi menjadi dua bagian
    • host code berjalan di CPU dan bertanggung jawab atas pemuatan data, alokasi memori GPU, serta eksekusi kernel dengan grid thread yang telah dikonfigurasi
    • device code berjalan di GPU dan mendefinisikan fungsi kernel yang sebenarnya

Tahapan eksekusi kernel di GPU

  • Menyalin data dari host ke device

    • Sebelum menjalankan kernel, data yang diperlukan harus disalin dari memori CPU ke global memory GPU
    • Pada hardware GPU modern, unified virtual memory juga dapat digunakan untuk membaca langsung dari host memory

  • Menjadwalkan thread block ke SM

    • Setelah data yang diperlukan siap di memori GPU, thread block dialokasikan ke SM
    • Semua thread dalam satu block diproses secara bersamaan pada SM yang sama
    • Sebelum eksekusi, GPU harus mengamankan resource SM yang dibutuhkan oleh thread tersebut
    • Dalam praktiknya, beberapa thread block dapat dialokasikan ke SM yang sama secara bersamaan
    • Karena jumlah SM terbatas dan kernel besar dapat memiliki sangat banyak block, tidak semua block langsung dijalankan
    • GPU mempertahankan daftar block yang menunggu, lalu ketika suatu block selesai, satu block yang menunggu dialokasikan untuk dieksekusi

  • SIMT dan warp

    • Thread yang dialokasikan ke SM kembali dikelompokkan dalam satuan 32, dan kelompok ini disebut warp
    • Ukuran warp pada GPU Nvidia generasi saat ini adalah 32, tetapi bisa berubah pada hardware masa depan
    • SM mengambil dan menerbitkan instruksi yang sama untuk semua thread dalam warp
    • Thread menjalankan instruksi yang sama secara bersamaan, tetapi memproses bagian data yang berbeda
    • Model ini disebut single instruction multiple threads (SIMT) dan mirip dengan instruksi SIMD pada CPU
    • GPU modern setelah Volta juga memiliki independent thread scheduling, yang memungkinkan konkurensi penuh antar-thread terlepas dari warp

  • Penjadwalan warp dan toleransi latensi

    • Meski semua processing block di dalam SM menangani warp, pada momen tertentu hanya sebagian warp yang benar-benar menjalankan instruksi
    • Alasannya adalah jumlah unit eksekusi pada SM terbatas
    • Jika suatu warp menunggu hasil instruksi yang memakan waktu lama, SM membiarkan warp itu dalam status menunggu dan menjalankan warp lain yang tidak perlu menunggu
    • Karena setiap thread pada setiap warp memiliki kumpulan registernya sendiri, perpindahan antar-warp tidak memiliki overhead tersendiri
    • Context switching proses pada CPU mahal karena harus menyimpan register ke memori utama dan memulihkan status proses lain

  • Menyalin data hasil dari device ke host

    • Setelah semua thread pada kernel selesai berjalan, hasilnya disalin kembali ke host memory

Pembagian resource dan occupancy

  • Pemanfaatan resource GPU diukur dengan metrik yang disebut occupancy
    • occupancy adalah rasio jumlah warp yang dialokasikan ke SM terhadap jumlah maksimum warp yang dapat didukung SM tersebut
    • Untuk throughput maksimum, occupancy 100% diinginkan, tetapi tidak selalu memungkinkan karena berbagai batasan
  • SM memiliki resource eksekusi tetap seperti register, shared memory, thread block slot, dan thread slot
    • Resource ini dibagi secara dinamis sesuai kebutuhan thread dan batas GPU
  • Contoh Nvidia H100
    • Setiap SM dapat menangani 32 block, 64 warp, yaitu 2048 thread
    • Mendukung maksimal 1024 thread per block
    • Jika dijalankan dengan ukuran block 1024 thread, 2048 thread slot dibagi menjadi 2 block
  • Pembagian dinamis dapat menggunakan resource komputasi lebih efisien daripada pembagian tetap
    • Dalam pembagian tetap, setiap thread block menerima jumlah resource eksekusi yang tetap
    • Dalam beberapa kasus, thread mendapat resource lebih banyak daripada yang diperlukan, sehingga terjadi pemborosan resource dan penurunan throughput
  • Contoh yang menurunkan occupancy
    • Jika ukuran block ditetapkan 32 thread dan total yang dibutuhkan 2048 thread, akan terbentuk 64 block
    • Namun setiap SM hanya dapat menangani 32 block sekaligus, sehingga dalam praktiknya hanya 1024 thread yang berjalan dan occupancy menjadi 50%
    • Ketika register per SM berjumlah 65.536, untuk menjalankan 2048 thread secara bersamaan, setiap thread hanya dapat menggunakan maksimal 32 register
    • Jika kernel membutuhkan 64 register per thread, hanya 1024 thread per SM yang dapat berjalan, sehingga occupancy kembali menjadi 50%
  • Occupancy rendah membuat latensi tidak dapat disembunyikan dengan cukup dan juga dapat mengurangi throughput komputasi yang diperlukan untuk mencapai throughput puncak hardware
  • Untuk menulis kernel GPU yang efisien, resource harus dialokasikan dengan cermat agar latensi berkurang sambil mempertahankan occupancy tinggi
    • Menggunakan banyak register dapat membuat kode itu sendiri lebih cepat, tetapi juga dapat menurunkan occupancy, sehingga keseimbangan optimasi menjadi penting

Materi untuk dipelajari lebih lanjut

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-22
Komentar Hacker News

  • Seseorang mengirim email protes tentang tulisan ini: https://twitter.com/abhi9u/status/1715753871564476597
    Ini adalah pelanggaran aturan HN. Bahkan, ini satu-satunya poin yang cukup penting sampai dimasukkan baik dalam panduan situs maupun FAQ, dan pengguna HN sangat sensitif soal ini
    Q: Bolehkah saya meminta upvote untuk tulisan saya?
    A: Tidak. Pengguna seharusnya memberi suara ketika mereka sendiri merasa sesuatu menarik secara intelektual, bukan karena ada konten yang ingin dipromosikan seseorang. Jika melanggar aturan ini, tulisan, akun, atau situs dapat dikenai penalti atau diblokir, jadi jangan lakukan
    https://news.ycombinator.com/newsfaq.html
    Jangan meminta upvote, komentar, atau submission. Pengguna seharusnya memberi suara dan berkomentar ketika mereka secara pribadi merasa tertarik pada sesuatu yang mereka temui langsung, bukan untuk tujuan promosi
    https://news.ycombinator.com/newsguidelines.html

    • Saya tidak tahu aturan itu, dan saya juga tidak mengenal orang yang memposting tulisannya
      Sekarang sudah tahu, saya tidak akan melakukannya lagi

  • Saya terkejut bagian “menyalin data dari host ke device” tidak membahas penyalinan asinkron. Agar GPU dimanfaatkan semaksimal mungkin, GPU tidak boleh menganggur saat data sedang disalin antara host dan GPU
    Banyak framework menyediakan mekanisme penjadwalan penyalinan asinkron yang dapat berjalan bersama pengajuan pekerjaan asinkron. Tulisan ini sendiri lebih dekat ke pengantar GPU, tetapi dalam pemrograman GPU nyata ada berbagai trik dan teknik lebih lanjut untuk memeras GPU mahal sampai batasnya. Seperti kebanyakan optimisasi sekarang, ada banyak jurang tersembunyi dan non-linearitas, sehingga alat profiling sangat membantu

    • Kemungkinan yang dipakai adalah floating point 64-bit (double), dan kalau begitu tidak semua GPU akan banyak membantu. Apalagi jika dibandingkan dengan CPU yang kuat
      Namun jika memakai GPU dengan banyak unit FP64, kecepatannya bisa meningkat besar. Biasanya ini bukan GPU gaming, tetapi jika kebetulan punya 4060, performa FP64-nya sekitar 300 GFLOPS, jadi kemungkinan besar lebih tinggi dari CPU. CPU modern juga kuat di area ini, karena tiap core dapat mengeluarkan beberapa operasi FP64 per clock

  • Kalimat pembuka “sebagian besar programmer memahami CPU secara mendalam” begitu terang-terangan tidak benar, sehingga meski tulisannya mungkin bagus, sulit untuk menanggapi sisanya secara serius

    • Bagaimana kalau diubah seperti ini: “cukup banyak ilmuwan komputer, insinyur komputer, insinyur elektro, dan developer hobi …”
      Di kampus saya pernah mengambil kelas filsafat untuk bersenang-senang, dan di sana saya belajar kemampuan untuk tidak langsung membuang sebuah kalimat, melainkan membacanya dengan memperbaikinya ke bentuk yang lebih baik. Sekarang otak saya otomatis menerjemahkan generalisasi berlebihan atau klaim yang jelas salah menjadi proposisi benar yang cukup masuk akal. Saat argumen berkembang, saya bisa merekonstruksi ide-ide itu dan menilai keseluruhan tulisan sebagai sesuatu yang koheren secara logis
      Berkat itu, bahkan setelah membaca tulisan yang buruk, saya tetap membawa pulang premis dan argumen baru—baik benar maupun salah—tentang topik yang saya minati, dan dunia mental saya menjadi lebih luas karenanya
    • Itu jelas tidak benar untuk sebagian besar programmer, tetapi mungkin penulisnya bermaksud engineer yang mendapat pendidikan CS. Jika mengikuti kurikulum ilmu komputer formal, orang biasanya memahami CPU cukup mendalam, sementara GPU sering dibahas jauh lebih dangkal
    • Saya tidak paham kenapa di setiap tulisan internet selalu ada komentar semacam “saya berhenti membaca di X”. Ucapan seperti itu tidak menambahkan apa pun
    • Sepertinya lebih dari separuh perdebatan ini bergantung pada bagaimana kita mendefinisikan memahami secara mendalam
      Di kampus saya mempelajari fakta-fakta dasar arsitektur CPU, punya gambaran medan secara sangat dasar, dan sesekali menerima pembaruan atas pengetahuan yang terbatas itu, tetapi saya tidak akan menyebutnya “pemahaman mendalam”. Rasanya lebih tepat disebut “pemahaman dasar tentang bagaimana CPU bekerja, dirancang, dan digunakan”
      Jika mahir assembly, mungkin bisa dibilang “memahami secara mendalam” cara menggunakan CPU pada level rendah, tetapi tetap terdengar agak berlebihan. Itu juga berbeda dari menjadi pakar desain CPU/GPU
      Jadi saya setuju. Meski begitu tulisannya menarik, terutama diagramnya bagus
    • Saya mempelajari keduanya dalam program gelar dan kelas Structure and Interpretation of Computer Programs, dan saya merekomendasikan kelas itu bagi siapa pun yang tertarik pada komputasi level rendah

  • Bagian “register yang dialokasikan ke thread yang sedang berjalan bersifat khusus untuk thread itu, sehingga thread lain tidak dapat membaca atau menulisnya” punya pengecualian
    Wave intrinsic di HLSL dan fitur serupa di CUDA dapat membaca register thread lain dalam wavefront saat ini. Selain itu, di paragraf arsitektur memori, layak juga ditambahkan bahwa meski cache tidak menjamin konsistensi antar-thread dalam dispatch/grid yang sama, ada blok fungsi khusus yang bersifat global di seluruh chip untuk mengimplementasikan operasi atomik memori global

  • Pemrograman SIMD benar-benar kasar
    Ingin menjalankan perhitungan pada setiap piksel di layar? Tidak masalah
    Ingin memasukkan kondisi percabangan? Aduh

    • Ingin memasukkan eval? Semuanya berhenti
    • Agar adil, ini masuk akal. Mengambil keputusan cerdas memang “lebih sulit” daripada menskalakan komputasi sederhana ke banyak pekerja

  • Kenapa masih disebut GPU? PPU (parallel processing unit) terdengar seperti nama yang lebih baik

    • Karena selain fitur GPU serbaguna, di dalamnya juga ada silikon khusus grafis
    • Karena kalau disebut GPU, semua orang paham maksudnya
      Hubungan drone dan quad-copter juga mirip
    • Unit pemrosesan vektor sepertinya lebih tepat
    • CPU juga PPU
    • General Processing Unit

  • Tulisan yang bagus. Dan GPU, untuk hal-hal yang memang dikerjakannya, sudah lebih maju dan lebih kencang daripada apa pun yang bisa saya bayangkan
    Namun SIMD, setelah kita mempelajari paradigma lain yang lebih fleksibel, ingin saya masukkan ke kategori yang tidak benar-benar diperlukan. Saya lebih menyukai MIMD dan kluster/transputer, yang tampaknya menghilang sekitar era 2000-an. Kondisi saat ini menuntut developer untuk memindahkan data secara manual, menulis shader di bawah batas arbitrer atas jumlah lokasi memori yang bisa diakses secara bersamaan, menduplikasi pekerjaan dengan memakai bahasa terpisah untuk GPU/CPU, mengetahui hardware apa yang tersedia untuk fitur seperti ray tracing, dan terikat pada framework yang sangat beropini seperti OpenGL/Metal/Vulkan. GPU adalah cabang samping yang tidak akan pernah membawa saya ke tempat yang ingin saya tuju, jadi 25 tahun terakhir terasa seperti hidup di garis waktu yang salah
    Secara longgar, dalam batasan setelah berakhirnya Hukum Moore, CPU serbaguna yang dapat diskalakan adalah multicore dengan memori lokal, berbagi data lewat memori beralamat-konten copy-on-write atau skema caching lain, dan menyediakan satu ruang alamat terpadu agar pengguna bebas mengeksplorasi semua cara komputasi di lingkungan desktop. Ia memakai bahasa assembly standar, tetapi biasanya diprogram dengan bahasa pemrograman fungsional seperti Erlang/Go, Octave/MATLAB, dan idealnya Julia. Rendering 3D dan library AI adalah lapisan di atasnya, bukan elemen fundamental
    Menariknya, GPU kira-kira sudah mencapai konfigurasi multicore yang saya maksud, tetapi driver memisahkan pengguna dari akses bare-metal yang diperlukan untuk MIMD serbaguna. Saya dulu mengira satu-satunya cara meruntuhkan keunggulan GPU adalah FPGA, tetapi mungkin ada peluang untuk menulis driver yang membuat hardware GPU tampak seperti MIMD dengan memori terpadu. Saya tidak tahu seberapa baik core GPU menangani operasi integer, tetapi mungkin bisa didekati dengan bagian integer 32-bit dari floating-point 64-bit. Karena kompromi seperti itu, mesin MIMD mungkin 10–100 kali lebih lambat daripada GPU, tetapi bisa 10–100 kali lebih cepat daripada CPU. Pada saat yang sama, ia dapat diskalakan tanpa terlalu bergantung pada cache besar dan bus cepat yang membuat CPU stagnan setelah sekitar 2007, ketika pasar mobile mengambil kendali dan harga serta efisiensi daya diprioritaskan di atas performa. Mesin MIMD bisa diklusterkan untuk membentuk jaringan komputasi terdistribusi seperti SETI@home tanpa perubahan kode. Untuk membayangkan seberapa besar daya yang dapat diberikannya kepada pengguna biasa, ini mirip perbandingan BitTorrent vs FTP untuk komputasi, bukan untuk data

  • Saya kurang paham bagaimana arsitektur Apple Silicon berbeda dari NVIDIA
    Ketika membaca kalimat “GPU Nvidia H100 punya 132 SM, 64 core per SM, total 8448 core”, 8448 core jelas terdengar mengesankan. Tetapi Apple M2 Ultra hanya punya 76 core?
    Bagaimana mungkin NVIDIA H100 GPU bisa punya core lebih dari 110 kali lipat? Jelas performanya tidak 110 kali lebih tinggi daripada M2 Ultra, jadi apa yang sebenarnya terjadi di sini?

    • Secara umum, SM NVIDIA paling mirip dengan CU pada GPU AMD atau core pada GPU Apple. Di sini, “core” saya pahami sebagai subkomponen SM yang menjalankan operasi individual
      Lihat diagram ini dari blog NVIDIA: https://developer-blogs.nvidia.com/wp-content/uploads/2021/g...
      (https://developer.nvidia.com/blog/nvidia-ampere-architecture...)
    • NVIDIA menyebut sesuatu yang pada dasarnya adalah vector lane sebagai “core”, dan juga memakai “thread” dalam SIMT untuk berarti eksekusi pada satu vector lane semacam itu; ini sengaja dibuat tidak jelas dan, terus terang, tidak jujur
      Tentu, karena tiap lane mendukung program counter terpisah, mereka mungkin merasa punya alasan untuk menyebutnya “thread”, tetapi pada akhirnya yang penting adalah kecepatan dan throughput ALU
    • H100 bisa dipakai untuk menghangatkan sebuah ruangan. Konsumsi dayanya lebih dari 10 kali M2 Ultra

  • Sekarang saya paham mengapa machine learning memakai floating point untuk presisi. Itu bukan pilihan, melainkan karena kode grafis memang menggunakannya seperti itu
    Ini potongan lain dari teka-teki “mengapa machine learning seinefisien ini”
    Saya penasaran seberapa besar overhead penyalinan memori di lingkungan nyata. Jika perilakunya seperti pekerjaan pada umumnya, itu akan sangat berat. Sampai-sampai pemrosesan TCP dialihkan ke hardware untuk menghindarinya. Di sini datanya jauh lebih banyak, tetapi diproses dalam bongkahan yang lebih besar

    • Pada banyak jaringan besar modern, waktu komputasi GPU untuk perhitungan gradien dan backpropagation begitu lambat sehingga menyalin data floating point lewat bus PCIe bukanlah bottleneck
      Dengan kata lain, menyalin minibatch gambar floating point masih cukup cepat. Iterasi gradien/SGD-lah yang lambat dan beban komputasinya sangat besar. Itu tetap berlaku meski memakai mixed precision
      Pada jaringan yang dangkal, mungkin ada manfaat menyalin hanya data terkompresi asli ke memori GPU lalu melakukan dekompresi dan semacamnya di GPU. Namun alasan GPU modern belum mengadopsi PCIe 5 adalah karena performa komputasi mentah lebih penting
      Terakhir, pengaruh tensor core juga besar, dan tergantung jaringannya, bisa jadi terlalu cepat sehingga tingkat utilisasinya sangat rendah
    • Saya tidak melihat pilihan memakai angka floating point sebagai sesuatu yang secara khusus tidak efisien. Jika framework secara default memakai fixed point, akan sulit menyesuaikan rentang dinamis di seluruh jaringan
      Matematika pelatihan juga mengasumsikan bahwa angkanya kontinu
    • Floating point lebih besar, dan operasinya juga lebih sulit
      Namun saya penasaran mengapa LLM berbasis CPU melakukan kuantisasi. Sepemahaman saya, itu adalah proses menurunkan presisi bobot agar memakai lebih sedikit memori
      Tidak jelas apakah kurangnya presisi membuat perbedaan. Jika begitu, mengapa sejak awal memakai floating point? Jika presisi tidak penting, presisi tambahan hanya membuat sumber daya terpakai lebih banyak tanpa alasan nyata, dan kemungkinan memakai sumber daya beberapa orde magnitudo lebih banyak daripada yang diperlukan
      Bidang ini tidak dimulai oleh orang-orang yang memahami performa. Mereka membuat sesuatu dengan menggunakan alat, tetapi tidak ada “mengapa”. Mereka melakukannya karena alatnya bekerja seperti itu
      Alasan ini penting adalah sebagai berikut. Bahkan pada CPU umum, satu cara mengakses data bisa beberapa orde magnitudo lebih cepat daripada cara lain, tetapi kita harus mengetahuinya. Bukankah kita ingin menurunkan biaya LLM beberapa orde magnitudo?
    • Apa yang tidak efisien dari floating point? Machine learning tampaknya mendapat keuntungan besar dari kemampuan mengakses rentang dinamis dalam skala beberapa orde magnitudo

  • Presentasi dan slide dari beberapa tahun lalu tentang bagian-bagian rumit CPU dan GPU ini juga layak dilihat
    Alexander Titov — Know your hardware: CPU memory hierarchy https://youtu.be/QOJ2hsop6hM
    https://github.com/alexander-titov/public/blob/master/confer...
    Know Your Hardware - CPU Memory Hierarchy -- Alexander Titov -- C%2B%2B Moscow Meetup March 2019.pdf
    https://github.com/alexander-titov/public/blob/master/confer...
    GPGPU - what it is and why you should care -- Alexander Titov -- CoreHard 2019.pdf