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（リンク時最適化）**が無効化された状態で、メモリ使用量とビルド時間を削減するための措置となっている
    • ビルダーは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除外の可能性に言及していた
    • 今後のビルダーはラック搭載およびリモート管理が可能なサーバー型システムである必要があり、SBCベースで手動再起動が必要な環境は不適切
    • これらの条件を満たせなければ、Fedoraの公式64ビットRISC-Vアーキテクチャ採用は不可能

  • QEMUを使ったローカルテスト

    • ビルド時間が長いため、QEMUエミュレーションによるローカルテストが有用
    • 80コアのAArch64デスクトップでQEMUユーザー空間のriscv64エミュレーションを使うと、llvm15パッケージを約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も当初は速度重視だったが、その後は電力効率へ舵を切って組み込み市場で成功し、今は再び速度重視に戻ってきた流れがある

    • 場合によっては、RISC-VのISA仕様そのものが問題だと見る
      例えば LLVM issue #150263、#141488 のような事例がある
      また、4KiBページサイズが固定されているため、ARM比で性能が制約される面もある
    • 「RISC-Vもいつか追いつく」という話には同意しにくい
      ARMは速かった時期も遅かった時期もあり、そこからまた速くなったが、RISC-Vはまだ一度も高性能領域で競争力を示したことがない
      小規模チームが作った実装は印象的だが、モバイル・デスクトップ・サーバークラスでは依然として不足している
    • 「ISAではなく実装の問題」というのは正しいが、あまりに自明な話でもある
      実際にはキャッシュ構造やDDR・PCIインターフェースのようなアナログVLSI設計が核心だが、これをきちんとやれるチームがほとんどない
      また、どの企業も「高性能RISC-Vベンダー」にはなりたがる一方で、「組み込み市場」を担おうとするところはない
      米国ではチップを自社生産するよりIPだけを売る構造なので、実際のハードウェアを入手しようとすると中国ベンダーに依存せざるを得ないのが現実だ
    • CPU性能向上のパターンを見ると、まず電力効率を最適化し、その後で速度を上げるという循環が繰り返されている
      Pentium 4のNetburstアーキテクチャが限界に突き当たり、低消費電力コアから派生したCoreアーキテクチャがIntelの主力になった事例が代表的だ
      ARMの歴史も似た流れをたどっている
    • LowSpecGamerの動画では、ARM初期のチップが保護ダイオードだけでも動作したという逸話が紹介されている
      Steve Furberによれば、電源接続を忘れたのにコードが実行されたほど効率的だったという

  • 同僚が書いたブログ記事に対する訂正を共有する
    Fedora RISC-Vビルドシステムでは、Milk-V “Megrez”で67分でbinutilsのビルドを完了しており、これは従来の143分記録から大幅な改善だ
    現在最速の開発ボードはBanana Piではなく、SiFive “HiFive P550”とUltraRISC “DP1000”である
    FOSDEM発表 “Fedora on RISC-V: state of the arch” でも関連ベンチマークを扱っている
    MarcinのテストはStarFive “VisionFive 2”で行われたが、このボードは安定している一方で速度は遅めだ

    • VisionFive 2は信頼性は高いが、3年以上前のボードなので最新ビルドではメモリの限界がある
      gccビルド時に4つのバイナリを同時リンクするには最低16GB以上が必要で、swapを有効にしないと安定しない
      VisionFive 2では -j1 または -j2 でビルドする必要があるため、時間が2〜4倍に延びる
      より良い**リンカー（ld代替）**を使うか、LLVMビルドシステムのように並列リンク数を別指定できるようにするほうが効率的だ

  • ARMが今の位置に来るまで40年かかり、RISC-Vはまだ15年しか経っていない
    今年はTenstorrentがRVA23ベースのサーバープラットフォームを投入予定とのことで、注目に値する
    結局のところ、ハードウェアベンダーが高性能シリコンを出してくるかどうかが鍵だ

    • RISC-VはMIPSから多くの影響を受けており、MIPSも90年代初頭には大きな期待を集めたが、最終的には市場で押し負けた
    • AArch64はまだ15年しか経っていないが、32ビットARMとはほぼ完全に別のアーキテクチャである

  • felixがMilk-V PioneerでArch Linux RISC-Vリポジトリをビルド中である
    SOPHGOへの制裁で開発が遅れたことも原因だと思う
    SOPHGOのSG2380ベースMilk-V Oasisは発売中止になったが、非常に有望なSoCだった
    この会社のチップはARM/RISC-Vを切り替え可能なデュアルアーキテクチャをサポートしていた
    Arch RISC-Vリポジトリ、関連記事 を参照

    • どの制裁が実際にどんな影響を与えたのか、具体的に説明できる人がいるとありがたい

  • なぜRISC-Vソフトウェアを必ずRISC-Vシステム上でビルドしなければならないのか疑問だ
    コンパイラは対象アーキテクチャ情報をコードに埋め込むのだから、理論上は別のシステムでも可能ではないかという疑問である

    • ディストリビューション全体をクロスコンパイルするには、そのディストリビューション側がそれをサポートしている必要がある
      Fedoraは現在ネイティブビルドのみをサポートしており、クロスコンパイラはファームウェア向けのbare-metal版しかない
      また、テスト自動化が難しいため、実機ハードウェアでテストできるネイティブビルドのほうが現実的だ
      AArch64も初期は遅かったが、今ではQt4ビルドが18分で終わるほど進歩した
    • ビルドスクリプトがホストOSのライブラリや設定を参照してしまう依存関係の問題が多い
      言語ごとに解決策はあるが、C/C++エコシステムは特に複雑だ
      そのため、多くはVMや実際のターゲットハードウェア上でビルドしている
    • 昔のコンパイラはバックエンドをコンパイル時に選択していたため、マルチアーキテクチャ対応が難しかった
      LLVM以降は可能になったが、テストには依然としてエミュレータが必要だ
    • クロスビルド自体は可能だが、ビルド後のテストのほうがより多くのリソースを要求する
    • クロスコンパイラ自体は簡単でも、数万個のパッケージのビルドスクリプトを修正しなければならないため、保守負担が大きい

  • 「単にx86_64サーバーでクロスコンパイルすればいいのでは？」という意見もある

    • しかし、すべてのソフトウェアをクロスコンパイル完全対応に修正するのは非常に大きな作業だ

  • 1年前にMastodonで「最速のRISC-VハードウェアがQEMUより遅い」という投稿を見た
    RISC-Vはさまざまな分野へ広がりつつあるが、高性能コンピューティングでは依然として弱い

    • Milk-V Pioneerはその限界を超えたが、高価で使われているアーキテクチャも古い
      しかも開発元は米国の制裁で消滅した

  • クロスコンパイルが不可能なわけではないが、%install と %check 段階でのテスト実行が問題になる
    例えば rpyパッケージPR では、RISC-Vでベクタテストを無効にする必要があった
    ビルドとテストを分離することはできるが、複雑さのわりに時間短縮効果は大きくない

    • Fedoraは伝統的にネイティブビルドを好む
      2012年のLWNスレッド（リンク）でもすでにクロスコンパイル反対の議論があった
    • QEMUを使ったビルドが最も現実的な代替策である

  • i686がx86_64より14%速いという結果は疑わしい
    通常はx86_64のほうが速く、これはレジスタ数の増加とベクタ命令のおかげだ
    ただし、コンパイラがより多くの最適化を試みるため、ビルド時間が長くなる可能性はある
    RISC-Vでも似た現象が起きている可能性がある

    • i686のほうが速い場合は、メモリ帯域幅のボトルネックが原因かもしれない
    • x86_64ビルドはi686よりリンカーテストが50%多い

  • 記事でどのRISC-V CPUを使ったのか明記されておらず、比較が曖昧だ

    • 実際には4〜8コア、8〜32GB RAM構成のビルダーが大半で、選択肢も多くない
      Milk-V Pioneerは64コア・128GB RAMで例外的だが、古いアーキテクチャで価格も高い