RISC-V fazlasıyla yavaş

 (marcin.juszkiewicz.com.pl)
3 puan yazan GN⁺ 2026-03-24 | 1 yorum | WhatsApp'ta paylaş
  • Fedora Linux'un RISC-V port çalışmaları yaklaşık 3 aydır sürüyor ve paketlerin büyük bölümü Fedora 43 için derlenmiş durumda
  • Şu anda RISC-V donanımı çok yavaş derleme hızları gösteriyor; aynı paketin derlenmesi x86_64'e kıyasla 5 kat veya daha fazla sürebiliyor
  • Fedora'nın resmî mimarisi olarak kabul edilmesi için binutils'i 1 saat içinde derleyebilen sunucu sınıfı donanım gerekiyor
  • Derleme gecikmeleri paket bakımcılarının şikâyetlerine yol açıyor ve RISC-V'nin dışarıda bırakılabileceği de belirtiliyor
  • İleride Fedora 44 derlemeleri ve daha hızlı builder'ların devreye alınmasıyla hız sorununun iyileştirilmesi, ayrıca çekirdek birliğinin sağlanması ve LTO'nun kapalı tutulması planlanıyor

Fedora RISC-V portlama durumu

  • Fedora Linux'un RISC-V port çalışmaları yaklaşık 3 ay önce başladı ve bu süreçte çeşitli değişiklikler yaşandı
  • Fedora RISC-V takipçisindeki maddelerin büyük bölümü temizlendi ve şu anda yalnızca 17 madde NEW durumunda kaldı
  • Fedora paket kaynakları alınıp fedpkg mockbuild -r fedora-43-riscv64 komutuyla derleme yapılıyor
  • Şimdiye kadar 86 paket için Pull Request gönderildi; bunların çoğu birleştirildi ve Fedora 43 için derlendi
  • f43-updates etiketi izlenerek ek derlemeler yapılabiliyor

  • RISC-V derleme hızı sorunu

    • RISC-V donanımı şu anda çok yavaş derleme hızları sergiliyor
    • binutils 2.45.1-4.fc43 için derleme süresi riscv64'te 143 dakika, aarch64'te 36 dakika, x86_64'te ise 29 dakika olarak ölçüldü
    • Kullanılan StarFive VisionFive 2 kartı sürücü desteği açısından iyi olsa da hız bakımından yavaş
    • Aynı paket Milk-V Megrez kartında derlendiğinde 58 dakika sürüyor
    • Şu anki RISC-V derlemelerinde LTO (link-time optimization) kapalı; bunun amacı bellek kullanımını ve derleme süresini azaltmak
    • Builder'lar 4~8 çekirdek ve 8~32 GB RAM ile geliyor; performansları Arm Cortex-A55 seviyesinde değerlendiriliyor
    • Gelecekte UltraRISC UR-DP1000 SoC (64 GB RAM'e kadar) ve SpacemiT K3 tabanlı sistemlerin (32 GB RAM'e kadar) iyileştirme sağlaması bekleniyor

  • Fedora'nın resmî mimariye kabul koşulları

    • Fedora'nın resmî mimarileri arasına girebilmek için binutils paketini 1 saat içinde derleyebilen donanım gerekli
    • Sistem genelinde LTO etkin olsa bile diğer mimarilerle aynı seviyede hız sağlanması gerekiyor
    • Derleme sonuçları ancak tüm mimariler tamamlandığında depoya yansıtıldığı için, yavaş builder'lar paket bakımcılarının şikâyetlerine neden oluyor
    • Geçmişte AArch64 builder'larının yavaşlığı yüzünden de şikâyetler olmuştu; bazı geliştiriciler RISC-V'nin hariç tutulabileceğini dile getirdi
    • Gelecekteki builder'ların rack'e takılabilen ve uzaktan yönetilebilen sunucu tipi sistemler olması gerekiyor; SBC tabanlı ve elle yeniden başlatma gerektiren ortamlar uygun değil
    • Bu koşullar karşılanamazsa Fedora'nın resmî 64 bit RISC-V mimarisi olarak kabul edilmesi mümkün değil

  • QEMU ile yerel test

    • Derleme süreleri uzun olduğu için QEMU emülasyonu ile yerel test kullanışlı oluyor
    • 80 çekirdekli bir AArch64 masaüstünde, QEMU kullanıcı alanı riscv64 emülasyonu ile llvm15 paketi yaklaşık 4 saatte derlenebiliyor
    • Aynı paket Banana Pi BPI-F3 builder'ında derlendiğinde 10,5 saat sürüyor
    • LLVM paketi hem çekirdeği hem belleği yoğun kullandığından, Ampere One tabanlı 192/384 çekirdekli sistemlerde performans artışı bekleniyor
    • QEMU yalnızca yerel derleme ve test için kullanılıyor; Fedora ise yalnızca native derleme yapıyor

  • Gelecek planları

    • Fedora Linux 44 derlemelerine başlanması planlanıyor
    • Hedef, tüm builder'larda aynı çekirdek imajını kullanmak; şu anda çekirdek sürümleri karışık durumda
    • LTO'nun kapalı tutulmasına devam edilecek
    • Hız sorununu çözmek için yeni ve daha hızlı builder'ların devreye alınması planlanıyor; ağır paketlerin bir kısmı bu builder'lara atanacak

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-24
Hacker News görüşleri

  • Sorunun ISA'nın kendisinden ziyade silikon uygulaması ve mimariye özgü optimizasyonlardan yoksun yazılım olduğunu düşünüyorum
    RISC-V de sonuçta gelişecektir
    ARM de başlangıçta hız odaklıydı, sonra güç verimliliğine yönelip gömülü pazarda başarı kazandı ve bugün yeniden hız odaklı bir çizgiye dönmüş görünüyor

    • Bazı durumlarda sorunun RISC-V ISA spesifikasyonunun kendisi olduğunu düşünüyorum
      Örneğin LLVM issue #150263, #141488 gibi örnekler var
      Ayrıca 4KiB sayfa boyutunun sabit olması da ARM'e kıyasla performansı sınırlayabiliyor
    • “RISC-V de bir gün yetişir” sözüne katılmak zor
      ARM hızlıydı, sonra yavaşladı, sonra tekrar hızlandı; ama RISC-V henüz yüksek performans alanında bir kez bile rekabet gücü gösteremedi
      Küçük ekiplerin yaptığı uygulamalar etkileyici ama mobil, masaüstü ve sunucu sınıfında hâlâ yetersiz
    • “Sorun ISA değil, uygulama” demek doğru ama fazla apaçık bir tespit
      Asıl kritik nokta önbellek yapısı, DDR·PCI arayüzleri gibi analog VLSI tasarımı, ama bunu gerçekten iyi yapan ekip neredeyse yok
      Üstelik herkes ‘yüksek performanslı RISC-V satıcısı’ olmak istiyor, ama ‘gömülü pazarla’ ilgilenmek isteyen yok
      ABD'de çip üretmekten çok yalnızca IP satma modeli baskın olduğu için, gerçek donanım bulmak gerektiğinde Çinli üreticilere bağımlı kalınıyor
    • CPU performans gelişiminin desenine bakınca, önce güç verimliliği optimize ediliyor, sonra hız yükseltiliyor; bu döngü tekrar ediyor
      Pentium 4'ün Netburst mimarisinin sınırlarına dayanması ve düşük güç çekirdeklerinden türeyen Core mimarisinin Intel'in ana hattı hâline gelmesi bunun tipik örneği
      ARM'in tarihi de benzer bir akış gösteriyor
    • LowSpecGamer videosunda, ARM'in ilk dönem çiplerinin yalnızca koruma diyotlarıyla bile çalıştığı anlatılıyor
      Steve Furber'a göre, güç bağlantısı unutulmasına rağmen kod çalışacak kadar verimliymiş

  • Bir iş arkadaşımın yazdığı blog yazısına dair bir düzeltme paylaşılıyor
    Fedora RISC-V derleme sisteminde Milk-V “Megrez” ile binutils derlemesi 67 dakikada tamamlandı; bu da önceki 143 dakikalık sonuca göre büyük bir iyileşme
    Şu anda en hızlı geliştirme kartı Banana Pi değil, SiFive “HiFive P550” ile UltraRISC “DP1000”
    FOSDEM sunumu “Fedora on RISC-V: state of the arch” da ilgili benchmark'lara değiniyor
    Marcin'in testi StarFive “VisionFive 2” üzerinde yapılmış; bu kart kararlı ama nispeten yavaş

    • VisionFive 2 güvenilir olsa da 3 yıldan daha eski bir kart, bu yüzden güncel derlemelerde bellek sınırlarına takılıyor
      gcc derlerken 4 ikiliyi aynı anda linklemek için en az 16GB gerekiyor ve kararlı çalışması için swap açmak gerekiyor
      VisionFive 2'de -j1 ya da -j2 ile derlemek gerektiğinden süre 2 ila 4 kat artıyor
      Daha iyi bir linker (ld yerine) kullanmak ya da LLVM derleme sistemindeki gibi eşzamanlı link sayısını ayrı belirlemek daha verimli olur

  • ARM'in bugünkü konumuna gelmesi 40 yıl sürdü, RISC-V ise henüz sadece 15 yıllık
    Bu yıl Tenstorrent'in RVA23 tabanlı sunucu platformunu piyasaya sürmesi bekleniyor; izlemeye değer
    Sonuçta belirleyici olan, donanım üreticilerinin yüksek performanslı silikon ortaya koyması

    • RISC-V, MIPS'ten çok etkilendi; MIPS de 90'ların başında büyük umut yaratmıştı ama sonunda pazarda geride kaldı
    • AArch64 sadece 15 yıllık olsa da, 32 bit ARM'den neredeyse tamamen farklı bir mimari

  • felix, Milk-V Pioneer ile Arch Linux RISC-V deposunu derliyor
    SOPHGO yaptırımları yüzünden geliştirmenin yavaşlamasının da bir etken olduğunu düşünüyorum
    SOPHGO'nun SG2380 tabanlı Milk-V Oasis'i iptal edildi, ama çok umut verici bir SoC idi
    Şirketin çipleri, ARM/RISC-V arasında geçiş yapabilen çift mimariyi destekliyordu
    Arch RISC-V deposu, ilgili haber

    • Hangi yaptırımın pratikte neyi nasıl etkilediğini somut olarak açıklayabilir misiniz, merak ediyorum

  • RISC-V yazılımının neden mutlaka RISC-V sisteminde derlenmesi gerektiğini merak ediyorum
    Derleyici hedef mimari bilgisini koda eklediğine göre, teoride başka bir sistemde de mümkün olması gerekmez mi?

    • Tüm dağıtımı cross-compile etmek istiyorsanız, o dağıtımın bunu desteklemesi gerekir
      Fedora şu anda yalnızca native build destekliyor; cross-compiler ise sadece firmware için bare-metal sürüm olarak mevcut
      Ayrıca test otomasyonu zor olduğu için, gerçek donanım üzerinde test edilen native build daha gerçekçi
      AArch64 de ilk zamanlarında yavaştı ama bugün Qt4 derlemesi 18 dakikada bitecek kadar ilerledi
    • Derleme betiklerinin ana işletim sisteminin kütüphanelerine ya da ayarlarına başvurmasından doğan çok sayıda bağımlılık sorunu var
      Bu sorunlar dile göre çözülebilir ama C/C++ ekosistemi özellikle karmaşık
      Bu yüzden çoğu kişi VM ya da gerçek hedef donanım üzerinde derleme yapıyor
    • Eski derleyicilerde backend derleme zamanında seçildiği için çoklu mimari desteği zordu
      LLVM'den sonra bu mümkün hâle geldi ama test için hâlâ emülatör gerekiyor
    • Cross build'in kendisi mümkün, ama derleme sonrası testler daha fazla kaynak gerektiriyor
    • Cross-compiler'ın kendisi kolay, ama on binlerce paketin derleme betiğini düzeltmek gerektiğinden bakım yükü çok büyük

  • “Neden doğrudan x86_64 sunucuda cross-compile yapmıyoruz?” diyenler de var

    • Ama cross-compile'ı kusursuz destekleyecek şekilde tüm yazılımı düzeltmek çok büyük bir iş

  • Bir yıl önce Mastodon'da “en hızlı RISC-V donanımı QEMU'dan daha yavaş” diye bir gönderi görmüştüm
    RISC-V çeşitli alanlara yayılıyor olsa da, yüksek performanslı hesaplama tarafında hâlâ zayıf

    • Milk-V Pioneer bu sınırı aştı ama pahalı ve kullandığı mimari de eski
      Üstelik geliştirici şirket ABD yaptırımları nedeniyle ortadan kayboldu

  • Cross-compile imkânsız değil, ama %install ve %check aşamalarında testlerin çalıştırılması sorun yaratıyor
    Örneğin rpy package PR içinde RISC-V üzerinde vektör testlerini devre dışı bırakmak gerekmişti
    Derleme ile testi ayırmak mümkün, ama karmaşıklığa kıyasla zaman kazancı büyük değil

    • Fedora geleneksel olarak native build yaklaşımını tercih ediyor
      2012 tarihli LWN başlığında da (bağlantı) cross-compile karşıtı tartışmalar vardı
    • En gerçekçi alternatif, QEMU kullanarak derleme yapmak

  • i686'nın x86_64'ten %14 daha hızlı çıktığı sonuç şüpheli görünüyor
    Normalde x86_64 daha hızlı olur; bunun nedeni daha fazla register ve vektör komutları
    Ama derleyici daha fazla optimizasyon denediği için derleme süresi uzayabilir
    RISC-V'de de benzer bir durum yaşanıyor olabilir

    • i686'nın daha hızlı olduğu durumlar bellek bant genişliği darboğazı ile açıklanabilir
    • x86_64 derlemelerinde i686'ya kıyasla %50 daha fazla linker testi var

  • Yazıda hangi RISC-V CPU'nun kullanıldığı belirtilmediği için karşılaştırma muğlak kalıyor

    • Gerçekte çoğu derleyici sistemi 4~8 çekirdek ve 8~32GB RAM yapılandırmasına sahip; seçenek de fazla değil
      Milk-V Pioneer 64 çekirdek ve 128GB RAM ile istisna, ama mimarisi eski ve fiyatı yüksek