Cluster OpenMP

分散メモリ環境で共有メモリ型の並列プログラムを実現する環境としてIntelのCluster OpenMPって機能があるようです。その名の通り、PCクラスタなどの環境でOpenMPによるプログラムが可能となります。Intel Compiler v9.1以降でサポートされているようですが、完全にOpenMP互換というわけではなく、共有する変数にsharable指示子を付ける、などの移植作業は必要なようです。Intel以外の会社の出しているベンチマークを見ると、あまり性能良さそうではないのですが。。。Relaxed Consistency Modelを採用しているようです。Google File SystemもやはりRelaxed Consistency Modelですね。やはり分散環境でそれなりの性能でCoherenceをとろうとしたらRelaxedしかないのかな。
Clustern OpenMPのsharable heapがどのような実装になっているのか調べてませんが、SVM的な事をやってるんでしょう。SVMに関しては、コンパイラの介入を許す場合、コンパイル時に共有メモリアクセスを検出して、前後に特殊な命令列を挟む、などとしてfalse sharing missを減らすようにする工夫があるみたいです。とりあえず滝田さんの論文を見る限り、Shasta(*1)やBlizzard-S(*2)という研究があったようです。どちらも1996年ですね。
共有メモリだがCoherence制御はハードウェアでは行わない。コヒーレンスをとりたい場合はatomic指示をしてTransactional Memory的な制御をする、みたいな方向で新しい並列モデル、作れませんかね。いや、共有メモリって部分はなくした方が良いのかなぁ・・・不正なプログラムの挙動を保証できなくなって、潜在的なバグを作り込みやすい環境になっちゃうし。

*1: A Low Overhead, Software-Only Approarch for Supporting Fine-Grain Shared Memory
*2: Parallel Computer Research in the Wisconsin Wind Tunnel Project

共有とか分散とか

メニーコア化が進むと、いずれキャッシュコヒーレンス制御が難しくなってくる。
BlueGeneにはじまる超並列計算機環境が既にそうであるように、近いコアとは共有メモリ、遠いコアとは分散メモリ、といった環境にならざるを得ない。こういった環境でプログラムしようとすると、プログラマは共有メモリと分散メモリ、OpenMPとMPIといったように、２つの層を意識した複雑なプログラム開発を強いられる。これは大変、という事でもっともナイーブな解決策は、共有メモリであっても一貫してMPIを使うという方法。この方式だと共有メモリが利用できたとしても、MPIを通して、高速に通信可能な分散ノードとしてしか見ない。けどまぁ、どのみち外側の分散メモリ環境が並列計算全体を律速するので、よほど物理的なノード構成、ネットワークトポロジを意識して最適化しない限り、これでほとんど問題はない。というか、MPIを使っている時点で、そこまで繊細なチューニングはできない。
ただ、一般的な用途を考えた場合、SMPですらマルチコアが一般に浸透するまでこれだけ時間がかかったのだから、メニーコア環境をMPIで使いこなすエンドユーザ環境というのはあまり想像できない。となると、やはり今後の流れとしては、ハードウェアで一部のコア群のコヒーレンス制御を行い、コア群間のコヒーレンス制御は必要に応じてソフトウェアで行うことになるのかなぁ・・・。そうするとShared Virtual Memoryが再び脚光を浴びるようになる気がしないでもない。たぶんOSレベルで機能を取り入れるべきで、OSの仮想記憶管理と統合しちゃう。んでまぁ、コンシステンシモデルはどうするかと言えば、Transactional Memoryと統合しちゃって。TMの世界が主流になれば、そもそも細切れにコヒーレンス制御を行う必要はなく、Transaction単位でメモリの同期を行えば済むようになる。あとはデッドロックをどう考えるか、なのかなぁ。