一般的な処理を関数型の書き方をすると遅い

**デフォルトの名無しさん** · 2014/01/26(日) 15:05:44.15

Rubyで関数型とか遅いからやめればいいのに

**デフォルトの名無しさん** · 2014/02/05(水) 19:52:06.99

そもそもshared mutable stateが問題になるほど複雑な並列処理を行うプログラムを作る人間がこのスレにいるのかどうか

**デフォルトの名無しさん** · 2014/02/05(水) 20:00:14.99

>>91
だな
関数型よりC♯とVBの方が優れてるよな。おれも同意するわ。

>>92
関数型教だよなwww
惑わされずにC♯とVB使うのが情強だ。

>>93
だな。
おれも同意する。C♯の方が良いとみんなも思ってるよ

**デフォルトの名無しさん** · 2014/02/05(水) 20:06:24.04

ドカタ用の汎用プログラミングを侵食するものではないから不安がることは無いよ

**デフォルトの名無しさん** · 2014/02/05(水) 20:37:29.86

ランダムアクセス(readもwriteも)がO(1)で
クローンがO(1)であるような、リストって作れる？

これが出来れば並列プログラミングがぐっと楽になるぞ？

**デフォルトの名無しさん** · 2014/02/05(水) 20:38:30.33

できます。

**デフォルトの名無しさん** · 2014/02/05(水) 20:39:38.49

>>97
どうすんの？普通の俺んちのパソコンでだぞ？

**デフォルトの名無しさん** · 2014/02/05(水) 20:43:04.38

関数理論を調べてください。

**デフォルトの名無しさん** · 2014/02/05(水) 20:55:55.52

>>99
みつけた。VListか？
これなんでみんな使わないの？

**デフォルトの名無しさん** · 2014/02/05(水) 20:57:00.85

関数理論にアレルギーがあるからです。

**デフォルトの名無しさん** · 2014/02/05(水) 21:01:10.24

これ最強じゃね？普通な配列におとるかもしれないけど
参照でやれば効率いいけど誰かが書き換えないか心配
コピーしてしまえば楽だけど・・・っていうトレードオフをしなくて良い
さっそく、俺の愛用するC#で実装してみるかな

**デフォルトの名無しさん** · 2014/02/05(水) 21:22:56.61

>>73に一歩近づいたかっていうか
研究者は2002年の時点でこれやってるわけだから
まだ普及した実装がないだけで、今分かっている研究を全て
集結させたコンパイラ作ったらかなり最適化できるのかな

**デフォルトの名無しさん** · 2014/02/05(水) 21:36:39.70

データ集合体へのアクセスパターンを認識し、集合構造を最適化します。
これは知識と呼ばれるものと同じであり、近い将来において、人工知能に
進化する可能性が危惧されています。

**デフォルトの名無しさん** · 2014/02/05(水) 22:20:53.60

関数型の利点は並列プログラムをしなくても、意識しなくても、コンパイラが対応すれば出来てしまうところ。
1コア、10コア、100万コアでも同一コードで動かせる。
純粋関数型で、対応コンパイラがあれば。

**デフォルトの名無しさん** · 2014/02/06(木) 00:17:06.85

>>105
残念ながら、現在の並列関数型言語処理系の研究で成果を挙げているのは、
メモリを共有する密結合型並列方式のみ
そして今後半導体の集積技術がどこまで進化するのか予測は難しいが、
せいぜい数十から数百で限界がくるから、
結果的にHPCの世界で研究されている粗結合型超並列へと向かわざるをえない
それを、従来のアルゴリズムで書かれたプログラムを粗結合型並列へ自動変換できる
魔法のコンパイラがたやすく実現できるものだと想像してしまうのは、
素人の浅はかな考えと言わざるをえない

**デフォルトの名無しさん** · 2014/02/06(木) 00:25:51.52

>>77
並列に動く複数のレーザを備えたDVDドライブがあれば、
関数型言語でもI/Oを並列に処理できるよ。

**デフォルトの名無しさん** · 2014/02/06(木) 01:08:10.67

>>64
なんかScalaって読みにくいな

何が読みにくいかって、
xs.length とメソッドっぽい書き方、Array.concat(...) とモジュールっぽい書き方、
と思えばsort(...) と普通の関数っぽい書き方、
さらには xs filter (...) と中置記法の演算子のような書き方、
さらに (pivot >) では中置記法の演算子を部分適用、

なんだかsyntaxが盛りだくさんで統一感がないように思えるんだが。

**デフォルトの名無しさん** · 2014/02/06(木) 03:40:15.90

CだってCで書きやすいようにCPUが設計されてたりするんだし
関数型で書かれたコードを動かすことが前提のプロセッサがあってもいいんじゃないの？
そういうのは世に無いの

**デフォルトの名無しさん** · 2014/02/06(木) 07:43:42.91

標準のコレクション（List）が連結リストな時点で、速いわけがない。

**デフォルトの名無しさん** · 2014/02/06(木) 19:14:44.32

VListちょっと思ってたのと違うな
fully persistent arrayっていうのが俺の思ってたのに近い
これはclone, read, writeがlog(log(操作数))

**デフォルトの名無しさん** · 2014/02/06(木) 19:57:23.87

Haskellは問題によってはアセンブラより速いらしいよ。

**デフォルトの名無しさん** · 2014/02/06(木) 21:57:24.60

誰も釣られてくれないようだな。下手糞なアセンブラよりも早いってことかな。

**デフォルトの名無しさん** · 2014/02/06(木) 22:11:03.09

たらいまわし関数をgccとsbclで試したら僅差でsbclの方が速かった

**デフォルトの名無しさん** · 2014/02/06(木) 22:26:42.18

たらい回し言語機ｗ

**デフォルトの名無しさん** · 2014/02/10(月) 00:16:05.36

細かいところ並列化しても遅いまま。でかいところは、並列化する方法はすぐわかる。

**デフォルトの名無しさん** · 2014/02/10(月) 11:22:15.55

細かいところの並列化って
パイプラインとかスーパースカラでやってるじゃん？
CPU処理の並列化

で、この機能の限界の原因は、なんでも並列化出来るわけじゃないんだよ。
前処理の計算結果に依存する処理があるから並列化出来ない。

これは関数型言語にしても当てはまる話で
できないものはできない。

で、>>116が言うように、でかいところは並列化する方法はすぐわかる。

**デフォルトの名無しさん** · 2014/03/06(木) 03:49:38.86

関数型に魅入られた人は我々と違ってなんか宗教のように関数型を推すけど
あれはなんなんだろうか。なにか彼らの中で現行の言語で許せない何かがあって
よくわからない"それ"からの解放が宗教的恍惚をもたらすのだろうか？

たとえば俺はRPNの電卓を愛用していて日常的に2*3+4*5を
2ent3*4ent5*+と操作して計算しているわけだが
この方が計算機の構造に合ってるしエレガントで速いとは思うものの
「これからの数学では2*3+4*5は2ent3*4ent5*+と表記すべき！未来はそうなる！」
なんてあたまおかしなことはそれが引き起こす「副作用」を考えると
とても言えないわけで。

ちょうど俺が最近のC++やらなんやらのわけのわかんない型や書式、クラスの氾濫に嫌気が差して
あの「なんでもクラスだ」「クラス名は読んでわかる奴にしろ」「メソッドも見てわかるように作れ」で
長い名前だらけでキートップの磨耗をできるだけ防ぎたいプログラマーに絶不評のObjective-C最高じゃん？
ってなってんのと逆ベクトルで、関数型こそ至高！ってなる…なにがあるんだろう？

**デフォルトの名無しさん** · 2014/03/06(木) 04:45:59.26

>>118
近頃の関数型言語周辺の雰囲気は、C言語全盛時代のパソコン通信における
「オブジェクト指向」の雰囲気にそっくり。

**デフォルトの名無しさん** · 2014/03/06(木) 10:48:44.97

どこが？

**デフォルトの名無しさん** · 2014/03/12(水) 00:34:00.68

時代は、マルチパラダイムに進んでるけどね。
大枠をオブジェクト指向で作って、細かい部分を関数型で埋める。

**デフォルトの名無しさん** · 2014/03/13(木) 16:01:01.92

クラス=状態がある=テストが書きにくい=管理しにくい
関数=状態がない=テストが書きやすい=管理しやすい

**デフォルトの名無しさん** · 2014/03/13(木) 18:14:20.27

そんなに違いは無いと思うけどね。
テストは関数型が断然やりやすいけど。

**デフォルトの名無しさん** · 2014/03/21(金) 01:37:37.08

自分で使ってF#で書いた方がバグの発生率やそれの修正コスト含めて圧倒的にC#より生産性高いので使えるならF#使うわ。

>>121
だいたいそんな感じやね。大枠にするようなものまで関数型にする必要ないしと言って細かいクラスを乱立させる意味は無い。

**デフォルトの名無しさん** · 2014/03/21(金) 02:34:39.99

カリー化って何の役に立つの？
呼び出しコストが何倍にもなるだけだと思うのだけど

**デフォルトの名無しさん** · 2014/03/21(金) 02:35:00.76

機械に対するヒントが手続型より少ないのだから、仕方がないだろう。
Fortranだって早くするには、ディレクティブをたくさん書かないといけない。

**デフォルトの名無しさん** · 2014/03/21(金) 09:00:49.91

>>125
その場その場で適した関数化に役立つ。
むしろ事前適用するので後からの呼び出しコストが減る

**デフォルトの名無しさん** · 2014/03/23(日) 23:39:20.28

この関数は副作用ありませんよっていう
キーワードみたいなのが手続き型でも使えれば
デバッグ中にウォッチ式で関数呼び出せたりできて便利な気がする

**デフォルトの名無しさん** · 2014/03/23(日) 23:49:28.28

__attribute__((pure))

**デフォルトの名無しさん** · 2014/03/24(月) 01:40:47.03

そもそも高級言語は「人間が処理を理解しやすいように」作られてんのに
なんで「こういうわかりにくい書き方をするとこんな利点が！」ってドヤるんだよ

**デフォルトの名無しさん** · 2014/03/24(月) 02:59:59.07

>>130
人間が理解しやすい ≠ お前が理解できる

**デフォルトの名無しさん** · 2014/03/24(月) 10:01:42.73

俺にわかりにくいものは、他の誰にも絶対にわかりくい、ってドヤってるバカはおまえだw

**デフォルトの名無しさん** · 2014/03/24(月) 13:52:41.93

×高級言語
○高水準言語

単純にハードに近いか遠いかだけなんだけどな。指摘するのが馬鹿らしくなる位に
高級言語としか書かないのしかいないけど。

**デフォルトの名無しさん** · 2014/03/24(月) 14:02:52.49

High level languageという表現を見たことが無い奴を篩い分けるいい目安なので、
そういう正しい知識を広めるの、やめてくれないかなw

**デフォルトの名無しさん** · 2014/03/24(月) 14:29:26.54

>>134
高級言語ならhigh class languageになるな。

**デフォルトの名無しさん** · 2014/03/24(月) 17:56:30.52

関数型言語がまったく普及しないのはコードが読みにくいのに
「これが読める俺tueee！」って厨二病しか支持してないせいだよね…

**デフォルトの名無しさん** · 2014/03/24(月) 17:58:21.44

ということにしたいのですね、としか言いようがない。

**デフォルトの名無しさん** · 2014/03/24(月) 22:09:12.40

>>136
そういうことだな

**デフォルトの名無しさん** · 2014/03/25(火) 03:26:52.14

>>136
んーわかってる人の中では普通に使われてるからねぇ。

**デフォルトの名無しさん** · 2014/03/25(火) 04:19:36.70

Javaで書かれたソフトウェアを使いたくないエンドユーザーが一般に存在することを
考えると、関数型で書かれたソフトウェアがユーザーに受け入れられがたいのは
容易に想像できます。

例えば、ホビーで良く使われるmebed NXP LPC1768はフラッシュ512KB、RAM32KBを
搭載、C++で開発するのが主流です。

RAMが32KBしかないのです。
この環境で関数型を使いたいでしょうか？

ユーザーはパソコン上であっても、関数型で書かれたソフトウェアを敬遠するでしょう。
アイデアは良かったと思います。
関数型は遠い未来には期待が持てると思います。
でも今は・・・

**デフォルトの名無しさん** · 2014/03/25(火) 04:28:05.32

訂正

RAMが32KBしかないのです。
関数を使いたくないのは、この環境ぐらいじゃないでしょうか？

**デフォルトの名無しさん** · 2014/03/25(火) 05:06:34.96

(関数型(笑))

**デフォルトの名無しさん** · 2014/03/25(火) 08:39:46.40

関数型言語でどういうコードが「読みやすいか」ってのは、手続き型言語やオブジェクト指向言語に比べてまだ定石のないところだとは思う。
カウボーイコーディングで場当たり的に書いていくと、より手の付けられない状態になりやすいのは関数型言語の方、ってのは実感としてあるがどうか。

**デフォルトの名無しさん** · 2014/03/25(火) 10:40:18.20

>>140
遠い過去の世界に生きてる人がなんか言ってる、という感じにしか聞こえない。

**デフォルトの名無しさん** · 2014/03/25(火) 10:43:16.42

>>143
むしろオブジェクト指向より歴史あるんだが(´･_･`)

**デフォルトの名無しさん** · 2014/03/25(火) 13:16:02.08

正直、C++とか筋の悪いオブジェクト指向言語で
ソースの可読性の問題でやたらバグが出て頓挫するようになったから
"ソースの可読性もクソもないコレで書けばバグが出ないよ！"って
滅んだ過去の亡霊が墓所から這い出て来たようにしか見えない。

**デフォルトの名無しさん** · 2014/03/25(火) 13:27:26.93

それはお前こそが手続き脳ゾンビだと思うw

**デフォルトの名無しさん** · 2014/03/25(火) 13:43:31.68

コンパイラさんから見た可読性が大事なんだよ

**デフォルトの名無しさん** · 2014/03/25(火) 13:49:04.38

Haskellはむしろ構文解析はめんどいぞ。
PEGの論文書いた人がサンプルに使ったのが、それが理由でJavaの構文を使ってるくらいだからw

**デフォルトの名無しさん** · 2014/03/25(火) 14:04:37.20

まぁ普通に書いたら何でもかんでもオブジェクトにしてスパゲティになるよりも値をトランスフォームしてく関数型の方がバグが少ないのは自明だわな(´･_･`)

**デフォルトの名無しさん** · 2014/03/25(火) 14:22:47.64

だがバグのあるプログラムを書く自由は神に与えられた権利

それを脅かす者どもとは戦わねばならない

**デフォルトの名無しさん** · 2014/03/25(火) 15:09:23.71

Haskellでもバグのあるプログラムは書けるよ。
単に型システムによって蹴落とされるようなバグだけが、コンパイル時に弾かれる、というだけで。

**デフォルトの名無しさん** · 2014/03/25(火) 15:38:21.95

C++が勘違いして導入した(そしていまも勘違いしてる奴が多い)オブジェクト指向と違って
本来のオブジェクト指向はオブジェクトにコレをやれとメッセージ(メソッド)を送ると
能動的にオブジェクトが自分で対処するという「ロール」としての区切りだから
本来スパゲティもなんもない。

**デフォルトの名無しさん** · 2014/03/25(火) 15:55:31.26

本来の、というより、Smalltalk流の、だな。
Simula流を「勘違い」と定義している奴はそんなにいないと思うぞ。
まぁ観測範囲を偏らせれば、それなりにいるのかもしれんが。

**デフォルトの名無しさん** · 2014/03/25(火) 16:25:19.67

>>153
メッセージの実行方式とメッセージをどこに送るかは何も関係ないんだが…(´Д` )

**デフォルトの名無しさん** · 2014/03/25(火) 17:40:01.96

>>145
歴史があるかどうかは関係ないんだが(´･_･`)
あらゆるソフトウェア、様々な規模のプロジェクトに適用されていて
経験とプラクティスがより蓄積されているのはどっちか言ってみ？(´･_･`)

**デフォルトの名無しさん** · 2014/03/25(火) 21:42:23.18

>>156
ドカタは知らんかもしらんが、OCamlもHaskellもLispもErlangも色んなものに使われてるんだが(´･_･`)

**デフォルトの名無しさん** · 2014/03/25(火) 21:54:28.24

いろんなものというのはな。
たとえば、・・・あとは>>157が答えてくれるはずｗ

**デフォルトの名無しさん** · 2014/03/25(火) 22:02:41.15

LispはAutocadのマクロに使われていたが、いつの間にかVBAが主流に変わっていた。
使いにくさはいい勝負なのでどっちでもいいけど。

**デフォルトの名無しさん** · 2014/03/25(火) 22:08:49.40

関数型じゃないけど、Paintshop ProはPythonをマクロに導入して、そこから転落が始まり
ついに表舞台から消え去った。
今はひっそりと裏街道をとぼとぼしてる。

**デフォルトの名無しさん** · 2014/03/25(火) 22:23:56.86

例えばお掃除ロボットのAIがlispで書かれてたりするみたい

**デフォルトの名無しさん** · 2014/03/25(火) 22:26:01.21

特殊な用途ばかりだね。

お掃除ロボットって作ったことあるかい？

**デフォルトの名無しさん** · 2014/03/25(火) 22:29:19.16

使ったことすらないよ

**デフォルトの名無しさん** · 2014/03/25(火) 22:31:38.58

そもそも関数型はアプリのマクロ程度にしか使いようがない。
ブラウザのスクリプトがJSではなくHaskellだったとしたら、現在のJSと同様に
広まったかもしれない。
そういう言語。

**デフォルトの名無しさん** · 2014/03/25(火) 22:47:21.88

関数型は、マルチコアに良いから出てきた。
未来の言語。
まだ、マルチコアに十分に対応したのがない。

**デフォルトの名無しさん** · 2014/03/25(火) 23:01:12.10

それは机上の空論の可能性が高いよ。
マルチコアに良いって言うのが副作用が無いことに依存している時点で、
既に使い道がかなり限定される。
ほとんどのユーザーは副作用のためにソフトウェアを利用するんだから。

**デフォルトの名無しさん** · 2014/03/25(火) 23:05:22.71

オール純粋関数型でなくてもいい。
マルチコアに対応したいところだけでいい。
CPU、GPUをフル活用しても時間食う処理の部分だけ純粋関数型で書く。

**デフォルトの名無しさん** · 2014/03/25(火) 23:06:19.07

副作用はあるけど無い部分とうまく分けられる部分が評価されてるんじゃないの

**デフォルトの名無しさん** · 2014/03/26(水) 00:35:10.61

OSがタスク振り分けるからプログラムは自分で各コア勝手に弄るな！ってなりそうだよね

**デフォルトの名無しさん** · 2014/03/26(水) 00:48:06.90

>>166
Haskellだって副作用のあるコードかけんだよ。馬鹿じゃねーの

**デフォルトの名無しさん** · 2014/03/26(水) 01:02:50.65

>>167 Fortran95以降のpure/elemental functionがそれに該当するかもね。
引数わ書き換えたり(Fortranは基本、アドレス渡し)、ファイルI/Oの処理
が内部で禁止される。
スカラーからスカラーへの関数が、ベクトルからベクトルへの関数に自動的に
拡張されて、自動並列化をONにすれば要素毎の演算がコアに割り振られる。

**デフォルトの名無しさん** · 2014/03/26(水) 02:55:25.28

こんな問題、インライン化できないスクリプト言語だけ

**デフォルトの名無しさん** · 2014/03/26(水) 09:59:28.83

ソースコードから作られてたんだ！

**デフォルトの名無しさん** · 2014/03/26(水) 20:16:47.96

↑
とまあこのように、関数型をマンセーしているのは関数型を使いこなせないでいる人たちってことですわ。
使いこなせる人は悟りを開いて使わない選択をする。
そんな時代ですわ。

**デフォルトの名無しさん** · 2014/03/26(水) 21:42:41.71

ということにしたいのですね。

**デフォルトの名無しさん** · 2014/03/26(水) 23:37:06.47

まぁ今の時代にmutableデフォで作ることがあり得ないけどな

**デフォルトの名無しさん** · 2014/03/28(金) 15:31:32.57

関数型言語を使いこなすコストパフォーマンスはオブジェクト指向とはさほど変わらないだろうけど、コストとパフォーマンスの総和はオブジェクト指向よりもかなり大きいって感じるなあ。

**デフォルトの名無しさん** · 2014/03/28(金) 16:02:36.26

>>177
C#とF#で作ったもの、概ね速度同等で動くんだが。

**デフォルトの名無しさん** · 2014/03/28(金) 16:34:57.35

なぜそこでオブジェクト指向がでてくるのか理解できない。

**デフォルトの名無しさん** · 2014/03/28(金) 17:44:57.16

ブロックみたいな感じだね。

**デフォルトの名無しさん** · 2014/03/28(金) 18:21:02.92

>>178
実行速度じゃなくてプログラマの労力の話ね。

**デフォルトの名無しさん** · 2014/03/28(金) 19:37:13.40

>>181
何がコストで何がパフォーマンスなんだよ(´･_･`)

つかそもそもコストとパフォーマンスって足せるのか。

**デフォルトの名無しさん** · 2014/03/28(金) 19:41:52.44

壊れてんな、この人。

**デフォルトの名無しさん** · 2014/03/28(金) 22:29:12.64

お前のモジュールって必要以上にファンクショナルだよな

**デフォルトの名無しさん** · 2014/03/30(日) 10:13:05.52

haskellでforMとかmutable arrayとかRWSTモナドとか使ってると、これもう手続き型言語じゃんって気分になる
でもオブジェクト指向にはなれないんだよな
やっぱ両方使える方がいい

**デフォルトの名無しさん** · 2014/03/30(日) 10:57:46.58

んじゃF#かScalaどぞー

**デフォルトの名無しさん** · 2014/03/31(月) 00:03:10.70

x64って何か変なスタックフレームの書き方するよな
再帰呼び出しが遅くなってスタック領域も多量消費すると思うんだけど

**デフォルトの名無しさん** · 2014/03/31(月) 08:55:02.45

製品版はどうせマイクロソフトなんだよ(´･_･`)

**デフォルトの名無しさん** · 2014/04/04(金) 21:41:40.67

JAVAで世界が変わる！
JAVAでOSが消える！
全てのソフトウェアはJAVAになる！
JAVA用のプロセッサが開発される！
OOP以外の言語は消える！

と言われていた時代を思い出した。

**デフォルトの名無しさん** · 2014/04/04(金) 22:41:45.02

あー、日経とかがそう言ってたよねw

**デフォルトの名無しさん** · 2014/04/05(土) 11:52:17.99

言ってたって証拠あるの？

**デフォルトの名無しさん** · 2014/04/05(土) 15:53:48.75

おまえの目の前の箱で探せばすぐに