連載308回からHPC向けのGPGPUについて説明してきたが、今回はそのまとめとして、現状で判明している問題と、各社の将来の方向性について解説していきたい。
現状の問題点は
演算の種類が偏ってしまうこと
現状のHPCの問題は? というとこれはけっこうある。まずはサポートされる演算の種類がどうしても偏る方向にあることだ。
理由は簡単で、インテルはともかくとしてNVIDIAおよびAMDはGPUとコアを共有しているため、どうしても内部の構成はGPUを意識したものにならざるを得ない。
ではGPUを意識するとどういうことになるかというと、32bitの単精度浮動小数点でのMAC演算ができれば今のところ十分であり、64bit、つまり倍精度浮動小数点演算のサポートがあってもほとんどが使われないことになる。
したがって、新しいコアを設計するにあたっては64bitのサポートを追加するか否かは、どの程度HPC向けに使うかを熟慮する必要がある。
NVIDIAの場合これが顕著で、Tesla(32bitのみ)→Fermi(32bitのみ)→Kepler(32/64bit)→Maxwell(32bitのみ)→Pascal(16/32bitのみ?)→Volta(16/32/64bit?)といった具合に、世代毎にサポートされるデータ型が変わっている始末だ。
PascalとVoltaはなにしろまだ製品が存在しないため推定での記述であるが、実際問題としてKepler→Maxwellでは同じ製造プロセス(28nm)ながら、GPUとしての性能はMaxwellの方がずっと高く、しかも効率が上がっている。
この理由はいくつかあるが、1つには倍精度のサポートを削った分、より多くのシェーダーをダイに詰め込めるようになったことが挙げられる。結果、Maxwellベースの製品はKeplerベースの製品をほぼ駆逐することになったが、それも当然であろう。
NVIDIAの現在の売り上げを見ると、2015年度の売り上げの38億ドルのうち、GPU向けが20億ドル以上を占めており、HPC&クラウド向けの2.8億ドルと比較すると7倍以上の違いがある。
この状態で、HPC向けに倍精度演算を搭載することで肝心のGPU側の性能が落ちる、というのは普通に考えると許容されにくいのは理解できるだろう。
結果、Maxwellは従来のHPC向けには非常に使いにくいものになってしまった。ここで「ではGPU以外で倍精度演算がなくても利用できるHPC的な用途はないか?」と模索した結果がディープラーニングである(関連リンク)。
ところが、実際にはディープラーニングには単精度演算でもオーバースペックであり半精度、つまり16bit演算でも十分という話が出てきた。Pascalはこれに向けて、32bitの演算器を2つの16bit演算に振り分けることで性能を2倍にする、という仕組みが搭載される模様だ。
要するにHPCは置いておき、Pascal世代ではGPU的な使い方とディープラーニングに焦点を当てた製品になるという話であり、HPC向けには2018年に予定されているVoltaまでの間は引き続きKeplerベースの製品が提供され続けるという形になると思われる。
一方AMDは、GCNで64bit演算をサポートしており、GCNベースの同社の製品はローエンドからハイエンドまですべてが64bit演算をサポートするという、ある意味整合性の取れたアーキテクチャーである。
これはAMDの場合、OpenCL経由で普通のアプリケーションからGPGPU的に利用することを想定しており、64bit演算のサポートは当然必要という判断だったようた。結果的にGCNベースのGPUは、同一構成ではMaxwellベースのGPUよりもやや性能は劣ることになるが、AMDはそれは問題ないと考えているようだ。
もう1つの雄であるインテルの場合、GPU的な使い方は考慮する必要がないので比較的制約は少ないが、その代わりにx86ベースという別の制約が付いてしまっており、これがダイサイズの大型化を招いている。
特定の計算以外は高速化できない
さて、ここまでは演算の種類を単に単精度か倍精度かだけで説明してきたが、実はこれ以外にもある。GPU/GPGPUが提供する浮動小数点演算は極めて基本的なものだけで、あまり複雑なものはない。
NVIDIAの場合、ここのSM/SMXは加算や乗算などの基本的な演算のみであり、三角関数や指数/対数などの「基本的ではあるが、やや特殊な」算術演算はSFU(Special Function Unit)に実装される形となっているが、こちらはそれほど種類が多くなく、また演算器の数もずっと少ない。
例えばKeplerの場合、1つのSMXには192個のSingle-Float CUDA Core、64個のDouble-Float Unit、32個のLoad/Store Unitと同じく32個のSFUが実装されている形で、こうした特殊な演算を利用すると途端に性能が落ちることになる。
これはAMDも同じで、GCNには特殊な演算命令を持っておらず、ライブラリーで特殊な演算を(通常のベクトル演算器を使って)処理することになり、効率は悪い。
同じようにインテルのMICアーキテクチャーで採用されるAVX512命令も、ここで扱われるのは基本的な演算の他はデータ移動やフォーマット変換のみである。
これは、LINPACKなどに代表される行列の乗加算を大量に行なうといった演算にはかまわないが、HPCの用途が広がってきて、それ以外の計算も高速にさせたいなどと思った瞬間に行き詰まりを見せることになる。
もちろんx86プロセッサーのFPUに相当するものが全部のシェーダーに入っていればこうした問題はだいぶ解決するのだが、これはインテルのMICアーキテクチャーよりもさらにエリア効率を落とすことになりかねない。
フル機能を実装した倍精度対応のFPUが占めるエリアは、(ダイ上の)CPU全体の面積の中で無視できない割合を占める。ARMのプロセッサーが、FPUをオプション扱いで提供するのは、このあたりの損得勘定が難しいからである。
これに関しては、今のところ各社あきらめ気味である。こうした特定用途向けには、既存の汎用プロセッサー(IntelのXeonやIBMのPower、長期的にはARMのCortex-Aシリーズなど)を多用するか、もしくはFPGAを利用するという方向性が固まりつつある。
ただFPGAは「GPGPUにできないこと」をやらせる分には効率が良いが、汎用プロセッサーあるいはGPGPUにできることをやらせると、おそろしく効率が悪いという特徴があり、これも相まって用途に応じて使い分ける方向性になりつつある。
インテルがFPGA大手のAlteraを買収した、というニュースをこうしたHPC向けの観点から見ると非常に興味深い。MICアーキテクチャー+FPGAというソリューションは、相互に補完しあえる可能性が高いからだ。
→次のページヘ続く (メモリー帯域が不足)
この連載の記事
-
第795回
デジタル
AI性能を引き上げるInstinct MI325XとPensando Salina 400/Pollara 400がサーバーにインパクトをもたらす AMD CPUロードマップ -
第794回
デジタル
第5世代EPYCはMRDIMMをサポートしている? AMD CPUロードマップ -
第793回
PC
5nmの限界に早くもたどり着いてしまったWSE-3 Hot Chips 2024で注目を浴びたオモシロCPU -
第792回
PC
大型言語モデルに全振りしたSambaNovaのAIプロセッサーSC40L Hot Chips 2024で注目を浴びたオモシロCPU -
第791回
PC
妙に性能のバランスが悪いマイクロソフトのAI特化型チップMaia 100 Hot Chips 2024で注目を浴びたオモシロCPU -
第790回
PC
AI推論用アクセラレーターを搭載するIBMのTelum II Hot Chips 2024で注目を浴びたオモシロCPU -
第789回
PC
切り捨てられた部門が再始動して作り上げたAmpereOne Hot Chips 2024で注目を浴びたオモシロCPU -
第788回
PC
Meteor Lakeを凌駕する性能のQualcomm「Oryon」 Hot Chips 2024で注目を浴びたオモシロCPU -
第787回
PC
いまだに解決しないRaptor Lake故障問題の現状 インテル CPUロードマップ -
第786回
PC
Xeon 6は倍速通信できるMRDIMMとCXL 2.0をサポート、Gaudi 3は価格が判明 インテル CPUロードマップ -
第785回
PC
Xeon 6のIOチップレットには意地でもDDR5のI/Fを搭載しないインテルの強いこだわり インテル CPUロードマップ - この連載の一覧へ