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

ET-SoC-1の設計思想で納得、やっぱりEsperantoはDitzel氏の会社だった　AIプロセッサーの昨今

100～1000TOPSのピークレートを
1つのET-SoC-1で実現できる

　ちなみにテンソル命令でどんなことができるのか？　というのが下の画像だ。

テンソル命令でできること。こうなってくると、ET-Minionの効率は「どれだけ扱うデータがこのテンソル演算に親和性が高いか」で決まることになる。例えば8×8の演算なら高速だが、9×9などではいきなり効率が4分の1に落ちることになりかねない

　最大512回というあたりだとすると、例えば2次元行列乗算なら16×16の行列(データ型8bit)同士の乗算の合計をCに出力とか、3次元テンソルなら8×8×8の行列の乗算を実行できる格好になる。従来のプロセッサーでは、このためには2次元なら最低でも(演算命令+データ移動命令)×256、3次元なら×512個が必要なので、これを1命令で済ませられることの効果は大きい。

　ただ命令実行の方は自動でできるとして、問題になるのはデータのロード/セーブである。なにしろ最大だと1命令で32K演算なので、Int 8としても32KB分のロードとセーブが512サイクルごとに入ることになる。

　もっと正確に言えば、レジスターファイルが512個並んでいれば512サイクルごとに入れ替えれば済むことになるが、実際にはそんな巨大なレジスターファイルを置くのはエリアサイズ的にも消費電力的にも無理である。

データ移動の構図。外部メモリーから内部の2Dメッシュ経由で読みだされ、一旦Shire内のSRAMに格納。ここからTensorLoad経由で個々のET-Minionの1次データキャッシュに入り、そこからレジスターファイルにロードされる。この際、外部メモリーアドレスを自動的にインクリメントする、それこそDMAコントローラー的な機能がどこかに入っているものと思われる

　したがってレジスターファイルと1次データキャッシュの間で常にデータのやり取りが発生する格好になる(しかもこれはET-Minionのロード/ストアー命令ではなく、テンソル命令を発行するとロード/ストアーユニットが(RISC-Vのパイプラインとは独立に)動作して、定期的にデータのロード/セーブをSRAMとの間で行なう形になる。レジスターファイルは8組なので、例えば4組ごとにロード/セーブをするのかもしれない。

　これが理想的に動作すれば、1個のET-Mineonで32FLOPs/サイクル、これが1088個同時動作で34816FLOPs/サイクルである。300MHz動作なら1044GLOPSs相当になるわけで、「100～1000TOPSのピークレート」を1個のET-SoC-1で実現できるわけだ。

あくまでこれは理想的な演算での話なので、アプリケーション性能はまた別の話である

デュアルM.2カードとPCIeカードに
ET-SoC-1が搭載される

　なお、ET-SoC-1は、デュアルM.2カードとPCIeカードの2種類の形で提供される予定だそうだ。

GP v2カード(上段)の場合、このデュアルM.2カードを上下2段積みで1枚に6個のET-SoC-1を搭載できる

　さらにデータセンター向けとしては、そのGP v2カードを2つ搭載したYosemite v2 Sledや、それをさらに4つ搭載したYosemite v2 Cubby、そのCubbiyを8つ搭載したラック構成なども想定されているとする。

CP GP v2カードで120W、Yosemite v2 Sledで240W、Yosemite v2 Cubbyで960W、ラック全体では8KWといったところ。ただYosemite v2 Sled以降は相互接続用ネットワーク(100Gイーサネットあたり)の分も加味しないといけないので、もう少し消費電力は増えそうだ

　すでにCelebresやGraphcoreのように、サーバー向けに先行者利益を享受しているベンダーもある中で、今後Espelantoがどれだけ巻き返しを図れるのか、楽しみである。