【IDF Fall 2007レポート】

会期：9月18日～20日(現地時間)

会場：San Francisco「Moscone Center West」

●ヘテロジニアスマルチコアの時代へ

現状では、アクセラレータは、OSの管理下でドライバなどを介してアプリケーションから利用する

　次世代以降のIntel CPUやこれを使うプラットフォームの特徴は、アクセラレータやGPGPUなどの異種コアの存在である。Intelは、PCI Expressを使ったGeneseoを提案し、Tolapaiでは、QuickAssistアクセラレータを搭載する。このようなアーキテクチャでは、従来型のプログラミングが行ないにくくなる。特に、通常のコア以外に演算機能のあるコアやアクセラレータを持つヘテロジニアスなシステムでは、複数の命令セットで記述されたプログラミングコードを扱う必要がある。

　Intelがこれらの製品の出荷を開始すれば、これまで、特殊な用途にしか使われておらず、特定の開発者しか扱わなかったヘテロジニアスなシステムを一般の開発者も扱う機会が増えることになる。

　問題になるのは、プログラムの開発手法やプログラミングモデルである。たとえば、ソニーのCellの場合、PPEとSPEはメモリ空間や命令コードが異なっているため、SPEで実行されるプログラムと、SPEの実行環境を準備し、実行を指示するという形式のPPE用プログラムを作る。もちろん、これをサポートするためのライブラリなどは用意されるが、PPEとSPE用の2種類のプログラムを作らねばならない。アクセラレータの場合も同じで、アクセラレータで動くプログラムと、IAコアで動くプログラムを作らねばならない。

　もう1つの問題は、コアそれぞれが独立しているため、タイミング的な問題や、他のプログラムとの関係(もしかしたらほかのプログラムもアクセラレータを使いたい/使っているかもしれない)などがある。PLAYSTATION 3では、仮想化を使って1つのプロセスがSPEを占有しているかのように扱えるようにしてある。実際には、背後で動くハイパーバイザーが、PPEのコンテキスト切り替えなどに応じて、SPEの処理を切り替えていく。

　このように、2つのアーキテクチャが異なるコアがあり、それぞれのメモリ空間が違う場合、他方のメモリ内にあるデータを相手に渡すには、一定手順の処理が必要で、CやC++といった言語では通常やっているように単にポインタを渡せばいいというわけにはいかなくなる。

　そうなると、受け渡しのための領域の確保や、その領域に対する排他制御、そのほかいろいろなものをアプリケーション自身が管理しなければならなくなる。ただ、一方で、こうしたアクセラレータを低いオーバーヘッドで使いたい(最も考えられるのは、アクセラレータを使うためのライブラリなどであろう)といった用途もある。

●ヘテロジニアスマルチコアのための言語

　こうした問題に対して、Intelが研究しているのがAccelerator Exoskeletonと呼ばれるシステムである。この言語では、IAコア(汎用コア)自体に、他の専用コアが組み込まれているかのうようなプログラミングモデルを提供する。つまり、アクセラレータの機能をMMX/SSE命令のような感じで利用することができるようになる。なお、このシステムでは、CやC++を使い、VisualStudioやEclipsといった従来のIA用開発環境をそのまま利用できる。

Exoskeletonは、アクセラレータの機能をIAプロセッサの一部機能であるかのように見せかけることでプログラム開発を容易にする	PCI Expressで接続されるGeneseoを使ったアクセラレータは、このように複雑な階層を使って管理されている。しかし、Exoskeletonを使うことで直接アクセスしているかのようにプログラミングすることが可能になる

　MMX/SSE命令は、専用のレジスタを使うなど、通常の演算命令と比べるとちょっと変わっている。これは、浮動小数点演算は、もともとは、メインCPUとは別ハードウェアだったコプロセッサで処理していたからで、MMXやSSE命令は、これを拡張したものだからである。

　コプロセッサとは、メインCPUの命令を拡張するための機構で、メインCPUの一部となって動作するものをいう。アクセラレータなどとの最大の違いは、コプロセッサ用の命令セットは、あらかじめ、メインCPUの命令セットの中に確保されており、フェッチやメモリアクセスは、メインCPU側が行なうようになっている。また、コプロセッサ命令は、そのまま通常命令と混在させるこができる。

　これに対して、アクセラレータや専用処理コアは、データアクセスは自身が行なうか、メインCPU(汎用CPU)がソフトウェアで行なう。また、命令は、完全に独立しており、メインCPUの命令ストリームとは別になっている。

　Exoskeletonでは、前述したように、アクセラレータなどを汎用コアの一部であるかのように見せる。つまり、スケジューリングは、汎用コアと同じであり、汎用コアで実行しているプログラムからは、あたかもこれを占有しているかのように見える。

　たとえば、Geneseoのような場合には、これをカーネルモードドライバと、各ユーザープロセスに置かれるユーザーモードドライバを使って行なう。ユーザーモードドライバが各プロセスからのリクエストを受け付け、カーネルモードドライバが、実際の実行の指示や、コンテキスト切り替えなどを行なう。

Exoskeletonで記述されたコードは、IAとアクセラレータプログラムを一緒にしたFat Binaryにコンパイルされる。これを実行時にランタイムがIAコアとアクセラレータ用の分け、ランタイムがアドレス変換やデータ転送を行なう

　このようにすることで、アクセラレータの機能を各IAコアの一部機能として利用できるようになる。ただし、命令コード自体は混在させることはできず、それぞれが独立したバイナリとなるが、Exoskeletonでは、これを1つのファイルにまとめるFat Binary形式とする。

　さらにこれにランタイムライブラリを組み合わせ、実行時のIAコア側のプログラムとアクセラレータ側のデータ交換を行なわせる。これにより、IAコア側は、自身のメモリ空間内に置いたデータを直接アクセラレータに渡すことができるようになる。

　このようにすることで、Exoskeletonは、プログラム中で、アクセラレータをCPUの拡張機能として使うことができ、また、スケジューリングやデータ転送などを管理したり、記述する必要がない。

　実際のソースプログラムでは、インラインアセンブラのような形で、アクセラレータ用のコードを直接記述しておけば、IAコア、アクセラレータ用のマシンコードを含むバイナリが出力される(Fat Binary)。

　この方式では、直接アクセラレータを制御するマシンコードを記述できるため、低レベルの記述が、低いオーバーヘッドで実現可能になる。しかも、開発のやり方やプログラミングモデルは従来と同じままで、複数の異なるCPUを扱うといった面倒さがかなり軽減される。

　実際の製品として登場するのはまだ先ではあるが、ヘテロジニアスであるがための問題をある程度解決できており、特にシステム系のプログラミングでは割と使われることになるのではないかと思われる。

□IDF Fall 2007のホームページ(英文)
http://www.intel.com/idf/us/fall2007/
□関連記事
【9月20日】【IDF】ポール・オッテリーニCEO基調講演
http://pc.watch.impress.co.jp/docs/2007/0920/idf03.htm
【4月17日】【海外】Intelがアクセラレータ向けI/F「Geneseo」を公開
http://pc.watch.impress.co.jp/docs/2007/0417/kaigai351.htm

□IDF Spring 2007レポートリンク集
http://pc.watch.impress.co.jp/docs/2007/link/idfs.htm

(2007年9月20日)

[Reported by 塩田紳二]