NVIDIAのGPUコンピューティング部門であるTesla business unitのCTO Steve Scott(スティーブ・スコット)氏は、昨年(2011年)8月にNVIDIAに加わる前は、米国のスーパーコンピュータメーカーCrayのCTOを務めていた。CrayのベクトルスーパーコンピュータであるCray X1のチーフアーキテクトを務めたこともある。

　Crayの前身であるCray Researchを設立したシーモア・クレイ氏は、スーパーコンピュータで重要なのはメモリ帯域であると主張していた。しかし、現在のGPUでは、メモリ帯域と演算パフォーマンスの間には大きなギャップが開いてしまっている。Scott氏は、その問題には、根本的な解決策がないと説明する。

　「残念なことに、物理的な制約により、この問題は解決ができない。メモリ帯域が安くなるよりもはるかに速いペースで、FLOPS(演算パフォーマンス)は安くなりつつある。FLOPSの増加はタダ同然だが、メモリ帯域は極めて高価につく。コストだけでなく、電力もFLOPSの方が、メモリ帯域よりもはるかに低い。言い換えれば、高いBytes/FLOPS比率(メモリ帯域/演算パフォーマンス比率)を達成しようとすると、コストが高くつきすぎてしまう。

　そのため、経済的な観点から、ユニット当たりのパフォーマンスを最大にするには、メモリ帯域に対するFLOPSの比率を高めなくてはならない。実際には、GPUはCPUよりずっと広いメモリ帯域を持っている。Fermi GPUのメモリ帯域は170GB/secであるのに、CPUは40～50GB/sec程度だ。とはいえ、メモリ帯域に対するFLOPSの比率は、今後も継続して上がって行くことは確実だ」。

　演算はコスト的にも電力的にも安い。ところが、データの移動はコスト的にも電力的にも高くついてしまう。これが、現在のプロセッサの抱える問題で、GPUのようなスループットに最適化したプロセッサであればあるほど、この問題の影響が大きい。そして、汎用プロセッサであるGPUの場合、低コストに作る必要があるため、どうしてもBytes/FLOPS比率(メモリ帯域/演算パフォーマンス比率)は低下していってしまう。これが現状だ。しかし、緩和する手段もある。

データの移動にかかる電力

各GPUにおけるメモリ演算比率の比較 PDF版はこちら

　NVIDIAのScott氏は、メモリ帯域の問題については、パッケージ技術の革新を利用すると語る。

　「我々は、この問題を緩和するために、次の数世代のうちに、新しいレベルのメモリ階層を導入しようと考えている。3D積層によって、メモリチップをGPUと同じパッケージに収めることだ。その場合は、パッケージに積層メモリが載り、さらにメインメモリがDIMMなどで載るという形となるだろう。

　50年に渡るコンピュータ業界の歴史の中で、常にメモリに対してプロセッサのクロックが上がり、メモリがどんどん遠くなり、それを埋め合わせるために新しいメモリ階層が導入されて来た。最初にL1キャッシュが、次にL2キャッシュ、そして3階層目のL3キャッシュと加わってきた。そして、新しい階層がパッケージ内のメモリ積層だ。メモリ階層のレベルを増やすことで、広がり続けるギャップを埋めて行く。とはいえ、ギャップ自体が広がり続けることを止めることはできない」。

　NVIDIAは過去に何回か、3Dスタックメモリを採用することを示唆してきた。シリコン貫通ビア(TSV:Through Silicon Via)技術を使った、超広帯域のダイスタックを前提としている。最大1TB/secのメモリ帯域で、スタックしたメモリを接続、それによってメモリボトルネックを解消しようとするアイデアだ。

　Scott氏の説明からは、NVIDIAが3Dスタックメモリを、新しいメモリ階層として導入しようとしていることがわかる。GPUのビデオメモリを全てスタックで、GPUに載せてしまうのではなく、オフパッケージのメモリとの組み合わせを考えているようだ。

DRAMのスタック PDF版はこちら

TSVの基本技術 PDF版はこちら

　TSVによる3Dスタックメモリも、モバイル向けのアプリケーションSoC(System on a Chip)と、スーパーコンピュータ向けのハイエンドチップの両方から採用が始まる様子を見せている。モバイル/組み込みとスパコンの技術接点の1つとなっている。

　NVIDIAの現在のGPUアーキテクチャでは、複雑なメモリ階層を取っている。ハードウェア制御のキャッシュメモリと、ソフトウェア管理の共有メモリの組み合わせだ。また、NVIDIA GPUは膨大なレジスタファイルも備えている。NVIDIAは、こうしたメモリアーキテクチャを、今後も維持して行く見込みだ。Scott氏は次のように説明する。

　「メモリ階層を組み立てる上で、キャッシュは最も電力効率の高い方法ではないと考えている。キャッシュはレイテンシを短縮して、レイテンシトレラントではないプロセッサをできる限り速く走らせるための技術だ。しかし、キャッシュはかなりの電力を消費する上に、キャッシュミスで外部メモリにアクセスする場合にはさらに電力を消費してしまう。

　それに対して、NVIDIA GPUを見ると、キャッシュだけでなく異なるソースのメモリを備えていることがわかる。まず、IntelのMIC(マイク:Many Integrated Core)」と比べるとはるかに大きなレジスタファイルを備えている。これは、大量のスレッドをオンザフライで立ち上げるためだ。

　さらに、オンチップの共有メモリによる明示的なデータ管理によって、キャッシュミスすることなく内部メモリを使うことができる。我々は、ソフトウェア制御されたメモリ階層による、キャッシュミスもなく、タグ参照のロスもないメモリ管理が電力的に優れていると考えている。物理的な設計の観点から、電力効率を上げようとすると必然的に明示的に管理されたメモリ階層が好ましくなる。ただし、キャッシュが便利なケースもあるので、実際には、メモリを組み合わせることになる」。

　NVIDIAは、データ移動をある程度明示的にコントロールすることが電力効率を高めるとする。Cell Broadband Engine(Cell B.E.)の時にも似たような議論があった。電力効率を第1に考えると、考え方がある程度似通って来る。そして、こうしたアイデアは、プログラミングモデル側でのサポートを必要とする。

NVIDIA GPUのメモリ階層 PDF版はこちら

Fermiのアーキテクチャ PDF版はこちら

　GPUコンピューティングの抱える問題の1つは、プログラミングの複雑性にある。この問題に対しては、よりコンパイラに任せる新しいモデルが昨年(2011年)相次いで紹介された。1つは、Microsoftが発表しAMDが支持する「C++ AMP」、もう1つがNVIDIAが旗を振る「OpenACC」だ。OpenACCはCUDAより抽象度を引き上げたプログラミングモデルで、コンパイラディレクティブ(Directive)によって、コンパイラにGPUコードを生成させる。C++ AMPと、かなり似通ったアプローチのモデルだ。

OpenACCのアプローチ

　Scott氏は、OpenACCが、HPCでの新しい標準になって行くと期待する。

　「OpenACCのようなコンパイラディレクティブ(Directive)ベースのプログラミングモデルがハイブリッドアーキテクチャでは理にかなうと考えている。ディレクティブベースによって、ソフトウェア開発者は、より手軽に、高い生産性で、よりポータブルなハイブリッドコンピューティングのコードを構築することができる。オークリッジ国立研究所(Oak Ridge National Laboratory:ORNL)では、我々のGPUを使った新しいスーパーコンピュータTitan向けに、OpenACCでアプリケーションを書いている。

　OpenACCを使うことで、GPUで走るようにチューンされたコードを、そのままCPUでも速く走らせることができる。並列性を明示させながら、ポータビリティも保つことができるため、将来のハイブリッドマルチコアアーキテクチャにも対応できる。もちろん、IntelのMICアーキテクチャも含めてだ。

　さらに、我々はOpenACCの標準化にも取り組んでいる。OpenMPスタンダードのリーダーシップから熱心なサポートを受けており、標準の一部としてOpenACCを組み込ませたいと考えている」。

　昨年夏に、AMDとMicrosoftがC++ AMPを発表して以来、NVIDIAの対応が注目されて来たが、NVIDIAもまた、似たような路線で対応を進めている。GPUコードの開発を容易かつポータブルにしようという動きは、全体の大きな流れとなっている。

GPGPUの流れ

　ハイブリッドコンピューティングモデルに対しては、新しく定義したディレクティブによるプログラミングモデルを提供する。これがNVIDIAの路線だ。その点で、Scott氏は、Intelの提唱するプログラミングモデルに対して疑問をぶつける。

　「IntelのMICアーキテクチャ自体は理にかなっている。問題は、MICのプログラミングモデルについて多くの議論があり、その中には、MICをプログラムする方法として非現実的な期待が含まれている。プログラマーは、何も労力をかけずにコードを移植できるといったもので、プログラミングコミュニティをミスリードしかねないものであり、我々は危惧している。

　Intelとそのパートナーの一部は、MICがx86命令セットを使っているため、既存のコードを全く変更しなくてもMICで走らせることができると主張している。コンパイル時に、MICをターゲットとするコンパイラフラッグを立てるだけで、MICで走るコードを生成できると。既存の並列コンピューティングのプログラミングモデルであるMPIやOpenMPのコードが、MICの上でネイティブに走るようになるため、移植のコストがかからないと主張している。

　しかし、これは非現実的なプログラミングモデルだと思う。なぜなら、パフォーマンスについての議論が欠けているからだ。確かに、機能としては、リコンパイルするだけで、MICの上で走るコードにできるが、パフォーマンスを考慮しなければ意味をなさない。現実問題として、MPIコードもOpenMPコードも、そのままではMIC上でパフォーマンスを発揮できないだろう」。

　Intelは、Larrabee(ララビ)アーキテクチャ系のMICでは、従来のマルチコア/マルチプロセッサCPU向けのコードが、そのままリコンパイルするだけで走るので移植の手間がかからないと説明している。Scott氏は、その方法では、パフォーマンスが出ないので、意味がないと主張している。

　「MPIコードについては、まず、コア当たりのメモリ量が少なくなるため、メモリを必要とするMPIでは問題が生じる。MPIの膨大なメッセージパッシングもインターコネクトの負担になる。また、リコンパイルすると、全てのコードをMICコアの上で走らせることになり、シリアルコードは、MICコアの搭載する古いPentiumコアで走ることになり、Xeonコアで走らせることができない。各MPIランクのシリアルコードは重いため、アムダールの法則のボトルネックも制約となる。

　OpenMPの場合は、ややましだが、やはり問題がある。もともとがマルチコアCPUをターゲットにしたものであるため、4～8コア程度までが適しており、50コアを越えるようなプロセッサまでスケールすることは難しい。また、再コンパイルだけなら、全てのコードをMIC側で実行することになるため、やはりPentiumコアの貧弱なシングルスレッド性能のために、アムダールの法則がボトルネックになる」。

　では、Intel MICに適したプログラミングモデルは何なのか。Scott氏は、ハイブリッドアーキテクチャであるMICには、やはりGPUと同じプログラミングモデルが適すると指摘する。つまり、アーキテクチャを改革するなら、プログラミングモデルにも改革が必要だという。

　「我々は、GPUとMICは非常に似たプログラミングモデルが適するだろうと考えている。Intelのカテゴリでは、アクセラレータモデルとなる。マシン向けにコードをディレクティブを加えて書くことで、高いパフォーマンスを得ることができる。アクセラレータモデルでは、シリアルコードはXeonコアのベストなシングルスレッドパフォーマンスで走り、並列処理可能な部分はアクセラレータにオフロードされる。そのため、ハイブリッドアーキテクチャの利点を享受できる。Intelが主張するようなフリーランチにはならないが、MICをプログラムする方法としては現実的だ。

　これはGPUをプログラムする方法と基本的には同じだ。だから、MICでのプログラミングに興味があるなら、今すぐにGPUを使って始めることもできる」。

　コンパイラを洗練させることで、よりポータブルかつ生産性の高いプログラミングモデルを実現する。プログラミングでは当たり前の流れが、GPUプログラミングでも始まっている。では、よりローレベルのプログラミングモデルであるCUDAはどうなって行くのか。Scott氏は、コミュニティベースのコンパイラインフラストラクチャへと移行することで、より入口と出口を広げると説明する。

　「我々は、CUDAのコンパイラインフラストラクチャをLLVM(Low Level Virtual Machine)コンパイラストラクチャに移行している。LLVMはオープンであるため、より迅速なイノベーションが期待できる。現在、CUDAソースコードを学術コミュニティと業界のツールパートナーに公開しているところだ。

　LLVMに移行することで、コミュニティが別な言語に対する新しいフロントエンドを開発することができるようになる。ドメインスペシフィックな専門言語のフロントエンドを作ることもできる。LLVMでは、フロントエンドを通じてそれぞれの言語から、コンパイラがローレベルのGPUコードを生成する。GPUコードの生成はバックエンドが行なうが、こちらでも、コミュニティは新たなバックエンドを開発することで、コンパイラのターゲットハードウェアを広げることができる。IntelのMICプロセッサやx86にも広げることが可能だ。また、LLVMコンパイラベースに移行することで、10～15%のパフォーマンス向上も期待できる」。

　AMDもFSA(Fusion System Architecture)において、コンパイラをドライバから切り離し、新しい基盤を作ろうとしている。NVIDIAは、盛り上がりつつあるLLVMコミュニティの力を借りて、コンパイラの再構築を行なおうとしている。