Programming Update

最後にこちらの話題に少しふれておきたい。といっても、こちらの話とは全然異なっており、Tera Scale Computingに関係するR&D寄りの話である。要するにMany Coreを生かすPallarel ComputingのためのProgrammingという話だ。このParallelismの分類方法にはいくつかの切り方があるが、ここではTask level parallelismとData level parallelismという観点で論じている(Photo34)。これを支える方法として、既にいくつかの手法は実際に存在するが(Photo35)、ただこれらが普及しているとは言いにくいのも実情だ(Photo36)。

Photo34:Task level parallelismは、要するにMulti-Threadを多用する話となり、Data level parallelismはSSEに代表される命令を多用する話となる。

Photo35:これとPhoto34の手法は、今のところ明確に区別できない。例えばOpenMPにおける最適化手法のいくつかは、Data level parallelismをコンパイラレベルでTask level parallelismに分解するという方法になる。完璧な意味でのData Parallelは、MATLABを使ったシミュレーションとか、大規模ベクトル演算位しかないのが実情だ。

Photo36:直接的にPhoto35とこれが繋がるわけでは無いが、要するに新しい言語というか開発環境が出てきても、直ぐに普及するわけではない、という事をここでは言いたいようだ。

こうしたところに向けたIntelの開発プロジェクトがSTMとCt、Exoである。このうちExoは先にExoskeletonとしてこちらでレポートしているのでここでは割愛するとして、STMとCtについてもう少しレポートしたい。

Photo37:あくまでこれはまだ研究途上の成果というレベルであって、本格的にこれで行ける、というものではないようだ。一番実現可能性が高いのはExoのようだが……

STMのベースとなるのは、Transaction Memoryである。昨年のIDFで紹介された、Transaction Memoryをソフトウェア側で実装する、という試みである。基本的なアイディアは、複数のThreadからのメモリのアクセス時に、そのTransaction管理を行おうというものであった。要するに複数のThreadから書き込みがあった場合、そこでCommitなりRollbackなりを掛けることで、予期せぬ値が書き込まれるのを防ごうというものだ(Photo38)。STMは、これをSoftwareで行う(なので、STM:Software Transaction Memoryと名づけられた)ものだ(Photo39)。具体的には? というとPhoto40に示すとおりで、プログラミング的には__tm_atomic{}と呼ばれるディレクティブを追加し、この中に記述した部分がCritical Section同様に扱えるという仕組みである。

Photo38:ただし、DBの手法では一旦データを書き込んだ後でCommitを掛け、その戻り値でTransactionが成立したか失敗(Rollback)したかを判断する形になる。これをどうやってハードウェアで実現するかという点と、どの程度の粒度で制御を行うべきか(Bytes/bit単位では細かすぎるだろうし、Page単位では大きすぎる様に思われる)というあたりが課題となっている。

Photo39:基本的なアイディアは、書き込みを保留してからロックを確認するのではなく、先にロックしてから書き込むという、言わばCritical Sectionの一種である。

Photo40:単に__tm_atomicというディレクティブを定義しただけではなく、ランタイム側で色々やっている模様。それにしても、このディレクティブであまり大きな処理を囲ってしまうと、今度はむしろオーバーヘッドが大きくなりそうで、いっそCritical Sectionの方がマシだったということにもなりかねない。このあたりをどう切り分けるか、も難しいところだ。

何がCritical Sectionと異なるのか? という部分に関してIntelが公開した説明はこちら(Movie01)。要するに、

  • メモリ領域全体をCritical Sectionで管理する(通常のLock)のは確実かつ容易だが、Shared Memoryの利用効率が落ちる
  • メモリ領域を細かく分割してCritica Sectionで管理する(Fine Grain Lock)と利用効率は上がるが、管理が大変になる上、もしLockの場所を間違えるとConflictが発生しやすい
  • Transaction Memoryは干渉が起きそうな時だけ、自動的に調停を行ってアクセス順を定めるので、問題がおきにくい

というアイディアである。既にIntelはこのアイディアを実装した、Intel C++ STM Compilerのプロトタイプ版を公開しており、これを使ってのFeedbackを広く求めている状態だ。

動画
Movie01 (WMV方式 45秒 1.4MB)

アイディアとしては面白いのだが、具体的にこれを内部でどう実装しているか、に関しては今回は一切発表がなかった。筆者が察するには、RuntimeのどこかでMemory管理を行うロジックが入っており、__tm_atomic{}ディレクティブ内部のアクセスは全てこのロジック経由でアクセスを行う様にしてあり、ここでアクセス調停を掛けるというあたりではないかと思う。これはCritical Sectionをアプリケーションプログラマが意識する必要がないという観点では秀逸であるが、Commit/Rollbackモデルからすると一歩後退という観は否めない。あと、メモリ管理部分が最終的にボトルネックになりそうな気がする点もちょっと懸念事項だ。