[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part33 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
911(1): 2021/09/27(月)18:11 ID:XYchXu+H(1) AAS
>>910
mutable stateの排他制御をしてないから複数のスレッドで実行するとまずいことが起こるかもしれない、ってことじゃないの？
排他制御
外部ﾘﾝｸ:ja.wikipedia.org
916: 2021/09/30(木)09:22 AAS
>>911
具体的にどういうケースでどういう問題が起こるか解らないので、取り敢えずドキュメントにスレッド間で共有はやめろとある以上、大人しく従うことにします
>>912
STM版が、3950Xエコモードシングル500分の処理が30スレッド割り当てで220分くらいになりましたが
CPU使用率も75%前後で残念でした
競合するリソースが多過ぎたからではと思い、競合を避ける事を考えていると
そもそもSTMを使わず、スレッド毎にローカルにデータを貯めて処理して最後に各スレッドで部分的に仕上げたデータをChanで流して
、受信した側でデータを総括する、初歩的な方式を思いついたので書き換えました
getChanContentsを使いましたが、EOFみたいな最後の通知方法が判らずに、全スレッドの処理が終わりもう誰もデータを流すことのないチャネルから性懲りもなく読みだそうとしてしまい
例外が発生して困っていました
幸いスレッドの数は判っているのでチャネルからtakeする数をスレッド数ちょっきりとして切り上げた所、遅延評価が幸いしてその先を読もうとしなくなり例外は発生しなくなりました（本質的解決かは判りません）
これにより処理が18分で終わりました
スレッド毎にcreateSystemRandomするように書き換えると21分かかるようになりました
オーバヘッド込みでも500分かかっていた時代から驚異的な進化を遂げました
憧れだった Software Transactional Memory は期待程速くなくがっかりしました
STMは最初に検討するべきではなく、巧く競合が発生しないように書けないときの最後の手段なのかなと思いました
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s