マルチスレッドプログラミング相談室 その9

[1 デフォルトの名無しさん 2012/06/15(金) 01:31:57.88]

マルチスレッドプログラミングについて語るスレ

■前スレ
マルチスレッドプログラミング相談室 その8
http://toro.2ch.net/test/read.cgi/tech/1253521167/

■過去スレ
その１ ttp://pc3.2ch.net/tech/kako/997/997345868.html
その２ ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/
その３ ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/
その４ ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/
その５ ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/
その６ ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/
その７ ttp://pc12.2ch.net/test/read.cgi/tech/1215253576/

OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【ＯＳ】
【言語】
【実行環境】
【その他特記する事項】

[2 デフォルトの名無しさん 2012/06/15(金) 01:35:25.58]

■関連スレ・関連性の高いスレ

ネットワークプログラミング相談室 Port28
http://toro.2ch.net/test/read.cgi/tech/1334736934/

[3 デフォルトの名無しさん 2012/06/15(金) 03:59:42.18]

>>1 乙

前スレ >>994
並列実行「可能」でも「スケールする」かは知らんぞ。

OpenMP なら !$omp parallel do としてコンパイルオプション /Qopenmp

[4 デフォルトの名無しさん 2012/06/15(金) 16:15:07.07]

>>前すれ995
そういうオプションがあるのですね，レポートと書き直したソースを添付します．

http://www5.puny.jp/uploader/download/1339744079.zip
pass:giko

potential OUTPUT 依存関係
らしいですが，ググってもよくわかりません．依存関係がないように>>前すれ999のようにpureに書き換えたのですが．

>>前すれ997
これは試しにつけてみただけのものです，やはり使い方が違いますか・・．

[5 デフォルトの名無しさん 2012/06/15(金) 18:14:50.61]

gfortran -O3 20120528_fast_pararell_subroutine.f90 -ftree-vectorize -msse2 -ftree-vectorizer-verbose=2

[6 デフォルトの名無しさん 2012/06/15(金) 18:54:01.14]

彼女二人と同時にデートする時はマルチスレッドじゃないといけないんだけど
どうすればいいかな

[7 デフォルトの名無しさん 2012/06/15(金) 19:08:46.12]

時分割でがんばれ

[8 デフォルトの名無しさん 2012/06/15(金) 21:41:34.19]

Analyzing loop at 20120528_fast_pararell_subroutine.f90:237
237: not vectorized: not suitable for gather D.2660_224 = *shoi_69[D.2659_223];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:196
196: not vectorized: not suitable for gather D.2600_148 = *a_147(D)[D.2599_146];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:150
150: not vectorized: loop contains function calls or data references that cannot be analyzed
Analyzing loop at 20120528_fast_pararell_subroutine.f90:131
131: not vectorized: not suitable for gather D.2767_169 = *a_86(D)[D.2766_168];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:91
91: not vectorized: not suitable for gather D.2704_87 = *a_86(D)[D.2703_85];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:37
37: not vectorized: not suitable for gather D__I_lsm.780_635 = MEM[(real(kind=8)[0:] *)D.2433_241][pretmp.758_17];
Analyzing loop at 20120528_fast_pararell_subroutine.f90:38
38: not vectorized: not suitable for gather D.2485_318 = MEM[(real(kind=8)[0:] *)D.2298_95][D.2484_317];

[9 デフォルトの名無しさん 2012/06/16(土) 12:26:31.55]

>>4
ループ間で出力変数に依存関係があるかも、という判断。

○ i, j は value 属性を付け、b は戻り値にする。
○ サブルーチン inv の宣言部に interface で sho_det の引数属性を書く。

ここまでで依存はクリア、反復回数が少ないかも、というようになる。
/Qpar-threshold0 オプション (100〜0) で並列化は完了。

[10 デフォルトの名無しさん 2012/06/16(土) 12:48:12.18]

bに依存がないことくらい解析できてもよさそうなのにね

[11 デフォルトの名無しさん 2012/06/16(土) 16:27:05.54]

sho_det呼び出しの２重ループで並列化できるの？

[12 デフォルトの名無しさん 2012/06/16(土) 16:52:50.21]

双子と付き合う時はマルチスレッドのチンポ子が欲しい。

[13 デフォルトの名無しさん 2012/06/16(土) 16:54:32.86]

クリティカルセクションとかミューテクスって重いんですか？
秒間2500回とかマジキチですか？

[14 デフォルトの名無しさん 2012/06/16(土) 17:00:15.54]

400μ秒は今のパソコン環境でも、厳しいんじゃね
何をしたいかにもよるけど、専用環境作ったほうがハマらんかもね

[15 デフォルトの名無しさん 2012/06/16(土) 17:19:32.25]

ロックフリー！

[16 デフォルトの名無しさん 2012/06/16(土) 17:33:56.57]

>>13
そのあたりだと、API 呼び出しのオーバーヘッドもバカにならないから
自前で実装したほうがいいんじゃね？

[17 デフォルトの名無しさん 2012/06/16(土) 21:17:30.95]

https://gist.github.com/2841832
によれば
> Mutex lock/unlock 25 ns

[18 デフォルトの名無しさん 2012/06/16(土) 22:25:28.46]

>>13
重いけどそれくらいならいけると思う
できるならスレッドごとにリソースもって
最後に合体させたほうが速い

[19 4 2012/06/16(土) 23:07:53.93]

申し訳ありません，並列化ですが，解決しました．
/Qpar-threshold(並列化のしきい値)の値を100から20ぐらいまで下げたら5スレッドで実行されました．

ただ，ものすごく，計算が遅くなってしまって，なおかつ不必要なところまで並列化されてしまったようです．
このループだけ並列化したいっていうような指定ってできるのでしょうか？

[20 デフォルトの名無しさん 2012/06/16(土) 23:18:15.13]

>>17
Mutexってスレッド数によると思うんだけどな。
シングルコアならオンキャッシュで対応できるけど、
マルチコアだったりマルチCPUだったらメモリ参照と大差ないと思う。

[21 デフォルトの名無しさん 2012/06/17(日) 02:24:44.41]

答え教えてもらって、闇雲にやるのが今風なの？

[22 デフォルトの名無しさん 2012/06/17(日) 02:28:46.34]

それって、単純ループがスレッド化されただけじゃねえの？

[23 デフォルトの名無しさん 2012/06/17(日) 03:56:01.16]

実行環境に寄って自動で最適化して欲しいよね。
ちょっと違うけどjitみたいに自分でプロファイルとって実行処理罹る所を重点的に最適化とかさ。

4coreの環境と64coreの環境といちいち最適化するのめんどくさい。

[24 デフォルトの名無しさん 2012/06/17(日) 04:08:44.71]

core数増えたから、早くなるってわけでもないでしょうに

[25 デフォルトの名無しさん 2012/06/17(日) 06:28:14.10]

効率が悪かろうと並列化したいループには !DEC$ PARALLEL ALWAYS
※ 依存性に目をつぶれという指示ではない

> 64core の対応
３日かかる計算を１時間に押し込みたいなら、やる価値はある。
１分の処理が１秒になることを期待するなら、最適化する時間のほうが長い。

そもそも、大体の 64core での性能問題は 4core では小さくて見えないだけ。
スケールするとかしないとかはそういう話。

[26 デフォルトの名無しさん 2012/06/17(日) 14:48:00.38]

速くなってくれないと高額な多コア買った意味無いんだが。

[27 デフォルトの名無しさん 2012/06/17(日) 19:02:58.50]

それは、プログラム作ったベンダーに言え。
場合によっては、どれくらい高速化するかの見積もりくらい出してくれるだろ。

[28 デフォルトの名無しさん 2012/06/17(日) 20:27:37.75]

分散処理できるように考えるほうが難しいのに
道具によってはできることとできないことがあるでしょ

[29 デフォルトの名無しさん 2012/07/06(金) 19:30:56.61]

多コア化すれば、将来は、割込優先スレッド用コア、時分割スレッド用コア、OS用コアに別れて、それぞれのコアが空き時間でどうでもしてくれスレッドを処理するようになる気がする。
そうしないとスケジューリングに費やすコストが無駄だ。

[30 デフォルトの名無しさん 2012/07/06(金) 19:38:42.21]

あまり賢そうに見えないな

[31 デフォルトの名無しさん 2012/07/06(金) 19:45:56.15]

gpuが標準的になった時点で、非対称プログラミングが当たり前になるから、コア間に使い分け、役割分担が発生するのは必然じゃないかな。もっともどのコアがどの役割をやるかは、スケジューラが決めることになるけど。