ロードマップでわかる！当世プロセッサー事情 第683回

Hot Chips 34で判明したAMDのInstinct MI200とインテルのPonte Vecchioの詳細　AMD/インテル GPUロードマップ

インテルPonte Vecchioの
動作周波数は1.6GHz程度

　次いでインテルのPonte Vecchioについて。こちらの詳細は連載629回と連載632回で説明しているが、もう少しだけ細かい情報がわかったので、説明したい。

　まずは動作周波数。もともとPonte Vecchioに関しては、Xe-Core1個あたりの処理性能は公開されていたが、全体としての性能はFP32で45TFlops以上、と漠然とした数字しか出ていなかった。

　Ponte Vecchioの場合、Xe Coreを64個まとめた「スタック」を2つ集積した構造であり、つまりXe Core数は128となる。先の性能で言えば、Vector Engineの性能はXe Coreあたり256 Flops/サイクル(FP32およびFP64)となり、これが128個集積されるので32K Flops/サイクル(32768 Flops/cycle)という計算になる。これで45TFlopsを実現しようとすると、最低でも動作周波数は1.4GHz前後(1.37296……GHz)ということになる。ただ実際にどの程度の動作周波数を想定しているのか？　ははっきりしなかった。

　今回、このPonte Vecchioのピーク・スループットが公式に発表された。

VectorとMatrix、どちらのエンジンも1.6GHz駆動とすると数字の辻褄が合う

　大雑把に言えば、動作周波数は1.6GHz程度と考えられる。もっともこれはピーク・スループット、つまり製品の公式な動作周波数という話で、Auroraで実際に稼働させるにあたってこの動作周波数のままかどうか、はまだ未知数である。

　というのはFrontierのように、性能/消費電力比を高めるためにInstinct MI250Xの動作周波数を1.7GHz→1.6GHzに落としたという実例があるからだ。このあたりはAuroraが稼働してTOP500に登録されるまでははっきりわからないところである。

　もう1つ明らかになったのはRambo Cacheの詳細である。L1がXe-Coreあたり512KBという話は以前公開されていた（連載629回）が、未公開だったのはL2ことRambo Cacheである。今回これが408MBと発表された。

これはPonte Vecchio全体でのサイズである。それはともかく、レジスターファイルのサイズも512KBというのはなかなかすさまじい

　もともとRambo Cacheは8つのタイルに分かれて実装されていることが明らかにされていたので、つまりタイルあたり51MBという、少し不思議な容量になっている。

　Rambo Cacheは先の図でもわかる通り2つのCompute Tileから同時アクセスが可能な構造になっており、Compute TileとRambo Cacheの間の帯域はおおよそ832GB/秒ほどという計算になる(これが8タイル×2つのI/Fで、トータル13TB/秒)。この帯域はかなり広いというか、先のInstinct MI250Xのダイ間接続の倍以上、というおそろしい代物である。

　ただこちらはそもそも2次キャッシュということもあり、おそらくバス幅はかなり広いと思われる。仮にRambo Cacheへのアクセス速度がダイと同じ1.7GHzで行なわれているとすれば、512bit幅があれば足りる。半分の速度だとしても1024bit幅があればまかなえる。Foveros経由ということを考えれば、512bit幅あるいは1024bit幅であってもそれほど構成は難しくないだろう。

　また408MBものRambo Cacheを搭載したメリットとしてインテルが示した例が下の画像だ。ディープニューラルネットワーク向け処理はともかく、特に科学技術計算の中でもランダムアクセスが頻繁に発生するFFTで、32MB/80MBの場合と比較して倍近くまでスループットが上がるとしている。もっとも特にFFTの場合、本当に408MBで十分なのか？　というのは気になるところだ。

というよりも、FFTの場合だと1次キャッシュでは全然容量が足りず、結局HBM2eからのデータ読み出しが煩雑になりすぎ、ここがボトルネックになって性能が上がらない(Xe-Coreは遊んでる)状況が、408MBにすると解消される、という話である

　性能ではもう1つ、XMX Matrix Unitの効率も今回示されたのだが、なんというかものすごすぎる。これはBF16を利用してGEMMを実施した例で、Matrixのサイズを4096まで引き上げると効率が95%を超えるとしているのだが、逆に512で40%未満、1024で70%弱、2048でも90%にいかないというありさまである。

理屈としてはわかるが、サイズを大きくするということはそれだけメモリーを多く利用するという話でもあり、全Xe-CoreでMatrix Unitをフルに動かすようなアプリケーションではメモリー管理が難しそうではある

　相当大きくしないと効率が悪いというのは、逆に言えばMatrix Unitにデータを格納したり、逆に結果を取り出すオーバーヘッドが相当大きい、ということになる。このあたりは、性能をうまく出すためには苦労しそうである(同じことはSapphire Rapidsで搭載されるAMX Unitにも言えそうだが。

　あとおもしいのは、Ponte VecchioではSPMD(Single Processor Multi Data)/SIMT(Single Instruction Multi Thread)とSIMD(Single Instruction Multi Data)の2種類の動作モードをサポートする、という話もあった。GPU的な動作で言えばSPMD/SIMT的なプログラミングの方が一般的であるが、CPUで動いていたプログラムを移植するという観点ではSIMDの方が楽である。

　性能はもちろんSPMD/SIMTの方が出るという話で、例えばHACC(Hardware/Hybrid Accelerator Cosmology Code:アルゴンヌ国立研究所で開発されている、宇宙の構造などの計算に利用されるライブラリー。Exascale Computing Projectsにもう少し細かい話がある)をまずSIMDの形で移植、これをSIMTに書き換えたら4.2倍程度に高速化したとされる(SPMDに最適化するにはもう少しチューニングが必要だそうだが)。ただこれも書き方とかデータの持ち方などで変わってくる部分があることもあり、定量的な形での性能向上率などは示されなかった。

　もともとPonte Vecchioは、消えてしまったKnights Hill(第3世代Xeon Phi)の代わりに開発されたもので、そのXeon PhiはCPUで行なっていた処理をより効率的に実行するGPGPUになる予定だったわけで、そうなるとx86からのアプリケーションの移行は必須である。

　このために同社は最近oneAPIに力をいれており、最近では低レベルでのGPUのハードウェアの制御も可能とするoneAPI Level Zero APIの提供や、CUDAで記述されたアプリケーションをSYCLに効率的に変換するIntel DPC++ Compatibility Toolの提供など、ソフト面での充実に余念がない。

　今回のSPMD/SIMTモードとSIMDモードの両提供も、こうした流れの一部と考えれば理解はしやすいのだが、問題は「いつ出てくるの？」という話である。Sapphire Rapidsもそうだが、Ponte Vecchioも何時になったら本格稼働に至るのだろうか？

ASCII倶楽部