ハクソク

世界を動かす技術を、日本語で。

RISC-Vは遅いです

50日前原文(marcin.juszkiewicz.com.pl)

概要

  • 約3か月前からFedora LinuxのRISC-Vポートの作業を開始
  • バグトリアージやパッケージビルドに積極的に取り組み
  • RISC-Vハードウェアの遅さが大きな課題
  • QEMUによるエミュレーション活用でビルド効率化を模索
  • 今後は新しいビルダー導入とFedora 44への移行を計画

Fedora Linux RISC-Vポート作業報告

  • 約3か月前よりFedora LinuxのRISC-Vポートに従事
  • Fedora RISC-Vトラッカーのバグエントリーを確認・トリアージ
    • 現在、NEW状態のエントリーは17件
    • 可能な範囲で個別に対応
  • Fedoraパッケージ管理
    • fedpkg clone -aコマンドでパッケージソース取得
    • fedpkg mockbuild -r fedora-43-riscv64でビルド実行
    • ビルド結果を確認し、失敗時はログから原因調査
    • 86件のプルリクエストをFedoraパッケージに送信
      • 大型パッケージ（例: llvm15）から小型ゲーム（例: iyfct）まで幅広く対応
      • 大部分がマージ済み、Fedora 43向けにビルド完了
      • ‘f43-updates’タグをFedora kojiで追跡し、ビルド状況確認

RISC-Vハードウェアの課題と現状

  • RISC-Vハードウェアの処理速度が遅いことが最大の課題
    • ビルド時間が他アーキテクチャと比較して著しく長い
    • 例: binutils 2.45.1-4.fc43パッケージのビルド時間
      • aarch64: 36分（12コア/46GB）
      • i686: 25分（8コア/29GB）
      • ppc64le: 46分（10コア/37GB）
      • riscv64: 143分（8コア/16GB）
      • s390x: 37分（3コア/45GB）
      • x86_64: 29分（8コア/29GB）
  • 現在のRISC-VビルドはLTO（Link Time Optimization）無効化
    • メモリ消費とビルド時間短縮のため
  • RISC-Vビルダーは4～8コア、8～32GB RAM
    • コア性能はArm Cortex-A55相当
  • 新型SoC（UltraRISC UR-DP1000やSpacemiT K3）への期待
    • UR-DP1000搭載のMilk-V Titanは64GB RAM対応
    • K3ベースシステムも最大32GB RAM
    • これらは改善にはなるが、根本解決には至らず
  • 理想は1時間以内でbinutilsをLTO有効でビルド可能なハードウェア
    • ラック搭載やサーバー管理が容易な機器が必要
    • 現状ではFedoraの公式プライマリアーキテクチャ昇格は困難

QEMUによるビルド効率化

  • QEMUエミュレーションを活用し、ビルド時間短縮を図る
    • 80コアをエミュレートし、llvm15パッケージを約4時間でビルド
    • 実機（Banana Pi BPI-F3ビルダー）では10.5時間かかる
    • Ampere Oneベースの192/384コアシステムでは更なる高速化を期待
  • LLVMパッケージはコア・メモリ両方をフル活用
    • btopツールで80コア稼働状況を可視化

今後の計画と展望

  • Fedora Linux 44のビルド開始を予定
    • すべてのビルダーで同一カーネルイメージ使用を目指す
    • LTOは引き続き無効化
  • 新規・高速ビルダーの導入計画
    • 重量級パッケージは新ビルダーに割り当て予定
  • RISC-Vエコシステム強化と公式アーキテクチャ昇格への課題解決

Hackerたちの意見

ISAを責めるんじゃなくて、シリコンの実装とアーキテクチャ特有の最適化がされてないソフトウェアを責めるべきだよ。RISC-Vもそのうち追いつくさ。ARMも最初はパワー消費に気を使ったスピードモンスターだったけど、デスクトップではx86やPPCに抜かれて、埋め込み市場に移ってからはパワーを節約することで輝いてた。でも今は、パワーよりスピード最優先の実装で埋め込み市場から出て行こうとしてる。
└
記事をちゃんと読めば、アーキテクチャを責めてるんじゃなくて、利用可能なシリコンの実装を責めてるってわかるよ。
└
ずっと前から気づいてるパターンなんだけど、高性能CPUへの道は、まずパワーを最適化して、その後スピードを最適化して、またその繰り返しって感じだよね。パワーと熱がスピードを制限する大きな設計制約だから。最初に気づいたのは、Pentium 4の「Netburst」アーキテクチャと、Coreアーキテクチャの祖先となる小さいx86コアの違いだった。IntelはP4で壁にぶつかって、そこから低消費電力のコアを派生させて、10年以上もIntelを支配するCoreアーキテクチャが生まれた。ARMの歴史もまた一例だね。
└
マルチンがFedoraとRHELのRISC-V対応でうちと一緒に作業してるんだけど、現在の実装の問題にはよく気づいてるよ。年末までにはほぼ解決することを期待してる。
└
> アーキテクチャ特有の最適化がないソフトウェア ARMやMIPSに適用される最適化は、RISC-Vにも同じように適用できると思う。これはソフトウェアの最適化が足りない問題ではないと思うよ。手書きのアセンブリが大きなメリットを持っていた時代はもう過ぎたし、gccやllvmのような現代のコンパイラは、命令の出力に関してはほぼ同じ作業をしているからね（SIMD命令をどこに配置できるかを決定することを含めて）。もしこれらのチップがすごく変なパフォーマンス特性を持っているなら（x86のlea命令が算術に使われるような変なこと）、見逃されるヒューリスティックはあまりないだろうね。
└
> RISC-Vは最終的にはそこにたどり着くよ。 これは冗談じゃなくて、どうしてこれが真実だと考えられているのか全然わからない。これは達成されるまで真実にならないことの一つだよ。そうじゃなければ、超高性能なSparcやSuperHプロセッサを作れるはずだけど、実際にはそうなってない。君が言うように、Armもかつては速かったけど、遅くなり、また速くなった。RISC-Vは実際には速くなったことがない。少数の人たちによって驚くほど良い実装が可能になったけど、高性能な分野（モバイル、デスクトップ、サーバー）で競争するのは難しいね。
└
RISC-VのISA仕様が問題だと思うこともあるよ：1) https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 もう一つの例は、ARMと比較してISAを実質的に制限するハードコーディングされた4 KiBのページサイズだね。
└
LowSpecGamerのARMに関する動画では、チップに電源を接続するのを忘れたのに、コードを実行していたって話をしてる。スティーブ・ファーバーによると、チップは保護ダイオードからだけ電源が供給されていたらしい。だから、ARMは最初から信じられないほど電力効率が良かったんだ。
└
> ISAを責めるな - シリコン実装を責めろ それは本当だけど、当たり前のことだね。問題は、RISC-Vコアが問題の簡単な部分で、誰もそれを正しく生成できるチップを作れないみたいだってこと。もっと根本的な技術的問題は、キャッシュの構成やDDRインターフェース、PCIインターフェースなどが単に合成できるものではないってこと。アナログ/RF VLSIデザイナーがクロックのフォワーディングや信号の整合性分析を行う必要がある。これを間違えるとパフォーマンスが落ちるし、今のところ、みんながいろんな方法で間違えている。ビジネスの問題は、みんなが「パフォーマンス」RISC-Vベンダーになりたがるけど、「組み込み」RISC-Vベンダーになりたがらないってこと。これは、実際に「パフォーマンス」プロセッサにお金を出す人は、ARMが要求するコストプレミアムにはほとんど無関心だから、問題なんだ。組み込み分野はコストに非常に敏感だけど、そこに踏み込む人はいない。なぜなら、マーケティングやソフトウェア、デバッグツール、在庫配分などの面倒なエコシステムのことをしなきゃいけないから。これが、アメリカのビジネスの問題につながっていて、みんながIPベンダーになりたがるけど、誰もチップを出荷したがらない。だから、実際のRISC-Vハードウェアが欲しいなら、いろんなレベルの怪しさを持つ中国のベンダーとやり取りしなきゃいけないんだ。
└
RISC-Vは、実装が比較的簡単で本当に役立つ命令がいくつか欠けていて、ほとんどの拡張は本当にオプショナルだから、頼ることができないんだ。これが、学者たちがISAをペーパーミルに変えてしまうと問題になる。理論的には、欠陥のあるISAをパフォーマンスさせるために多くの努力を費やすことができるけど、それは簡単でも美しくもない。例えば、実際のLinuxディストリビューションは、デュアルイシューの順次RV64GCから、すべての機能を備えた8ワイドのアウトオブオーダーRV64まで、すべてのuarchに対して最適化されたパッケージを配布できない。深く埋め込まれたシステムでしか、ツールチェーンを再ターゲットして、出会うすべてのアーキテクチャのサブセットに最適化することはできないんだ。
└
ARMは決して「スピードデーモン」じゃなかった。最初は低消費電力で小型のコアとしてスタートして、MIPSやRISC-Vよりも明らかに複雑で考えられてたよ。もう10年以上前の話だけどね。RISC-Vもいつかはそこにたどり着くと思うけど、ちょっと疑問だな。90年代にいた人たちは、MIPSの盛り上がりを覚えてるかもね。
クロスコンパイルは無理なの？
└
セットアップがめちゃくちゃ面倒なんだよね。QEMUが一番の選択肢かも。
└
問題は、.specファイルの`%install`と`%check`のステージを実行することだと思う。Pythonライブラリのrpy（マルチンのPRからのランダムな例）では、rpyのpytestテストスイートを実行する必要があって、RISC-Vでベクターテストを実行しないように修正しなきゃいけなかった。ビルドとテストを分けるのは解決可能な問題だけど、時間の節約が複雑さに見合うかは疑問だね。 https://src.fedoraproject.org/rpms/rpy/pull-request/4#reques...
└
確か、Fedoraはビルドにネイティブコンパイルを好むみたい。君の質問でFedoraにおけるArmの歴史を調べてみたら、2012年のLWNスレッドが出てきたよ。あの頃からクロスコンパイルに反対する議論があったんだね。[1] https://lwn.net/Articles/487622/
それか、クロスコンパイルを直して、普通のx86_64サーバーでコンパイルすればいいんじゃない？
だからフェリックスはMilk-V Pioneerを使ってrisc-v archlinuxリポジトリを構築してるんだよ。SOPHGOの禁止が開発の遅れに一因だと思う。彼らは最もパフォーマンスが高くて面白いSOCを持ってたから。Milk-V Oasisの予約もたくさんしてたけど、キャンセルされちゃった。SG2380を使う予定だったんだけど、記事に出てるMilk-V Titanよりもずっとパフォーマンスが良いって言われてた（まだ出てないけど）。それに、SOPHGOのSOCが超安価でパフォーマンスが高くて多用途なMilk-V DUOボードを支えてたんだよね。ARM/RISC-Vアーキテクチャを切り替えることもできるし。
└
この禁止が何かに影響を与えたと思う理由と、その禁止が何に適用されると思うかを説明できる？
Armは今の地位に至るまで40年かかってる。RISC-Vは15歳だよ。もう少し辛抱が必要かもね。彼らが約束を守るなら、今年の後半にTenstorrentがRVA23ベースのサーバー開発プラットフォームを出荷する予定なんだって。[1] 彼らは去年のNA RISC-V Summitでそれを発表したよ。[2] どうなるか見てみよう。ハードウェアベンダーが高性能なシリコンを作る番だね。[1] https://tenstorrent.com/ip/risc-v-cpu [2] https://static.sched.com/hosted_files/riscvsummit2025/e2/Unl...
└
RISC-VがモデルにしているMIPSも、だいたい40年前のもので、90年代初頭にはかなり盛り上がってたよね。
彼らのチャートを正しく読んでるなら、RISC-Vマシンのメモリは他のどれと比べても半分しかないってこと？ メモリがボトルネックになってるかどうかはよくわからないけど、その数字を見て遅いって主張するのはちょっと変だよね。それについて何も言わないのも不思議だし。彼らがその不一致の原因を排除したことを願うけど、確認なしでは判断が難しいね。
あのページには遅いRISC-V CPUがどれか書いてあるの？ 見当たらなかったから、ちょっと無駄な愚痴に思える。
1年くらい前にMastodonで、手に入る中で最速のRISC-VハードウェアがQEMUで動かすよりも遅いって気づいた人がいたんだよね。普通はそうならないはずなのに :\ RISC-Vは確かにニッチな分野で広がってるけど、パフォーマンスの高いコンピューティングはその一つじゃない。編集: 笑、著者も同じことを言ってるね！もしかしたら、僕が考えてる元のMastodonの投稿の出所かもしれない。
RISC-VソフトウェアをRISC-Vシステムでビルドしなきゃいけない理由って簡単に説明できる？ なぜコンパイラが別のアーキテクチャ用にコンパイルするのがそんなに難しいの？ ターゲットアーキテクチャの一般的な構造はコンパイラコードの中にあって、現在のシステムを調べても生成されないんだよね？
└
指定されたビルド依存関係は、ターゲットシステムではなくホストOSのライブラリや設定を使うんだ。言語ごとに解決できるけど、C/C++エコシステムはごちゃごちゃしてるから、みんな考えなくて済むようにVMやターゲットアーキテクチャの実機を使ってる。
└
クロスビルドは可能だけど、ビルドしたソフトウェアをテストできるのはかなり便利だよね… しかも、テストにはビルドよりも多くのリソースがかかることが多いし。
それってRISC-Vなの？それとも層が重なった抽象化で膨れ上がったソフトウェアなの？
└
この…人…は、これらの概念を区別できてないんじゃないかな。