OpenMPのordered解決編 - Ｓｏｄａ教

コメントいただいて、もう一度見直してみた。
何かが違うんだろう？
何回も見直してみる・・・orderedが２回でている？？

ここで、気が付いた、２回目に登場するorderedがポイントではないかと。
私は、
#pragma omp parallel for ordered
と指定することで、そのfor文が順次処理されるのだと思っていた。
でもって、それってどんな意味があるのか謎だった、だってforを並列指定している意味がないんだから(^^;
２つ目のorderedで謎が解けた。
そうか、２つ目に指定したorderedの部分が順次処理されるように、スレッドを調整するものだったのか。
つまり、２つ目のorderedが登場する前までは並列に処理され、orderedが登場したところで、順番を崩さないように、スレッドが待機すると。
forのスレッドごとの処理数（チャンクって名前でいいのかな？）が大きくなると、待っている時間が長くなり意味が薄い。
しかし、これが１だった場合などは、並列に処理できるぎりぎりまで処理して、順次処理が必要な部分でorderedを指定すれば、なかなか使えることになる。
最初のorderedは、ordered指定を使いますよーってな宣言だったわけか・・・

ここで、問題のバブルソートに戻って考えると、２つ目のforの直前で
#pragma omp ordered
を指定すればよいわけか、そして、その場合は時間がかかる最大の原因でもある
#pragma omp critical
が不要となるわけですねぇ。

結果として、並列で動作できる部分が皆無ですが、ソートは問題なく行われるようになると。
実際に確認して、納得できました。
うーん、これは自分だけじゃわからなかったなぁ。
最初の解釈だと、orderedの存在理由が謎でしたが、なにかあるんだろうなーってな感じで疑わなかったんですよねぇ。

そうそう、多重ループで内側のループにもパラレルな指定ができるかどうかってのも検索ワードを変えて（OpenMP ネスト）探したら・・・
実装依存だという内容がちらほら？
特に決められているわけではなかったということかな？
でも、omp_set_nested()ってなのも見つかった、有効にするかどうか決めれるということは、実装依存じゃないような(^^;
ただ、ネストした状態で使うとスレッドが乗数で増えてくことになるし、デフォルトのスレッド数だとコア数を超えてしまう。
効率を下げる要素のほうが多いような気がするので、使えたとしても使わないほうがいいのかな？
omp_set_nested()は試している時間がなかったんだけど、ヘタに設定すると怖そう(^^;

追記　2010-07-13 06:42
見出しの書式が悪くてコメント欄が使えなかったのを修正