アカウント名:
パスワード:
マルチプロセッサの有効活用 http://msdn.microsoft.com/en-us/library/vstudio/dd460693(v=vs.100).aspx [microsoft.com]
SIMD対応 http://blogs.msdn.com/b/clrcodegeneration/archive/2014/04/03/ryujit-ct... [msdn.com]
アクターモデル http://blogs.msdn.com/b/dotnet/archive/2014/04/02/available [msdn.com]
> これからは並列、並行処理を楽に書ける言語が求められると思う。だったらC#とF#両方既にでてるんだからいいだろキチガイさんか?
参照透過性があろうと、副作用が無かろうと、y=F(x)のyは、xが決まらなければ計算できない。関数型言語はコンパイラが依存関係を解析しやすいから「自動」並列化がしやすいというだけ。手続き型言語で並列化できない処理が、関数型言語で並列化できるようになるわけじゃない。速度を求めないなら、オブジェクト毎にスレッドを割り振って、イベントドリブンで処理させんのが分かりやすい。
それは30年くらい前の認識ですね
C#とF#はできることは基本的には同じだけど、F#のほうがはるかに強力な言語サポートがあるのです
>C#とF#はできることは基本的には同じだけど、F#のほうがはるかに強力な言語サポートがあるのです
具体例の提示希望
例えばC#ではasyncやawaitはキーワードですがF#ではコンピューテーション式にすぎません型推論もF#のほうが強力ですので、同じ処理でもずっと柔軟かつ簡潔に書けます
タイムマシンは実在したのか....
C#もF#も30年ちかく前からあるんだ…？
30年前からあるのは「手続き型言語」と「関数型言語」であって、C#やF#が30年前からあるように書いてあるとは読めませんでしたが。
ただ、30年前の認識ということは29年くらい前に「関数型言語は並列化に向かない」という認識を覆す言語があったと主張しているのでしょうが、そのころにF#は無いので、別の何かの言語が認識を覆したと主張しているのだろうと読み取りました。
何言語だろう？ 10年前くらいにしとけばよかったのに。30年は言い過ぎ
30年前というとIdやSISALの時代です
> 「関数型言語は並列化に向かない」
これはどこからかと思いましたが、タイトルなんですね
> 関数型言語はコンパイラが依存関係を解析しやすいから「自動」並列化がしやすいというだけ。
こちらととまったく整合性が取れていませんね向くのか向かないのかどちらなんでしょう
関数型言語が並列処理に向いているというのはより並列実行が可能なプログラミングスタイルを強制するという意味です、今も昔もI-structureやストリームなどがすぐに思い浮かびますよね？
逆に言うと、たとえ関数型言語であっても、並列向けデータ構造なしに自動並列化のみではあまり並列度は得られないということも、やはり30年ごろ前にはわかっていたのですなので好意的に解釈すれば、元コメの主張は正しい、ただし30年前の認識では、ということになります
10年、30年なんて、盛るにしても中途半端な数字はよくない。誤解を招きますね。そこは我々が300年前に通った道だ！とでもしておいた方がお互い誤解がなくていいとおもいます。
>y=F(x)のyは、xが決まらなければ計算できない。
つ非正格評価
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
いまさらC# (スコア:0)
Re: (スコア:0)
マルチプロセッサの有効活用
http://msdn.microsoft.com/en-us/library/vstudio/dd460693(v=vs.100).aspx [microsoft.com]
SIMD対応
http://blogs.msdn.com/b/clrcodegeneration/archive/2014/04/03/ryujit-ct... [msdn.com]
アクターモデル
http://blogs.msdn.com/b/dotnet/archive/2014/04/02/available [msdn.com]
Re: (スコア:0)
> これからは並列、並行処理を楽に書ける言語が求められると思う。
だったらC#とF#両方既にでてるんだからいいだろ
キチガイさんか?
関数型言語は並列化に あんまり向かない。 (スコア:0)
参照透過性があろうと、副作用が無かろうと、y=F(x)のyは、xが決まらなければ計算できない。
関数型言語はコンパイラが依存関係を解析しやすいから「自動」並列化がしやすいというだけ。
手続き型言語で並列化できない処理が、関数型言語で並列化できるようになるわけじゃない。
速度を求めないなら、オブジェクト毎にスレッドを割り振って、イベントドリブンで処理させんのが分かりやすい。
Re: (スコア:0)
それは30年くらい前の認識ですね
C#とF#はできることは基本的には同じだけど、F#のほうがはるかに強力な言語サポートがあるのです
Re: (スコア:0)
>C#とF#はできることは基本的には同じだけど、F#のほうがはるかに強力な言語サポートがあるのです
具体例の提示希望
Re: (スコア:0)
例えばC#ではasyncやawaitはキーワードですがF#ではコンピューテーション式にすぎません
型推論もF#のほうが強力ですので、同じ処理でもずっと柔軟かつ簡潔に書けます
Re: (スコア:0)
タイムマシンは実在したのか....
Re: (スコア:0)
C#もF#も30年ちかく前からあるんだ…？
30年前からあるのは「手続き型言語」と「関数型言語」であって、C#やF#が30年前からあるように書いてあるとは読めませんでしたが。
ただ、30年前の認識ということは29年くらい前に「関数型言語は並列化に向かない」という認識を覆す言語があったと主張しているのでしょうが、そのころにF#は無いので、別の何かの言語が認識を覆したと主張しているのだろうと読み取りました。
何言語だろう？ 10年前くらいにしとけばよかったのに。30年は言い過ぎ
Re: (スコア:0)
30年前というとIdやSISALの時代です
> 「関数型言語は並列化に向かない」
これはどこからかと思いましたが、タイトルなんですね
> 関数型言語はコンパイラが依存関係を解析しやすいから「自動」並列化がしやすいというだけ。
こちらととまったく整合性が取れていませんね
向くのか向かないのかどちらなんでしょう
関数型言語が並列処理に向いているというのはより並列実行が可能なプログラミングスタイルを強制するという意味です、今も昔も
I-structureやストリームなどがすぐに思い浮かびますよね？
Re: (スコア:0)
逆に言うと、たとえ関数型言語であっても、並列向けデータ構造なしに自動並列化のみではあまり並列度は得られないということも、やはり30年ごろ前にはわかっていたのです
なので好意的に解釈すれば、元コメの主張は正しい、ただし30年前の認識では、ということになります
Re: (スコア:0)
10年、30年なんて、盛るにしても中途半端な数字はよくない。誤解を招きますね。
そこは我々が300年前に通った道だ！
とでもしておいた方がお互い誤解がなくていいとおもいます。
Re: (スコア:0)
>y=F(x)のyは、xが決まらなければ計算できない。
つ非正格評価