[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part33 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
212: 2020/04/14(火)01:52:08.41 AAS
>>207
まあ最終手段はそうなるんでしょうね
しかし早すぎる段階での最適化はたいてい悪手って言われてるし
その前に、アルゴリズムの選定が間違ってるんではとなって、あれこれ作戦変えて
いつしか通るわけです。すると結局いつまで経ってもプロファイリングを練習する機会が来ないんですよね
319(1): 2020/05/08(金)18:31:16.41 ID:HMlJY84s(1) AAS
>>317
使ってないけど、富士通かな？
川崎の案件で募集してたぞ。
546: 2020/11/01(日)15:24:45.41 ID:BdB3gM+x(1) AAS
返り血
637: 2021/01/12(火)10:08:30.41 ID:fccMRI32(1) AAS
何かを生まなければならないというのは道徳か？
その道徳から全てが始まるのか
857: 2021/07/10(土)09:09:34.41 ID:Qo9dk8cs(1/3) AAS
>>856
なるほど
まだよくわかってないですけどunboxed typeというやつなんですね
後半もどなたか分かりませんか？
実は事情で“多倍長の浮動小数点”を自作したいのです
そのためにはReal型にしなくてはならずsinとなlogとか結構ある数の関数を実装する必要があります
どこかに参考にできるライブラリ転がってませんか？
性能は求めないので多倍長精度の計算ができるReal型を実装してる例が欲しいです
916: 2021/09/30(木)09:22:48.41 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.043s