RISC-V terlalu lambat, bahkan kelewat lambat

 (marcin.juszkiewicz.com.pl)
3 poin oleh GN⁺ 29 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Pekerjaan port RISC-V untuk Fedora Linux sudah berjalan sekitar 3 bulan, dan sebagian besar paket telah selesai dibangun untuk Fedora 43
  • Saat ini perangkat keras RISC-V menunjukkan kecepatan build yang sangat lambat, dengan waktu build untuk paket yang sama mencapai lebih dari 5 kali dibanding x86_64
  • Agar bisa diadopsi sebagai arsitektur resmi Fedora, dibutuhkan perangkat keras kelas server yang mampu membangun binutils dalam waktu kurang dari 1 jam
  • Keterlambatan build memicu keluhan dari maintainer paket, dan bahkan ada kemungkinan RISC-V dikeluarkan
  • Ke depan, mereka berencana memperbaiki masalah performa lewat build Fedora 44 dan penerapan builder yang lebih cepat, sambil mempertahankan penyatuan kernel dan menonaktifkan LTO

Status perkembangan porting Fedora RISC-V

  • Pekerjaan port RISC-V untuk Fedora Linux sudah berlangsung sejak sekitar 3 bulan lalu, dan ada banyak perubahan selama prosesnya
  • Sebagian besar item pada pelacak Fedora RISC-V sudah dibereskan, dan kini hanya 17 item yang masih berstatus NEW
  • Sumber paket Fedora diambil lalu dibangun dengan perintah fedpkg mockbuild -r fedora-43-riscv64
  • Sejauh ini sudah diajukan 86 Pull Request untuk paket, sebagian besar telah di-merge, dan build untuk Fedora 43 pun selesai
  • Build tambahan dapat dilakukan dengan mengikuti tag ‘f43-updates’

  • Masalah kecepatan build RISC-V

    • Perangkat keras RISC-V saat ini menunjukkan kecepatan build yang sangat lambat
    • Waktu build binutils 2.45.1-4.fc43 terukur 143 menit pada riscv64, 36 menit pada aarch64, dan 29 menit pada x86_64
    • Board StarFive VisionFive 2 yang digunakan memiliki dukungan driver yang baik, tetapi performanya lambat
    • Membangun paket yang sama pada board Milk-V Megrez memakan waktu 58 menit
    • Saat ini build RISC-V dilakukan dengan LTO (link-time optimization) dalam keadaan nonaktif, untuk mengurangi penggunaan memori dan waktu build
    • Builder yang digunakan memiliki 4~8 core, RAM 8~32GB, dan performanya dinilai setara Arm Cortex-A55
    • Ke depan, UltraRISC UR-DP1000 SoC (hingga 64GB RAM) dan sistem berbasis SpacemiT K3 (hingga 32GB RAM) diharapkan bisa membawa perbaikan

  • Syarat masuk sebagai arsitektur resmi Fedora

    • Agar bisa dimasukkan sebagai arsitektur resmi Fedora, dibutuhkan perangkat keras yang mampu membangun paket binutils dalam waktu kurang dari 1 jam
    • Kecepatan yang setara dengan arsitektur lain juga harus dicapai bahkan saat LTO diaktifkan secara global di seluruh sistem
    • Hasil build baru bisa masuk ke repositori setelah semua arsitektur selesai, sehingga builder yang lambat memicu keluhan dari maintainer paket
    • Di masa lalu juga ada keluhan terkait masalah kecepatan builder AArch64, dan beberapa pengembang bahkan menyebut kemungkinan mengecualikan RISC-V
    • Builder ke depan juga harus berupa sistem server yang bisa dipasang di rack dan dikelola dari jarak jauh; lingkungan SBC yang butuh reboot manual tidak cocok
    • Jika syarat-syarat ini tidak terpenuhi, adopsi RISC-V 64-bit sebagai arsitektur resmi Fedora tidak akan memungkinkan

  • Pengujian lokal dengan QEMU

    • Karena waktu build sangat lama, pengujian lokal melalui emulasi QEMU menjadi berguna
    • Pada desktop AArch64 80-core, emulasi userspace riscv64 melalui QEMU dapat membangun paket llvm15 dalam sekitar 4 jam
    • Paket yang sama membutuhkan 10,5 jam saat dibangun pada builder Banana Pi BPI-F3
    • Karena paket LLVM memanfaatkan baik core maupun memori, ada harapan peningkatan performa pada sistem berbasis Ampere One 192/384-core
    • QEMU hanya digunakan untuk build dan pengujian lokal, sementara Fedora tetap hanya melakukan build native

  • Rencana ke depan

    • Akan mulai build Fedora Linux 44
    • Targetnya adalah semua builder menggunakan image kernel yang sama, karena saat ini versi kernel masih bercampur
    • LTO akan tetap dipertahankan dalam keadaan nonaktif
    • Untuk mengatasi masalah kecepatan, mereka berencana mengadopsi builder baru yang lebih cepat, dan sebagian paket berat akan dialokasikan ke builder tersebut

Bacaan terkait

1 komentar

 
GN⁺ 29 hari lalu
Opini Hacker News

  • Menurut saya, alih-alih menyalahkan ISA itu sendiri, masalahnya lebih pada implementasi silikon dan perangkat lunak yang belum punya optimasi spesifik arsitektur
    Pada akhirnya RISC-V juga akan berkembang
    ARM juga awalnya berfokus pada kecepatan, lalu beralih ke efisiensi daya dan sukses di pasar embedded, dan sekarang terlihat kembali bergerak ke arah performa

    • Dalam beberapa kasus, spesifikasi ISA RISC-V itu sendiri memang bisa menjadi masalah
      Misalnya ada kasus seperti LLVM issue #150263, #141488
      Selain itu, ukuran halaman 4KiB yang tetap juga membatasi performa dibanding ARM
    • Sulit setuju dengan pernyataan “RISC-V suatu hari akan menyusul”
      ARM pernah cepat, lalu lambat, lalu cepat lagi, tetapi RISC-V belum pernah sekali pun menunjukkan daya saing di ranah performa tinggi
      Implementasi buatan tim kecil memang mengesankan, tetapi untuk kelas mobile, desktop, dan server masih belum cukup
    • Pernyataan “ini bukan masalah ISA, melainkan implementasi” memang benar, tetapi juga terlalu jelas
      Pada praktiknya, yang penting adalah desain VLSI analog seperti struktur cache dan interface DDR·PCI, dan hampir tidak ada tim yang benar-benar piawai dalam hal ini
      Selain itu, semua perusahaan ingin menjadi ‘vendor RISC-V performa tinggi’, tetapi tidak ada yang mau mengambil pasar ‘embedded’
      Di AS, model bisnisnya adalah menjual IP saja alih-alih memproduksi chip langsung, jadi untuk mendapatkan hardware nyata kita bergantung pada vendor Tiongkok
    • Kalau melihat pola perkembangan performa CPU, siklusnya berulang: pertama mengoptimalkan efisiensi daya, lalu meningkatkan kecepatan
      Contoh paling jelas adalah ketika arsitektur Netburst pada Pentium 4 mencapai batas, lalu arsitektur Core yang diturunkan dari core hemat daya menjadi andalan Intel
      Sejarah ARM juga menunjukkan pola serupa
    • Di video LowSpecGamer ada kisah bahwa chip ARM awal bahkan bisa berjalan hanya dengan dioda proteksi
      Menurut Steve Furber, chip itu begitu efisien sampai-sampai kode tetap berjalan meski sambungan daya sempat terlupa

  • Membagikan koreksi atas tulisan blog yang dibuat rekan kerja
    Pada sistem build Fedora RISC-V, build binutils selesai dalam 67 menit memakai Milk-V “Megrez”, peningkatan besar dari rekor sebelumnya 143 menit
    Saat ini board pengembangan tercepat bukan Banana Pi, melainkan SiFive “HiFive P550” dan UltraRISC “DP1000”
    Presentasi FOSDEM “Fedora on RISC-V: state of the arch” juga membahas benchmark terkait
    Pengujian Marcin dilakukan di StarFive “VisionFive 2”, board yang stabil tetapi tergolong lambat

    • VisionFive 2 memang andal, tetapi merupakan board berusia lebih dari 3 tahun, sehingga build modern terbentur batas memori
      Saat build gcc, untuk melakukan link 4 biner secara bersamaan dibutuhkan setidaknya 16GB dan swap agar berjalan stabil
      Di VisionFive 2, build harus dijalankan dengan -j1 atau -j2, sehingga waktu build menjadi 2~4 kali lebih lama
      Akan lebih efisien memakai linker yang lebih baik (pengganti ld) atau seperti sistem build LLVM yang bisa mengatur jumlah link paralel secara terpisah

  • ARM membutuhkan 40 tahun untuk mencapai posisinya sekarang, sedangkan RISC-V baru berusia 15 tahun
    Tahun ini Tenstorrent dikabarkan akan merilis platform server berbasis RVA23, jadi menarik untuk dilihat
    Pada akhirnya yang menentukan adalah apakah vendor hardware bisa menghadirkan silikon performa tinggi

    • RISC-V banyak dipengaruhi MIPS, dan MIPS sendiri sempat sangat diharapkan pada awal 1990-an tetapi akhirnya tersingkir dari pasar
    • AArch64 memang baru 15 tahun, tetapi arsitekturnya hampir sepenuhnya berbeda dari ARM 32-bit

  • felix sedang membangun repo Arch Linux RISC-V dengan Milk-V Pioneer
    Saya juga mengira lambatnya pengembangan dipengaruhi sanksi terhadap SOPHGO
    Milk-V Oasis berbasis SG2380 dari SOPHGO memang batal dirilis, padahal itu SoC yang sangat menjanjikan
    Chip perusahaan ini mendukung arsitektur ganda yang bisa beralih antara ARM/RISC-V
    Lihat repo Arch RISC-V, artikel terkait

    • Saya penasaran apakah bisa dijelaskan lebih konkret sanksi apa yang benar-benar berdampak dan bagaimana efeknya

  • Saya penasaran kenapa software RISC-V harus dibangun langsung di sistem RISC-V
    Compiler memasukkan informasi arsitektur target ke dalam kode, jadi secara teori bukankah itu juga bisa dilakukan di sistem lain

    • Untuk cross-compile seluruh distribusi, distribusi tersebut memang harus mendukungnya
      Fedora saat ini hanya mendukung native build, dan compiler cross yang tersedia hanya versi bare-metal untuk firmware
      Selain itu, otomasi pengujian juga sulit, sehingga native build di hardware nyata lebih realistis
      AArch64 juga lambat pada masa awal, tetapi sekarang sudah berkembang sampai build Qt4 selesai hanya dalam 18 menit
    • Ada banyak masalah dependensi karena script build merujuk ke library atau konfigurasi OS host
      Ini bisa diatasi tergantung bahasanya, tetapi ekosistem C/C++ sangat rumit
      Karena itu kebanyakan build dilakukan di VM atau hardware target yang sebenarnya
    • Compiler lama memilih backend saat waktu kompilasi, sehingga dukungan multi-arsitektur sulit
      Setelah LLVM hal ini menjadi memungkinkan, tetapi untuk pengujian tetap memerlukan emulator
    • Cross-build sendiri memungkinkan, tetapi pengujian setelah build membutuhkan lebih banyak resource
    • Cross-compiler itu sendiri mudah, tetapi harus memperbaiki script build untuk puluhan ribu paket, jadi beban pemeliharaannya besar

  • Ada juga pendapat, “kenapa tidak cross-compile saja di server x86_64?”

    • Tetapi memperbaiki semua software agar sepenuhnya mendukung cross-compilation adalah pekerjaan yang sangat besar

  • Setahun lalu saya melihat posting di Mastodon yang mengatakan “hardware RISC-V tercepat masih lebih lambat daripada QEMU”
    Memang RISC-V sedang menyebar ke banyak bidang, tetapi di high-performance computing masih lemah

    • Milk-V Pioneer memang melampaui batas itu, tetapi mahal dan arsitektur yang dipakai juga sudah tua
      Selain itu, perusahaan pengembangnya hilang karena sanksi AS

  • Cross-compilation bukan tidak mungkin, tetapi masalahnya ada pada pengujian saat tahap %install dan %check
    Contohnya, pada PR paket rpy pengujian vektor harus dinonaktifkan di RISC-V
    Build dan test memang bisa dipisahkan, tetapi penghematan waktu tidak sebanding dengan kompleksitas tambahannya

    • Fedora secara tradisional lebih memilih native build
      Bahkan pada thread LWN tahun 2012 (tautan) sudah ada perdebatan yang menolak cross-compilation
    • Build dengan QEMU adalah alternatif yang paling realistis

  • Hasil yang menyebut i686 14% lebih cepat daripada x86_64 terasa meragukan
    Biasanya x86_64 lebih cepat, berkat jumlah register yang lebih banyak dan instruksi vektor
    Namun compiler mungkin mencoba lebih banyak optimasi sehingga waktu build bisa lebih lama
    Hal serupa mungkin juga terjadi di RISC-V

    • Kasus i686 lebih cepat bisa jadi karena bottleneck bandwidth memori
    • Build x86_64 memiliki 50% lebih banyak pengujian linker dibanding i686

  • Tulisan tersebut tidak menjelaskan CPU RISC-V mana yang dipakai, sehingga perbandingannya jadi kabur

    • Pada praktiknya, kebanyakan builder memakai konfigurasi 4~8 core dan RAM 8~32GB, karena memang pilihannya tidak banyak
      Milk-V Pioneer menjadi pengecualian dengan 64 core dan RAM 128GB, tetapi arsitekturnya sudah tua dan harganya mahal