# Co-Design and System for the Supercomputer Fugaku > [!abstract] 概要 > スーパーコンピュータ「富岳」は、FLAGSHIP 2020 プロジェクトで日本の国家フラッグシップ・スーパーコンピュータとして開発された、エクサスケールのメニーコアベース並列システムである。 > 「富岳」は 2020 年に TOP500、HPCG、HPL-AI、Graph500 などの複数のベンチマークで 1 位になったが、主要な設計概念は、電力効率と高性能のための協調設計によるアプリケーション優先の概念である。 > 我々は産業パートナーである富士通とともに、スケーラブルベクトル拡張を備えた Armv8 命令セットに基づく独自のメニーコアプロセッサ A64FX を設計した。 > システムは 158,976 ノード、合計 760 万コアで構成され、倍精度浮動小数点数の理論ピーク性能は毎秒 537 ペタ浮動小数点演算であり、Tofu-D インターコネクトで接続される。 > 高性能計算(HPC)指向の設計により、画期的な電力効率を持つ HBM2 メモリのおかげで、メモリ集約型ワークロードに対して極めて良好な性能が得られる。 > 本稿では、「富岳」の協調設計の実践的な取り組みを述べ、続いて「富岳」の概要と性能を示す。 ## 論文情報 - タイトル: Co-Design and System for the Supercomputer "Fugaku" - 著者・所属: Mitsuhisa Sato、Yuetsu Kodama、Miwako Tsuji(理化学研究所 計算科学研究センター、神戸)、Tetsuya Odajima(富士通。原文の綴りは Tesuya。理研の連絡先メールでは Tetsuya) - 媒体: IEEE Micro(Theme Article: Cool Chips)、2022 年 3/4 月号、pp. 26-34。オンライン公開は 2021 年 12 月 21 日、誌面版は 2022 年 3 月 28 日 - DOI: 10.1109/MM.2021.3136882。Creative Commons Attribution 4.0 ライセンス - 資金: 文部科学省「次世代超高速計算機システムの開発・改良」(大規模研究施設の運営費補助) - 9 ページの解説論文であり、参考文献は 12 件。詳細な設計過程は SC20 の論文(文献 7)、Tofu-D は文献 8、電力制御の評価は文献 12 に譲る ## 概要 「富岳」は、電力予算 30〜40 MW の中で実アプリケーションの性能を最大にすることを目標に、アーキテクチャ・ソフトウェア・アプリケーションの各チームが富士通と協調して設計したメニーコア並列機である。本稿は、設計に使った道具(性能推定ツール・シミュレータ・解析モデル)、A64FX のパラメータ決定の理由、電力制御機構(パワーノブ)、システムの概要、ベンチマーク結果、A64FX 向けの性能チューニングを一通り述べる。 ## 問題設定 - 背景: エクサスケール計算の課題は、許容できる電力予算で動くシステムを作ることである。その主要な戦略として、協調設計(co-design)が HPC コミュニティで注目されてきた。協調設計は、科学アプリケーション、ソフトウェア、ハードウェアの各コミュニティが共同で将来の HPC システムを設計する方法論として提案されている - プロジェクト: FLAGSHIP 2020 は 2014〜2020 年に、[[K computer]] の後継となる国家フラッグシップ機の設計・構築(開発名 Post-K、のちに「富岳」)と、そこで動く幅広い HPC アプリケーションの開発を任務とした。政府の委員会が創薬、防災、気候変動から材料科学、基礎科学まで 9 つの重点課題を選び、アプリケーションプロジェクトが組織された - 設計目標(KPI): 1. 電力効率の高いシステム。施設の最大給電容量を 30〜40 MW とし、この範囲で性能を最大にする 2. 実アプリケーションの実効性能。一部のアプリケーションで K computer の 100 倍の高速化を狙う 3. 使い勝手。多様な利用者が共有するため、使いやすくする - 難しさ: 対象アプリケーションは数千行規模で複雑なアルゴリズムとデータ構造を持つ。サイクル精度のプロセッサシミュレータは精度が高い代わりに極めて遅く、単一プロセッサに限られてノード間の MPI 通信を含められない ## 提案手法 協調設計の道具、プロセッサ、電力、インターコネクトの順に述べる。 - **協調設計の道具**: 9 つの重点課題のそれぞれから対象アプリケーション群を提供してもらい、エネルギー・コスト・性能のトレードオフをアプリケーション特性を踏まえて決めた。次の 3 つのシミュレーション系に、単純な解析モデルを加えて使い分けた - 性能推定ツール: 富士通 FX100(前世代機)の実行プロファイルを入力に、与えたアーキテクチャパラメータでの性能を投影する。富士通のマイクロアーキテクチャに沿って作られ、電力も見積もれる。メモリ読み書き、L1/L2 キャッシュアクセス、浮動小数点演算、命令コミットなどの性能カウンタのビジー・サイクルを組み替えて、パイプラインの各機能ブロックを合算する単純な式で実行時間を出す。このため、ループのような挙動が一様な区間に適用できる。手順は、対象アプリケーションのカーネルを特定してライブラリ呼び出しを挿入し、プロファイルを取り、カーネルごとの推定時間を合計するというもので、アーキテクチャパラメータを変えて繰り返して設計空間を探索した - 富士通社内のプロセッサシミュレータ: 初期は FX100 の SPARC 命令セットシミュレータとコンパイラを拡張して使い、のちに Armv8 + SVE のシミュレータとコンパイラに切り替えた。性能推定ツールはアウトオブオーダー(O3)資源の影響を扱えないため、新命令や O3 資源の変更の効果はこちらで解析した。重要カーネルは独立プログラムとして切り出し、論理設計検証用のエミュレータにも使った - Gem5 ベースの Post-K プロセッサシミュレータ: 理研がアーキテクチャ検証と性能チューニングのために作った - 解析モデル: HPL・dgemm・STREAM のような単純なカーネルでは、ハードウェアパラメータだけの数式で実行時間を出せる。インターコネクトの設計では、対象アプリケーションから通信パターンを抜き出し、LogP モデルなどの解析モデルで通信性能を見積もった - **メニーコアプロセッサの設計**: 2012〜2013 年の事前調査(feasibility study)は、広い SIMD 演算器を持つ汎用メニーコアの大規模システムを基本構成として示した - 命令セット: 富士通が Armv8 と、そのベクトル拡張 SVE(Scalable Vector Extension)を提案した。Arm 命令セットはモバイルに加え HPC でも広く受け入れられてきた(ThunderX2 が Astra や Isambard などに使われている)。SVE の最大の特徴は、ベクトル長に依存しないプログラミングを可能にする点である。SIMD 演算器は事前調査の提案どおり 512 bit 幅を 2 本とした - 構造: コアのバックエンドは富士通のマイクロアーキテクチャによる。各コアが L1 キャッシュを持ち、コアの集まりが L2 キャッシュとメモリコントローラを共有する。この単位をコア・メモリ・グループ(CMG)と呼ぶ。Intel や AMD の L1・L2 をコア内に置き L3 を共有する構成と異なり、コア内は L1 のみとしてコアの面積を減らした - ダイとコスト: 7 nm FinFET を前提とした。チップのコストは面積に比例し、ある大きさを超えると急増して歩留まりも悪化する。小チップを MCM でつなぐチップレット方式は、基本設計時点では MCM のコストが高いと判断され、インターコネクトと I/O 用に別種のチップが要る点と、チップ間接続の電力増も理由となって採用しなかった。そこで CMG 複数個とインターコネクト用ネットワークインターフェースと PCIe を、オンチップネットワーク(NoC)でつないだ単一の大型ダイにした。結果として 48(+4)コア(12 コア × 4 CMG)、ダイ面積は約 400 mm2 に収まった - メモリ: CPU のピーク浮動小数点性能が数 TFLOPS に達すると見込まれ、DDR4 の帯域では釣り合わないため、HBM やハイブリッドメモリキューブを検討した。HBM2 は 1 モジュール 256 GB/s だが容量は最大 8 GiB で、シリコンインターポーザが要るためコストが高い。2019 年頃に使える技術として、電力効率と高帯域を理由に HBM2 を選び、コスト削減のため DDR は載せなかった。CMG に 1 モジュールずつ 4 個で 32 GiB になる。容量は小さいが、K computer 向けの多くのスケーラブルなアプリケーションはノード数を増やして問題サイズを増やせる、と述べる - キャッシュ: 多くのアプリケーションで高いヒット率を出し、メモリからフル帯域で供給されるときにボトルネックにならない構造を目指した。ライン長・ウェイ数・容量を、単一 CMG のシミュレータで抜き出したカーネルを走らせて評価した。連想キャッシュの電力を節約するため、タグ検索と並行してデータを読む方式をやめ、タグ一致後にデータへアクセスする。レイテンシは伸びるがスループット重視の HPC アプリケーションへの影響は小さく、これを L1(ベクトルアクセス用)と L2 に適用して HPL の電力を 10% 削減し、性能低下はほとんどなかった - O3 資源: 性能とダイ面積への影響のトレードオフを、抜き出したカーネルの評価で決めた **表 1(Table 1): 協調設計による最終的なアーキテクチャパラメータ** ![[_attachments/Co-Design-and-System-for-the-Supercomputer-Fugaku/table1-parameters.png]] (表 1. チップは 4 CMG・48(+4)コア・HBM2 32 GiB・メモリ帯域 1024 GB/s。CMG は 12(+1)コアと L2 8 MiB(16 ウェイ、L1 へのロード 128 GB/s、ストア 64 GB/s、ライン 256 バイト)。コアは SIMD 幅 512 bit・演算器 2 本、L1D 64 KiB(4 ウェイ、ロード 256 GB/s、ストア 128 GB/s)、リオーダバッファ 128 エントリ、リザベーションステーション 60 エントリ、物理 SIMD レジスタ 128、ロードバッファ 40、ストアバッファ 24。+ はアシスタントコア。キャッシュ帯域は CPU クロック 2 GHz での値。) - **低電力のための協調設計**: 基本方針は、性能を落とさずに無駄な電力を減らすことである。アプリケーション特性に応じてオン・オフする複数の電力制御機構「パワーノブ」を用意し、SIMD 幅、浮動小数点・整数パイプライン数、メモリ帯域をノブに選んだ - メモリ集約型アプリケーションでは演算器の利用率が低いので、演算パイプラインの制御が電力削減に効くと見込んだ。しかし STREAM で演算器を制御しても電力削減はわずかだった。電力変動に対して安定に動作するための機構が、演算器が遊んでいても一定の電力を消費するためである - そこで、片方の演算器だけを有効にし、もう片方は安定動作機構ごと停止する「エコモード」を定義した - 逆に、電力が多少増えても最大性能を追求したい要求に対し、電源電圧を上げて通常モードより高い最大周波数にする「ブーストモード」を用意した - これらの電力モードとノブは Sandia の Power API で制御できる - **ノード間インターコネクト**: K computer との大規模アプリケーションでの性能互換性を理由に、6 次元トーラスの Tofu トポロジを選んだ。対象アプリケーションから通信パターンを抜き出し、解析モデルで通信性能を見積もった - リンクには、技術の入手性と成熟度から 28 Gb/s の SerDes を選んだ。ポート速度は 2 リンクで 6.8 GB/s だが、チップ内のメモリとネットワークをつなぐ DMA エンジンである TNI(Tofu Network Interface)が 6 個あるため、ノード当たりの注入帯域は 40.8 GB/s になる(6.8 GB/s × 6 = 40.8 GB/s の算術と一致する) - 多くの対象アプリケーションは隣接通信か近傍ノードとの通信であるため、注入帯域 40.8 GB/s の Tofu で十分と結論した。新版は「TofuD」と呼ぶ ## 新規性 - 単一のアルゴリズムや部品ではなく、協調設計の実践過程そのものが貢献である。実アプリケーションのカーネルを起点に、粗い性能推定ツール、O3 資源を見られる社内シミュレータ、アーキテクチャ検証用の Gem5 を段階的に使い分け、パラメータを決めた過程が具体的に報告されている - 汎用のメニーコア(Armv8 + SVE)で HPC 向けに、L3 なし・DDR なし・単一ダイ・HBM2 のみという割り切りを取り、同時に電力ノブを設計段階から入れた。コスト(ダイ面積、MCM 費用、HBM2 の容量と価格)と電力の制約を、アプリケーション特性で裏づけて決めている ## 実験設定 - 基本性能: 1 つの A64FX チップでの STREAM triad と dgemm カーネル、Tofu-D の put 通信(1 MB) - 科学ワークロード: UK Mini-Apps の CloverLeaf(2 次元正規格子上のオイラー方程式のステンシルコードで、メモリ帯域律速に分類される)を、A64FX(2.0 GHz、1 ソケット)と Xeon Gold 6126(Skylake、2.6 GHz、12 コア/ソケット、2 ソケット)、Cavium ThunderX2(2.0 GHz、28 コア/ソケット)で比較する。1 MPI プロセス・最大 12 OpenMP スレッドを、A64FX では CMG ごと、他機ではソケットごとに割り当てた。強スケーリングは Fugaku で最大 2,048 ノード(1 次元と 2 次元の分割、フラット MPI)まで測る - オープンソース HPC アプリケーション: A64FX(2.2 GHz、1 ソケット)と 2 ソケットの Xeon Platinum 8268(Cascade Lake、2.90 GHz、24 コア/ソケット)で、実行時間と平均電力を比べる - SPEC ベンチマーク: SPEC CPU 2017 の整数(speed / base)と SPEC OMP 2012(speed / base)。A64FX はすべて 2.0 GHz(通常モード)。SPEC CPU の Xeon は Platinum 8168(Skylake、2.7 GHz、24 コア × 2 チップ、ターボ有効)、SPEC OMP の Xeon は Platinum 8280(Cascade Lake、2.7 GHz、28 コア × 1 チップ、ハイパースレッド有効で 56 スレッド、ターボ有効) - 電力モード: エコモードは STREAM、ブーストモードは dgemm で評価する ## 実験結果 - **システム**: Fugaku は 432 ラック・158,976 ノード(1 ラック 384 ノードとの記述。432 × 384 = 165,888 は総ノード数と一致しないため、ラックの構成の詳細は本稿からは読み取れない)。各ノードは A64FX 1 チップで、Tofu-D で接続される。第 1 層のストレージは、計算ノード 16 台ごとに割り当てた 1 ノードに付く SSD で、第 2 層は富士通が開発した Lustre ベースのグローバルファイルシステムである。ノードでは Linux カーネルが動き、システムデーモンはすべて 2 個または 4 個のアシスタントコアで動く。計算専用ノードのチップは 2 個、計算兼 I/O ノードのチップは I/O 処理に CPU 資源が要るため 4 個のアシスタントコアを持つ - **A64FX**: TSMC 7 nm FinFET で作られ、4 つの CMG はリングバスの NoC で結合されてキャッシュコヒーレンシを保つ。TNI と PCI Express コントローラも同じチップ上にある。標準クロックは 2.0 GHz でブースト時 2.2 GHz。標準クロックでの倍精度理論ピークは 1 チップ 3 TFLOPS である **図 1(Figure 1): A64FX メニーコアプロセッサ** ![[_attachments/Co-Design-and-System-for-the-Supercomputer-Fugaku/fig01-a64fx.png]] (図 1. (a) 構成図: NoC を中央に、4 つの CMG(それぞれ HBM2 メモリに接続)、上部に PCIe コントローラと Tofu インターフェースが並ぶ。(b) チップパッケージとダイ写真。) - **基本性能**: 1 チップで STREAM triad は 830 GB/s 超、dgemm は 2.7 TFLOPS 超(効率 90%)。Tofu-D の遅延は 1 MB の put 操作で 0.49〜0.54(単位は本文抽出で ms と読めるが、桁から μs の誤りとみられる)、帯域は 6.35 GB/s - **主要ベンチマーク**: A64FX のプロトタイプ機は 2019 年 11 月に Green500 で 1 位(電力効率 16.87 GFLOPS/W。GPU を上回るとする)。Fugaku は 2020 年 6 月に TOP500、HPCG、HPL-AI、Graph500 の 4 つで 1 位になり、2021 年 11 月までその位置を保った。報告値は TOP500 HPL が 442 PF、HPCG が 16 PF、HPL-AI が 2 EF、Graph500 が 102.95 TTEPS である。HPL 442 PF を理論ピーク 537 PF で割ると約 82% である(算術による確認) - **CloverLeaf(図 2)**: A64FX 1 チップの性能は、HBM2 の高メモリ帯域のおかげで、他のプロセッサの 4 ソケット分より良い。Fugaku の強スケーリングは 2 次元分割で良好にスケールする **図 2(Figure 2): CloverLeaf の性能** ![[_attachments/Co-Design-and-System-for-the-Supercomputer-Fugaku/fig02-cloverleaf.png]] (図 2. (a) A64FX 1 コアに対する相対性能。MPI プロセス数と OpenMP のコア数を変えた場合。(b) Fugaku での強スケーリングの実行時間(入力は clover_bm2048_shot.in)。) - **オープンソースアプリケーション(図 3)**: A64FX の消費電力は多くのアプリケーションで Xeon の約半分で、性能は同等である **図 3(Figure 3): オープンソースアプリケーションの実行時間と平均電力** ![[_attachments/Co-Design-and-System-for-the-Supercomputer-Fugaku/fig03-apps-power.png]] (図 3. A64FX 1 チップの実行時間と平均電力を、2 ソケットの Intel Xeon に対する相対値で示す。) - **SPEC(表 2)**: SPEC CPU 2017 の整数 base の総合値は Fugaku 1.98 に対し Xeon 9.07 で、A64FX は Xeon の約 1/4 未満(1.98 / 9.07 ≒ 22%)である。単一スレッド整数性能が低い理由は、SPEC CPU int の SIMD 率が低く、A64FX の周波数と O3 資源がスループット指向で限られているためである。SPEC OMP 2012 の総合値は Fugaku 7.77 対 Xeon 12.0 で約 65%(48 スレッド対 56 スレッド)。363.swim(53.1 対 8.38)と 370.mgrid(32.6 対 7.46)は HBM2 の高帯域により大きく上回る。350.md(2.63 対 62.6)は極端に低いが、手作業のソース最適化(インライン化、ループアンローリング)で改善を確認している **表 2(Table 2): A64FX と Xeon の SPEC ベンチマーク結果** ![[_attachments/Co-Design-and-System-for-the-Supercomputer-Fugaku/table2-spec.png]] (表 2. (a) SPEC CPU 2017(int speed/base)。10 本の個別結果と総合値(Fugaku 1.98、Xeon 9.07)。657.xz_s のみ 48 スレッドで 8.52 対 23.5。(b) SPEC OMP 2012(speed/base)。14 本の個別結果と総合値(Fugaku 7.77、Xeon 12.0)。) - **A64FX の性能チューニング**: 浮動小数点命令の多くは FMA 演算器で 9 サイクルで実行され、レイテンシが長い。コアが L1 のみのキャッシュ構造もデータアクセスのレイテンシを伸ばしうる。スループット指向のループなら効率良く実行できるが、長いレイテンシの影響を受ける演算が多いと問題になり、O3 資源が枯渇して性能が落ちる。対策として、ソフトウェアパイプライニング(O3 資源での値の生存期間を短くする)と、ループ分割(ループ本体が長いと O3 資源不足とレジスタスピルを招くため)が有効で、富士通コンパイラは両方(ループ分割は自動)を支援する - **エコモード・ブーストモード(図 4)**: エコモードは通常モードに対し電力を 15〜25% 削減し、性能はほぼ同じ。24 スレッドでスループットがピークメモリ帯域の 80% に達し、電力も 24 スレッドまで増える。ブーストモードは dgemm で性能が通常モードより 10% 高いが、電力は 13.7% 増え、電力効率は 3.3% 下がる **図 4(Figure 4): エコモードとブーストモードの効果(性能と消費電力)** ![[_attachments/Co-Design-and-System-for-the-Supercomputer-Fugaku/fig04-eco-boost.png]] (図 4. (a) STREAM でのエコモードの効果。(b) dgemm でのブーストモードの効果。) - **KPI の達成**: 1. 電力効率: A64FX は Green500 で 1 位になり、当時の GPU に近く、汎用メニーコアプロセッサとしては極めて良い電力効率だった 2. 実効性能: 対象アプリケーションのうち MD アプリケーション(GENESIS)と、データ同化つき気候シミュレーション(NICAM + LETKF)の 2 本が K computer の 100 倍以上になった。他の対象アプリケーションも、プロジェクト中盤での見積もりを上回る性能を確認した 3. 使い勝手: 標準のプログラミングモデルは OpenMP-MPI ハイブリッドであり、多くのアプリケーションは Intel 環境からの単純な再コンパイルで動く。LLNL 開発のパッケージ管理ツール Spack を支援して自動化を進めており、Fugaku 向けに 3,000 件超のパッケージレシピが用意されている ## 考察 - 運用: Fugaku は 2021 年 3 月から一般利用が可能で、現在(執筆時)の運用電力は平均約 20 MW、最大で 30 MW 近い。これは設計段階での想定より電力効率が良いと著者は述べる - 課題: A64FX は HPC 指向のメニーコアで多くのアプリケーションがよく動くが、コンパイラが一部のケースでまだ未成熟であり、プロセッサを効率的に使う十分な経験がなく、最適化されていないアプリケーションが残る。今後はコンパイラ技術と A64FX 向けの最適化技法を探る - 設計上の割り切りの帰結として、単一スレッド整数性能は低く(SPEC CPU int で Xeon の約 1/4)、メモリ帯域が効く負荷では高い(swim、mgrid、CloverLeaf)。設計が HPC のスループット型アプリケーション向けであることの裏返しである ## 強み / 弱点・課題 - 強み: 設計判断の根拠(ダイ面積とコスト、MCM を選ばない理由、HBM2 の容量と DDR 非搭載、L3 なし、タグ一致後データ読み出し)が、使った道具とともに具体的に語られる。電力ノブは、演算器の安定動作機構が電力を食うという実測から生まれたエコモードのように、想定と実測のずれから設計を直した例を含む - 強み: 電力効率(Green500 首位)、実効性能(2 本で K 比 100 倍以上)、使い勝手(単純な再コンパイル)の KPI ごとに達成度を述べている - 弱点: 解説論文であり、詳細な数値と評価条件は他論文(文献 7、10-12)に譲る。図 2〜4 の相対値は本文と図キャプションだけで、生データは示されない。K computer 比 100 倍の達成は 2 本のアプリケーションだけで、残りは「見積もりを上回った」という記述にとどまる - 弱点: SPEC の比較は世代の異なる Xeon(Skylake と Cascade Lake)との単一の設定であり、電力あたりの評価は図 3 の相対値に限られる。Green500 の GPU 比較(「GPU を上回る」と「GPU に近い」)は、同じ論文内で表現が揺れている(前者は 2019 年 11 月のプロトタイプ機、後者は KPI の節での説明) - 弱点: 「エクサスケール」を標榜するが、報告された FP64 の HPL は 442 PF で 1 EF に届かず、2 EF は HPL-AI(混合精度)の値である。倍精度の理論ピークが 537 PF である点は概要と整合するが、「エクサスケール」の意味は論文中で定義されない > [!contradiction] 「エクサスケール」の意味 > 本稿は Fugaku を「エクサスケール」のシステムと呼ぶが、倍精度の HPL は 442 PF(理論ピーク 537 PF)で、1 EF は混合精度の HPL-AI だけが超える。倍精度の持続性能 1 EF 以上を要件とする定義では、[[エクサスケール]] ページの Aurora(HPL 1.012 EF/s)とは並べて読めない。 (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]]) ## 出典 - 原本: [[.raw/papers/Co-Design-and-System-for-the-Supercomputer-Fugaku.pdf]]