アカウント名:
パスワード:
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とはなんだったのか
手続き系言語で並列実行できるようにする場合のキモは「いかに確実かつ高パフォーマンスに処理をスレッドセーフにできるか」といった所じゃないかな。
簡単な記述で並列実行を指定できるようになっても、それだけじゃ美味しくないというか、その個々の処理間で並列処理のためのロックだとかそのあたりの問題の方がよっぽど大変というか。
スレッドセーフの自動化といっても安直にデータアクセス全部にロックが入るようではパフォーマンスの低下がひどいことになりそうだし。そのあたりをちゃんと解析して必要最小限なロックだけで済ませてくれるような処理をコンパイラがやってくれるならうれしいんですけどねぇ…
並列化をするかしないかはユーザに任せないつもりで書きましたが、自動ロックは考えていません。i++; i++; って書いたとき、iがどうなるかは未定義でいいと思います。
C言語で副作用完了点をまたがず順序に依存した処理を書くと未定義になったり、C++0xのsequenced-before関係が半順序だったりするのはできるだけ並列化を妨げないためなんですよ。
.NET Framework 4.0 の Task とかで似たようなことができるんじゃなかったっけ
OpenMPのようなもの?
・並列可能なブロックを二重波カッコで区切る・ブロック内で、上に記述されている処理が全て実行されるまで待機しなければならない場合、二重セミコロンをつける
なんだそのOccam擬きは!Transputerって登場が早すぎたんじゃないだろうか?と思うんだな
ちなみにIntelがどんなにがんばってたくさんのCPUコアをオンチップにしてもメモリの帯域が狭くなる一方だとおもうのだ。バスの多重化でメモリへのアクセス速度が上がらないとどんなにプロセッサを増やしても頭打ちになるからこの方向で技術の華が開くならメモリとバス関係のブレークスルーが絶対必要だと思う。
#CSPってなんではやらないだよう >_<#OccamらぶりーなAC
それぞれの関数が整数型の戻り値を持つなら、
foo() & bar() &((hoge1() | 1) && (hoge2() | 1) && hoge3()); baz();
でいけそうな気はする。そこまで頑張ってくれるコンパイラがあるのかどうかは知らんけど。
expr(){return 1;} /* C++じゃないよ */
と、不定な引数をとる関数を作っておいて、
expr(foo(), bar(), expr(hoge1()) && expr(hoge2()) && expr(hoge3()));
ってするかな、俺なら。無駄な関数呼び出しは最適化で消えるはず。
……けど、そんなバッドノウハウみたいなテクじゃ、ダメなんだよ。意識しなくても使ってしまうような記法じゃないと。
verilogで書けばいいんじゃねーの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
並列化 (スコア:1, すばらしい洞察)
効率的なのはもちろんだけど、あえて「ここは並列で!」なんて指示しなくても良きに計らってくれるくらいでないと、なかなか厳しいと思う。
#pragma omp parallelうねうね。
Re:並列化 (スコア:0)
C/C++は抽象度が低すぎるから勝手に並列化するのはかえって難しいんですよ。
プログラマの「人間様である俺様がもっとも高速なプログラムを書けるんだ」信仰と、それを支えるC/C++にover optimizeされたハードウェアアーキテクチャのせいでいつまでたってもC/C++支配は終わりそうにありませんが。
Re:並列化 (スコア:2)
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とはなんだったのか
Re:並列化 (スコア:1)
手続き系言語で並列実行できるようにする場合のキモは「いかに確実かつ高パフォーマンスに処理をスレッドセーフにできるか」といった所じゃないかな。
簡単な記述で並列実行を指定できるようになっても、それだけじゃ美味しくないというか、
その個々の処理間で並列処理のためのロックだとかそのあたりの問題の方がよっぽど大変というか。
スレッドセーフの自動化といっても安直にデータアクセス全部にロックが入るようではパフォーマンスの低下がひどいことになりそうだし。
そのあたりをちゃんと解析して必要最小限なロックだけで済ませてくれるような処理をコンパイラがやってくれるならうれしいんですけどねぇ…
Re:並列化 (スコア:1)
並列化をするかしないかはユーザに任せないつもりで書きましたが、自動ロックは考えていません。
i++; i++; って書いたとき、iがどうなるかは未定義でいいと思います。
1を聞いて0を知れ!
Re: (スコア:0)
C言語で副作用完了点をまたがず順序に依存した処理を書くと未定義になったり、C++0xのsequenced-before関係が半順序だったりするのはできるだけ並列化を妨げないためなんですよ。
Re: (スコア:0)
.NET Framework 4.0 の Task とかで似たようなことができるんじゃなかったっけ
Re: (スコア:0)
OpenMPのようなもの?
Re: (スコア:0)
なんだそのOccam擬きは!
Transputerって登場が早すぎたんじゃないだろうか?と思うんだな
ちなみにIntelがどんなにがんばってたくさんのCPUコアをオンチップにしてもメモリの帯域が狭くなる一方だとおもうのだ。
バスの多重化でメモリへのアクセス速度が上がらないとどんなにプロセッサを増やしても頭打ちになるからこの方向で技術の華が開くならメモリとバス関係のブレークスルーが絶対必要だと思う。
#CSPってなんではやらないだよう >_<
#OccamらぶりーなAC
Re: (スコア:0)
スレッド分割や順序入れ替えはコンパイラというか実行時判断になりますが。
Re: (スコア:0)
それぞれの関数が整数型の戻り値を持つなら、
でいけそうな気はする。そこまで頑張ってくれるコンパイラがあるのかどうかは知らんけど。
Re:並列化 (スコア:1)
と、不定な引数をとる関数を作っておいて、
ってするかな、俺なら。無駄な関数呼び出しは最適化で消えるはず。
……けど、そんなバッドノウハウみたいなテクじゃ、ダメなんだよ。
意識しなくても使ってしまうような記法じゃないと。
1を聞いて0を知れ!
Re: (スコア:0)
verilogで書けばいいんじゃねーの?