Orz日記 by Akio Morita

_ [SAD]ビームラインコンパイラ

Trackingを速く出来ないかと、いろいろ検討中であるが、ホットスポットになっ ている末端サブルーチンのOpenMP化はthread forkコストが処理負荷を下回る しきい値が高すぎて実用的では無い模様。(DynamicApetureSurvey[]などを想 定)

現在考えてるのは、ビームラインパラメータによる分岐を実行時ではなく Tracking初期化時に行うというアイデア。 要するに、部分コンパイルとかJITと呼ばれるもので、 同じビームラインを繰り返し評価するなら パラメータに基づく分岐ペナルティーの消去で コンパイルコストを賄えると思われる。 また、ビームラインにそったエレメントのdispatchについても 展開してしまえば stack frameのpush/pop操作と call/returnコストを 削減できるはず。

また、連続するDRIFTの結合や MARKエレメントの削除なども行えるので Trackingの写像評価回数自体の削減も期待できる。

_ [SAD]OpenMP化について考察

このまえ、トラッキングコードの呼び出し頻度の高いルーチンをOpenMP化した ら、性能が劣化した件について考察してみた。

まず、OpenMPが使う POSIX Threadに関してだが、 Process fork cost >> Thread fork costの関係は成立している。 しかし、NPARAモデルではビームライントラッキングにつき一回 Process forkを行う。それに対して、末端ルーチンでのOpenMP化は、 エレメント毎に Thread forkが発生する。 ここで、KEKB Latticeを想定すると QUADや DRIFTエレメントの数は 100〜1000のオーダー存在する。 したがって、Thread fork costが 1000倍以上安くないとペイしないという 結論にたどり着く。

したがって、OpenMP化する場合は、

• ドライバー側で Thread forkする
• エレメントサブルーチン側で、omp doな並列化を行う

必要がある。 また、トラッキングルーチンが呼び出す関数には、再突入可能であることが 求められる。相互作用計算や統計処理の前には、Thread間同期が必要(nowait 並列化の場合)となり、統計処理は reduction演算で実装する必要がある。 注意が必要なのは、アパーチャー処理に伴う、粒子分布入れ替えは、 Thread間同期と排他制御が必要。

書き換え範囲は、かなり広いと思われる。 やはり、branchを作って作業か？

_ [雑記]ファイル消失事故

ファイルサーバー上のOther writableなファイルが消失する事故が 発生している模様。

まあ、Other writableな段階で何が起こっても不思議はないけどね...

_ [FreeBSD]8.1-BETA1

BETA1が出たようです。

8.1へのリリースエンジニアリングは、順調みたいだねぇ