バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はPythonでマルチプロセス化したコードを確認した。
Pipe関連のコードが大きな変化点。
sin波は描画側のメインプロセスだと結局描画負荷の影響を受けるので、
FMU側のサブプロセスで実施している。
今回は、これらの負荷の影響を実際に確認してみる。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
まずは動作させてみる。
前回でコード修正は終わったから早速動作させてみるよー。
おー?
結構キレイな感じなった・・・か?
でも、よくよく見ると少し波形が崩れてる箇所があるねー。
負荷を確認している。
じゃー、CPU負荷もプロットしてみよう。
オッケー。
これは・・・。
負荷は下がったけど、それでも50msくらいは待たされる時があるみたいだなー。
この50msはなんだろう?
マルチプロセスだから描画側のメインプロセスの影響はほぼ無いと思うんだけど・・・。
試しにpauseで描画を止めて見たけど、負荷の状況は変わらなかったし。
たぶんプロセス間通信のオーバーヘッドだな。
まじか。
これってもしかして回避不可?
例えば他のプロセス間通信をすると行けるとか無いのかな?
実は私の方もちょっと実験はしてるんだが、
結論から言うとどのプロセス間通信を使っても似たようなオーバーヘッドは乗ってしまうな。
ガーン。
ということは実験失敗かー。
違うな。
ってことは!
「それは失敗じゃなくて、その方法ではうまくいかないことがわかったんだから成功なんだよ。」by トーマス・エジソン
おーい!
まぁこういうこともあるさー。
行き当たりばったりでやってるんだもん。
というわけで、
今後の実験はマルチプロセス版じゃない方をベースにやるかな。
マルチプロセス版の方が描画している状態に於いては安定してるけど?
ぶっちゃけるとマルチプロセス版は実験要素が強すぎて
今後の拡張を考えると手を入れにくい構成になってしまった。
つまりメンドクサクなりそうだからここでお蔵入りだ。
うーん、この実験は一体なんだったのか・・・。
ソースコードとか
今回使用したソースコードはGithubで公開している。
興味ある人は試しに動かしてみると良いだろう。
まとめ
まとめだよ。
- マルチプロセス化実験コードを実際に動作させてみた。
- 一応負荷は下がったが、それでも50ms間の負荷がかかるポイントが散見される。
- 結果としてはPipeのプロセス間通信のオーバーヘッド。
- 他のプロセス間通信でもこのオーバーヘッドはそれほど変わらない。
- 今後の実験は通常のシングルプロセス版のコードをベースとする。
バックナンバーはこちら。
コメント