[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part33 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
667(1): 2021/01/21(木)06:01 ID:mwzMDOkA(1/5) AAS
Haskellで厳しく性能を最適化しようとすると
抽象的なところで実装を意識したコードを書くことになって苦労する
みたいなレビューがあった
Haskellはベンチ結果良いように見えて
その手の「実装を意識したコード」がベンチ用に書かれるからで
実際は割と遅めなんだな
669: 2021/01/21(木)06:30 ID:mwzMDOkA(2/5) AAS
外部ﾘﾝｸ:stackoverflow.com
この辺
> thanks for the link.
80 lines is what I called "low-level style of programming not much different than
programming in C itself." . "the higher level code",
that would be the "stupid" fmap (length &&& length .
words &&& length . lines) readFile.
If that was faster than (or even comparable to) C,
the hype here would be totally justified then.
We still need to work hard for speed in Haskell as in C, is the point.
>>605もそんなことをかいてる
670: 2021/01/21(木)06:38 ID:mwzMDOkA(3/5) AAS
以下の厳密というのは遅延評価じゃなくするという事だろう？
しかも「プロファイルを作成して改善」は一度アプリを書いてから実行の様子を観察して最適化していくという事だろう。
抽象的にHaskellらしく書いていきなり速いというわけではないという事だ。
プロファイラーでボトルネックを特定して特殊なコードに変えていけば速くなる、と。
＞はい、怠惰はおそらくナイーブなHaskellが遅い最大の理由であり、
最適化されたHaskellでさえ速度の点で信頼できない可能性があります。
そのため、パフォーマンスが重要なアプリケーションにはお勧めしません。
OCamlの方が適しています。繰り返しになりますが、
HaskellをBangPatternsなどで厳密にすることはそれほど難しくありません。
また、コードの読み取りや保守が難しくなることもありません。
したがって、パフォーマンスが望ましいが、遅いプロトタイプでも問題がない場合は、
Haskellが非常に良い選択です。うまく機能するものを一緒にハックしてから、
プロファイルを作成して改善します。
671: 2021/01/21(木)08:18 ID:mwzMDOkA(4/5) AAS
こういう認識
・Haskellはコードだけでは最適化ポイントを見つけれない
・最適化したら変なコードになる
・普通のHaskellコードはベンチで他言語に惨敗する
672: 2021/01/21(木)09:21 ID:mwzMDOkA(5/5) AAS
これも
・最適化の方法が処理系（GHC)次第で決まり、プログラマーの認識内に無い。
GHCに対してひたすらトライアンドエラー
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s