Intelが、一部顧客にテスト用に提供した最初の世代のLarrabeeは、単体のコプロセッサでPCI Expressカードとなっていた。製品もPCI Expressベースとなる予定だ。これは、CPUとLarrabeeで、メモリが分断されていることを意味する。こうしたメモリモデルは、プログラミング上では大きな障壁となる。そこでIntelは、「シェアードバーチャルメモリ (Shared Virtual Memory)」技術によって、この問題を解決しようとしている。IntelはSVMには実績があり、Larrabee開発を進める傍らで、この技術をLarrabeeに応用する研究も行なって来た。これは、CPUにLarrabeeなどデータ並列コアを統合するまでの間のブリッジとなる。

Justin R. Rattner氏

　IntelもAMDも、最終的にはCPUにデータ並列プロセッサを統合しようとしている。PC向けのCPUコアと、発展型GPUやLarrabeeコアのようなデータ並列コアを、1つのダイ(半導体本体)に載せる方向だ。IntelのCTOであるJustin R. Rattner(ジャスティン・R・ラトナー)氏(Senior Fellow, Vice President, Director of Intel Labs, Intel Chief Technology Officer, Intel)は、統合の動機は、プログラミングモデルと電力効率にあると説明する。

　「大きな(CPU)コアと、大きなベクトルエンジンを備えた小さな(CPU)コアがある場合、問題は、どうやってそれを簡単にプログラムできるようにするかという点になる。この点については(両方を統合することによって)、統合したメモリアドレス空間を得ることで、(プロセッサが2つに分かれていることで生じる)余計なプログラム作業を避けることができる。プログラミングモデルはずっとシンプルになり、両方のコアの利点を享受できる。

　もちろんトレードオフもある。CPUでは、メモリは容量を重視するため、それほど高速なメモリを使うことができない。アクセラレータチップの方が高パフォーマンスのメモリを使うことができる。統合化によってメモリ性能が落ちることは、価格と性能のトレードオフとなる。その一方で、統合化によって電力効率がよくなるという利点もある。実際には、これが一番重要な利点だろう」

　とはいえ、当面のLarrabeeは、単体のコプロセッサであり、PCI Express経由でCPUに接続されるそのため、CPUとLarrabeeの両方にメモリがあり、データをCPUからLarrabeeに転送してプロセッシングしなければならない。

　CPUとの間のデータ転送は、GPUの汎用コンピューティングでも、プログラミング上の大きなボトルネックの1つだ。そこで、Larrabeeではそれを軽減するための仕組みとしてSVMを持ってくる。CPUとLarrabeeの間で、比較的小さなコストで、効率よくメモリを共有できるからだ。

　Rattner氏は10月に日本で行なった記者会見で、次のように説明した。「メモリ共有は、あらゆるアクセラレータアーキテクチャにつきまとう古典的な問題の1つだ。最初の浮動小数点演算アクセラレータの時からあった。そのため、我々は、この問題をどうやって克服するかを、長年研究してきた。

　そして、バーチャルメモリ技術を拡張することで、問題を解決できることを発見した。データ共有を、(バーチャルメモリの)ページレベルで行なうことができれば、異なるタイプのIAコア同士で、効率的にメモリを共有できるようになる。その方が、複雑なコヒーレントメカニズムのハードウェアにコストをかけるより、ずっといい。このテクニックを、我々は『Mine, Yours, Ours(MYO)』と呼んでいる」

　Intelは、LarrabeeとメインのCPUの間に、SVM技術を導入することで、効果的なデータ共有を図ろうとしている。LarrabeeとCPUは、それぞれ物理メモリを備えるが、バーチャルメモリメカニズムの上ではメモリを共有する。両プロセッサからは同じバーチャルメモリを共有しているように見えるため、データ構造をそのまま転送することができる。

　少し混乱するかも知れないが、これは、CPU間で見られるようなNUMA (Non-uniform memory access)型のシェアードメモリシステムとは異なる。例えば、IntelはCPUとLarrabeeをQuickPath Interconnect (QPI)で接続して、Larrabeeにコヒーレントメカニズムを実装し、完全なシェアードメモリを構築できるように設計することも、やろうと思えばできる。

　しかし、IntelはLarrabeeを広汎に普及させたいため、PCI Expressベースで導入しようとしている。Larrabeeには、QPIとコヒーレントメモリメカニズムは実装しない。そのため、CPUとLarrabeeの間で、NUMAメモリを取ることができない。その代替として、SVMを持ってこようとしている。後述するが、SVMでは、コヒーレンシを取るためのハードウェアメカニズムが不要だからだ。

SVMの概要	仮想メモリが異なる種類のIA間での効率的なメモリ共有を実現する

　実際には、シェアードバーチャルメモリ自体は新しいアイデアではない。Intelはこの技術を、かつて超並列のスーパーコンピュータで導入している。Rattner氏自身が手がけたIntelスーパーコンピュータ「Paragon」は、メモリコヒーレンシを保つために同技術を使っており、その時の技術名は「MYOAN」だった(最初に導入したのはiPSC/2で技術名はKOAN)。

　ここで興味深いのは、IntelはLarrabee開発に当たって、スーパーコンピュータでの経験を広汎に反映していることだ。Larrabeeアーキテクチャ自体が、スーパーコンピュータ戦争の時のSIMDとMIMD(Multiple Instruction, Multiple Data)の研究から産まれた。そして、メモリ共有にも、スーパーコンピュータの時の技術が転用されようとしてる。

　もっとも、SVMについては、Intelは過去2～3年の間に、何回か言及している。アクセラレータ(CPUに付加する専用処理チップ)に使うアイデアとして、同技術を持ち出したからだ。2007年には、Intel Developer Forum (IDF)でアクセラレータを使ったヘテロジニアスシステム構成のためのプログラミング環境「Accelerator Exoskeletons」の重要技術として、SVMを挙げた。

　さらに、今年3月のGDC(Game Developers Conference)では、「MYO」という名称で、この技術をデモしていた。Rattner氏が10月の来日時の記者会見でデモしたのは、GDCの際のデモと同じものだった。11月のSC09でも同じデモを見せたようだ。MYOの「Mine, Yours, Ours」は、もちろんSVMのアクセス権を示している。

Accelerator Exoskeletonsモデル	デモの概要

　Rattner氏がスパコン時代から育ててきたSVM技術には、そもそもアプリケーションレベルでどういう利点があるのか。Larrabeeについて言えば、複雑なデータ構造を、そのままCPUと共有できる点にある。

　「問題は、汎用CPU側のメモリ上にある多くの複雑なデータ構造を、アクセラレータに転送しなければならない点にある。通常は、CPUとアクセラレータ、これはGPU、FPU、FPGAなど全てを含むが、その間に、複雑なデータ構造をそのまま転送する手段がない。

　そのため、CPUは、まずデータ構造を分解してフラットにして、PCIなどのインターコネクトを通じて転送し、その上で、アクセラレータ側でコンピュテーションのために再構築しなければならない。さらに、多くの場合、同じことを逆方向にもしなければならない。つまり、アクセラレータがデータをアップデイトしたら、その構造を分解して、CPUに送り返して、再構築する必要がある。

　我々は、実際に、GPU上で実行する軟体物理シミュレーションのコードを調べてみた。このケースでは、軟体のデータは、CPUからGPUへと転送される。

　その結果、我々は、物理エンジン自体は完全にGPUアーキテクチャに向いているにもかかわらず、データ転送に大きなオーバーヘッドがあることを発見した。データ構造を分解して、移動させて、再構築して、プロセスした後に、再び逆の作業する。これが、スピードを大きく低下させてしまう。

　また、この仕組みでは、エラーが産まれるケースが極めて多い。非常に複雑なデータ構造になると、データのフラット化や再構築の過程で不正確な結果が生じる可能性が高いからだ。しかも、そうしたエラーは、見つけることが極めて難しい。エラーは、開発作業の生産性を下げ、時間がかかるものにする。ゲームプログラマを例にとると、データ構造のプログラミングだけに何日もかけている。我々は、そうした労力を削除できれば、生産性で大きなジャンプとなると考えた」(Rattner氏)

　最大の問題は、GPUやLarrabeeでプロセッシングさせたいデータが、しばしば複雑な構造を持っている場合にあるという。もちろん、この問題はアプリケーションによって異なるが、大きなボトルネックの1つであることは間違いない。そして、構造があまりに複雑であるがために、GPU側へとオフロードすることが事実上不可能な処理も存在する。

なぜメモリがインターフェイスを取るのか	軟体の物理エンジン

　Intelは、SVMを、この問題を解決する手段として持ち込んだ。Rattner氏は次のように説明する。

　「そこで我々は、LarrabeeがIA (Intel Architecture)プロセッサであるという利点を使うことを決定した。Larrabeeは、IA CPUのメモリ管理マネージメントのフル機能を備えている。そのため、NehalemやWestmereといった汎用プロセッサとの間で、非常に効率的なSVMを構築することができる。

　さまざまなメモリページと共有スペースへのアクセスの交換によって、我々は両方のタイプのプロセッサに効果的にデータにアドレスできるようにできる。日常的なデータ構造の分解と構成をすることなしに、データの共有が可能だ。

　具体的には次のように働く。CPUのプロセッサがある共有のメモリページを「Own」している場合を考えてみよう。そのページは、もう一方のプロセッサ、例えばLarrabeeから保護されている。CPUが、Larrabeeに対して明示的にアクセス権を与えるまで、Larrabeeはそのページにアクセスができない状態が続く。

　そして、CPUがそのページでの作業を終えると、「OK、こちらはメッシュデータを含んでいるページ全てでの、メッシュのリフォーム作業を終えた。これからは、これらのページ全てはLarrabeeのものだ」と宣言する。CPUは、もうそれらのページへのアクセスを行なわないことがメモリ管理ユニットに確約される。

　すると、Larrabeeは、それらのページにアクセスできるようになる。ページからデータを読み込み、物理シミュレーション計算を行ない、データ構造をアップデートする。すると、今度はLarrabeeが「OK、こちらの処理は終わった、これらのページのアクセス権をCPUに戻す」と宣言する」

　CPU側がセットアップしたデータ構造が、そのままGPU側からバーチャルメモリスペース上のデータとして見えるため、話は簡単だ。アクセス権さえCPU側から与えられれば、データ構造を崩すことなく、直接取ってくることができる。

　この仕組みは、ちょっと聞いただけでは、普通のシェアードメモリシステムのように聞こえる。しかし、実際には大きな違いがある。まず、目立つのはメモリのコヒーレンシを保つ単位がページである点と、ソフトウェア処理あるいは部分的なソフトウェア処理が可能である点だ。

　「ポイントは、ページレベルでコヒーレンシを維持することだ。もちろん、コヒーレンシ維持のためのコストは払わなければならない。しかし、データをシェアするために必要な計算量は非常に小さい。オーバーヘッドはそれほど大きくはないだろう。コストに対して、適切なパフォーマンスが得られるだろう」とRattner氏は説明する。

　通常のシェアードメモリでは、CPUのキャッシュブロック単位にコヒーレンシを保つ。「このキャッシュブロックは、今、こちらのCPUが読み込んでいるから、他のプロセッサが書き換えることはできない」といった管理を行なう。ところが、シェアードバーチャルメモリの場合は、それをメモリページ単位で行なう。管理の粒度がずっと大きいため、一定の条件下ではシェーアドメモリの管理が容易になる。粒度が大きいため、ハードウェアでコストをかけて制御しなくても性能を出せる。

SVMのメモリ管理	SVMでのソフトウェアアーキテクチャについての提案

　それから、もう1つの違いは、これがバーチャルなシェアードメモリである点。実際には、ランタイムソフトウェアが管理するシェアードバーチャルメモリのアドレス空間が、CPUとLarrabeeの両方の同じ物理メモリアドレス空間上にマップされる。そして、CPUの物理メモリとLarrabeeの物理メモリとの間で、コヒーレントがページレベルで保たれる。SVMは2つの物理メモリにまたがり、片方のメモリページはもう片方の同じメモリページのキャッシュのように振る舞う。

　Rattner氏の説明に沿って説明すると、次のようになる。CPU側が、CPUの物理メモリ上にマップされたSVMの、あるページ上に存在するデータをセットアップする。その間、Larrabee側の物理メモリ上の同じアドレスは、Larrabeeがアクセスができないようにブロックされている。CPU側がデータのセットアップが終わると、ランタイムが2つの物理メモリ間で、そのメモリページのコヒーレンシを取る。実質的にデータが転送され、CPUがアクセス権を放す。すると、Larrabee側のアクセスが許されるようになる。ランタイムがハンドルしているので、OS自体の対応は必要がない。

　そして、ここでLarrabeeがIA (x86) CPUである点が生きてくる。Larrabeeは通常のIntelのIA CPUと全く同じメモリ管理機能を持っている。メモリページサイズや構成といったページテーブルフォーマットが同じだ。そのために、Intelが非IAコアを想定して開発したAccelerator Exoskeletonsに見られるような、ページテーブルの変換メカニズムが必要ない。今までIntelがAccelerator Exoskeletonフレームワークとして発表してきたものより、さらにシンプルな制御になる。

　また、今回の場合は、Larrabeeにオフロードしようとしている処理がデータ並列であり、大きなデータの塊に対する処理である点も有利に働く。データとコンピュテーションの粒度が大きいため、コヒーレンシを取るメモリの粒度が大きくてもフィットしやすいからだ。データの粒度が小さいと、ページベースのコヒーレンシでは非効率になりかねないが、Larrabeeではその問題はない。

MYOプログラミング環境	多様なヘテロジニアスの構成

　こうしてみると、IntelはLarrabeeを導入するための技術的な下準備は着々と整えつつあることがわかる。デベロッパによっては、SVMの1点だけでもLarrabeeが欲しいと感じる場合もありそうだ。にも関わらず、製品戦略上ではLarrabeeの動向が見えない。このアンバランスが、Intelの現在の戦略の揺れを示している。