マルチスレッドプログラミングについて語るスレ
■前スレ
マルチスレッドプログラミング相談室 その8
http://toro.2ch.net/test/read.cgi/tech/1253521167/
■過去スレ
その1 ttp://pc3.2ch.net/tech/kako/997/997345868.html
その2 ttp://pc5.2ch.net/test/read.cgi/tech/1037636153/
その3 ttp://pc8.2ch.net/test/read.cgi/tech/1098268137/
その4 ttp://pc8.2ch.net/test/read.cgi/tech/1130984585/
その5 ttp://pc11.2ch.net/test/read.cgi/tech/1157814833/
その6 ttp://pc11.2ch.net/test/read.cgi/tech/1187008532/
その7 ttp://pc12.2ch.net/test/read.cgi/tech/1215253576/
OS・言語・環境は問わないが、それゆえ明記すべし。
テンプレ
【OS】
【言語】
【実行環境】
【その他特記する事項】
マルチスレッドプログラミング相談室 その9
2012/06/15(金) 01:31:57.88
2012/06/15(金) 01:35:25.58
2012/06/15(金) 03:59:42.18
2012/06/15(金) 16:15:07.07
>>前すれ995
そういうオプションがあるのですね,レポートと書き直したソースを添付します.
http://www5.puny.jp/uploader/download/1339744079.zip
pass:giko
potential OUTPUT 依存関係
らしいですが,ググってもよくわかりません.依存関係がないように>>前すれ999のようにpureに書き換えたのですが.
>>前すれ997
これは試しにつけてみただけのものです,やはり使い方が違いますか・・.
そういうオプションがあるのですね,レポートと書き直したソースを添付します.
http://www5.puny.jp/uploader/download/1339744079.zip
pass:giko
potential OUTPUT 依存関係
らしいですが,ググってもよくわかりません.依存関係がないように>>前すれ999のようにpureに書き換えたのですが.
>>前すれ997
これは試しにつけてみただけのものです,やはり使い方が違いますか・・.
2012/06/15(金) 18:14:50.61
gfortran -O3 20120528_fast_pararell_subroutine.f90 -ftree-vectorize -msse2 -ftree-vectorizer-verbose=2
2012/06/15(金) 18:54:01.14
彼女二人と同時にデートする時はマルチスレッドじゃないといけないんだけど
どうすればいいかな
どうすればいいかな
2012/06/15(金) 19:08:46.12
時分割でがんばれ
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];
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];
2012/06/16(土) 12:26:31.55
>>4
ループ間で出力変数に依存関係があるかも、という判断。
○ i, j は value 属性を付け、b は戻り値にする。
○ サブルーチン inv の宣言部に interface で sho_det の引数属性を書く。
ここまでで依存はクリア、反復回数が少ないかも、というようになる。
/Qpar-threshold0 オプション (100〜0) で並列化は完了。
ループ間で出力変数に依存関係があるかも、という判断。
○ i, j は value 属性を付け、b は戻り値にする。
○ サブルーチン inv の宣言部に interface で sho_det の引数属性を書く。
ここまでで依存はクリア、反復回数が少ないかも、というようになる。
/Qpar-threshold0 オプション (100〜0) で並列化は完了。
2012/06/16(土) 12:48:12.18
bに依存がないことくらい解析できてもよさそうなのにね
2012/06/16(土) 16:27:05.54
sho_det呼び出しの2重ループで並列化できるの?
2012/06/16(土) 16:52:50.21
双子と付き合う時はマルチスレッドのチンポ子が欲しい。
13デフォルトの名無しさん
2012/06/16(土) 16:54:32.86 クリティカルセクションとかミューテクスって重いんですか?
秒間2500回とかマジキチですか?
秒間2500回とかマジキチですか?
2012/06/16(土) 17:00:15.54
400μ秒は今のパソコン環境でも、厳しいんじゃね
何をしたいかにもよるけど、専用環境作ったほうがハマらんかもね
何をしたいかにもよるけど、専用環境作ったほうがハマらんかもね
2012/06/16(土) 17:19:32.25
ロックフリー!
2012/06/16(土) 17:33:56.57
2012/06/16(土) 21:17:30.95
18デフォルトの名無しさん
2012/06/16(土) 22:25:28.46194
2012/06/16(土) 23:07:53.93 申し訳ありません,並列化ですが,解決しました.
/Qpar-threshold(並列化のしきい値)の値を100から20ぐらいまで下げたら5スレッドで実行されました.
ただ,ものすごく,計算が遅くなってしまって,なおかつ不必要なところまで並列化されてしまったようです.
このループだけ並列化したいっていうような指定ってできるのでしょうか?
/Qpar-threshold(並列化のしきい値)の値を100から20ぐらいまで下げたら5スレッドで実行されました.
ただ,ものすごく,計算が遅くなってしまって,なおかつ不必要なところまで並列化されてしまったようです.
このループだけ並列化したいっていうような指定ってできるのでしょうか?
2012/06/16(土) 23:18:15.13
2012/06/17(日) 02:24:44.41
答え教えてもらって、闇雲にやるのが今風なの?
2012/06/17(日) 02:28:46.34
それって、単純ループがスレッド化されただけじゃねえの?
2012/06/17(日) 03:56:01.16
実行環境に寄って自動で最適化して欲しいよね。
ちょっと違うけどjitみたいに自分でプロファイルとって実行処理罹る所を重点的に最適化とかさ。
4coreの環境と64coreの環境といちいち最適化するのめんどくさい。
ちょっと違うけどjitみたいに自分でプロファイルとって実行処理罹る所を重点的に最適化とかさ。
4coreの環境と64coreの環境といちいち最適化するのめんどくさい。
2012/06/17(日) 04:08:44.71
core数増えたから、早くなるってわけでもないでしょうに
2012/06/17(日) 06:28:14.10
効率が悪かろうと並列化したいループには !DEC$ PARALLEL ALWAYS
※ 依存性に目をつぶれという指示ではない
> 64core の対応
3日かかる計算を1時間に押し込みたいなら、やる価値はある。
1分の処理が1秒になることを期待するなら、最適化する時間のほうが長い。
そもそも、大体の 64core での性能問題は 4core では小さくて見えないだけ。
スケールするとかしないとかはそういう話。
※ 依存性に目をつぶれという指示ではない
> 64core の対応
3日かかる計算を1時間に押し込みたいなら、やる価値はある。
1分の処理が1秒になることを期待するなら、最適化する時間のほうが長い。
そもそも、大体の 64core での性能問題は 4core では小さくて見えないだけ。
スケールするとかしないとかはそういう話。
2012/06/17(日) 14:48:00.38
速くなってくれないと高額な多コア買った意味無いんだが。
2012/06/17(日) 19:02:58.50
それは、プログラム作ったベンダーに言え。
場合によっては、どれくらい高速化するかの見積もりくらい出してくれるだろ。
場合によっては、どれくらい高速化するかの見積もりくらい出してくれるだろ。
2012/06/17(日) 20:27:37.75
分散処理できるように考えるほうが難しいのに
道具によってはできることとできないことがあるでしょ
道具によってはできることとできないことがあるでしょ
29デフォルトの名無しさん
2012/07/06(金) 19:30:56.61 多コア化すれば、将来は、割込優先スレッド用コア、時分割スレッド用コア、OS用コアに別れて、それぞれのコアが空き時間でどうでもしてくれスレッドを処理するようになる気がする。
そうしないとスケジューリングに費やすコストが無駄だ。
そうしないとスケジューリングに費やすコストが無駄だ。
2012/07/06(金) 19:38:42.21
あまり賢そうに見えないな
31デフォルトの名無しさん
2012/07/06(金) 19:45:56.15 gpuが標準的になった時点で、非対称プログラミングが当たり前になるから、コア間に使い分け、役割分担が発生するのは必然じゃないかな。もっともどのコアがどの役割をやるかは、スケジューラが決めることになるけど。
2012/07/06(金) 19:58:44.83
標準的な入出力は動くコア決めたほうがいいかもしれんけど
プロセス、スレッドはどのコアで動こうが関係無いような
どうせ、暇な?コアに割り当てられるだろうから
プロセス、スレッドはどのコアで動こうが関係無いような
どうせ、暇な?コアに割り当てられるだろうから
2012/07/06(金) 20:28:22.95
linuxだとこういう指定が出来るようだ
ttp://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/sched_setaffinity.2.html
ttp://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/sched_setaffinity.2.html
2012/07/06(金) 22:01:45.18
それぐらいは WindowsNT 4.0 からあるが。
SetProcessAffinityMask
http://msdn.microsoft.com/ja-jp/library/cc429334.aspx
SetProcessAffinityMask
http://msdn.microsoft.com/ja-jp/library/cc429334.aspx
2012/07/06(金) 22:04:26.89
コア数とかうるさい割にapiのことは言わんのね?
36デフォルトの名無しさん
2012/07/21(土) 14:53:22.69 pスレッドについて教えてください。
関係性のない処理を行う2つのスレッドA、Bを同時に動かし始めたいのですが、
・スレッドAの待ち状態にpthread_cond_wait(&cond, &mutex1);
・スレッドBの待ち状態にpthread_cond_wait(&cond, &mutex2);
として(condは同じで、mutexが異なる)、これらを動かし始めるために別スレッドで
pthread_cond_broadcast(&cond);
をコールしたのですが、思ったとおりに動いてくれません。
なにがいけないのでしょう?
(pthread_cond_wait()の使い方を間違えている?)
関係性のない処理を行う2つのスレッドA、Bを同時に動かし始めたいのですが、
・スレッドAの待ち状態にpthread_cond_wait(&cond, &mutex1);
・スレッドBの待ち状態にpthread_cond_wait(&cond, &mutex2);
として(condは同じで、mutexが異なる)、これらを動かし始めるために別スレッドで
pthread_cond_broadcast(&cond);
をコールしたのですが、思ったとおりに動いてくれません。
なにがいけないのでしょう?
(pthread_cond_wait()の使い方を間違えている?)
2012/07/21(土) 14:57:02.99
馬鹿には無理
2012/07/21(土) 15:18:21.14
>>36
broadcast を受ける側のスレッドは、 broadcast するときに wait していなければいけない
broadcast したときに wait しているスレッドがいなければ、無駄撃ちになる
通常 cond が mutex と一緒に使われるのは、ターゲットが wait に入る一瞬前に broadcast を撃って運悪く外れたりするような事態を回避し、確実に当たるようにするため
思ったとおりに動いてくれないというのなら、あなたの使い方には何か誤りがあって、そういった問題を防ぎ切れていないのだろう
broadcast を受ける側のスレッドは、 broadcast するときに wait していなければいけない
broadcast したときに wait しているスレッドがいなければ、無駄撃ちになる
通常 cond が mutex と一緒に使われるのは、ターゲットが wait に入る一瞬前に broadcast を撃って運悪く外れたりするような事態を回避し、確実に当たるようにするため
思ったとおりに動いてくれないというのなら、あなたの使い方には何か誤りがあって、そういった問題を防ぎ切れていないのだろう
39デフォルトの名無しさん
2012/07/21(土) 15:33:58.32 >>38
素朴に待っていると思っていたスレッドが、実は待っていないせいで
シグナルがすり抜けていたということですね
このての、「関数を素朴に並べただけでは思いどおりに動作しない」問題の対応方法には
それぞれに決まった「お作法」「イディオム」がありそうな気がしますが、どうなんでしょう?
ともかく、ありがとうございました
素朴に待っていると思っていたスレッドが、実は待っていないせいで
シグナルがすり抜けていたということですね
このての、「関数を素朴に並べただけでは思いどおりに動作しない」問題の対応方法には
それぞれに決まった「お作法」「イディオム」がありそうな気がしますが、どうなんでしょう?
ともかく、ありがとうございました
2012/07/21(土) 15:42:20.05
2012/07/21(土) 15:49:59.71
>>40
頭で考えたアルゴリズムを実験するときに「安全装置」を省略したせいで
かんたんなこーどなのにはまるなんてありそうですね・・・・
自分が使いたい本番コードは、各スレッドの処理に十分なマスがあるので
素朴なつくりでもそれなりに動いたかもしれませんが、
再現性のないトラブルが発生する前にそういう問題を認識できてよかったです
ありがとうございました
頭で考えたアルゴリズムを実験するときに「安全装置」を省略したせいで
かんたんなこーどなのにはまるなんてありそうですね・・・・
自分が使いたい本番コードは、各スレッドの処理に十分なマスがあるので
素朴なつくりでもそれなりに動いたかもしれませんが、
再現性のないトラブルが発生する前にそういう問題を認識できてよかったです
ありがとうございました
2012/07/21(土) 16:06:39.87
>>41
去年の暮れ辺りに悩んでいたのが、mutexでスレッドプールを管理していたツールなんだよね。
mutexは相手がロックしていれば待つけど、相手がスケジュールはずされてロックしてくれていないと
自分が待たずにロックしちゃうことに。
メインスレッドでmutex_unlock(); mutex_lock()のように書いているのにunlockしたあと
lockするところまで実行できないなんてちょっと想像しにくいぞ。
# 詳細不明だけど、unlockした時点でプールスレッドがスケジュールされてメインスレッドがスケジュールからはずされるっぽい。
去年の暮れ辺りに悩んでいたのが、mutexでスレッドプールを管理していたツールなんだよね。
mutexは相手がロックしていれば待つけど、相手がスケジュールはずされてロックしてくれていないと
自分が待たずにロックしちゃうことに。
メインスレッドでmutex_unlock(); mutex_lock()のように書いているのにunlockしたあと
lockするところまで実行できないなんてちょっと想像しにくいぞ。
# 詳細不明だけど、unlockした時点でプールスレッドがスケジュールされてメインスレッドがスケジュールからはずされるっぽい。
2012/08/25(土) 18:20:47.36
いつでもどんな時にでも
スケジュールから外されても動かされても
大丈夫なように作るのが鉄則
スケジュールから外されても動かされても
大丈夫なように作るのが鉄則
2012/08/26(日) 08:54:03.71
そうそう。
だから、Web上のサンプルは当てにならない。
だから、Web上のサンプルは当てにならない。
2012/08/26(日) 09:32:08.49
そもそも並列化したいのは高速に処理したいからじゃん?
サンプルにかならずあるsleep()を消すと、途端にまともに動かなくなる
まともに動かなくなるならまだいいけど、「ときどき動作がおかしい」これ最悪
サンプルにかならずあるsleep()を消すと、途端にまともに動かなくなる
まともに動かなくなるならまだいいけど、「ときどき動作がおかしい」これ最悪
2012/08/26(日) 09:34:18.81
て言うかサンプルってそういうもんだし。
そもそも >>42 が
> mutexは相手がロックしていれば待つけど、相手がスケジュールはずされてロックしてくれていないと
> 自分が待たずにロックしちゃうことに。
って書いてるけど、それ以外にどんな動作を期待してるのか、よくよわからん。
そもそも >>42 が
> mutexは相手がロックしていれば待つけど、相手がスケジュールはずされてロックしてくれていないと
> 自分が待たずにロックしちゃうことに。
って書いてるけど、それ以外にどんな動作を期待してるのか、よくよわからん。
2012/08/26(日) 09:57:42.57
マトが止まっていないとシグナルがすり抜けちゃうなんて最初はわかんないでしょ
そんなことより、マトがトマるだって・・・・・!喜w
そんなことより、マトがトマるだって・・・・・!喜w
2012/09/01(土) 15:54:33.37
ダレモイナイ・・・・・・ダジャレオソルベシ・・・・・
素朴なQなんですが、マルチCPUのマシンで、
@ひとつのプロセスに属するスレッドは、全部同じCPU(プロセスがいる)で動く
Aひとつひとつのスレッドが独立してCPUを渡り歩いているように見えるのは、
スレッド単体ではなく、それの属するプロセスが渡り歩いているため
こういう理解は正しいですか?
素朴なQなんですが、マルチCPUのマシンで、
@ひとつのプロセスに属するスレッドは、全部同じCPU(プロセスがいる)で動く
Aひとつひとつのスレッドが独立してCPUを渡り歩いているように見えるのは、
スレッド単体ではなく、それの属するプロセスが渡り歩いているため
こういう理解は正しいですか?
2012/09/01(土) 15:58:04.54
スレッドの割り当てとかはOSが決めてることだからね
OSの挙動に影響しないようなことを考えながらやりませう
マルチCPUじゃなく
単一CPUの時のスレッド等の挙動を考えてみませう
OSの挙動に影響しないようなことを考えながらやりませう
マルチCPUじゃなく
単一CPUの時のスレッド等の挙動を考えてみませう
2012/09/01(土) 16:04:51.98
同じプロセッサ内のコアを移動するならまだしも、別のプロセッサに移動してしまったら、
せっかく溜め込んだキャッシュがおじゃんになってしまうのではないでしょうか?
せっかく溜め込んだキャッシュがおじゃんになってしまうのではないでしょうか?
2012/09/01(土) 16:11:29.80
逝ってるなマルチコアはCPU毎に命令データキャッシュ持ってるでしょ
2012/09/01(土) 16:12:43.77
でも分岐したらダメなのでは?
2012/09/01(土) 16:16:42.15
よく考えたら、分岐するんだったらCPU移らなくてもダメだった
ドピュッ
ドピュッ
2012/09/01(土) 16:27:35.25
命令の先読みとかやってるの知ってる?
同じ領域を読み込む場合に早くなるってのがキャッシなのでは?
HDDキャッシュとかも同じでしょ
同じ領域を読み込む場合に早くなるってのがキャッシなのでは?
HDDキャッシュとかも同じでしょ
2012/09/01(土) 16:29:03.73
別のプロセッサに移動してしまったらキャッシュとかおじゃんになってしまうかもしれないが、
ひとつのプロセッサに多数のスレッドが集中して別のプロセッサを遊ばせておくくらいならいくつかのスレッドを移した方がいい場合もある
OSの裁量次第
ひとつのプロセッサに多数のスレッドが集中して別のプロセッサを遊ばせておくくらいならいくつかのスレッドを移した方がいい場合もある
OSの裁量次第
2012/09/01(土) 16:32:16.93
キャッシュ知らんでも
スレッド系のプログラム作るのには関係無いような
速度ウンタラは動いてから考えればいい話でしょ
スレッド系のプログラム作るのには関係無いような
速度ウンタラは動いてから考えればいい話でしょ
2012/09/05(水) 01:11:52.99
初心者の質問です
new;した領域 p があって
スレッドAは条件によってdelete p;をする
スレッドBはpを参照する
この時に
変数 blReference, blDeletingを使って
Aの処理中 delete部分
while( blReference ){ Sleep(1); }
blDeleting= true;
delete p;
p = NULL;
blDeleting = false;
Bの処理中 参照部分
while( blDeleting ){ Sleep(1); }
blReference = true;
char* cp = (char*)p:
//以下参照
blReference = false;
っていうのは安全でしょうか?
new;した領域 p があって
スレッドAは条件によってdelete p;をする
スレッドBはpを参照する
この時に
変数 blReference, blDeletingを使って
Aの処理中 delete部分
while( blReference ){ Sleep(1); }
blDeleting= true;
delete p;
p = NULL;
blDeleting = false;
Bの処理中 参照部分
while( blDeleting ){ Sleep(1); }
blReference = true;
char* cp = (char*)p:
//以下参照
blReference = false;
っていうのは安全でしょうか?
レスを投稿する
ニュース
- 【速報】中国、水産物輸入停止と通達 日本政府に ★2 [おっさん友の会★]
- 中国側が首相答弁の撤回要求、日本側拒否★6 [夜のけいちゃん★]
- 高市首相答弁を“引き出した”立民・岡田克也氏が改めて説明「なぜ慎重な答弁をされなかったのか。非常に残念に思っている」 [ぐれ★]
- 【速報】 米大使「はっきりさせておこう、米国は尖閣諸島含め日本の防衛に全面コミット、中国がどうしようが変わらない」 [お断り★]
- 「厚かましい挑発的発言だ」中国国連大使が高市首相発言に強く反発 日本の常任理事国入りに明確に反対 [ぐれ★]
- 自民、経済対策で子ども1人に2万円給付へ 児童手当に上乗せ 所要額は約4000億円 [ぐれ★]
- 【高市訃報】ホタテ業者、死亡😇😇😇 [573041775]
- 「日本の保守層のご機嫌を取りながら、中国、ロシア、アメリカのご機嫌も取る」👈こういう総理がいれば良かったよな [762037879]
- 高市早苗 「靖国神社電撃参拝」説が浮上 [163661708]
- 【朗報】ウヨの姫小野田大臣、吠える「何か気に入らないことがあったらすぐに経済威圧をする国に依存するのはリスク」脱アメリカを宣言 [856698234]
- 【終国悲報】高市早苗、たったの10日で莫大な経済的損失を叩き出す [165981677]
- 【緊急】高市早苗 月内辞任か [695089791]
