共有とか分散とか

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

ハードウェアプリフェッチ

ハードウェアプリフェッチの分析方法としてSrinivasanらによるPTMT: Prefetch Traffic and Miss Taxonomy(*1)という手法が有名です。古典的な評価では、Coverage（本来ミスだったメモリアクセスの何割がプリフェッチで救えたか）とAccuracy（プリフェッチのうち何割が有効なプリフェッチだったか）でしか評価してなかったわけですが、PTMTではプリフェッチを行った場合と行わなかった場合の両方のケースについて同時にシミュレーションを行い、プリフェッチにより取得したキャッシュライン、プリフェッチにより追い出されたキャッシュラインそれぞれがキャッシュヒットとなったか、あるいは追い出されたかを調べて分析します。例えばあるプリフェッチにより取得したキャッシュラインがヒットしたとしても、追い出したキャッシュラインがミスを引き起こしてしまっては意味がないわけです。

これがマルチプロセッサ（SMP）環境になると、キャッシュのコヒーレンス制御が影響してきます。プリフェッチにより早期にデータを取得しても、その後のリモートプロセッサのストアによりせっかく取得したキャッシュラインをINVALID化する必要があります。このような効果も考慮したのがJergerらによるMPTMTと呼ばれる手法(*2)です。

さらにマルチコア（CMP）の場合にどうなるかというと、これはちょっと複雑で、キャッシュを共有する効果ってのも考える必要が出てきます。SMPの時のようなコヒーレンス制御の影響より、アグレッシブなプリフェッチを行った際の汚染の影響の方がクリティカルになるので、CMPならではの新しい問題、というよりはシングルコアの頃に研究されていたキャッシュのAccuracyを高めるといった手法が効果的になってくるみたいですね。そんなわけで、プリフェッチをフィルタリングして最小限度の質の高いプリフェッチを発行する、というのがプリフェッチ研究の1つの柱としてあるようです。プリフェッチのターゲットアドレス、あるいはプリフェッチを発行したPCをキーとしてプリフェッチが有効だったか否かのヒストリーをとり、そこから先は分岐予測と同じストーリー。やっぱりgshareとか使うと良い結果が出たりします(*3)。学習が入ってくるとなると、学習の種としてPTMT的な分析手法も重要になってきます。実際にインプリできるハードとして、1回の実行でどれだけ効果的に学習できるか、ですね。ちょっと前にキャッシュのセット方向の情報を使って１回の実行で様々なキャッシュサイズを想定したミス率変化グラフを書くって手法を聞きました。なんか同様のうまい方法を思いつかないかなぁ・・・なんて考えてたりしますが、一朝一夕にはいきません。

整数系のベンチマークでは、RDS: Recursive Data Structuresに着目した研究成果(*4)もあります。リストとかを辿る処理を検出して先読みする類いのやつです。この手の構造体のポインタを読み出すLoad命令をIPL: Induction Pointer Loadと呼ぶらしいです。なんか、アーキテクチャ屋さんにとっては紛らわしい略語ですね。この手の研究は学生の頃にもちょろっと調べた記憶があります。Sohi先生のとこでもやってたような。こっち方向の研究はあまり筋がよくない事が多いですよね。

*1: A Prefetch Taxonomy
*2: Friendly Fire: Understanding the Effects of Multiprocessor Prefetches
*3: Reducing Cache Pollution via Dynamic Data Prefetch Filtering
*4: Characterization of Repeating data Access Patterns in Integer Benchmarks

POWER6の物理設計

あまり新しい話題でもないですが、IBM Journal of Research and DevelopmentにてPOWER6の特集が組まれていまして。その中でも気になっているのがIBM POWER6 microprocessor physical design and design methodologyって記事です。

図2に設計フローが紹介されているんですが、これによればPOWER6はVHDLで論理設計を行っているんですね。今までゲートレベルで設計していたプロセッサメーカも徐々にRTL設定にシフトしてるって事でしょうか。

面白いのが、RTLへ移行したタイミングで周波数が一気に上がって、でも複雑なOoO制御は止めて・・・という、直感とは違う結果が出ていること。後者は電力から来る要求で、そもそもアーキテクチャをダイナミックに変更できたというのがRTLの成果なのかもしれませんが。周波数に関しては、ゲートレベル設計が有利というのはもはやアセンブラプログラムが速いってのと同様の幻想なのかもしれません。

System z10の特集はまだだけど、同じような傾向があるのでやっぱりRTL設計なのかな。

気迫と勘だけで作ってる某社とは違って、きちんとサイエンスしてるな、と思います。

追記：設計フローの基本はPOWER4の頃から変わってないとの事で、POWER4の特集を調べたら当時からVHDLで論理設計をしているようでした。ただ、物理設計周りの人手でやっていた部分がだいぶ自動化されたようですね。