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に代表される命令を多用する話となる。 |
こうしたところに向けたIntelの開発プロジェクトがSTMとCt、Exoである。このうちExoは先にExoskeletonとしてこちらでレポートしているのでここでは割愛するとして、STMとCtについてもう少しレポートしたい。
STMのベースとなるのは、Transaction Memoryである。昨年のIDFで紹介された、Transaction Memoryをソフトウェア側で実装する、という試みである。基本的なアイディアは、複数のThreadからのメモリのアクセス時に、そのTransaction管理を行おうというものであった。要するに複数のThreadから書き込みがあった場合、そこでCommitなりRollbackなりを掛けることで、予期せぬ値が書き込まれるのを防ごうというものだ(Photo38)。STMは、これをSoftwareで行う(なので、STM:Software Transaction Memoryと名づけられた)ものだ(Photo39)。具体的には? というとPhoto40に示すとおりで、プログラミング的には__tm_atomic{}と呼ばれるディレクティブを追加し、この中に記述した部分が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を広く求めている状態だ。
アイディアとしては面白いのだが、具体的にこれを内部でどう実装しているか、に関しては今回は一切発表がなかった。筆者が察するには、RuntimeのどこかでMemory管理を行うロジックが入っており、__tm_atomic{}ディレクティブ内部のアクセスは全てこのロジック経由でアクセスを行う様にしてあり、ここでアクセス調停を掛けるというあたりではないかと思う。これはCritical Sectionをアプリケーションプログラマが意識する必要がないという観点では秀逸であるが、Commit/Rollbackモデルからすると一歩後退という観は否めない。あと、メモリ管理部分が最終的にボトルネックになりそうな気がする点もちょっと懸念事項だ。