RISC-V ช้าเกินไปจริง ๆ

 (marcin.juszkiewicz.com.pl)
3 คะแนน โดย GN⁺ 2026-03-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • งาน พอร์ต RISC-V ของ Fedora Linux ดำเนินมาได้ราว 3 เดือนแล้ว และแพ็กเกจส่วนใหญ่คอมไพล์สำหรับ Fedora 43 เสร็จเรียบร้อย
  • ขณะนี้ฮาร์ดแวร์ RISC-V มี ความเร็วในการคอมไพล์ที่ช้ามาก โดยการคอมไพล์แพ็กเกจเดียวกันใช้เวลามากกว่า x86_64 ได้สูงสุดเกิน 5 เท่า
  • หากต้องการถูกรับเข้าเป็นสถาปัตยกรรมทางการของ Fedora จำเป็นต้องมี ฮาร์ดแวร์ระดับเซิร์ฟเวอร์ที่คอมไพล์ binutils ได้ภายใน 1 ชั่วโมง
  • ความล่าช้าในการคอมไพล์ทำให้เกิด ความไม่พอใจจากผู้ดูแลแพ็กเกจ และมีการพูดถึงความเป็นไปได้ที่ RISC-V อาจถูกตัดออก
  • ในอนาคตมีแผนจะ เริ่มคอมไพล์ Fedora 44 และนำบิลเดอร์ที่เร็วขึ้นมาใช้ เพื่อแก้ปัญหาความเร็ว พร้อมทั้งตั้งเป้ารวมเคอร์เนลให้เป็นชุดเดียวกันและคงการปิด LTO เอาไว้

ความคืบหน้าของการพอร์ต Fedora ไปยัง RISC-V

  • ตั้งแต่ราว 3 เดือนก่อน ได้มีการดำเนิน งานพอร์ต RISC-V ของ Fedora Linux และมีการเปลี่ยนแปลงหลายอย่างเกิดขึ้น
  • รายการส่วนใหญ่ใน Fedora RISC-V tracker ถูกจัดการแล้ว และตอนนี้เหลือเพียง 17 รายการที่ยังเป็นสถานะ NEW
  • ดึงซอร์สแพ็กเกจของ Fedora มาแล้วคอมไพล์ด้วยคำสั่ง fedpkg mockbuild -r fedora-43-riscv64
  • จนถึงตอนนี้มีการส่ง Pull Request สำหรับ 86 แพ็กเกจ โดยส่วนใหญ่ถูกรวมแล้ว และคอมไพล์สำหรับ 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 คอร์, RAM 8~32GB และประเมินประสิทธิภาพได้ในระดับ Arm Cortex-A55
    • ในอนาคตคาดหวังการปรับปรุงจาก UltraRISC UR-DP1000 SoC (RAM สูงสุด 64GB) และ ระบบที่ใช้ SpacemiT K3 (RAM สูงสุด 32GB)

  • เงื่อนไขการรับเข้าเป็นสถาปัตยกรรมทางการของ Fedora

    • หากต้องการถูกรวมเป็นสถาปัตยกรรมทางการของ Fedora จำเป็นต้องมี ฮาร์ดแวร์ที่คอมไพล์แพ็กเกจ binutils ได้ภายใน 1 ชั่วโมง
    • ต้องรักษาความเร็วให้เทียบเท่าสถาปัตยกรรมอื่นได้ แม้ในสถานะที่เปิด LTO ทั้งระบบ
    • ผลการคอมไพล์จะถูกสะท้อนเข้ารีโพซิทอรีก็ต่อเมื่อทุกสถาปัตยกรรมคอมไพล์เสร็จแล้ว ดังนั้นบิลเดอร์ที่ช้าจึงทำให้เกิด ความไม่พอใจจากผู้ดูแลแพ็กเกจ
    • ในอดีตเคยมีความไม่พอใจจากปัญหาความเร็วของบิลเดอร์ AArch64 และนักพัฒนาบางส่วนก็พูดถึง ความเป็นไปได้ที่จะตัด RISC-V ออก
    • บิลเดอร์ในอนาคตจะต้องเป็น ระบบเซิร์ฟเวอร์ที่ติดตั้งในแร็กและบริหารจัดการจากระยะไกลได้ โดยสภาพแวดล้อมแบบรีบูตด้วยมือบน SBC นั้นไม่เหมาะสม
    • หากไม่สามารถตอบโจทย์เงื่อนไขเหล่านี้ได้ ก็จะ ไม่สามารถรับ Fedora RISC-V 64 บิตเป็นสถาปัตยกรรมทางการได้

  • การทดสอบภายในเครื่องด้วย QEMU

    • เนื่องจากเวลาคอมไพล์นาน การทดสอบภายในเครื่องผ่านการจำลองด้วย QEMU จึงมีประโยชน์
    • บน เดสก์ท็อป AArch64 80 คอร์ สามารถคอมไพล์แพ็กเกจ llvm15 ผ่าน QEMU user-space riscv64 emulation ได้ในเวลาประมาณ 4 ชั่วโมง
    • แต่หากคอมไพล์แพ็กเกจเดียวกันบน บิลเดอร์ Banana Pi BPI-F3 จะใช้เวลา 10.5 ชั่วโมง
    • แพ็กเกจ LLVM ใช้ทั้งคอร์และหน่วยความจำอย่างเต็มที่ จึงคาดว่าจะได้ประสิทธิภาพดีขึ้นบน ระบบที่ใช้ Ampere One 192/384 คอร์
    • QEMU ใช้สำหรับคอมไพล์และทดสอบในเครื่องเท่านั้น ส่วน Fedora จะ คอมไพล์แบบเนทีฟเท่านั้น

  • แผนต่อไป

    • มีแผนจะ เริ่มคอมไพล์ Fedora Linux 44
    • ตั้งเป้าให้บิลเดอร์ทุกตัวใช้เคอร์เนลอิมเมจเดียวกัน โดยปัจจุบันยังมีหลายเวอร์ชันปะปนกันอยู่
    • จะยังคงปิด LTO ต่อไป
    • เพื่อแก้ปัญหาความเร็ว มีแผนจะ นำบิลเดอร์รุ่นใหม่ที่เร็วกว่าเข้ามาใช้ และ มอบหมายแพ็กเกจขนาดใหญ่บางส่วนให้กับบิลเดอร์เหล่านั้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-24
ความเห็นจาก Hacker News

  • คิดว่าปัญหาไม่ใช่ตัว ISA เองเท่าไร แต่เป็นเรื่องของการนำไปทำเป็นซิลิคอนและซอฟต์แวร์ที่ยังไม่มีการปรับแต่งตามสถาปัตยกรรม
    สุดท้ายแล้ว RISC-V ก็น่าจะพัฒนาขึ้น
    ARM เองช่วงแรกก็เน้นความเร็ว แต่ภายหลังก็เปลี่ยนทิศไปเน้นประสิทธิภาพพลังงานจนประสบความสำเร็จในตลาด embedded และตอนนี้ก็ดูเหมือนกำลังกลับมาเน้นความเร็วอีกครั้ง

    • ในบางกรณีก็มองว่าสเปก ISA ของ RISC-V เองก็เป็นปัญหา
      ตัวอย่างเช่น LLVM issue #150263, #141488
      อีกทั้งยังมีข้อจำกัดเรื่องขนาดหน้า 4KiB ที่ถูกกำหนดตายตัว ทำให้ประสิทธิภาพสู้ ARM ไม่ได้ในบางด้าน
    • เห็นด้วยได้ยากกับคำพูดที่ว่า “เดี๋ยว RISC-V ก็ไล่ทันเอง”
      ARM เคยเร็ว แล้วช้าลง ก่อนจะกลับมาเร็วอีกครั้ง แต่ RISC-V ยังไม่เคยแสดงให้เห็นเลยว่าแข่งขันได้ในกลุ่มสมรรถนะสูง
      งานออกแบบจากทีมเล็ก ๆ น่าประทับใจ แต่ในระดับมือถือ เดสก์ท็อป และเซิร์ฟเวอร์ก็ยังไม่พอ
    • คำพูดที่ว่า “ไม่ใช่ปัญหาของ ISA แต่เป็นปัญหาการนำไปใช้จริง” ก็ถูก แต่ก็เป็นเรื่องที่ชัดเจนอยู่แล้ว
      ในความเป็นจริงสิ่งสำคัญคือการออกแบบ analog VLSI อย่างโครงสร้างแคช อินเทอร์เฟซ DDR และ PCI ซึ่งแทบไม่มีทีมไหนทำได้ดีจริง
      อีกทั้งทุกบริษัทต่างก็อยากเป็น ‘vendor RISC-V สมรรถนะสูง’ แต่ไม่มีใครอยากดูแล ‘ตลาด embedded’
      ในสหรัฐฯ โมเดลธุรกิจเป็นแบบขายIP อย่างเดียวมากกว่าจะผลิตชิปเอง ทำให้ถ้าจะหาฮาร์ดแวร์จริงก็ต้องพึ่ง vendor จีน
    • ถ้าดูรูปแบบการพัฒนาสมรรถนะ CPU จะเห็นว่าวงจรเดิมเกิดซ้ำคือ เริ่มจากปรับ ประสิทธิภาพพลังงาน ก่อน แล้วค่อยดันความเร็วขึ้น
      ตัวอย่างชัดเจนคือสถาปัตยกรรม Netburst ของ Pentium 4 ที่ไปต่อไม่ไหว และ Core architecture ที่แตกแขนงมาจากคอร์ประหยัดพลังงานกลับกลายเป็นเสาหลักของ Intel
      ประวัติของ ARM ก็มีแนวโน้มคล้ายกัน
    • ในวิดีโอของ LowSpecGamer มีเกร็ดว่าชิป ARM ยุคแรก ๆ ทำงานได้ด้วยแค่ไดโอดป้องกัน
      ตามคำบอกของ Steve Furber เคยลืมต่อไฟเลี้ยงแต่โค้ดยังรันได้ แสดงถึงประสิทธิภาพที่สูงมาก

  • แชร์คำแก้ไขเกี่ยวกับโพสต์บล็อกที่เพื่อนร่วมงานเขียน
    บนระบบ build ของ Fedora RISC-V สามารถ build binutils บน Milk-V “Megrez” ได้เสร็จภายใน 67 นาที ซึ่งดีขึ้นมากจากสถิติก่อนหน้าที่ 143 นาที
    ตอนนี้บอร์ดพัฒนาที่เร็วที่สุดไม่ใช่ Banana Pi แต่เป็น SiFive “HiFive P550” และ UltraRISC “DP1000”
    ในสไลด์ FOSDEM “Fedora on RISC-V: state of the arch” ก็มี benchmark ที่เกี่ยวข้องด้วย
    การทดสอบของ Marcin ทำบน StarFive “VisionFive 2” ซึ่งบอร์ดนี้เสถียรแต่ค่อนข้างช้า

    • VisionFive 2 เชื่อถือได้ก็จริง แต่เป็นบอร์ดที่อายุเกิน 3 ปีแล้ว จึงเริ่มติดข้อจำกัดด้านหน่วยความจำสำหรับงาน build รุ่นใหม่
      ถ้าจะลิงก์ไบนารี 4 ตัวพร้อมกันตอน build gcc ต้องมีอย่างน้อย 16GB ขึ้นไป และต้องเปิด swap เพื่อให้ทำงานเสถียร
      บน VisionFive 2 จึงต้อง build ด้วย -j1 หรือ -j2 ทำให้ใช้เวลานานขึ้น 2-4 เท่า
      ถ้าใช้linker ที่ดีกว่า (ตัวแทน ld) หรือกำหนดจำนวนงานลิงก์ขนานแยกแบบระบบ build ของ LLVM จะมีประสิทธิภาพกว่า

  • ARM กว่าจะมาถึงจุดนี้ใช้เวลา40 ปี ขณะที่ RISC-V มีอายุแค่15 ปี
    ปีนี้ Tenstorrent มีแผนจะออก server platform ที่ใช้ RVA23 จึงน่าจับตา
    สุดท้ายประเด็นสำคัญก็คือเหล่าvendor ฮาร์ดแวร์จะออกซิลิคอนสมรรถนะสูงมาได้หรือไม่

    • RISC-V ได้อิทธิพลจาก MIPS มาก และ MIPS เองก็เคยถูกคาดหวังสูงมากในช่วงต้นยุค 90 แต่สุดท้ายก็แพ้ในตลาด
    • AArch64 มีอายุแค่ 15 ปีเหมือนกัน แต่แทบจะเป็นสถาปัตยกรรมคนละตัวกับ ARM แบบ 32 บิต

  • felix กำลัง build คลังแพ็กเกจ Arch Linux RISC-V บน Milk-V Pioneer
    คิดว่าการพัฒนาที่ช้าลงก็มีสาเหตุจากมาตรการคว่ำบาตร SOPHGO ด้วย
    Milk-V Oasis ที่ใช้ SG2380 ของ SOPHGO ถูกยกเลิกการวางจำหน่าย แต่เดิมเป็น SoC ที่มีอนาคตมาก
    ชิปของบริษัทนี้รองรับสถาปัตยกรรมคู่ที่สลับ ARM/RISC-V ได้
    ดูได้ที่ Arch RISC-V repo, บทความที่เกี่ยวข้อง

    • อยากรู้ว่ามาตรการคว่ำบาตรไหนส่งผลอะไรจริงบ้าง ช่วยอธิบายแบบเจาะจงได้ไหม

  • สงสัยว่าทำไมต้อง build ซอฟต์แวร์ RISC-V บนระบบ RISC-V ด้วย
    เพราะตัวคอมไพเลอร์ก็ฝังข้อมูลสถาปัตยกรรมเป้าหมายลงในโค้ดอยู่แล้ว ตามทฤษฎีน่าจะทำบนระบบอื่นก็ได้ไม่ใช่หรือ

    • ถ้าจะ cross-compile ทั้งดิสทริบิวชัน ดิสทริบิวชันนั้นก็ต้องรองรับสิ่งนี้ด้วย
      ตอนนี้ Fedora รองรับเฉพาะ native build และ cross-compiler ที่มีอยู่ก็เป็นเวอร์ชัน bare-metal สำหรับเฟิร์มแวร์เท่านั้น
      อีกทั้งการทำระบบทดสอบอัตโนมัติก็ยาก จึงเป็นจริงมากกว่าที่จะทำ native build และทดสอบบนฮาร์ดแวร์จริง
      AArch64 เองช่วงแรกก็ช้า แต่ตอนนี้พัฒนาไปจน build Qt4 เสร็จได้ใน 18 นาทีแล้ว
    • มักมีปัญหาการพึ่งพาที่สคริปต์ build ไปอ้างอิงไลบรารีหรือการตั้งค่าของ host OS
      บางภาษาแก้ได้ แต่ใน ecosystem ของ C/C++ เรื่องนี้ซับซ้อนเป็นพิเศษ
      เพราะแบบนั้นคนส่วนใหญ่จึง build บน VM หรือฮาร์ดแวร์เป้าหมายจริง
    • คอมไพเลอร์รุ่นเก่าเลือก backend ตอนคอมไพล์ ทำให้รองรับหลายสถาปัตยกรรมได้ยาก
      หลังยุค LLVM จึงเริ่มทำได้ แต่ถ้าจะทดสอบก็ยังต้องใช้อีมูเลเตอร์อยู่ดี
    • ตัว cross build เองทำได้ แต่หลัง build เสร็จขั้นตอนทดสอบกลับกินทรัพยากรมากกว่า
    • ตัว cross-compiler สร้างไม่ยาก แต่ต้องไปแก้สคริปต์ build ของแพ็กเกจนับหมื่น จึงมีภาระการดูแลรักษาสูง

  • มีความเห็นว่า “ก็ cross-compile บนเซิร์ฟเวอร์ x86_64 ไปเลยไม่ได้หรือ?”

    • แต่การแก้ซอฟต์แวร์ทั้งหมดให้รองรับ cross-compilation อย่างสมบูรณ์เป็นงานใหญ่มาก

  • เมื่อปีที่แล้วเห็นโพสต์บน Mastodon ว่า “ฮาร์ดแวร์ RISC-V ที่เร็วที่สุดยังช้ากว่า QEMU”
    แม้ RISC-V จะกำลังกระจายไปหลายด้าน แต่ในงานhigh-performance computingก็ยังอ่อนอยู่มาก

    • Milk-V Pioneer ข้ามข้อจำกัดนั้นไปได้ แต่ราคาแพง และสถาปัตยกรรมที่ใช้ก็เก่าแล้ว
      แถมบริษัทผู้พัฒนายังหายไปเพราะมาตรการคว่ำบาตรของสหรัฐฯ

  • ไม่ใช่ว่า cross-compilation ทำไม่ได้ แต่ปัญหาอยู่ที่การรันทดสอบในขั้น %install และ %check
    ตัวอย่างเช่นใน rpy package PR ต้องปิดการทดสอบเวกเตอร์บน RISC-V
    จะแยกขั้น build กับ test ออกจากกันก็ได้ แต่เวลาที่ประหยัดได้ไม่คุ้มกับความซับซ้อนที่เพิ่มขึ้น

    • Fedora มีแนวทางดั้งเดิมที่ชอบnative build
      ในเธรดของ LWN ปี 2012 (ลิงก์) ก็มีการถกเถียงคัดค้าน cross-compilation กันแล้ว
    • การ build ผ่าน QEMU เป็นทางเลือกที่สมจริงที่สุด

  • ผลที่ว่า i686 เร็วกว่า x86_64 อยู่ 14% ฟังดูน่าสงสัย
    ปกติแล้ว x86_64 มักเร็วกว่า เพราะมีจำนวนรีจิสเตอร์มากขึ้นและมีคำสั่งเวกเตอร์
    แต่ก็เป็นไปได้ว่าคอมไพเลอร์พยายามทำ optimization มากขึ้นจนใช้เวลาสร้างนานกว่า
    ใน RISC-V เองก็อาจมีอาการคล้ายกัน

    • กรณีที่ i686 เร็วกว่าอาจเกิดจากคอขวดด้านแบนด์วิดท์หน่วยความจำ
    • build ของ x86_64 มีการทดสอบ linker มากกว่า i686 อยู่ 50%

  • ในบทความไม่ได้ระบุชัดว่าใช้ CPU RISC-V รุ่นไหน ทำให้การเปรียบเทียบค่อนข้างกำกวม

    • ในความเป็นจริง builder ส่วนใหญ่จะเป็นเครื่องระดับ 4-8 คอร์ แรม 8-32GB และตัวเลือกก็มีไม่มาก
      Milk-V Pioneer เป็นข้อยกเว้นด้วยสเปก 64 คอร์ RAM 128GB แต่ใช้สถาปัตยกรรมเก่าและมีราคาสูง