どなたかに、複雑なモデルで実験してほしいです(自分には適当なものが思いつきませんでした)。%timeitがマルチスレッドの場合は時間×スレッド数をはじき出すかと思い、timeモジュール+自分の時間間隔でも計測しましたが、やはり遅かったです。サンプリング時にhtopコマンドでCPU利用数を見ていましたが、高々200%ぐらいになるだけで、本来理想としていた800%等になることはありませんでした。(@hankagosa)さんから次のような指摘をいただきました。2018年10月10日Stanのmap_rect使うchain内並列化は、たぶんデータ点が10万ぐらいはないとご利益ないような...。その10万個を切って並列処理する感じ。2018年10月10日というわけで、軽く実験してみます。モデルは簡単な一次回帰です。シミュレーション的にデータを10万点作成します。以下のモデルはThreadingで必要なmap_rect関数が使われていないので早くなるはずはありません。STAN_NUM_THREADS=4で投入してみました。計測方法は同じで7回の平均です。5.71うーん、ちょっとだけ早くなっています。t検定で有意差が出る気がしません。データ数を増やせばより効果があるのではないでしょうか。何れにせよ、小標本なのにThreadingが必要なほどサンプリングで時間がかかりすぎている場合は、モデルが適切でない可能性をまず考えるべきです。丁寧に、メカニズムを考えて、モデルを改良していきましょう!追記(2018-10-18)discourseで質問したところ、ThreadingやMPIのような操作をするためには、データやモデルをそれ専用に作り変える必要があるとの回答を頂きました。試せていませんが、cmdstanを使った例についてはこのリポジトリが参考になります。追記(2018-10-19)map_rect用のモデルを別に書いて実験しました。ついでにデータ数は合成に100万まで増やしてみました。実験につかったnotebookはこちらです。5.71なんと、やっぱり遅くなってしまいました。top等のコマンドで確認してもCPU使用率が100%までいかないんですよね。別の原因がある気がしますが、現状不明です。今回は第6章の章末問題に取り組んでいきます。今回は第5章の章末問題に取り組んでいきます。»プロフィールid:ajhjhaf検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事StanのMAP推定の収束判定についてのコードを読むDockerでPyomo+Jupyterlabの実行環境をパッケージ化こうしてGoogleに落ちたScipyでBrunner-Munzel検定Stanで非閉型な逆関数を含む分布のモデリング月別アーカイブはてなブログをはじめよう!ajhjhafさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。