ToDo:
SAD/Tkinter周りで Backslash escape問題(GCC 4.2.x以前では発症しませんが)を修正。 原因は、OBJ_BACKSLASH_ESCAPEの更新し忘れ Orz
これは、バックポート必要だよね(たぶん Tru64には影響する)
KEKB HER Crab Opticsを使った Tracking(RFSW/RAD/FLUC付き)で 疑似乱数発生器の置き換え前後を比較する。
RADと FLUCで放射減衰と量子励起による拡散に疑似乱数列が使われているので、 コードの置き換え(PRNG本体の置き換え&iseedのインライン化された線形合同 法を関数呼び出しに置き換えた)に失敗している部分をなめると結果に 違いが出るはずというのが、試験動機です。
試験内容は、粒子数1000個の初期分布を与えて 1000ターンのTrackingを行い結果と消費CPUタイムを比較する。
まず、疑似乱数発生器に Random/SAD pluginを使った場合
code | result | time/turn |
---|---|---|
CVS MAIN | reference | 5.9914 |
amorita | match | 5.9528 |
amorita-noarray | match | 6.1047 |
使用された範囲のコードでの疑似乱数列参照の書き換えは成功している模様。
amoritaと amorita-noarrayの実行速度差を見ると、 疑似乱数生成ループを新設したtran_array_,tgauss_array_ (乱数配列を取ってくるAPI)へ置き換えたが速度向上に 寄与しているように見える。 また、インラインルーチンを関数呼び出しへ置き換えことに伴う速度低下を 乱数配列生成APIによる速度向上でカバーできたようである。
続いて、SeedRandom[]を使って疑似乱数列を Random/SFMT pluginに切替えた場合
code | result | time/turn |
---|---|---|
CVS MAIN | mis-match | 6.0000 |
amorita | reference | 6.0035 |
amorita-noarray | match | 6.2041 |
CVS MAINの疑似乱数発生器は線形合同法固定(Random/SAD相当)なので 一致しない、きちんと違う疑似乱数列が適用されていることが判る。
また、処理速度の悪化の問題はないようである。
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記