「RISC-V is sloooow」。2026年3月10日、Red Hatのシニアエンジニア、Marcin Juszkiewicz氏が自身のブログに投稿したこのタイトルは、RISC-Vアーキテクチャの現状を余すところなく体現している。誇張でも煽りでもなく、3ヶ月間にわたってFedoraのRISC-V向けパッケージビルドを担当してきたエンジニアが、実測データをもとに下した率直な評価だ。

時期を同じくして、Canonical（Ubuntuの開発元）は「2026年はRISC-Vのスケールの年になる」と高らかに宣言していた。この偶然が、RISC-Vを取り巻く状況の複雑さをそのまま映し出している。

AD

binutils 2.45.1が示した5倍の格差

Juszkiewicz氏が示したデータは、議論の余地がない。GNU Binutils 2.45.1（Fedora 43向けビルド）をコンパイルするのにかかった時間を、アーキテクチャ別に比較したものだ。

アーキテクチャコア数メモリビルド時間
x86_64829 GB29分
i686829 GB25分
aarch641246 GB36分
s390x345 GB37分
ppc64le1037 GB46分
riscv64816 GB143分

8コアのRISC-Vビルダーが143分を要した一方、同コア数のx86_64は29分で完了した。約5倍の差である。さらに深刻なのは、この143分という数値がLTO（Link-Time Optimization）を無効化した状態での結果だという点だ。LTOを有効にすれば、ビルド時間はこれを大きく上回る。Fedoraのパッケージビルドが現在もLTOを無効化して運用しているのは、メモリ消費とビルド時間を抑えるためのやむを得ない妥協の産物である。

注目すべきはRISC-Vの「独り負け」ぶりだ。2番目に遅いPOWER PPC64LEでさえ46分であり、RISC-Vとの差は97分に達する。実質的にRISC-Vだけが別格の遅さにある。

現行RISC-Vシリコンの実力：「Cortex-A55相当」という厳しい現実

なぜこれほどの差が生じるのか。Juszkiewicz氏は現在のFedora向けRISC-Vビルダーの性格を一言で表している。「コア性能はARM Cortex-A55と比較されるレベル」。Cortex-A55は現行Armチップの中でも最下位に位置する省電力コアであり、スマートフォンの補助コアや低コストIoTデバイス向けに設計されたものだ。

ビルダーの構成は4〜8コア、メモリは8〜32GBというもので、これはデスクトップPCとして見ても見劣りする。Fedoraが利用しているRISC-Vビルダーの中に、Banana Pi BPI-F3やSiFive HiFive Premier P550といったシングルボードコンピュータが含まれているのは、そうした機材しか現時点では存在しないからだ。

ここで特に興味深いのが、QEMUエミュレーションという逆説的な解決策の活用だ。Juszkiewicz氏は、80コアのエミュレートされたRISC-V環境でLLVMパッケージをビルドすると約4時間で完了すると報告している。対して、ネイティブのRISC-VハードウェアであるBanana Pi BPI-F3では10.5時間かかる。本物のRISC-Vシリコンよりも、x86_64上でRISC-Vをソフトウェアエミュレーションしたほうが速い——この事実は、現行シリコンの性能限界を最も端的に示している。

AD

「公式アーキテクチャ」への昇格に必要な三つの条件

Juszkiewicz氏がFedora 43のRISC-Vポートで3ヶ月間に送った86件のプルリクエストは、llvm15のような重量級パッケージからシンプルなゲームまで多岐にわたる。その大半がマージされ、実際に稼働しているという実績は一定の前進を示している。しかし氏の目標はより遠い先にある。

Fedora LinuxのRISC-V 64ビットアーキテクチャを「official primary architectures（公式・一次アーキテクチャ）」に昇格させるために必要な条件として、Juszkiewicz氏は三点を明示した。binutilsのビルドを1時間以内に完了できること、LTOを有効化した状態で運用できること、そしてラックマウント可能で管理容易なサーバーフォームファクタのハードウェアが存在すること。現在のRISC-Vはいずれの条件も満たしていない。

この基準は、実は非常に謙虚な設定でもある。「binutilsを1時間以内」という閾値は、現行x86_64の約2倍の時間を許容する数値だ。Fedoraが求めているのは同等性ではなく、最低限の実用性である。それでも143分という現実は、この基準から87分も超過している。

次世代ハードウェアへの期待と限界

短期的な改善策として、Juszkiewicz氏はいくつかの新ハードウェアに言及している。Milk-V TitanマザーボードのUltraRISC UR-DP1000 SoCは最大64GBのRAMを搭載可能で、SpacemiT K3ベースのシステムは32GBまで対応する。「状況は改善する」とJuszkiewicz氏は認めつつも、「最終的な解決策ではない」とも明言している。

改善の可能性は確かにある。SiFive P550は過去のRISC-Vハードウェアと比較して大幅な性能向上を示しており、Juszkiewicz氏自身もBPI-F3とP550の比較でP550の優位性に触れている。Fedora 44向けのビルドでは、こうした新ハードウェアを積極的に活用する計画があるという。ただしLTOの有効化は依然として視野に入っておらず、「重いパッケージを新ビルダーに割り当てる」という段階的な対応にとどまる見通しだ。

AD

CanonicalとFedora：同じ課題への異なるアプローチ

この速度問題が公開される少し前、Canonicalは「RISC-Vの大規模普及は2026年に始まる」という楽観的な展望を発表していた。Ubuntu 26.04 LTSは2026年4月のリリースが予定されており、RVA23プロファイルを最低動作基準とした最初の長期サポート版となる。

両社の姿勢の違いは興味深い。Fedoraはオープンソースコミュニティの「公式一次アーキテクチャ」という厳格な基準のもとでRISC-Vの昇格を検討しており、ビルドインフラが基準に達するまでは正式採用を保留する立場だ。対してCanonicalは、パートナー企業との協業を通じて「動作する」環境を整えることを優先し、性能の制約を抱えながらも商用LTSサポートという形でRISC-Vを取り込もうとしている。

この構図は、RISC-VのエコシステムにおけるディストリビューションのRISC-V戦略の多様性を示している。Fedoraは「準備ができてから採用する」という品質優先のアプローチを、Ubuntuは「採用しながら整備する」という市場優先のアプローチをそれぞれ体現している。どちらが正解かという話ではなく、両者が異なるニーズに応えているのだ。

Canonicalの発表には、Rivos（データセンター向けRISC-Vソリューション）、SiFiveとESWIN（EIC7700X SoCへのUbuntu対応）、Alibaba DAMO Academy（XuanTieプロセッサへの対応）との協業が含まれる。これらはいずれも、特定の用途に絞り込んだ最適化であり、汎用ビルドサーバーとしての性能とは別の文脈で評価すべき取り組みだ。

ARM普及の歴史が示す「10年の圧縮」

現在のRISC-Vが置かれている状況を歴史的に位置づけると、Armアーキテクチャが組み込みデバイスから汎用コンピューティングへと本格進出した2010年代初頭に似ている。当時のArmベースのLinuxサーバーも、x86_64に比べれば性能面で明確な劣位にあり、ビルドインフラの整備に時間を要した。

その後、Raspberry Piの爆発的普及でエコシステムが拡張され、最終的にApple M1がアーキテクチャの性能限界を塗り替えた。ARMがその旅路に要したのは約10年だった。RISC-VはARMの前例を学びながら、より短い時間でその軌跡を追おうとしている。

Juszkiewicz氏が「143分」というデータで示したのは、RISC-Vが今まさにその「Raspberry Pi期」にあるということだ。ビルドインフラが追いつかない段階は、新アーキテクチャの普及において避けられない通過点でもある。問題は速度が遅いことそのものではなく、改善の速度が市場の期待に追いつくかどうかにある。

地政学がRISC-Vを押し上げるもう一つの力

性能面の制約とは別に、RISC-Vへの注目を高めている外部要因も見逃せない。x86はIntelとAMDという米国企業が、ArmはSoftBankグループ傘下の英国企業が握っている。地政学的リスクを回避したい中国や、半導体主権を模索する国々にとって、オープンかつフリーなRISC-Vは政治的に中立なアーキテクチャとして機能する。

実際、Canonicalが2025年に締結した協業先の多くは中国系企業（Alibaba DAMO Academy、SpacemiT、Milk-V）や中国市場を主要ターゲットとするベンダーだ。RISC-Vの採用が地政学的な動機と市場原理の両方から同時に押し上げられているという構造は、x86やArmにはなかった特殊な条件だ。

性能改善とエコシステム構築が進めば、この地政学的追い風はRISC-Vを想定以上の速度で普及させる可能性がある。ユシュキェヴィチ氏のデータが示す「今」の限界と、その外側で動く力学の両方を見ておく必要がある。

「sloooow」な今を超えるために

Juszkiewicz氏のブログタイトルにある「o」の四つ重ねは、単なる誇張表現ではない。実測データに基づいた、現場エンジニアによる正直な自己評価だ。同時に同氏は、より高速なビルダーの導入計画を持ち、Fedora 44のビルド開始に向けて前進している。現状への批判と次への準備が同居しているのが、オープンソースエコシステムにおける開発の実態でもある。

RISC-Vが「公式・一次アーキテクチャ」の地位を獲得するには、binutilsを1時間以内でビルドできるハードウェアと、ラックマウント可能なサーバーの登場が最低限必要だ。それが実現する時期を現時点で断言できる者はいないが、方向性は明確だ。問題は、その到達点がいつ来るかではなく、来るまでの間にどれだけのエコシステムが形成されているかにある。

Sources