アカウント名:
パスワード:
C/C++は抽象度が低すぎるから勝手に並列化するのはかえって難しいんですよ。プログラマの「人間様である俺様がもっとも高速なプログラムを書けるんだ」信仰と、それを支えるC/C++にover optimizeされたハードウェアアーキテクチャのせいでいつまでたってもC/C++支配は終わりそうにありませんが。
手続き型言語は順次実行されるという概念が、並列化を妨げてる気がする。
例えば、C/C++っぽいものを使うにしても。・並列可能なブロックを二重波カッコで区切る・ブロック内で、上に記述されている処理が全て実行されるまで待機しなければならない場合、二重セミコロンをつけるとでもしたら、マシになったりしないかなぁ？
例えばint main(){ foo(); bar(); {{ hoge1();; hoge2();; hoge3(); }} ;; baz();}としたら、foo()とbar()と、{{hoge1(), hoge2(), hoge3()の順次実行}}を並列にして、その全てが終わるのを待ってからbaz()を実行する、といったように。
# スレッド分割、順序入れ替えを行うか行わないかはコンパイラ判断で。
Objective-C + Cocoaだと、ブロック(いわゆるクロージャ)で並列部分を記述してNSOperationQueueに好きなだけ突っ込み、waitUntilAllOperationsAreFinishedメソッドで待機すればお望みのことが可能ですよ。(Grand Central Dispatch)フレームワーク側でCPUコア数などを勘案し、スレッドを準備してくれます。
参考リンクhttp://decafish.blog.so-net.ne.jp/2008-04-23-1 [so-net.ne.jp]
私の書いたコメントで、最も大切な部分は、ブロックではなく、明示していない限り、すべての文の実行順序が不定になることです。
何かのライブラリやら組み込みクラスやらを使って、ユーザが明示的にマルチスレッドにする部分を書くようじゃ、pthread使うよりは簡単だねってだけの話です。
Makefile?
同意。method/function callは原則として非同期実行に置き換えていいと思う。同期が必要な部分だけ宣言すればいい。volatileやcritical sectionがすでにあるんだし。
実行順序不定ってものすごく大きいパラダイム変化でしょ，言語にとっては．
その時点ですでに手続き型言語とは別物だと思うしこのコメント [srad.jp]でも言われているけど，そんなことを後付けで中途半端にやるくらいなら関数型言語マンセーでいいじゃん
そうかな？もともと、引数の評価順序みたいに、ごく自然に実行順序不定となるところはC/C++にあったのだから、大きな違いはないと思うよ。
実際にそれを利用して、マルチスレッド化された実行ファイルを出力するコンパイラの実装は、大きく変わるかもしれないけど、OpenMPみたいなのが作れてるし、それに言語仕様としては実行順序が上から順でも問題ないのだから、段階的に並列度を高めていく方法もとれる。
関数型言語は魅力的だし、ついこないだCはオワコン的なストーリーも出たばっかりだけど、それでも、C/C++系言語が今のコンピュータ動かす上で、LispやらHaskellやらの関数型言語よりも、大体の場合において効率がいいし、その状況を変えるほどに革新的な関数型言語の実装が現れない限りは、この状況は続くんじゃないかなぁ。
それでも、C/C++系言語が今のコンピュータ動かす上で、LispやらHaskellやらの関数型言語よりも、大体の場合において効率がいいし、
「動かす上で」よりも、「開発の面で現実的には」の気がする。理論的には並列プログラミングなら関数型のほうが優れているはずだけど、人が揃わないし、過去の資産の問題もある。
Erlangとはなんだったのか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
並列化 (スコア:1, すばらしい洞察)
効率的なのはもちろんだけど、あえて「ここは並列で！」なんて指示しなくても良きに計らってくれるくらいでないと、なかなか厳しいと思う。
#pragma omp parallelうねうね。
Re: (スコア:0)
C/C++は抽象度が低すぎるから勝手に並列化するのはかえって難しいんですよ。
プログラマの「人間様である俺様がもっとも高速なプログラムを書けるんだ」信仰と、それを支えるC/C++にover optimizeされたハードウェアアーキテクチャのせいでいつまでたってもC/C++支配は終わりそうにありませんが。
Re: (スコア:1)
手続き型言語は順次実行されるという概念が、並列化を妨げてる気がする。
例えば、C/C++っぽいものを使うにしても。
・並列可能なブロックを二重波カッコで区切る
・ブロック内で、上に記述されている処理が全て実行されるまで待機しなければならない場合、二重セミコロンをつける
とでもしたら、マシになったりしないかなぁ？
例えば
int main(){
foo();
bar();
{{
hoge1();;
hoge2();;
hoge3();
}}
;;
baz();
}
としたら、foo()とbar()と、{{hoge1(), hoge2(), hoge3()の順次実行}}を並列にして、その全てが終わるのを待ってからbaz()を実行する、といったように。
# スレッド分割、順序入れ替えを行うか行わないかはコンパイラ判断で。
1を聞いて0を知れ!
Re:並列化 (スコア:1)
Objective-C + Cocoaだと、ブロック(いわゆるクロージャ)で並列部分を記述してNSOperationQueueに好きなだけ突っ込み、
waitUntilAllOperationsAreFinishedメソッドで待機すればお望みのことが可能ですよ。(Grand Central Dispatch)
フレームワーク側でCPUコア数などを勘案し、スレッドを準備してくれます。
参考リンク
http://decafish.blog.so-net.ne.jp/2008-04-23-1 [so-net.ne.jp]
Re:並列化 (スコア:1)
私の書いたコメントで、最も大切な部分は、ブロックではなく、
明示していない限り、すべての文の実行順序が不定になることです。
何かのライブラリやら組み込みクラスやらを使って、
ユーザが明示的にマルチスレッドにする部分を書くようじゃ、
pthread使うよりは簡単だねってだけの話です。
1を聞いて0を知れ!
Re:並列化 (スコア:1)
Makefile?
Re: (スコア:0)
同意。
method/function callは原則として非同期実行に置き換えていいと思う。
同期が必要な部分だけ宣言すればいい。volatileやcritical sectionがすでにあるんだし。
Re: (スコア:0)
実行順序不定ってものすごく大きいパラダイム変化でしょ，言語にとっては．
その時点ですでに手続き型言語とは別物だと思うし
このコメント [srad.jp]でも言われているけど，
そんなことを後付けで中途半端にやるくらいなら
関数型言語マンセーでいいじゃん
Re:並列化 (スコア:1)
そうかな？
もともと、引数の評価順序みたいに、ごく自然に実行順序不定となるところはC/C++にあったのだから、大きな違いはないと思うよ。
実際にそれを利用して、マルチスレッド化された実行ファイルを出力するコンパイラの実装は、大きく変わるかもしれないけど、
OpenMPみたいなのが作れてるし、それに言語仕様としては実行順序が上から順でも問題ないのだから、段階的に並列度を高めていく方法もとれる。
関数型言語は魅力的だし、ついこないだCはオワコン的なストーリーも出たばっかりだけど、
それでも、C/C++系言語が今のコンピュータ動かす上で、LispやらHaskellやらの関数型言語よりも、大体の場合において効率がいいし、
その状況を変えるほどに革新的な関数型言語の実装が現れない限りは、この状況は続くんじゃないかなぁ。
1を聞いて0を知れ!
Re: (スコア:0)
「動かす上で」よりも、「開発の面で現実的には」の気がする。理論的には並列プログラミングなら関数型のほうが優れているはずだけど、人が揃わないし、過去の資産の問題もある。
Re: (スコア:0)
Erlangとはなんだったのか