ToDo:
このまえ、トラッキングコードの呼び出し頻度の高いルーチンを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間同期が必要(nowait 並列化の場合)となり、統計処理は reduction演算で実装する必要がある。 注意が必要なのは、アパーチャー処理に伴う、粒子分布入れ替えは、 Thread間同期と排他制御が必要。
書き換え範囲は、かなり広いと思われる。 やはり、branchを作って作業か？
Python3への移行とImageMagick7への移行が始まっているが色々問題あり
手持ち環境の実行環境のPython2依存性の残りは...
次に作るもの
性能に関しては、オリジナル実装では実数リスト等のケースで比較ルーチンがソートエンジン内に展開されているのに対して、qsort(3)等では関数呼び出しが必須となる点は不利だが、実数リストコンテナではインデックスソートではなく、出力配列を直接スワップすることで間接参照コストを低減する最適化を行ったため、N = 2^24でのテストでは、整列・逆整列・準整列・ランダムの各パターンで、オリジナル実装よりも概ね良好な性能が得られている
ISO C++がテンプレート版sortがつかえれば、比較ルーチンのinline展開により更なる改善が得られると思われる
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記
_ Y氏 [Qの電源が故障の模様。復帰は未定 よって秋葉には行っては駄目よん (^^]
_ Y氏 [う、もしかして何かわからないけど博麗神社例大祭ってやつにいくのかな？]
_ Y氏 [基板交換で治った模様。 現在初期化中。 コレクションは小磯さんがやってくれますので、ゆっくり遊んできてね (^^]