マルチスレッドプログラミング相談室 その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だったらメモリ参照と大差ないと思う。