RISC-V chậm đến mức quá chậm

 (marcin.juszkiewicz.com.pl)
3 điểm bởi GN⁺ 29 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Công việc port Fedora Linux sang RISC-V đã được tiến hành khoảng 3 tháng, và phần lớn các gói đã được build xong cho Fedora 43
  • Hiện tại phần cứng RISC-V cho thấy tốc độ build rất chậm, với cùng một gói có thể mất thời gian lâu hơn x86_64 tới hơn 5 lần
  • Để được chấp nhận là kiến trúc chính thức của Fedora, cần có phần cứng cấp máy chủ có thể build binutils trong vòng 1 giờ
  • Việc build chậm gây ra sự bất mãn từ các maintainer gói, và khả năng RISC-V bị loại trừ cũng đã được nhắc đến
  • Trong tương lai, dự án có kế hoạch cải thiện vấn đề tốc độ thông qua các bản build Fedora 44 và việc đưa vào các builder nhanh hơn, đồng thời duy trì kernel thống nhất và tiếp tục tắt LTO

Tình hình port Fedora sang RISC-V

  • Công việc port Fedora Linux sang RISC-V đã được tiến hành từ khoảng 3 tháng trước và đã có nhiều thay đổi
  • Phần lớn các mục trong tracker Fedora RISC-V đã được xử lý, hiện chỉ còn 17 mục ở trạng thái NEW
  • Lấy source gói Fedora và thực hiện build bằng lệnh fedpkg mockbuild -r fedora-43-riscv64
  • Tính đến nay đã có 86 Pull Request cho các gói được gửi lên, phần lớn đã được merge và build xong cho Fedora 43
  • Có thể tiếp tục các bản build bổ sung theo tag ‘f43-updates’

  • Vấn đề tốc độ build trên RISC-V

    • Phần cứng RISC-V hiện cho thấy tốc độ build rất chậm
    • Thời gian build binutils 2.45.1-4.fc43 được đo là riscv64 143 phút, aarch64 36 phút, x86_64 29 phút
    • Bo mạch StarFive VisionFive 2 được sử dụng có hỗ trợ driver khá tốt nhưng tốc độ chậm
    • Khi build cùng gói trên bo mạch Milk-V Megrez thì mất 58 phút
    • Hiện tại các bản build RISC-V đang ở trạng thái tắt LTO (link-time optimization) để giảm mức dùng bộ nhớ và thời gian build
    • Các builder có 4~8 lõi, 8~32GB RAM, với hiệu năng được đánh giá ở mức Arm Cortex-A55
    • Trong tương lai, UltraRISC UR-DP1000 SoC (tối đa 64GB RAM) và các hệ thống dựa trên SpacemiT K3 (tối đa 32GB RAM) được kỳ vọng sẽ cải thiện tình hình

  • Điều kiện để được đưa vào kiến trúc chính thức của Fedora

    • Để được đưa vào kiến trúc chính thức của Fedora, cần có phần cứng có thể build gói binutils trong vòng 1 giờ
    • Cũng cần đạt tốc độ tương đương các kiến trúc khác ngay cả khi LTO được bật trên toàn hệ thống
    • Kết quả build chỉ được phản ánh vào repository khi tất cả kiến trúc đều hoàn tất, nên builder chậm sẽ gây ra sự bất mãn từ các maintainer gói
    • Trước đây đã từng có phàn nàn về vấn đề tốc độ của builder AArch64, và một số nhà phát triển đã nhắc đến khả năng loại RISC-V
    • Trong tương lai, builder phải là hệ thống máy chủ có thể gắn rack và quản lý từ xa; môi trường phải reboot thủ công dựa trên SBC là không phù hợp
    • Nếu không đáp ứng được các điều kiện này thì Fedora sẽ không thể chấp nhận RISC-V 64-bit làm kiến trúc chính thức

  • Kiểm thử cục bộ bằng QEMU

    • Do thời gian build dài nên kiểm thử cục bộ thông qua giả lập QEMU rất hữu ích
    • Trên desktop AArch64 80 lõi, có thể build gói llvm15 trong khoảng 4 giờ bằng giả lập không gian người dùng riscv64 của QEMU
    • Cùng gói đó khi build trên builder Banana Pi BPI-F3 thì mất 10,5 giờ
    • Gói LLVM tận dụng cả lõi CPU lẫn bộ nhớ, nên người ta kỳ vọng hiệu năng sẽ tăng trên các hệ thống Ampere One 192/384 lõi
    • QEMU chỉ được dùng cho build và kiểm thử cục bộ, còn Fedora chỉ thực hiện native build

  • Kế hoạch sắp tới

    • Dự kiến sẽ bắt đầu build Fedora Linux 44
    • Mục tiêu là sử dụng cùng một image kernel trên mọi builder, trong khi hiện tại phiên bản kernel vẫn còn lẫn lộn
    • LTO sẽ tiếp tục được giữ ở trạng thái tắt
    • Để giải quyết vấn đề tốc độ, dự án có kế hoạch đưa vào các builder mới nhanh hơn, và phân bổ một số gói nặng sang các builder đó

Bài viết liên quan

1 bình luận

 
GN⁺ 29 ngày trước
Ý kiến trên Hacker News

  • Tôi cho rằng thay vì đổ lỗi cho bản thân ISA, vấn đề nằm ở triển khai silicon và phần mềm thiếu tối ưu hóa theo từng kiến trúc
    RISC-V rồi cuối cùng cũng sẽ phát triển
    ARM lúc đầu cũng đi theo hướng tốc độ, sau đó chuyển sang hiệu quả điện năng để thành công ở thị trường nhúng, và giờ lại cho thấy xu hướng quay về tập trung vào tốc độ

    • Trong một số trường hợp, tôi cho rằng vấn đề nằm ở chính đặc tả ISA của RISC-V
      Ví dụ như LLVM issue #150263, #141488
      Ngoài ra, kích thước trang 4KiB bị cố định cũng là điểm khiến hiệu năng bị hạn chế so với ARM
    • Tôi khó đồng ý với nhận định rằng “RISC-V rồi cũng sẽ bắt kịp”
      ARM đã từng nhanh, rồi chậm lại, rồi nhanh trở lại, còn RISC-V thì đến nay vẫn chưa từng chứng minh được năng lực cạnh tranh trong phân khúc hiệu năng cao
      Những bản triển khai do các nhóm nhỏ tạo ra thì ấn tượng thật, nhưng ở cấp độ mobile, desktop và server vẫn còn thiếu nhiều
    • Câu “vấn đề không phải ISA mà là triển khai” là đúng, nhưng cũng quá hiển nhiên
      Trên thực tế, cốt lõi nằm ở thiết kế VLSI analog như cấu trúc cache, giao tiếp DDR và PCI, mà gần như không có mấy đội làm tốt phần này
      Ngoài ra, công ty nào cũng muốn trở thành ‘vendor RISC-V hiệu năng cao’, nhưng chẳng mấy ai muốn đảm nhận ‘thị trường nhúng’
      Ở Mỹ, mô hình chủ yếu là chỉ bán IP thay vì tự sản xuất chip, nên nếu muốn có phần cứng thực tế thì cuối cùng vẫn phải phụ thuộc vào các vendor Trung Quốc
    • Nhìn vào quy luật phát triển hiệu năng CPU, ta thấy một chu kỳ lặp lại: trước hết tối ưu hiệu quả điện năng, rồi mới đẩy tốc độ lên
      Trường hợp điển hình là kiến trúc Netburst của Pentium 4 chạm trần, rồi kiến trúc Core phát triển từ lõi tiêu thụ điện thấp trở thành dòng chủ lực của Intel
      Lịch sử của ARM cũng cho thấy một dòng chảy tương tự
    • Trong video của LowSpecGamer có một giai thoại rằng các chip ARM đời đầu chạy được chỉ với diode bảo vệ
      Theo Steve Furber, có lần họ quên nối nguồn mà mã vẫn chạy được, đủ cho thấy mức hiệu quả của nó

  • Chia sẻ một đính chính cho bài blog do đồng nghiệp tôi viết
    Trên hệ thống build Fedora RISC-V, việc build binutils bằng Milk-V “Megrez” đã hoàn tất trong 67 phút, cải thiện lớn so với mốc 143 phút trước đó
    Hiện nay board phát triển nhanh nhất không phải Banana Pi mà là SiFive “HiFive P550” và UltraRISC “DP1000”
    Bài trình bày FOSDEM “Fedora on RISC-V: state of the arch” cũng đề cập các benchmark liên quan
    Bài test của Marcin được thực hiện trên StarFive “VisionFive 2”, một bo mạch ổn định nhưng khá chậm

    • VisionFive 2 đáng tin cậy, nhưng là bo mạch đã hơn 3 năm tuổi nên có giới hạn bộ nhớ với các bản build mới
      Khi build gcc, để liên kết 4 binary cùng lúc thì cần ít nhất 16GB trở lên, và phải bật swap để chạy ổn định
      Trên VisionFive 2 phải build với -j1 hoặc -j2, nên thời gian tăng lên gấp 2 đến 4 lần
      Dùng linker tốt hơn (thay cho ld) hoặc cho phép chỉ định riêng số lượng liên kết song song như hệ thống build của LLVM sẽ hiệu quả hơn

  • ARM đã mất 40 năm để đến được vị trí hiện tại, còn RISC-V mới chỉ có 15 năm
    Nghe nói năm nay Tenstorrent sẽ ra mắt nền tảng server dựa trên RVA23, nên cũng đáng theo dõi
    Cuối cùng thì mấu chốt vẫn là việc các vendor phần cứng có tung ra silicon hiệu năng cao hay không

    • RISC-V chịu ảnh hưởng nhiều từ MIPS, mà MIPS đầu thập niên 90 cũng từng được kỳ vọng lớn nhưng cuối cùng bị thị trường bỏ lại
    • AArch64 mới chỉ có 15 năm, nhưng gần như là một kiến trúc hoàn toàn khác so với ARM 32-bit

  • felix đang build repository Arch Linux RISC-V bằng Milk-V Pioneer
    Tôi cũng nghĩ việc SOPHGO bị trừng phạt đã làm chậm quá trình phát triển
    Milk-V Oasis dùng SG2380 của SOPHGO đã bị hủy phát hành, nhưng đó từng là một SoC rất hứa hẹn
    Chip của công ty này hỗ trợ kiến trúc kép có thể chuyển đổi giữa ARM/RISC-V
    Có thể tham khảo repository Arch RISC-V, bài viết liên quan

    • Tôi muốn biết cụ thể các lệnh trừng phạt đó đã thực sự gây ảnh hưởng như thế nào

  • Tôi thắc mắc vì sao phần mềm RISC-V nhất thiết phải build trên hệ thống RISC-V
    Compiler vốn nhúng thông tin kiến trúc đích vào mã, nên về lý thuyết chẳng phải có thể làm trên hệ thống khác sao?

    • Muốn cross-compile toàn bộ một bản phân phối thì bản phân phối đó phải hỗ trợ điều này
      Fedora hiện chỉ hỗ trợ native build, còn cross-compiler chỉ có bản bare-metal dùng cho firmware
      Ngoài ra, vì khó tự động hóa kiểm thử nên native build trên phần cứng thật thực tế hơn
      AArch64 thời kỳ đầu cũng chậm, nhưng giờ đã tiến bộ đến mức build Qt4 chỉ mất 18 phút
    • Có rất nhiều vấn đề phụ thuộc khi script build tham chiếu tới thư viện hoặc cấu hình của OS máy host
      Có thể xử lý tùy theo từng ngôn ngữ, nhưng hệ sinh thái C/C++ đặc biệt phức tạp
      Vì vậy phần lớn mọi người build trong VM hoặc trên phần cứng đích thực tế
    • Compiler đời cũ thường chọn backend tại thời điểm biên dịch, nên khó hỗ trợ đa kiến trúc
      Từ LLVM trở đi thì có thể, nhưng để test vẫn cần emulator
    • Bản thân cross-build là khả thi, nhưng việc kiểm thử sau build lại đòi hỏi nhiều tài nguyên hơn
    • Bản thân cross-compiler thì dễ, nhưng phải sửa script build của hàng chục nghìn package nên gánh nặng bảo trì rất lớn

  • Cũng có ý kiến rằng “cứ cross-compile trên server x86_64 là được mà?”

    • Nhưng việc sửa toàn bộ phần mềm để hỗ trợ cross-compile hoàn hảo là một khối lượng công việc khổng lồ

  • Một năm trước tôi thấy bài đăng trên Mastodon nói rằng “phần cứng RISC-V nhanh nhất còn chậm hơn QEMU”
    Dù RISC-V đang lan rộng sang nhiều lĩnh vực, nó vẫn yếu ở tính toán hiệu năng cao

    • Milk-V Pioneer đã vượt qua giới hạn đó, nhưng giá cao và kiến trúc được dùng cũng đã cũ
      Hơn nữa, công ty phát triển nó đã biến mất vì lệnh trừng phạt của Mỹ

  • Cross-compile không phải là bất khả thi, nhưng việc chạy test ở các bước %install và %check là vấn đề
    Ví dụ trong PR package rpy đã phải tắt vector test trên RISC-V
    Có thể tách build và test ra, nhưng mức tiết kiệm thời gian không lớn so với độ phức tạp tăng thêm

    • Fedora theo truyền thống vẫn ưu tiên native build
      Ngay trong thread LWN năm 2012 (liên kết) cũng đã có tranh luận phản đối cross-compile
    • Build bằng QEMU là phương án thay thế thực tế nhất

  • Kết quả cho thấy i686 nhanh hơn x86_64 14% là điều đáng nghi
    Thông thường x86_64 phải nhanh hơn, nhờ số lượng thanh ghi nhiều hơn và lệnh vector
    Tuy vậy compiler cũng có thể thử nhiều tối ưu hóa hơn, khiến thời gian build kéo dài hơn
    RISC-V cũng có thể gặp hiện tượng tương tự

    • Trường hợp i686 nhanh hơn có thể là do nút thắt băng thông bộ nhớ
    • Bản build x86_64 có nhiều hơn 50% linker test so với i686

  • Bài viết không nêu rõ đã dùng CPU RISC-V nào nên việc so sánh khá mơ hồ

    • Trên thực tế, phần lớn builder là cấu hình 4~8 lõi với 8~32GB RAM, và không có nhiều lựa chọn
      Milk-V Pioneer là ngoại lệ với 64 lõi và 128GB RAM, nhưng kiến trúc đã cũ và giá lại cao