OpenMPプログラミング

**デフォルトの名無しさん** · NG

オフィシャルサイト
http://www.openmp.org/

リンクなどは>>2以下で

**120** · 2007/09/21(金) 00:15:35

今日いろいろ簡単なテストプログラムを組んでいたのですが
かなり大きな配列を含む範囲を
単にパラレルリージョンに指定しただけのプログラムは
１CPUのときの1/3程度まで低下すると言う現象がありました。
（並列化を指定すると４CPUで３．８倍程度にちゃんとなりました）
同じ動作をするスレッドが複数あってメモリが競合してるんですかね？
あしたスレッドチェッカーの体験版でも落として調べてみます。
>>121
今日試してみたところうちの環境では
100000回ループするプログラムの内と外に
$omp parallel ～　$omp end parallel
をおいたプログラムをそれぞれ比較したのですがほとんど差はありませんでした。
リージョン内は簡単な内容だったのですが、
リージョン内のプログラムの内容によってもスレッド生成・消滅のオーバーヘッドは変わってくるんですかね？

>>122
並列化の指定をする前にまず並列化予定の範囲をパラレルリージョン指定して
ちゃんと動くのかを確認したかったのです。

長文失礼

**デフォルトの名無しさん** · 2007/10/10(水) 15:20:28

sections分割でsection分けを行った時に、
自分でどのスレッドに割り当てる的な事は
できないのでしょうか？

**120** · 2007/10/25(木) 21:51:43

いまさらながら経過報告
元となったプログラムが古いものだったので、配列をallocateするのではなく
メインの宣言でかなり大きくとっていたのですが、
それを必要量にしたところかなり早くなりました。
ただ強い最適化(fastオプションとか)つけると
OpenMPはそんなにスピードが上がらずシングルスレッドに追いつかれてしまうんですけどね。

**デフォルトの名無しさん** · 2007/11/30(金) 04:25:29

サーセーン。素人の恥ずかしい質問です。

OpenMPは従来の(OSなどに付属した)スレッドのライブラリの
置き換えとしては使用すべきではないのでしょうか？

（どこかで逐次プログラムの並列化がOpenMPの利用の前提であるとか見たのですが、）
並列で動くことが前提であるプログラム（例：HTTPデーモンなど）を
OpenMPを使って書こうと思っているのですが、止めたほうがいいのでしょうか・・・。

**126** · 2007/11/30(金) 04:26:29

うわぁ、このスレ伸びてないんだなあ。悪いけどage

**デフォルトの名無しさん** · 2007/12/01(土) 01:58:56

OpenMP はひとまとまりの大きなデータ（行列とか画像とか）に対する計算を
複数のスレッドで並列化するのに向いている希ガス。つまりデータ並列向き。
データ並列性のある for 文で書かれたアルゴリズム（行列ベクトル積とか
画像のしきい値処理とか）は parallel for ディレクティブでいとも簡単に並列化できる。
そこが OpenMP のおいしいところ。

タスク並列の並列プログラム、つまり各スレッドが独立に違う処理をする
（例えばそれぞれ別のクライアントからの要求を処理する）並列プログラムも
OpenMP で書けるけど、あまりうまみがないと思われ。

逐次プログラムを並列化するのが前提というのは違う気がする。
ただ、例えば parallel for ディレクティブしか使ってない並列プログラムは
コンパイラの OpenMP 機能をオフにすれば逐次プログラムとしてコンパイルできる。
そこが他の並列化手法（POSIXスレッドとかMPIとか）と違うところ。

でも、OpenMP機能をオフにするとコンパイル不能になる並列プログラムも書けるし、
parallel sections を使ったプログラムは逐次プログラムとしてコンパイルはできても
意味が変わってしまう（各セクションが順番に逐次実行される）。
つまり、この手のプログラムは並列で動くことが前提で書くわけだ。

結局のところ、OpenMP を使うのが妥当かどうかは126さんがやりたいことに依る。
並列性の高いデータ並列の計算をやりたいなら使う価値がある。

**デフォルトの名無しさん** · 2007/12/01(土) 02:04:37

追加。OpenMPでHTTPデーモンを書いた、という報告を見たことがあったのを思い出した。
http://www.nic.uoregon.edu/iwomp2005/Papers/f35.pdf
俺は詳しく読んでないので内容についてはノーコメント。参考までに。

**デフォルトの名無しさん** · 2007/12/01(土) 13:39:21

並列化した部分じゃbreakやreturn使えないし、難しかっただろうなぁ。
普通のWindowsプログラムでCreateThreadをOpenMPで置き換えろって言われたら・・・
メッセージポンプ使ってなんとかなるんだろうか

**デフォルトの名無しさん** · 2007/12/01(土) 23:44:51

＞並列化した部分じゃbreakやreturn使えない

kwsk

**126** · 2007/12/03(月) 05:18:50

スレッドを横断したbreakやreturnが出来ないということでは？
字句上は単なるスコープにしか見えないので、出来そう・・・しかし出来ないもどかしさ(何)。

>>128
ご返答ありがとうございます。
128氏から頂いた意見も考慮に入れつつ、色々と検討してみた結果、
今回やりたいことにはOpenMPは適していない、という判断に至りました。

しかし実験的にHTTPサーバらしきものをOpenMPを使って書いてみたところ、
簡単なものならかなり簡潔に書けることも分かり、、全てでなくとも部分的にOpenMPを使うのもありかと思えました。

**デフォルトの名無しさん** · 2007/12/05(水) 05:51:33

>>119の方法で
VC2005ExpressEditionで使えるようになったはいいんだけど
forループの所に
#pragma omp parallel for
ってやっても
error C3005: ';' : OpenMP 'parallel' ディレクティブでは予期しないトークンです
とかいうエラーが発生して使えないんだけど何故なの？？

#pragma omp parallel sections
とか他のは通るけど，forループのだけどうしても使えん・・・

#pragma omp parallel
{
#pragma omp for
・・・
}
にすると
error C3001: 'if' : OpenMP ディレクティブ名が必要です
って言われる

**デフォルトの名無しさん** · 2007/12/17(月) 18:47:08

>133
#pragma .. の行末に ';' がついてるとかいうオチだったら素っ裸で町内１周してこい

**デフォルトの名無しさん** · 2008/01/04(金) 15:12:19

すでにあるプログラムをOpenMP化しようと思うのですが、以下のような場合にfuncがスレッドセーフで再入可能であれば問題ないですか？
#pragma omp for
for(int i=0;i<100000;i++)
{
func(i);
}

**デフォルトの名無しさん** · 2008/01/04(金) 15:53:58

問題ないです
func()の定義が別ファイルでもおk

**デフォルトの名無しさん** · 2008/01/04(金) 16:38:48

>>136
ありがとうです。
OpenMPはSMPで使う分にはかなり便利ですね。

**sage** · 2008/02/06(水) 21:13:32

IntelFortran10.0で数値解析やってるんですけど
サブルーチン内で並列化領域をつくるのと
サブルーチンごとメインに展開して並列化領域つくるのとで
並列化時の速度が異なったり(逐次だとほぼ一緒)
逐次計算部分にある並列化と関係ないサブルーチンを
コメントアウトするかしないかで並列化時の速度向上が変わります。
並列スレッドのスタックサイズとかの問題なんでしょうかね。　

**デフォルトの名無しさん** · 2008/02/06(水) 22:02:55

速度や速度向上が具体的にどう違うの？

**デフォルトの名無しさん** · 2008/02/07(木) 00:50:56

まず、各CPUに処理が効率よく割り振られているか、CPUの負荷率を見てみたらいいんじゃないか？

**デフォルトの名無しさん** · 2008/02/13(水) 15:49:52

VC++2008でコンパイルするとVCOMPD.libが無いというエラーが出ます。
VCOMPD.libはどこで手に入りますか？

**デフォルトの名無しさん** · 2008/02/13(水) 16:40:58

>>141
VS2005だとPro版以上でサポート。VS2008も同じだと思う。

**デフォルトの名無しさん** · 2008/02/13(水) 20:12:04

>141
vcompd.libはProfessional版以外手に入れる方法はない。

ただしリリースビルド版のライブラリであるvcomp.libは
Windows Server 2008 SDKをインストールするとゲットできる。

デバッグビルドでもリリースビルドのライブラリ(vcomp.lib)を
リンクする設定にするとExpressでもOpenMPが自由に使用可能。

**デフォルトの名無しさん** · 2008/02/15(金) 14:05:13

たとえば、ソケットのread/writeのwait待ちをやっているslect(poll)のようなもので
while(1)
#pragma omp parallel sections
{
#pragma omp section
read後その処理
#pragma omp section
write後その処理
}
で、ここで、暗黙のwaitがかかると思われるが、select的な使い方って、出来る？

sectionの跡にnowaitをいれといたらよいだけ？

**デフォルトの名無しさん** · 2008/02/15(金) 14:26:50

nowaitを入れた場合、どのスレッドが生き残るのでしょうか？
それとも、並列実行するところはすべて子スレッドで、実行中のスレッド数が最大より1少なくなった時点で
メインスレッドが継続されるのでしょうか？

**デフォルトの名無しさん** · 2008/02/15(金) 16:42:54

read/writeのtimeoutを入れておけば、なんとかなりますか。
しかし、openmp（のsections）では、スレッドは、死にますか？
一応、処理が終われば、lockが外れるだけでしょう（gccの実装ではそのようです）

**sage** · 2008/03/01(土) 00:47:47

スレッドプロファイラー使ってる人居るかな。
あのREGIONS　VIEWの各リージョンの範囲はなにで決まってるの?
同期から同期の間かと思ってたんだけどソースの位置みるとちがうっぽい。
最適化オプションのせいでソースとの対応がとれなくなってるのかしらん。

**１３８** · 2008/03/04(火) 19:19:48

chkstkという関数に要する時間が
OpenMPにすると凄まじく増えているのが原因のようでした。
関数に引き渡す配列が多すぎなのか。

**デフォルトの名無しさん** · 2008/04/06(日) 10:57:30

>>148
私もintel fortran10+mkl+openmpで数値計算しています
openmp初心者の私は、intelのopenmpのドキュメントを参考にしました。

parallel do ,sections ,reduction,privateあたりしか使っていませんが、オリジナルの
プログラムのマルチスレッド化は割と簡単に出来、計算時間も「ほぼ」スレッド数倍
にできました。
（当然ですがparallel region部分です。プログラム全体ではありません）

そもそもchkstkは並列処理できるかどうかを検討してはどうですか。
各スレッドで相互参照するのであれば、reduction宣言等が適切であれば問題ないはず。

**デフォルトの名無しさん** · 2008/04/09(水) 22:52:21

>>148
関数のエントリ近辺で chkstk が呼び出され、必要に応じてスタックが拡張される
（実メモリが割り当てられる）わけですが、シングルスレッドの場合は一度拡張された
スタックはもちろん再利用されるので負荷が軽いわけです。

スタックはリニアなアドレスに(ページング機構を用いて)メモリを割り当てる必要があるため、
割り当てられたページを再利用できない場合には時としてヒープよりも確保・解放が重い
メモリとなります。マルチスレッドでスタックが頻繁に成長するような場合には、メモリを
スタック上に取るのをやめて、std::vector などを用いてヒープから確保した方がよいと
思います。

たどたどしい説明になってしまった。

**デフォルトの名無しさん** · 2008/05/12(月) 19:46:23

・アプリケーションAが、calc1.dll と calc2.dll を呼んでいる
・calc1.dll と calc2.dll は共に IntelCompiler で OpenMP を使って並列化
・calc1.dll のルーチンは問題なく呼べる
・calc2.dll のルーチンを呼ぶと、

　　OMP abort: Initializing libguide.lib, but fount libguide.lib already initialized

　を表示して落ちる／(^o^)＼

ネットを漁ってみて、環境変数 KMP_DUPLICATE_LIB_OK を TRUE にしてみたり
libguide.lib の代わりに libguide40.lib を使ってみるも効果なし

複数の DLL が Intel の OpenMP 使ってるとアウト？
そうなると DLL じゃ使えねーってハナシになるんですが・・・・

**デフォルトの名無しさん** · 2008/05/19(月) 17:00:29

>>143
Windows Server 2008 SDKにvcompd.libも入ってるみたい。

**デフォルトの名無しさん** · 2008/07/19(土) 15:25:36

GCCで4.3.1でOpenを利用するためのconfigureオプションを教えてください。
makeしてインストールしたgccを利用すると#include <omp.h>で
ファイルが無いと言われて困ってます。
gcc-4.3.1\libgomp\omp.h.in
は存在するのですが、どうすればいいのでしょう？configureは
./configure --enable-threads=win32 --with-system-zlib で行いました。

**デフォルトの名無しさん** · 2008/07/19(土) 15:30:42

Open => OpenMPのミスです。

**デフォルトの名無しさん** · 2008/07/19(土) 16:30:35

OpenMPが使えるGCCを自前でビルドしたことはないけど
MinGW用のGCC 4.3.0でgcc -vとしてバージョンを表示させると
configure時のオプションがずらっと表示される。

> gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks
--enable-version-specific-runtime-libs --build=mingw32 --with-bugurl=http://www.mingw.org/bugs.shtml
--prefix=/mingw --with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root
--with-libiconv-prefix=/
mingw/src/gcc/libiconv-root
Thread model: win32
gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC)

参考までに。

**デフォルトの名無しさん** · 2008/08/29(金) 10:56:03

OpenMPを使って一次元配列から最大値、最小値を求める方法を教えてください。

**デフォルトの名無しさん** · 2008/08/29(金) 13:00:28

reductionにminやmaxは無いんだよな。
俺はスレッド数を取得して解決した気がする。
大雑把に書くとこんな感じ。

int n_thread = omp_get_num_threads();
int imin = INT_MAX;

#pragma omp parallel for shared(imin, array)
for ( int j = 0; j < n_thread; ++j ) {
int imin_ = INT_MAX;
int offset = size/n_thread*j;
for ( int i = offset; i < offset+size/n_thread; ++i ) {
imin_ = min(imin_, array[i]);
}
#pragma omp critical
{
imin = min(imin, imin_);
}
}

**デフォルトの名無しさん** · 2008/08/30(土) 07:56:40

俺が　mingw用　gcc4.3.2をビルドしたときのコマンド　configureとmakeの行は実際は1行
------------- configure_gcc.sh -----------------
#!/bin/sh

export LC_ALL=C

../source/gcc-4.3.2/configure --prefix=/mingw --host=mingw32 --build=mingw32
--target=mingw32 --program-prefix="" --with-as=/mingw/bin/as.exe
--with-ld=/mingw/bin/ld.exe --with-libiconv-prefix=/mingw --with-gcc
--enable-libgomp --with-arch=i686 --with-tune=generic --with-gnu-ld
--with-gnu-as --enable-threads=win32 --disable-nls
--enable-languages=c,c++,objc,obj-c++,fortran --disable-win32-registry
--disable-shared --with-dwarf2 --disable-sjlj-exceptions
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--enable-version-specific-runtime-libs --enable-hash-synchronization
--enable-libstdcxx-debug --disable-bootstrap --with-bugurl=http://www.mingw.org/bugs.shtml
---------------------------------------------

------------- make_gcc.sh ---------------------
#!/bin/sh

export LC_ALL=C

make BOOTCFLAGS="-O2 -D__USE_MINGW_ACCESS" CFLAGS="-O2 -D__USE_MINGW_ACCESS"
CXXFLAGS="-O2 -mthreads" LDFLAGS="-s -Wl,--stack=0x2000000" 2>err.log
----------------------------------------------

**デフォルトの名無しさん** · 2008/08/30(土) 14:04:15

>>157
> reductionにminやmaxは無いんだよな
あれ、あったと思うけど・・・。
reduction(min:unko)
とか。Fortran でしか使ったこと無いけど。
でもどのアドレスでminだったか、とかを取得したいときは
結局 shared にしちゃうんだけどね。

**デフォルトの名無しさん** · 2008/08/30(土) 14:19:32

C/C++だとmin/maxは演算子どころかビルトイン関数ですらないから無理だと思う。

**159** · 2008/08/30(土) 17:17:59

>>160
そうなんだ。Cはバイナリをどうしても読みたいときにいやいや
使う程度だから知らなかったよ。
でもFortranでもmin,max関数はあまり使われないんだけどね。
１５６のがFortranでよかったら、

unkomin = 1.0e+10
unkomax =-1.0e+10
!$omp paralell do private(i,a) shared(unko)
!$omp& reduction(min:unkomin) reductionmax:unkomax) shared(unko)
do i = 1, 100
a = unko(i)
if (a .LT. unkomin) unkomin = a
if (a .GT. unkomax) unkomax = a
enddo
!$omp end parallel do
write(*,*) unkomin,unkomax

みたいな感じでいけると思うよ。いまコンパイラ使えないからチェックできないけど。
非OpenMPでコンパイルしてもちゃんと動く・・・はず。

**159** · 2008/08/30(土) 17:19:44

reductionmax は reduction(max ね。

**デフォルトの名無しさん** · 2008/09/04(木) 22:56:21

２次元配列変数は、reductionで使えないんでしたっけ？

**デフォルトの名無しさん** · 2008/09/07(日) 13:20:49

NG。
ifortは出来た気がする。

**デフォルトの名無しさん** · 2008/09/07(日) 13:26:10

#pragma omp for
#pragma omp parallel for

てなにが違うの？

**デフォルトの名無しさん** · 2008/09/07(日) 17:53:44

#pragma omp for は #pragma omp parallel ブロックの中に書く必要があるが、
parallelブロックにforブロックが１つのことも多いので
#pragma omp parallel for でまとめて書けるようにしてある。

**デフォルトの名無しさん** · 2008/09/09(火) 22:58:56

なるほど。

**デフォルトの名無しさん** · 2008/09/16(火) 07:09:33

>>143　>>68
スレチな質問で申し訳ないのだけどdllをリンクする設定を
教えて頂けないでしょうか
>>119を参考に
WindowsVista+Visual Studio2005 standardで
Microsoft Windows Software Development Kit for Windows Vistaと
vcredist_x86.exeでReleaseのビルドは通るようになった

で>>68を参考に
インストーラーを作ってみたのですが
C\ProgramFiles\Microsoft Visual Studio 8\VC\redistに入ってしまい
winsxsには入ってくれません…

**デフォルトの名無しさん** · 2009/01/21(水) 13:22:31

並列化前後で答えが変わってしまいます。どこがおかしいのでしょうか？

//画像上でランダムで数点選んできた線との距離が最少になる座標を算出
#ifdef _OPENMP
#pragma omp parallel for private(data,x,y,a,b,i,error)
#endif
for(j=0;j<KURIKAWSIKAISUU;j++){
better_error[j] = 1000;//距離初期化
for(y=100;y<=HEIGHT-100;y++){
for(x=100;x<=WIDTH-100;x++){
error = 0;
get_randum_number(data); //ランダムでデータNo.を選択

for(i=0;i<ITIDONIERAZUKAZU;i++){
error += abs(y - a[data[i]]*x - b[data[i]]) / sqrt(1+pow(a[data[i]],2));
}
error /= select;
if(better_error[j] > error){
better_error[j] = error;
ans[j].x = x;
ans[j].y = y;
}
}
}
}

**デフォルトの名無しさん** · 2009/01/21(水) 14:08:01

よくわかんねけど
get_randum_number
で配列dataにはいる乱数が変わるからじゃね？
たぶん呼ばれる順番が並列と１CPUのときで違うだろうから。

ループ内で乱数つくらないで、でかい乱数用の２次元配列
data0[KURIKAWSIKAISUU][ITIDONIERAZUKAZU]
をループが始まる前に「並列処理しないで」作ってから
(配列data0をshared属性付けて)ループ処理するといいかも。
計算は遅くなりそうだけどね。

**デフォルトの名無しさん** · 2009/01/21(水) 14:12:47

んでループ内で乱数生成してた部分は
for (i=.....){data[i]=data0[j][i];}
と乱数値の複製に置き換える、と。

**169** · 2009/01/26(月) 11:03:50

>170
>171
ありがとうございます。
いただいた意見を参考に修正し、できたらご報告します。

**デフォルトの名無しさん** · 2009/01/26(月) 11:33:59

マルチスレッドでrand()使うと全然ランダムじゃないデータが出てくるよ

**デフォルトの名無しさん** · 2009/01/26(月) 12:52:37

rand_r

**デフォルトの名無しさん** · 2009/02/24(火) 20:57:22

gcc-4.3 で OMP を使い始めました。初心者で正しい使いかたをしている
かどうか判然としません。/proc/cpuinfo で cpufamily 6, model
23 (Harpertown と呼ぶらしい)と表示されるXEONでは確かに速くなるので
すが、cpufamily 15 model 4 (Nocona と呼ぶらしい) では非常に遅くな
ります。これは正しい振る舞いでしょうか。時間は
clock()/CLOCKS_PER_SEC; で測っていますが、これで正しい判断ができる
のでしょうか? 並列化すれば速くなる速度のネックになっている部分を
探す方法はあるのでしょうか? 並列化できるかどうか判然としない部分
を並列化可能なコードに書き直してくれるようなソフトはないでしょうか?

**デフォルトの名無しさん** · 2009/02/24(火) 23:13:22

どうせNoconaの方はデュアルCPU構成じゃなくてしかもHT無効というオチだろ。

**デフォルトの名無しさん** · 2009/02/25(水) 00:35:19

Nocona の /proc/cpuinfo は
processor : 0
..
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 3.80GHz
stepping : 3
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts nopl pni monitor ds_cpl est tm2 cid cx16 xtpr

となっています

**デフォルトの名無しさん** · 2009/02/25(水) 23:58:19

環境変数 OMP_NUM_THREADS などでスレッド数を指定してますよね。
明示的に指定しないと環境によってスレッド数が1になったりコア数になったりします。

きちんと並列実行できているのに 4-way Nocona で並列性能が出ないとすると
応用依存の問題かと。例えばメモリ帯域幅がネックになっているのかも知れません
（Harpertown ではメモリ帯域幅が足りていて Nocona では足りていないとか）。
どういう計算をしているのかを書くともっと直接的なアドバイスが得られるかもです。

計時の仕方はそれでいいと思います。精度が気になるなら RDTSC について調べると良さげ。

速度のネックになっている部分は、皆目見当がつかないならプロファイラが利用できます。
GCC なら -pg オプション付きでコンパイル、プログラム実行後に gprof コマンドを使って
統計情報を得ます。

時間のかかっている部分が分かったとしてそれを並列化して高速化できるかは別問題。
OpenMP はループを分割して並列化するのがお手軽で効果的ですが、
それができるのはループ間にデータの依存関係がない場合です。
a[i] += a[i-1] のように前後の反復の計算結果を利用したり、
配列の同じ要素に書き込むといった処理がデータ依存性の典型例です。
データ依存関係がある場合はコードを書き換えないと普通は並列化できません。
このあたりは並列プログラミングの普遍的な課題で、対策はケースバイケースです。

自動並列化は研究レベルではよく聞きますが実用的なツールは寡聞にして知りません。
よい自動並列化ツールがあれば私も試してみたいです。

**デフォルトの名無しさん** · 2009/02/26(木) 01:53:54

Intel C++ Compiler 11.0の自動並列化オプション(-parallel)でSPEC CPU 2006のいくつかのベンチマークが高速化しているが
実際のコードでどれだけ役に立つかは使ったことが無いのでわからない

**デフォルトの名無しさん** · 2009/03/07(土) 23:30:29

OpenMPの効果を調べるため、同じコードを、gfprtranで二通りにコンパイルして実行してみました。
全然速くなりません。むしろ遅くなっています。実行方法やコードが間違っているのでしょうか？
gcc version 4.3.2 (Debian 4.3.2-1.1)

$ gfortran -fopenmp test.o -o test_omp.out
$ time ./test_omp.out
real 9m14.642s
user 3m51.902s
sys 4m22.468s

$ gfortran test.o -o test.out
$ time ./test.out
real 1m15.142s
user 1m14.809s
sys 0m0.340s

CPUは...(/proc/cpuinfoの抜粋)
model name : Intel(R) Pentium(R) D CPU 2.80GHz
cpu MHz : 2793.101
cache size : 1024 KB
cpu cores : 2

**180** · 2009/03/07(土) 23:32:33

ソースコードは
module ompParam
use omp_lib
implicit none
!integer :: OMP_GET_NUM_THREADS
!integer :: OMP_GET_THREAD_NUM
integer :: myid ! thread ID
end module ompParam

program variation !(coeff, NUM)
!$ use ompParam
implicit none
integer :: i, j, k
integer :: maxI=1000, maxJ=100, maxK=1000
integer :: NUM
double precision, allocatable :: coeff(:,:)
double precision :: alpha ! random number

NUM=1000
allocate( coeff(NUM, maxK) )
coeff(:,:) = 0.0d0

**180** · 2009/03/07(土) 23:33:54

（続き）
!$omp parallel num_threads(2) private(myid, i, j, k, alpha)
!$ !myid = OMP_GET_THREAD_NUM()
!$ !write(*,*) '(Number of threads in front of do)=', myid

open(unit=100, file='data.bin', form='unformatted', status='unknown')

!$OMP DO
do k = 1, maxK
do j = 1, NUM
do i = 1, maxI
call RANDOM_NUMBER( alpha )
coeff(j,k) = coeff(j,k) + alpha

!$ !myid = OMP_GET_THREAD_NUM()
!$ !write(*,'(3(A4,I3),A37,I2)') 'k=', k, 'j=',j, 'i=', i, 'Number of threads at the end of do:', myid
end do
coeff(j,k) = coeff(j,k) / maxI
write(100) coeff(j,k)
end do
end do

!$omp master
!$ !myid = OMP_GET_THREAD_NUM()
!$ !write(*,*) '(Number of threads after the do)=', myid
!$omp end master
!$omp end parallel
end program variation

**デフォルトの名無しさん** · 2009/03/08(日) 14:53:53

gfortranは良くしらんけど・・
環境変数で使うＣＰＵの数を指定してみて。
setenv OMP_THREAD_NUM 2
とか。プログラム内で明示しているからいらない気もするけど、まあ
正確にはマニュアルで確認してね。

あとは、I/O(read,write文)はparallel文の外で
するのが吉。この例だと、open(100,....) と write(100)....は
!$omp end parallel
の後でする。ふつうI/OはプライマリのCPUが単独で担当させる方が安全。
同じファイルに複数のプロセスが書き込みしようとすると
順序の保証が無くなるのであとで使いにくいし、書き込みの順番待ちが
発生するのでのろくなる。

乱数代入のループだけなら1/2になっている可能性大。そうなら
作ったコードは一応OpenMPとして動作している・・・と思う。

**180** · 2009/03/09(月) 17:16:44

>>183
ありがとうございます。実行シェルは作らず、そのまま
$time ./test_omp.out
という風にやっていました。これから実行シェルを作って見ようと思います。

あと、i/oを外に書いたら、確かに一割ほど速くなりました。
でも、それでも圧倒的にOpenMPは遅いです...

**180** · 2009/03/09(月) 17:18:47

乱数を使わないプログラムだとOKでした！！

~/test$ /bin/csh ./testOMP_exec.sh
Normal version executing...
2.2u 0.0s 0:02.20 100.4% 0+0k 0+1584io 0pf+0w

OpenMP version executing...
2.1u 0.0s 0:01.14 190.3% 0+0k 0+1584io 0pf+0w

資源使用率190%！！乱数発生器がパラレルに対応していなかったようです。
アドバイス、ありがとうございました。

**183** · 2009/03/10(火) 04:04:33

あ、そっか
乱数生成って種を使いまわすから、並列のときは最初に疑うべきだったね。
あまり役に立たなかったっぽいけど、
とりあえず、おめでとう。

**デフォルトの名無しさん** · 2009/04/19(日) 07:32:44

基本的な質問です。
#pragma omp for
でループを分割してもompを使わないときと差が出ないのですが
もしかしてループの外の資源にアクセスするとき、各スレッドは
排他制御してるってことなんでしょうか。

SSEとかで要素に演算を加えてるだけなんですけど・・・

外から渡された配列とか、mallocしたメモリとか、分割して処理
したいんですが、どこをどういじると改善されるのでしょう？

**デフォルトの名無しさん** · 2009/04/19(日) 09:11:48

>>187
確認だけど #pragma omp for を parallel リージョンで囲んでる？
もし囲んでないなら #pragma omp parallel for としないと並列化されないよ。

**デフォルトの名無しさん** · 2009/04/19(日) 10:08:48

>>188
はい、それはやってます。
中でスレッド数を確認するときちんとコア数分表示されます。

**デフォルトの名無しさん** · 2009/04/28(火) 10:36:42

>>187
外からのメモリは問題ないと思うけど。
ループ間の依存関係がないか、I/Oなど想定外の依存関係がないか、要チェックで。

**デフォルトの名無しさん** · 2009/05/08(金) 04:21:24

OpenMPで並列化することをやってみたのですが、
GCCの方がICCよりも圧倒的に速いのですが、こんなことはよくあるのですか？
ちなみにOptionは

GCC(4.3.2)：　-O3 -fopenmp -funroll-loops
ICC(11.0.0)：　-O3 -openmp -openmp -openmp-lib compat

コードはこんな感じのがいくつもあります。
GCCでうひょ早っ！と思ったので、ICCならもっとと思ったのですが、
そうならないのがびっくりです。何かいけないことはありそうでしょうか？
一応どちらも並列化はされており、CPU使用率はほぼ１００％になっています。

void func(void){
7 int i,j,k;
8 unsigned char index_x;
9 #pragma omp parallel for private(i,j,k,index_x)
10 for(i=0;i<XS-1;i++){
11 for(j=1;j<YS-1;j++){
12 for(k=1;k<ZS-1;k++){
13
14 index_x = IDX[i][j][k];
15
16 AX[i][j][k] = CX[index_x]*AX[i][j][k]
17 + CLY[index_x]*(BZ[i][j][k]-BZ[i][j-1][k])
18 - CLZ[index_x]*(BY[i][j][k]-BY[i][j][k-1]);
19 }
20 }
21 }
22 }

**デフォルトの名無しさん** · 2009/05/08(金) 04:25:11

>>191
ちなみにCorei７　９６５での話です。

**デフォルトの名無しさん** · 2009/05/08(金) 09:10:20

>>191
＞何かいけないことはありそうでしょうか？
・オプション指定辺り。
・時間の計測方法。

見たところ、gccにはunrollのヒントを与えているのにiccには与えていないように見える。
icc11が標準でunrollしたかどうか、記憶していないが影響があるかも知らん。
それと、gccでもiccでも言えることだがソース全部を見ないことには細かいことは判らん。
例えば、icc -fastでOpenMPを使わない場合の所要時間を測ってみてはどうだろう。

いずれにしても、iccスレ向きのネタになりそうだが。

**デフォルトの名無しさん** · 2009/05/08(金) 12:03:19

shared属性になる変数を大局変数で指定してるよね？念のため。

ifortだと-O2以上でunrollingはするけどiccだとどうなんだろう。

**,,・´∀｀・,,）っ-○○○** · 2009/05/08(金) 23:49:12

ICCなら-QaxSSE4.2くらいは最低限だろう。

**デフォルトの名無しさん** · 2009/05/09(土) 04:30:16

-ax??? /Qax???
ってかえって遅くなること無い？
コードにもよるだろうけど自分のはかえって遅くなるから切ってる

**デフォルトの名無しさん** · 2009/05/09(土) 07:47:19

結局いろいろなオプションを試してみましたが、 iccはgccには歯が立ちませんでした。
iccは結構高いので、かなりガッカリしてます。orz...

**,,・´∀｀・,,）っ-○○○** · 2009/05/09(土) 11:34:06

たしかにlibgompは優秀
SIMD化されてないように思えるのだが

kをOMPによる並列化対象から外して-QxSSE4.2とかってのはどう？
たしかSIMD化とスレッド化は両立できなかったような

**デフォルトの名無しさん** · 2009/05/10(日) 05:00:40

icc の -openmp-lib compat って必須だったけ？

**デフォルトの名無しさん** · 2009/05/10(日) 05:09:57

追加。
１９１の例だとcx,cly,clzの要素を参照するときに干渉が起こってそう。
たぶん一次元でそんなに大きくない配列だろうから、添字iとjのループの間で
この３変数をコピーしてみてはどうだろうか？
localcx[n]=cx[n]...みたいな。んでlocalcx, localcly...はprivate属性を付ける。
並列で無い場合には余計な動作だからかえって遅くなりそうだが。
gccはそこをうまくさばいているのかもしれないな。
>>198
お団子ありがとうw
おそらく添字kのループはunrollingの対象になるから、
そのままprivateな並列対象のままで良い気もするけどどうだろう？

**デフォルトの名無しさん** · 2009/05/10(日) 05:13:51

さらに追加。cx, cly, clz については
CLY[index_x]=CLY[(IDX[i][j][k])]なんだから、
CLY[i][j][k] で表現できると思うんだけど。
暴力的ないい方だけど今ってメモリが青天井に近いから
係数の3次元配列つくってもいいんじゃないかな？

いずれにしてもコードいじるからなあ・・・。gccで幸せならそのまま、という手も。

**デフォルトの名無しさん** · 2009/05/10(日) 21:24:42

そうか

**デフォルトの名無しさん** · 2009/05/11(月) 16:23:48

フリーソフトウェア最高や！
ぷろぷらICCなんか最初からいらんかったんや！

**デフォルトの名無しさん** · 2009/05/12(火) 09:56:25

OpenMPはいざ知らず、普通のプログラムでiccは随分賢いコードを吐くよ。
後はあれだ、MKLのOpenMP対応は生半可じゃなくリニアリティが高い(投入コア数とパフォーマンスがよく比例する)。

**デフォルトの名無しさん** · 2009/05/12(火) 10:55:45

ifortで使ってるけど、16CPUくらいまでならいいよね。
経験的には32個過ぎるあたりからだんだん悪くなる(64CPUでだいたい48CPU相当)けどまあしょうがないか。
それ以上を厳しく要求される計算だとたぶんMPIと自前のソルバの組み合わせになってしまうのかも
しれないけど、まあ普段の用途には16か32倍も出れば御の字だろう。

**デフォルトの名無しさん** · 2009/05/12(火) 18:55:41

OpenMPで16スレッドも使えるようなCPUなんて持ってるのか。羨ましい。
汎用だと4が限界だし

**デフォルトの名無しさん** · 2009/05/12(火) 19:02:43

PCサーバなら、4core*2CPUはざらだと思うが。
# さすがに16とか32は見たことがない……

**デフォルトの名無しさん** · 2009/05/12(火) 19:13:11

cell

**205** · 2009/05/13(水) 02:45:20

あまり使われていない altix の箪笥が使えるのです。
ふだんは 4core x 2 ですね。Xeon ８コアで、ちと古いItanium１６個相当のパフォーマンスは出るので。

**デフォルトの名無しさん** · 2009/05/14(木) 01:08:55

>>201

>>191です。

CLY[index_x]=CLY[(IDX[i][j][k])]はCLYのサイズが小さいため、
2ndキャッシュにキャッシュさせる目的で使っています。

> いずれにしてもコードいじるからなあ・・・。gccで幸せならそのまま、という手も。

これでコードをいじって30%くらい速くなるならやる価値はありそうですが、
おそらくそこまで行くような感じではないように思われます。
あと、GCCでもバージョンによって速さが違いますし、OSが32bitや64bitでも違いました。
「このコンパイラを使えばどの環境でも速くなる！」と言うのはないですかね。

**デフォルトの名無しさん** · 2009/05/14(木) 02:01:54

ハンドアセンブル

**デフォルトの名無しさん** · 2009/05/14(木) 09:53:37

>>210
VTuneは使っている? そのくらいシビアな話なら動的解析してみると何か分かるかもよ。

**デフォルトの名無しさん** · 2009/05/15(金) 01:38:09

VC++2008のStdしか持ってないが
C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugOpenMP\vcomp90d.dll
というファイルが入ってる。これ使えるの？

**デフォルトの名無しさん** · 2009/05/15(金) 02:44:45

>>210
非構造格子の格子形状の情報が格納されてるのかな？
それだとidx配列で引くのが不利より有理な点が多そうだね。
だったら２００みたいにループの始めでクローン作ったほうがいいかも。
コードもそんなにいじらないだろうし。
>>213
ディレクトリは忘れたけど、その名前のダイナミックリンクライブラリは
使った記憶がある。どういう使いかただったかは忘れた・・・。

**デフォルトの名無しさん** · 2009/05/21(木) 22:25:36

ちょっと興味があるのだが
OpenMPってこれから並列プログラミングのスタンダードになっていくのかね
MPI+OpenMPのクラスタなんてなかなかだな、環境とプログラムの内容によっちゃあ

**デフォルトの名無しさん** · 2009/05/22(金) 06:56:43

MPI使ったコードを既に持ってるなら、OpenMPはあまりいらないかもな。
OpenMP相当の事は自動並列かなりできるようだしMPI主体が大～中規模計算の主流で、
マルチ・コアCPUが１～２個くらいのシステムでお手軽並列が
これからのOpenMPの使いかたになるのではと勝手に予想するw

というかsgiが飛んだり、SUNがソフト屋に買収されたりNECが断念したりで今後のトレンドが読めんね。

**213** · 2009/06/02(火) 23:51:25

以下の2つのファイルをexeと同じフォルダに入れると使えました。
デバッグビルドでもOpenMPを使えるようです。

C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugOpenMP\vcomp90d.dll
C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugOpenMP\Microsoft.VC90.DebugOpenMP.manifest

**デフォルトの名無しさん** · 2009/06/23(火) 01:54:45

PriusOnlineでOpenMP/VC8つかってるっぽい
どうしようクアッドコアにしようか

**デフォルトの名無しさん** · 2009/06/23(火) 08:01:00

VC++2010にParallel Pattern Library(PPL)というマルチスレッドライブラリが
追加されるみたいだけどOpenMPとの住み分けはどうなるんだろう。

**デフォルトの名無しさん** · 2009/06/25(木) 06:30:55

いままでintel fortran 9.1使っていた。お試しで11入れてみた。
オプションはシェフお薦めの
ifort -fast -openmp
だけ。だいたい３０％くらい速いようだ。コードにもよるだろうけど、いいね。
というか今までのはなんだったんだw

関係ないけどversion 8は挙動が変だ。なんじゃありゃ。

**デフォルトの名無しさん** · 2009/06/25(木) 06:31:45

あ、OSはlinux(版はよくわからんw)ね

**デフォルトの名無しさん** · 2009/06/25(木) 21:51:20

OpenMP3.0使った人いる？