ポスト「京」のプロセッサ「A64FX」はArmベースながら異彩放つ重厚系：Arm最新動向報告（5）（1/3 ページ）

「Arm TechCon 2018」では、Armのアーキテクチャライセンスを基に開発が進められている、次世代スーパーコンピュータのポスト「京」（Post-K）向けのプロセッサ「A64FX」に関する講演が行われた。

[大原雄介，MONOist]

⇒連載「Arm最新動向」バックナンバー

　これまで4回に渡り「Arm最新動向」として、2018年10月に米国で開催されたArmの年次イベント「Arm TechCon 2018」であったさまざまな話題をご紹介してきた。今回の5回目では、締めくくりとして、富士通というか、東京工業大学 教授 兼 理化学研究所 計算科学研究センター長である松岡聡氏による、次世代スーパーコンピュータのポスト「京」（Post-K）に向けたプロセッサ「A64FX」の話を取り上げようと思う。

　「Cortex-Aシリーズ」などのArmのIPを使わずに、アーキテクチャライセンスを取得して独自のアーキテクチャを構築している半導体ベンダーは幾つか存在するが、Arm TechCon 2018では富士通のA64FXと、あとは設立されたばかりのAmpere Computingによる「eMAG」というプロセッサの2つのみがセッションとして取り上げられていた。ところが、あいにくAmpere Computingの方は、ぎりぎり顧客向けの製品出荷が開始されるかどうかという微妙なタイミング（正式な出荷開始は2018年10月11日）だったこともあってかアーキテクチャの説明などは一切なく、エコシステム向けのソリューションの概略を説明するにとどまったためあまり有益な情報とはいえなかった。

　これに対して、松岡氏によるA64FXの説明は、その大半が2018年8月に行われた「HotChips 30」で公開された内容と同じではあるものの、幾つか情報のアップデートが示されたので、この辺りをまとめてご紹介したいと思う。ちなみに筆者は、この原稿を2019年4月17日に書いているのだが、同年4月17〜18日には横浜で「Cool Chips 22」が開催されており、2日目の4月18日の最後で、富士通の山村周史氏による「A64FX High Performance Processor Architecture and its Design Challenges」という招待講演が行われることになっている。おそらくは、Arm TechCon 2018における情報をもう少しアップデートしたものが出てくると思われるが、この記事はそのための予習と考えていただければいいかもしれない。

　まずはA64FXのタイムラインから。当初は、2019年の第2四半期あたりで設計と実装（Design and Implementation）のフェーズが完了し、その後量産やインストールを2020年いっぱいかけて実施。2021年から、ポスト京の運用が順次開始されるという予定だった（図1）。ただし実際には、2019年4月15日に開発を完了、製造を開始することがアナウンスされており、若干ではあるがスケジュールは前倒しになり、開発も順調に完了したことを伺わせる。

図1　図の一番下にあるタイムラインにのみ注目。上に書いてある話はこの後もいっぱい出てくる（クリックで拡大）

　そのA64FXの設計目標（図2）は、とにかく性能やスループットもさることながら、高効率を狙った構成になっており、これをArmのアーキテクチャ「Arm v8.2A」で実現する、ということで国外からも（導入するかしないかはともかくとして）注目を集めている。そのA64FXのパッケージ構成がこちら（図3）。13コア（これらのうち演算には12コアを利用）のCMG（Core Memory Group）×4と、CMG間をつなぐネットワーク、それとTofuD/PCIeのコントローラーが1つのダイにつながり、さらにHBM2が4つつながる構成である。製造はTSMCの7nm FinFETプロセスを用い、トランジスタ数は87.9億個に達している。

図2　ちなみにもう少し設計時期が後であれば「Arm v9-A」が利用できたのだが、稼働時期を考えるとArm v8.2-Aが精いっぱいだったらしい（クリックで拡大）

図3　本当はPCIeもGen4にしたかったのだろうな、と思われる（クリックで拡大）

　さて、肝心のパイプライン構造だが、このスライド（図4）にもあるように、基本は「京」に採用された「SPARC64」のものをそのまま利用しつつ、フロントエンドのみArm命令に置き換えた形である。これは、富士通の基本的な方針であって、実際に富士通ジャーナルでも、メインフレームやUNIXサーバ、HPC向けでもマイクロアーキテクチャは共通であることを明言している。実際、SPARC64からの拡張は、512ビットのSVE（Scalable Vector Extensions） SIMD（Single Instruction/Multiple Data）エンジン×2を取り扱う部分と、当然こうなると扱うべきデータ量が128バイト/サイクルまで増えることになるため、L1データキャッシュ周りの拡張と、あとはHBM2/TofuDへの対応といった部分が変更点であり、逆に言えばそれ以外はほとんど差が無い形である。

図4　いわゆるMacro Ops Fusion（複数命令を統合）である（クリックで拡大）