Branch Predictor 2-Ahead pada Zen 5: Gagasan Berusia 30 Tahun yang Membuka Kemungkinan Baru

 (chipsandcheese.com)
1 poin oleh GN⁺ 2024-07-28 | 1 komentar | Bagikan ke WhatsApp
  • AMD Zen 5 memperkenalkan 2-Ahead Branch Predictor dalam perancangan ulang menyeluruh arsitektur Zen, membawa kembali riset prediksi cabang ahead multi-blok dari era 1990-an ke ekspansi front-end x86 modern
  • Prediksi cabang adalah mekanisme yang memungkinkan front-end CPU terus mengambil instruksi bahkan sebelum hasil cabang bersyarat diketahui; kegagalan prediksi berujung pada pipeline flush dan biaya restart
  • Zen 5 memiliki dua fetch pipe 32 byte/siklus dari cache instruksi L1 32KB, masing-masing terhubung ke cluster decode 4-wide, sementara Op Cache juga berstruktur dual-ported 6-wide yang dapat memasok hingga 12 operand ke Op Queue
  • Struktur baru ini memproses dua taken branch dalam satu siklus melintasi blok instruksi yang tidak berurutan, dan memakai field panjang 5-bit untuk menemukan titik awal jendela prediksi ketiga sehingga mengurangi penggunaan berlebih resource decode dan Op Cache
  • Karena instruksi x86 berukuran variabel membuat penentuan batas instruksi sulit diparalelkan, 2-Ahead Branch Predictor serta struktur fetch·decode ganda menjadi perubahan kunci dalam ekspansi front-end keluarga Zen

Titik perubahan pada front-end Zen 5

  • AMD memperkenalkan Zen 5 sebagai perancangan ulang menyeluruh arsitektur Zen, dan 2-Ahead Branch Predictor menjadi salah satu bagian yang menonjol dari perubahan tersebut
  • Struktur ini muncul kembali di tengah upaya meningkatkan performa single-core, berdasarkan gagasan yang dibahas dalam makalah-makalah 30 tahun lalu
  • Dengan memprediksi beberapa taken branch sekaligus, front-end dapat melihat lebih jauh ke depan dalam aliran instruksi

Mengapa prediksi cabang diperlukan dalam pipeline CPU

  • CPU modern menggunakan struktur pipeline yang membagi pengambilan instruksi (fetch), decode, dan eksekusi ke dalam beberapa tahap
  • Saat ada cabang bersyarat, front-end harus menentukan lokasi instruksi berikutnya yang akan diambil sebelum evaluasi kondisi selesai
  • Pilihan yang mungkin secara garis besar ada dua
    • Berhenti sampai hasil cabang keluar
    • Memprediksi jalur berikutnya, dan jika salah, membuang pekerjaan yang keliru lalu memulai lagi dari titik yang pasti
  • Jika prediksi salah, diperlukan flush untuk menghapus pekerjaan yang bergantung pada spekulasi tersebut dari pipeline
  • Biaya berhenti pada kondisi cabang sebanding dengan jumlah tahap pipeline antara instruction fetch dan selesainya evaluasi branch condition
  • Pada akhirnya, CPU harus memprediksi alur instruksi program seakurat mungkin

Konteks munculnya gagasan 2-Ahead

  • Dalam metode prediksi sederhana, ada strategi yang selalu menganggap backward jump pendek sebagai taken, dan secara historis strategi ini memberi keuntungan besar dibanding selalu mengambil alamat berikutnya
  • Dengan mempertahankan state kecil seperti riwayat cabang terbaru atau catatan alamat, hasil yang lebih baik dapat diperoleh pada program nyata
  • Bahkan struktur berukuran puluhan KB saja dapat mencapai tingkat prediksi cabang di kisaran atas 90%
  • 2-Ahead Branch Predictor adalah usulan yang telah dibahas sejak awal 1990-an, dan pada masa itu masalah memperlebar arsitektur menjadi 8-wide atau lebih juga dibahas bersama
  • Setelah itu, CPU komersial beralih ke multicore sehingga area tiap core menjadi lebih penting, dan akademia berfokus pada penyempurnaan TAGE predictor yang lebih efisien area
  • Seiring miniaturisasi proses memungkinkan lebih banyak transistor dimasukkan ke area serupa, minat pada performa single-core juga kembali meningkat bersama tren penskalaan hingga ratusan CPU out-of-order

Mengapa front-end x86 lebih sulit

  • ISA yang memakai instruksi berukuran tetap, seperti Arm 64-bit, lebih mudah mendecode bagian mana pun dari cache line instruksi secara paralel
    • Cukup membagi data input pada batas byte instruksi yang terjamin dan mereplikasi decoder logic
  • Pada x86, panjang instruksi bervariasi, sehingga byte instruksi harus di-parse secara linear untuk mengetahui batas berikutnya dari tiap instruksi
  • Paralelisasi sampai batas tertentu dapat dilakukan dengan pipelining seperti mendecode sebagian prefix terlebih dahulu, tetapi biayanya pada x86 tidak rendah
  • Inilah latar belakang mengapa decode 4-wide telah lama umum pada core x86 yang berorientasi performa
  • Desain seperti decode 6-wide pada Intel Golden Cove menjadi dapat dikomersialkan berkat peningkatan densitas logika pada proses terbaru, tetapi biaya area dan daya untuk monolithic parallel x86 decoding meningkat secara super-linear terhadap kenaikan width
  • Kode integer aplikasi umum memiliki branch density sekitar 1 branch setiap 5–6 instruksi, sehingga motivasi untuk memperlebar decoder jauh lebih besar menjadi berkurang
  • Front-end x86 membutuhkan cara untuk melewati tahap penentuan batas instruksi yang sulit diparalelkan, sekaligus mencapai batas instruksi berikutnya secara aman

Implementasi fetch·decode ganda pada Zen 5

  • “Multiple-block ahead branch predictors” oleh Seznec et al. adalah makalah kunci yang membahas alasan dan cara implementasi 2-Ahead Branch Predictor
  • Predictor yang menangani beberapa taken branch saja tidak cukup; Seznec et al. menilai instruction fetch dual-porting diperlukan agar dapat dimanfaatkan tanpa membuat kebutuhan area meledak
  • Zen 5 mengubah instruction fetch dan Op Cache menjadi struktur dual-port
    • Menggunakan dua fetch pipe 32 byte/siklus dari cache instruksi L1 32KB
    • Tiap fetch pipe terhubung ke cluster decode 4-wide miliknya sendiri
    • Op Cache memakai desain dual-ported 6-wide, dan dapat memasok hingga 12 operand ke Op Queue
  • Branch Target Buffer juga termasuk target dual-porting
    • Ukuran besar 16K entries yang dapat diakses oleh L1 BTB Zen 5 dapat menjelaskan kemungkinan L1 BTB dual-ported
    • L2 BTB memiliki 8K entries, lebih kecil daripada L1 BTB
    • AMD menggunakan L2 BTB mirip victim cache; entry yang di-evict dari L1 BTB dipindahkan ke L2 BTB

Cara memproses 2 taken branch dalam satu siklus

  • Zen 5 dapat memproses dua taken branch dalam satu siklus melintasi blok instruksi yang tidak berurutan
  • Perubahan ini mengurangi hilangnya fetch bandwidth saat bertemu taken branch, dan memungkinkan prediksi hingga melampaui dua taken branch
  • Karena dapat melihat lebih jauh ke instruction stream setelah taken branch kedua, Zen 5 dapat memiliki tiga prediction window
  • Ketiga prediction window semuanya dapat dimanfaatkan untuk menghasilkan instruksi bagi decode
  • Prediction window kedua diberi length field 5-bit
    • Mencegah situasi ketika resource decode atau Op Cache dipesan secara berlebihan
    • Lebih kecil daripada pointer, tetapi menyediakan titik awal prediction window ketiga
    • Saat prediction window ketiga melewati cache line boundary, tidak perlu menyimpan state tambahan pada prediction lookup index untuk siklus berikutnya
    • Jika prediction window ketiga berada dalam cache line yang sama dengan prediction window pertama atau kedua, partial third window tersebut tidak seefektif prediction window ketiga yang utuh

Batasan yang tersisa pada SMT

  • Ketika dua thread aktif di Zen 5, fetch pipe yang melekat pada decode cluster dipartisi secara statis
  • Dalam kondisi ini, agar dapat beroperasi seperti dual fetch core, Zen 5 harus melakukan fetch dari cache instruksi L1 dan Op Cache sekaligus
  • Alasan AMD membuat Op Cache dual-port mungkin untuk mempertahankan dual fetch pipeline dengan lebih baik

Makalah terkait yang turut disebutkan

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-28
Komentar Hacker News

  • Untuk artikel yang menjelaskan branch prediction dengan baik sejak implementasi awalnya, https://danluu.com/branch-prediction/ bagus

  • Penasaran bagaimana performa SMT akan muncul, dan berharap pendekatan kali ini memberi keuntungan sekaligus makin disempurnakan di generasi berikutnya
    Zen5c mencapai 192 core atau 384 vCPU, dan Zen 6c tahun depan tampaknya bisa mencapai 256 core. Untuk server 1U dual-socket, itu berpotensi menjadi 512 core dan 1024 vCPU
    Masalah penskalaan aplikasi web yang dialami pada 2014 kini, asalkan pendinginannya memadai, bisa masuk ke satu server. Bahkan jika hanya menghitung 1 RPS per vCPU, itu 1000 RPS tanpa memperhitungkan cache hit, sementara front page HN pun tidak menghantam server dengan 1000 pageview per detik

    • Menyajikan halaman web adalah pekerjaan murah, jadi sebelum core jenuh, kemungkinan besar akan lebih dulu menyentuh batas I/O jaringan
      Saya penasaran seperti apa performa HPC-nya. Pendinginan itu sendiri mungkin bukan masalah besar, tetapi mulai titik tertentu bisa menjadi persoalan “basah” yang membutuhkan direct liquid cooling (DLC)
    • Seperti komputasi memasuki era kilobyte pada 1940-an, kini kita sedang memasuki era kilocore
      Jika rak server padat berisi GPU dianggap sebagai satu mesin, kita sebenarnya sudah mencapai ratusan kilocore
      Saya pernah berdebat dengan orang yang tidak memahami konsep bahwa layanan berskala Wikipedia bisa disajikan dari satu server, dan itu cukup menarik. Sebenarnya itu sudah mudah dilakukan selama beberapa waktu; hanya saja tidak dilakukan karena alasan praktis seperti ketersediaan atau efisiensi biaya
    • Bisa juga sebaliknya. Semakin baik pipeline CPU dimanfaatkan, semakin kecil ruang untuk menyisipkan thread kedua, sehingga keuntungan SMT bisa mengecil
    • SMT membutuhkan jauh lebih banyak verifikasi benchmark
      Secara intuitif, jika semakin banyak pekerjaan memproses masalah yang sama dengan setengah kecepatan, seharusnya ada biaya penggunaan memori; saya penasaran apakah aplikasi yang hanya memakai lebih banyak memori tanpa mendapat peningkatan kecepatan saat SMT diaktifkan itu umum
      Dalam cukup banyak benchmark publik, sebagian besar aplikasi tampaknya tidak mendapat keuntungan yang nyata dalam kecepatan eksekusi
    • Masalah penskalaan aplikasi web biasanya muncul di sekitar latensi database

  • Selalu menarik melihat makalah berusia puluhan tahun yang saat diterbitkan tidak banyak diperhatikan, lalu mendadak menjadi mutakhir ketika hardware sudah cukup kuat
    Contohnya Z-buffer. Ini dipakai di video game 3D, tetapi ketika pertama kali muncul dalam makalah, ia diperlakukan seperti cabang sampingan, bukan topik utama, karena membutuhkan memori terlalu banyak
    Beberapa dekade kemudian, megabyte menjadi cukup murah, dan akhirnya semua renderer 3D real-time menggunakannya

    • Contoh lain adalah kode pemeriksaan paritas berdensitas rendah. Robert Gallager menemukannya pada 1962, tetapi karena secara komputasi tidak realistis, ia ditinggalkan dan terlupakan selama puluhan tahun
      Sepertinya ada kekosongan sekitar 38 tahun dalam literatur sampai David MacKay menemukannya kembali
      Penggunaan arus utama pertamanya terjadi pada 2003, dan sekarang dipakai di WiFi, Ethernet, dan 5G
      [1] https://en.wikipedia.org/wiki/Low-density_parity-check_code
      [2] https://scholar.google.com/scholar?q=%22low+density+parity+c...
    • Kadang saya bertanya-tanya apakah ada karier akademis semacam ini yang tersembunyi bagi engineer
      Jika pergi ke perpustakaan dan membaca hal-hal yang dulu dipublikasikan para peneliti ilmu komputer sebagai makalah cetak, mungkin ada ide yang saat itu tidak realistis tetapi sekarang bisa diimplementasikan
    • Menurut saya ini bukan semata-mata karena hardware menjadi kuat sehingga memungkinkan, melainkan lebih dekat ke fakta bahwa desain seperti itu sudah mungkin sejak puluhan tahun lalu, tetapi baru menjadi menarik dalam kombinasi trade-off saat ini
      Selama 20 tahun terakhir, performa single-core ditekan karena prioritas pada penskalaan horizontal, yaitu lebih banyak core, sehingga kompleksitas dan luas die tiap core menjadi masalah. Jika tren ini tidak ada dan perancang CPU terutama mengejar performa single-core, saya rasa kita akan melihat implementasinya jauh lebih awal
      Z-buffer adalah konsep sederhana, jadi masuk akal jika dalam makalah tampak seperti cabang sampingan. Contoh yang lebih baik mungkin ray tracing. Bahkan tanpa latar belakang grafis 3D, konsepnya sendiri cukup jelas, tetapi sampai baru-baru ini secara performa tidak realistis untuk rendering real-time
      Yang menarik adalah kita tidak menemukan pendekatan yang lebih sederhana untuk memperkirakan rendering yang mirip nyata, dan harus kembali ke solusi lama yang agak naif serta mahal
    • Contoh lain adalah borrow checker Rust, yang berakar pada makalah sistem tipe substructural dari puluhan tahun lalu
      Banyak akademisi menganggap sistem tipe substructural pada dasarnya telah mati tergeser garbage collection, tetapi Rust menghidupkannya kembali dengan menggabungkannya dengan ide-ide baru C++ pada masa itu
    • Z-buffer tidak hanya membutuhkan memori tambahan sebesar satu framebuffer, tetapi juga banyak bandwidth baca-tulis untuk setiap piksel
      Kebutuhan bandwidth memori tambahan inilah yang membuatnya sulit dan mahal diimplementasikan dengan benar. Implementasi kelas atas memakai kanal RAM khusus, tetapi pada hardware murah, ia banyak memakan bandwidth antarmuka memori bersama
      Misalnya, sebagian game N64 mematikan Z-buffer dan mengoptimalkan penggambaran latar belakang/latar depan yang dikelola lewat software untuk menghindari biaya membaca dan memperbarui informasi kedalaman

  • Prediktor spekulatif telah menjadi sasaran berbagai serangan untuk mengekstraksi data privat
    Jika cukup banyak ISA umum yang rentan, saya penasaran apakah ada langkah yang diambil untuk mengurangi dampak serangan seperti ini

    • Kerentanannya bukan pada prediksi cabang, melainkan eksekusi spekulatif. Prediktor cabang hanyalah target yang perlu diperdaya agar prosesor mengeksekusi kode secara spekulatif di program korban. Selain itu, untuk membaca hasil eksekusi spekulatif, penyerang juga memerlukan sumber timing yang valid
      Tidak ada cara untuk mencegahnya, kecuali pendekatan setingkat merebus lautan[0]. Eksekusi spekulatif terlalu bernilai bagi performa; komputer tanpa itu akan nyaris sama sekali tidak layak dipakai. Jika benar-benar menginginkan prosesor tanpa eksekusi spekulatif, belilah Pentium generasi pertama yang lama
      Mitigasi yang praktis ada bermacam-macam, tetapi setidaknya harus menjamin pemisahan proses antara proses korban yang memiliki rahasia dan calon penyerang yang dapat memengaruhi eksekusi korban
      Intel ketahuan melakukan eksekusi spekulatif melintasi ring, sehingga dari ruang pengguna dimungkinkan membaca memori kernel atau hypervisor. Pada CPU yang desainnya tidak buruk, hal utama yang perlu dikhawatirkan biasanya adalah HTML iframe
      Origin yang berbeda tidak bisa mengirim permintaan HTTP sesuka hati[1], tetapi bisa menyertakan satu sama lain tanpa izin[2]. Secara tradisional, informasi itu dimuat ke proses penyerang dan bisa dibocorkan lewat serangan timing
      Solusi awal di web bukan memisahkan iframe ke proses berbeda, melainkan menghapus shared-memory multithreading itu sendiri. Jika penyerang kehilangan acuan timing, apa pun yang dieksekusi spekulatif oleh korban menjadi kurang relevan. Namun untuk itu multithreading harus dihilangkan. Jika tidak, satu thread bisa membuat jam dengan berulang-ulang menulis data yang diketahui dalam sebuah loop
      [0] https://hackaday.com/2013/08/02/the-mill-cpu-architecture/
      [1] Setidaknya tidak bisa kecuali origin tujuan mengizinkannya lewat CORS
      [2] Contoh: hotlink gambar atau embed iframe
    • Titik yang dapat dieksploitasi adalah interaksi eksekusi spekulatif dengan translasi memori virtual dan cache
      Ini bukan kerentanan yang melekat pada prediksi itu sendiri

  • Dari sudut pandang pemula di bidang ini, setelah membaca tulisannya pun masih belum jelas apa sebenarnya prediktor cabang 2-ahead itu

    • Karena ini konsep dari sekitar 30 tahun lalu, sepertinya mengacu pada makalah tahun 1996 ini[0]. Isinya melampaui level saya, tetapi tampaknya membantu masalah prediksi cabang yang muncul pada banyak unit instruksi dan kecepatan clock tinggi
      Pada era 90-an, prosesor cenderung hanya mendekati salah satu dari keduanya, tetapi prosesor modern tampaknya kebanyakan memiliki keduanya
      Abstrak “Multiple-block ahead branch predictors” menjelaskan pendekatan yang tidak memakai informasi blok instruksi saat ini untuk memprediksi alamat blok instruksi berikutnya, melainkan memprediksi blok setelahnya. Dengan begitu, pada prosesor “brainiac” dengan dispatch lebar, bottleneck pengambilan instruksi dapat dikurangi, dan dua alamat blok instruksi dapat diprediksi secara efisien dalam satu siklus
      Selain itu, pada prosesor “speed demon”, proses prediksi cabang dapat dipipeline-kan untuk memperoleh clock yang lebih tinggi atau peningkatan akurasi melalui struktur prediksi yang lebih besar. Berbeda dari pendekatan multi-prediktor yang ada, prediktor cabang beberapa blok ke depan dapat menggunakan metode prediksi cabang apa pun
      [0] https://dl.acm.org/doi/10.1145/237090.237169
      Sebagai tambahan, sepertinya eyegor sudah memasang tautannya, tetapi maksud saya setidaknya lihat abstraknya
    • Sejauh yang saya pahami, ini memprediksi target bukan cabang berikutnya, melainkan cabang setelahnya
      Ini pasti jauh lebih sulit daripada memprediksi cabang berikutnya, tetapi memungkinkan kode yang akan memberi makan pipeline yang lebih dalam diambil jauh lebih awal
    • Bahkan bagi yang bukan pemula pun sama membingungkannya. Tulisan itu menghabiskan banyak waktu menjelaskan dasar-dasar prediksi cabang, lalu justru melewati penjelasan ketika sampai ke 2-ahead
    • Sepertinya ini memprediksi dua cabang, bukan satu cabang, dalam satu siklus
      Jadi, alih-alih hanya mengevaluasi lebih awal n+1 seperti prediksi cabang biasa, hasil n+2 juga dapat dievaluasi lebih awal. Saya belum benar-benar paham bagaimana ini bekerja tanpa merusak cache L1
      Jika caranya adalah melihat lebih jauh dari n+1, sepertinya cache eviction akan jauh meningkat, jadi rasanya ada sesuatu yang saya lewatkan
      Zen 5 disebut mampu melihat lebih jauh hingga instruction stream setelah taken branch kedua, sehingga dapat memiliki tiga jendela prediksi yang berguna untuk membuat instruksi yang akan didekode
      Makalah aslinya tersedia open access, tetapi saya belum banyak membacanya: https://dl.acm.org/doi/10.1145/237090.237169
    • Prediktor cabang biasa menebak arah mana yang akan diambil sebuah cabang, misalnya if-else, sebelum cabang itu dieksekusi. Dengan begitu CPU dapat mengambil dan mendekode instruksi lebih dulu
      Setiap arah cabang mengarah ke awal blok instruksi baru, dan instruksi terakhir di blok seperti itu biasanya adalah cabang lain
      Dengan kata lain, prediktor cabang adalah perangkat yang menebak alamat blok berikutnya. Prediktor cabang 2-ahead melakukan hal yang sama, tetapi untuk dua blok berikutnya
      Dalam istilah makalahnya, “informasi dari blok instruksi saat ini digunakan untuk memprediksi alamat blok yang datang setelah blok instruksi berikutnya”
      Berbeda dari prediktor cabang biasa, ini dapat dilakukan tanpa harus menunggu instruksi di blok berikutnya didekode. Karena itu, ia bisa memberi makan beberapa decoder instruksi secara bersamaan
      Ini sangat berguna pada CPU modern ketika decoder instruksi menjadi bottleneck. Dengan satu decoder yang hanya mendekode satu instruksi per siklus, sulit mengikuti front-end lebar yang bisa mengeksekusi banyak instruksi, misalnya 4–6 instruksi per siklus

  • Mungkin diperlukan lebih banyak hint cabang: https://github.com/ziglang/zig/issues/5177
    Saya membayangkan cold, warm, warmer, lalu hot dihilangkan karena menjadi default. Kadang semua cabang kecuali satu juga bisa ditandai sebagai cold

  • Mungkin ini ide buruk, tapi saya ingin tahu alasannya
    Saat ada branch bersyarat, saya penasaran kenapa tidak mengambil dan menyiapkan instruksi dari kedua kemungkinan branch, lalu membuang sisi yang salah
    Saya ingin tahu apakah itu jauh lebih sulit, atau ada alasan lain yang membuatnya tidak sepadan

    • Itu adalah strategi yang kurang optimal
      Branch predictor TAGE modern akurasinya jauh di atas 99%. Jadi instruksi tambahan dari branch sisi satunya hampir selalu dibuang
      Yang lebih buruk, front-end mengambil instruksi puluhan branch lebih jauh sebelum back-end bisa memastikan arah sebenarnya. Lalu apa yang dilakukan pada branch berikutnya? Mendekode 4 kemungkinan branch, lalu 8, 16, 32? Sebagian besar akhirnya dibuang
      Jika ada hardware untuk mengambil beberapa stream instruksi secara paralel, seperti Intel Gracemont/Goldmont/Skymont dan AMD Zen 5, strategi yang lebih baik adalah mengasumsikan branch predictor 100% benar. Ikuti satu branch, lalu lanjut mengikuti yang berikutnya
      Intel Skymont punya 3 decoder, masing-masing 3-wide, sehingga mendekode 3 target branch berikutnya secara paralel. Intel bahkan memasukkan branch palsu untuk memecah blok kode besar, agar ketiga decoder selalu mendekode bagian berbeda dari stream instruksi yang akan datang. Setelah itu, 3 stream micro-op digabungkan sehingga Skymont bisa mempertahankan bandwidth decode efektif 9 instruksi per siklus
      Mengeksekusi kedua branch hanya sedikit mengurangi latensi pada kasus langka ketika prediksi branch salah. Sebaliknya, dengan terus mengikuti dua atau tiga prediksi berikutnya ke satu arah, Intel dan AMD bisa membuat beberapa decoder bekerja paralel. Intel bisa membuat 9-wide dengan 3 decoder 3-wide yang lebih sederhana, dan AMD bisa membuat 8-wide dengan 2 decoder 4-wide yang lebih sederhana
    • Kasus ketika hasil branch acak itu jarang
      Compiler, runtime, CPU, dan sebagainya sering bisa menebak hasil mana yang lebih mungkin, dan sejak awal biasanya strategi yang lebih baik adalah tidak melakukan pekerjaan tambahan. Itu lebih baik daripada memakai silikon dan panas untuk jawaban yang salah untuk berjaga-jaga kalau tebakannya meleset
      Banyak orang tampaknya tidak punya intuisi tentang seberapa akurat branch prediction bisa. Cukup lihat kode sendiri, dan akan cepat sadar, “sebagian besar control flow akan ke sini, dan branch ini ada untuk menangani kondisi pengecualian”
      Compiler modern juga cukup baik menyimpulkan hal ini, dan CPU/JIT/runtime juga bisa membuat heuristik yang mengesankan. Namun ketika tetap gagal, kita bisa menaruh hint eksplisit di kode untuk memberi tahu compiler dan lainnya arah yang diharapkan
    • Saya bukan orang yang bekerja di bidang ini, hanya penggemar, tapi branch predictor tampaknya selalu begitu bagus sehingga melakukan keduanya tidak pernah sepadan
      Reorder buffer instruksi pada CPU modern punya kedalaman ratusan instruksi, dan jika di antaranya ada 8 conditional jump saja, jalur yang bisa ditempuh program menjadi 256
      Jika probabilitas branch predictor menebak benar semuanya lebih dari 50%, dan memang begitu kenyataannya, maka melakukan 256 kali pekerjaan untuk berjaga-jaga tidak sepadan
    • Itu disebut speculative execution, dan setahu saya semua CPU modern melakukannya
      Dibutuhkan silikon untuk menyimpan lebih banyak status mikroarsitektur, serta lebih banyak execution unit untuk memanfaatkan teknik itu sepenuhnya. Namun CPU superscalar sudah harus memiliki hal-hal tersebut untuk memanfaatkan instruction-level parallelism pada kode yang minim branch
      Sisanya adalah pekerjaan merepotkan untuk menangani hal-hal rumit seperti aliasing dan interrupt, tetapi para engineer hardware seperti penyihir, jadi mereka juga bisa melakukannya
      Namun speculative execution membuka kemungkinan penyalahgunaan side-channel timing cache, sehingga informasi bisa diekstrak dari data yang disentuh oleh kode yang hanya dieksekusi secara spekulatif dan efek samping arsitekturalnya tidak di-commit. Artinya, informasi bisa bocor bahkan dari kode yang tidak “benar-benar” dieksekusi
      Ini juga mencakup kode yang tidak dieksekusi secara eksplisit karena pemeriksaan kondisi, misalnya pemeriksaan izin
      Contoh serangan yang familier adalah Spectre: https://en.m.wikipedia.org/wiki/Spectre_(security_vulnerabil...
    • Puluhan tahun lalu akurasinya sudah mencapai 90%. Bergantung workload, chip modern jauh lebih baik lagi
      Jadi pada dasarnya sama sekali tidak menguntungkan. Resource chip itu jauh lebih baik dipakai untuk thread atau core lain

  • Untuk menilai apakah ini ide bagus, saya ingin melihat data performa terlebih dulu. Tidak ada juga informasi tentang penalti branch prediction dari pendekatan ini
    Bagaimanapun, intuisi dari pendekatan ini tampaknya adalah mengambil dan mendekode secara agresif instruksi yang mungkin belum ada di L1 instruction cache atau micro-op cache
    Ini penting untuk x86, dan mungkin juga RISC-V. Keduanya punya panjang instruksi yang bervariasi, jadi hanya dengan melihat blok instruction cache, core tidak bisa tahu bagaimana instruksi di dalam blok itu harus didekode. Pada kedua ISA, untuk mulai mendekode blok instruction cache, setidaknya PC dari satu instruksi harus diketahui
    Jadi jika aplikasi tahu ke mana ia bisa melompat dua blok di depan, itu membantu mengambil dan mendekode lebih jauh daripada pendekatan saat ini
    Pendekatan ini mirip dengan instruction prefetching, tetapi instruction prefetching tidak memberi informasi titik awal kepada core
    Core ARM berperforma tinggi kemungkinan tidak mengalami masalah “mencari titik awal” karena semua panjang instruksinya 32-bit. Karena itu, prosedur decoding bisa dilakukan secara paralel meski titik awal tidak diketahui
    Cara ini tampaknya akan menguntungkan aplikasi yang banyak bergantung pada front-end, misalnya workload cloud yang hot code block-nya tersebar di berbagai bagian biner. Saya penasaran apakah ada peningkatan atau penurunan performa pada jenis aplikasi lain

  • Saya masih sama sekali tidak paham apa itu 2-ahead branch predictor

    • Mungkin lebih baik mulai dengan membaca paper riset lama yang ditautkan di artikel
      Secara umum, paper riset lama mengasumsikan pembacanya tahu jauh lebih sedikit tentang topik seperti ini. Karena saat itu pengetahuan semacam ini jauh lebih niche

  • Yang dibutuhkan sekarang adalah bandwidth memori. Dua kanal memori pada soket AM5 konsumen terasa sangat kecil dibandingkan performa komputasi sebesar ini, terutama bahkan jika dibandingkan dengan Apple Silicon dasar
    Saya pindah dari konfigurasi Zen yang berat ke M2 Max, dan kembali terkejut melihat seberapa besar peningkatan bandwidth memori mempercepat pekerjaan data yang intensif. Bahkan dalam multitasking yang cukup berat, pipa memori yang sempit pada konfigurasi Zen sering tersumbat

    • Pada kenyataannya, sangat sedikit aplikasi yang mengalami bottleneck bandwidth memori tetapi CPU tetap lebih cocok daripada GPU
      Alasan orang-orang melirik Apple Silicon, terutama karena LLM, adalah karena meskipun LLM lebih cocok untuk GPU, ia juga membutuhkan banyak VRAM, sementara NVIDIA memasang harga yang tidak masuk akal untuk GPU dengan VRAM besar
      Jika AMD benar-benar ingin mematahkan dominasi NVIDIA, mereka harus menjual GPU konsumen dengan VRAM 64~128GB
    • AM5 sebenarnya memiliki 4 kanal memori. Karena DDR5 menggandakan jumlah kanal