RISC-V बहुत ही ज़्यादा धीमा है

 (marcin.juszkiewicz.com.pl)
3 पॉइंट द्वारा GN⁺ 2026-03-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Fedora Linux का RISC-V पोर्टिंग काम लगभग 3 महीनों से चल रहा है, और अधिकांश पैकेज Fedora 43 के लिए बिल्ड हो चुके हैं
  • मौजूदा RISC-V हार्डवेयर में बिल्ड स्पीड बहुत धीमी है, और वही पैकेज बिल्ड करने में x86_64 की तुलना में अधिकतम 5 गुना से भी ज़्यादा समय लग रहा है
  • Fedora की आधिकारिक आर्किटेक्चर के रूप में अपनाए जाने के लिए ऐसा सर्वर-ग्रेड हार्डवेयर चाहिए जो binutils को 1 घंटे के भीतर बिल्ड कर सके
  • बिल्ड में देरी से पैकेज मेंटेनरों में असंतोष पैदा हो रहा है, और RISC-V को बाहर रखने की संभावना का भी ज़िक्र है
  • आगे Fedora 44 बिल्ड और तेज़ बिल्डर लाने के ज़रिए स्पीड समस्या सुधारने, कर्नेल को एकरूप करने और LTO को निष्क्रिय बनाए रखने की योजना है

Fedora RISC-V पोर्टिंग की प्रगति

  • लगभग 3 महीने पहले से Fedora Linux के RISC-V पोर्ट का काम चल रहा है, और इस दौरान कई बदलाव हुए हैं
  • Fedora RISC-V ट्रैकर के अधिकांश आइटम सुलझाए जा चुके हैं और अभी सिर्फ 17 आइटम NEW स्थिति में बचे हैं
  • Fedora पैकेज सोर्स लाकर fedpkg mockbuild -r fedora-43-riscv64 कमांड से बिल्ड किया जा रहा है
  • अब तक 86 पैकेजों के लिए Pull Request भेजे गए हैं, जिनमें से अधिकांश मर्ज हो चुके हैं, और Fedora 43 के लिए बिल्ड पूरा हो गया है
  • ‘f43-updates’ टैग का अनुसरण करके अतिरिक्त बिल्ड किए जा सकते हैं

  • RISC-V बिल्ड स्पीड की समस्या

    • RISC-V हार्डवेयर अभी बहुत धीमी बिल्ड स्पीड दिखा रहा है
    • binutils 2.45.1-4.fc43 का बिल्ड समय riscv64 पर 143 मिनट, aarch64 पर 36 मिनट, और x86_64 पर 29 मिनट मापा गया
    • इस्तेमाल किया गया StarFive VisionFive 2 बोर्ड ड्राइवर सपोर्ट के मामले में अच्छा है, लेकिन स्पीड धीमी है
    • वही पैकेज Milk-V Megrez बोर्ड पर बिल्ड करने में 58 मिनट लगे
    • फिलहाल RISC-V बिल्ड में LTO (link-time optimization) निष्क्रिय है, ताकि मेमोरी उपयोग और बिल्ड समय कम किया जा सके
    • बिल्डर में 4~8 कोर, 8~32GB RAM है, और इसकी परफॉर्मेंस को Arm Cortex-A55 स्तर का माना गया है
    • आगे UltraRISC UR-DP1000 SoC (अधिकतम 64GB RAM) और SpacemiT K3 आधारित सिस्टम (अधिकतम 32GB RAM) से सुधार की उम्मीद है

  • Fedora की आधिकारिक आर्किटेक्चर में शामिल होने की शर्तें

    • Fedora की आधिकारिक आर्किटेक्चर में शामिल होने के लिए ऐसा हार्डवेयर चाहिए जो binutils पैकेज को 1 घंटे के भीतर बिल्ड कर सके
    • सिस्टम-व्यापी LTO सक्षम होने पर भी दूसरी आर्किटेक्चर के बराबर स्पीड हासिल करनी होगी
    • बिल्ड परिणाम तभी रिपॉज़िटरी में शामिल होते हैं जब सभी आर्किटेक्चर का काम पूरा हो, इसलिए धीमे बिल्डर पैकेज मेंटेनरों की नाराज़गी का कारण बनते हैं
    • पहले AArch64 बिल्डरों की स्पीड समस्या को लेकर भी शिकायतें थीं, और कुछ डेवलपर्स ने RISC-V को बाहर रखने की संभावना का ज़िक्र किया
    • आगे के बिल्डर rack-mounted और remote management वाले server-class सिस्टम होने चाहिए; SBC आधारित मैन्युअल रीबूट वाला माहौल उपयुक्त नहीं है
    • अगर ये शर्तें पूरी नहीं होतीं, तो Fedora में आधिकारिक 64-bit RISC-V आर्किटेक्चर के रूप में अपनाया जाना संभव नहीं होगा

  • QEMU से लोकल टेस्ट

    • लंबे बिल्ड समय के कारण QEMU emulation के ज़रिए local testing उपयोगी है
    • 80-कोर AArch64 desktop पर QEMU user-space riscv64 emulation के जरिए llvm15 पैकेज को लगभग 4 घंटे में बिल्ड किया जा सकता है
    • वही पैकेज Banana Pi BPI-F3 बिल्डर पर बिल्ड करने में 10.5 घंटे लगे
    • LLVM पैकेज कोर और मेमोरी दोनों का उपयोग करता है, इसलिए Ampere One आधारित 192/384-कोर सिस्टम पर बेहतर परफॉर्मेंस की उम्मीद है
    • QEMU का उपयोग केवल local build और testing के लिए किया जाता है, जबकि Fedora सिर्फ native build करता है

  • आगे की योजना

    • Fedora Linux 44 बिल्ड शुरू करने की योजना है
    • लक्ष्य यह है कि सभी बिल्डर एक ही kernel image का उपयोग करें, जबकि अभी kernel version मिले-जुले हैं
    • LTO को आगे भी निष्क्रिय ही रखा जाएगा
    • स्पीड समस्या हल करने के लिए नए और तेज़ बिल्डर लाने की योजना है, और कुछ भारी पैकेज उन बिल्डरों को सौंपे जाएंगे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-24
Hacker News की राय

  • मेरा मानना है कि दोष ISA को देने के बजाय silicon implementation और आर्किटेक्चर-विशिष्ट optimization की कमी वाले software में है
    RISC-V भी आखिरकार विकसित होगा
    ARM भी शुरुआत में speed-केंद्रित था, लेकिन बाद में power efficiency की ओर मुड़ा, embedded बाज़ार में सफल हुआ, और अब फिर से speed-केंद्रित दिशा में लौटता दिख रहा है

    • कुछ मामलों में RISC-V ISA spec खुद समस्या है
      उदाहरण के लिए LLVM issue #150263, #141488 जैसे मामले हैं
      साथ ही 4KiB page size तय होने की वजह से ARM की तुलना में performance सीमित होने की बात भी है
    • “RISC-V भी कभी न कभी बराबरी कर लेगा” इस बात से सहमत होना मुश्किल है
      ARM तेज़ था, फिर धीमा हुआ, और फिर दोबारा तेज़ हुआ, लेकिन RISC-V ने अभी तक high-performance segment में कभी प्रतिस्पर्धात्मक क्षमता नहीं दिखाई है
      छोटे टीमों की implementations प्रभावशाली हैं, लेकिन mobile·desktop·server स्तर पर अभी भी कमी है
    • “समस्या ISA नहीं, implementation है” यह बात सही है, लेकिन यह बहुत स्पष्ट बात भी है
      असल में cache संरचना, DDR·PCI interface जैसी analog VLSI design ही मुख्य हैं, और इसे ठीक से करने वाली टीमें लगभग नहीं हैं
      साथ ही हर कंपनी ‘high-performance RISC-V vendor’ बनना चाहती है, लेकिन ‘embedded market’ संभालना कोई नहीं चाहता
      अमेरिका में chips खुद बनाने के बजाय केवल IP बेचने की संरचना होने से, असली hardware पाने के लिए Chinese vendors पर निर्भर रहना पड़ता है
    • CPU performance के विकास का पैटर्न देखें तो पहले power efficiency optimize की जाती है, फिर speed बढ़ाई जाती है — यह चक्र बार-बार दोहराया गया है
      Pentium 4 की Netburst architecture की सीमा सामने आने के बाद, low-power core से निकली Core architecture का Intel की मुख्यधारा बन जाना इसका प्रतिनिधि उदाहरण है
      ARM का इतिहास भी कुछ ऐसा ही दिखता है
    • LowSpecGamer वीडियो में ARM के शुरुआती chips के बारे में एक किस्सा है कि वे सिर्फ protection diode से भी चल जाते थे
      Steve Furber के अनुसार, power जोड़ना भूल जाने पर भी code चल गया था — इतनी efficiency थी

  • एक सहकर्मी द्वारा लिखी गई blog post पर सुधार साझा किया गया
    Fedora RISC-V build system में Milk-V “Megrez” पर 67 मिनट में binutils build पूरा हुआ, जो पहले के 143 मिनट के रिकॉर्ड की तुलना में बड़ा सुधार है
    अभी सबसे तेज़ development board Banana Pi नहीं, बल्कि SiFive “HiFive P550” और UltraRISC “DP1000” हैं
    FOSDEM प्रस्तुति “Fedora on RISC-V: state of the arch” में भी संबंधित benchmarks शामिल हैं
    Marcin का test StarFive “VisionFive 2” पर किया गया था, जो board स्थिर तो है लेकिन काफ़ी धीमा है

    • VisionFive 2 भरोसेमंद है, लेकिन 3 साल से ज़्यादा पुराना board होने के कारण नवीनतम builds में memory की सीमा सामने आती है
      gcc build के दौरान 4 binaries को एक साथ link करने के लिए कम से कम 16GB चाहिए, और swap चालू करना पड़ता है ताकि स्थिरता बनी रहे
      VisionFive 2 पर -j1 या -j2 से build करना पड़ता है, इसलिए समय 2~4 गुना बढ़ जाता है
      बेहतर linker (ld replacement) का उपयोग करना, या LLVM build system की तरह parallel link count अलग से तय करना, अधिक प्रभावी होगा

  • ARM को आज की स्थिति तक पहुँचने में 40 साल लगे, और RISC-V को अभी केवल 15 साल हुए हैं
    कहा जा रहा है कि इस साल Tenstorrent RVA23-आधारित server platform जारी करेगा, इसलिए देखना दिलचस्प होगा
    आखिरकार मुख्य बात यह है कि hardware vendors high-performance silicon कब लाते हैं

    • RISC-V पर MIPS का काफ़ी प्रभाव रहा है, और MIPS को भी 90 के दशक की शुरुआत में बहुत उम्मीदों के साथ देखा गया था, लेकिन अंततः वह बाज़ार में पीछे रह गया
    • AArch64 सिर्फ 15 साल पुराना है, लेकिन 32-bit ARM की तुलना में यह लगभग पूरी तरह अलग architecture है

  • felix Milk-V Pioneer पर Arch Linux RISC-V repository build कर रहा है
    मेरा मानना है कि SOPHGO पर लगे sanctions की वजह से development धीमा हुआ
    SOPHGO के SG2380-आधारित Milk-V Oasis की release रद्द हो गई, लेकिन वह बहुत promising SoC था
    इस कंपनी के chips ARM/RISC-V के बीच switch की जा सकने वाली dual architecture को support करते थे
    Arch RISC-V repository, संबंधित लेख देखें

    • जानना चाहूँगा कि किस sanction का वास्तव में क्या असर पड़ा, इसे थोड़ा विस्तार से समझाया जा सकता है क्या

  • यह सवाल है कि RISC-V software को ज़रूरी तौर पर RISC-V system पर ही build क्यों करना चाहिए
    compiler तो target architecture की जानकारी code में डालता है, इसलिए सिद्धांततः किसी दूसरे system पर भी यह संभव होना चाहिए — ऐसा सवाल उठता है

    • पूरे distribution को cross-compile करने के लिए उस distribution को इसका समर्थन करना चाहिए
      Fedora अभी केवल native build को support करता है, और cross compiler सिर्फ firmware के लिए bare-metal version के रूप में उपलब्ध है
      साथ ही test automation कठिन होने के कारण, असली hardware पर test करने वाले native builds अधिक व्यावहारिक हैं
      AArch64 भी शुरुआती दिनों में धीमा था, लेकिन अब Qt4 build सिर्फ 18 मिनट में पूरा हो जाता है
    • build scripts में host OS की libraries या settings को refer करने वाली dependency problems बहुत होती हैं
      भाषाओं के अनुसार समाधान संभव हैं, लेकिन C/C++ ecosystem खास तौर पर जटिल है
      इसलिए ज़्यादातर लोग VM या असली target hardware पर build करते हैं
    • पुराने compilers compile समय पर backend चुनते थे, इसलिए multi-architecture support मुश्किल था
      LLVM के बाद यह संभव हुआ, लेकिन test के लिए अब भी emulator चाहिए
    • cross build खुद संभव है, लेकिन build के बाद testing के लिए अधिक resources चाहिए होते हैं
    • cross compiler बनाना अपने आप में आसान है, लेकिन दसियों हज़ार package build scripts को बदलना पड़ता है, इसलिए maintenance burden बहुत बड़ा है

  • कुछ लोगों की राय है, “सीधे x86_64 server पर cross-compile क्यों नहीं कर लेते?”

    • लेकिन cross-compilation को पूरी तरह support करने लायक सभी software को ठीक करना बहुत बड़ा काम है

  • एक साल पहले Mastodon पर एक पोस्ट देखी थी कि “सबसे तेज़ RISC-V hardware भी QEMU से धीमा है”
    RISC-V कई क्षेत्रों में फैल रहा है, लेकिन high-performance computing में अभी भी कमज़ोर है

    • Milk-V Pioneer ने उस सीमा को पार किया, लेकिन वह महँगा है और इस्तेमाल की गई architecture भी पुरानी है
      ऊपर से developer कंपनी अमेरिकी sanctions की वजह से गायब हो गई

  • cross-compilation असंभव नहीं है, लेकिन %install और %check चरणों में tests चलाना समस्या बनता है
    उदाहरण के लिए rpy package PR में RISC-V पर vector tests बंद करने पड़े थे
    build और test को अलग किया जा सकता है, लेकिन जटिलता के मुकाबले समय की बचत ज़्यादा नहीं है

    • Fedora परंपरागत रूप से native build को प्राथमिकता देता है
      2012 के LWN thread(लिंक) में भी cross-compilation के विरोध पर चर्चा हुई थी
    • QEMU का उपयोग करके build करना सबसे व्यावहारिक विकल्प है

  • i686 का x86_64 से 14% तेज़ होना संदिग्ध लगता है
    आम तौर पर x86_64 ज़्यादा तेज़ होता है, और इसकी वजह registers की बढ़ी हुई संख्या और vector instructions हैं
    हालाँकि compiler ज़्यादा optimization की कोशिश करता है, इसलिए build time लंबा हो सकता है
    RISC-V में भी ऐसा ही कुछ होने की संभावना है

    • i686 के तेज़ होने का मामला memory bandwidth bottleneck की वजह से हो सकता है
    • x86_64 build में i686 की तुलना में linker tests 50% ज़्यादा हैं

  • लेख में यह साफ़ नहीं बताया गया कि कौन-सा RISC-V CPU इस्तेमाल हुआ, इसलिए तुलना अस्पष्ट है

    • वास्तव में ज़्यादातर builders 4~8 cores और 8~32GB RAM वाले हैं, और विकल्प बहुत ज़्यादा नहीं हैं
      Milk-V Pioneer 64 cores·128GB RAM के साथ अपवाद है, लेकिन उसकी architecture पुरानी है और कीमत बहुत अधिक है