OpenMPプログラミング

じゃ、使わなければいいじゃん。
判らんものを無理に使うことはないよ。

>>349
オブジェクトをキーにしたmonitorが分からなければそもそもマルチスレッドプログラミングが分かっていないってことだろ

>>349
単なるmutexじゃねーか。

いじめないでくれよぅ。
shared private reduction
だけで今まで何とかなってたんだよ・・

OpenMPの弊害か。
やっぱりある程度基礎が必要だな。
ちなみに、omp_set_lock/omp_unset_lock
は軽くて便利だぞ。

これからOpenMP扱う初心者なのですがいきなり躓きました
Win7でVC++2010Expressを使用して

#include "stdafx.h"
#include <stdio.h>

int _tmain(int argc, _TCHAR* argv[])
{
printf("OpenMP Spec %d\n",_OPENMP);
return 0;
}

を実行しようとすると、ファイル 'VCOMPD.lib' を開くことができません。と表示され失敗してしまいました
ググったら構成プロパティでOpenMPサポートを「はい」にし、vcomp90.dllをPATHの通ったディレクトリにコピーするこが必要のとのこと
OpenMPサポートは解決したのですが、PATHの通ったディレクトリにコピーしてないから、vcompd.libを開け〜とエラーが起きるのでしょうか？
ちなみにVSコマンドプロンプト(2010)でpathと入力したら多くのディレクトリが表示されどこに入れればいいのか分かりません・・・
どこのディレクトリにコピーすればいいのか教えてください

よく分かってないなら、絶対パスで指定すればいいんじゃね

>>356
上のほう読んでたら、vcomp90.dllを実行ファイルの場所にコピーと書いてあったので試してみます
それでもダメだったら、絶対パスで指定してみます。本当に初心者ですみません・・・

まずC++を10年勉強しろ

OpenMP以前にC#とか使ってみ

>>358
すみません、初歩的なJavaやC言語しか学んでなかったんです；；
でも菅原清文著のC/C++プログラマのためのOpenMPという本で、C言語でも扱えるということで始めてみました

>>359
はじめてのC#というサイトを見て頑張ってみます

ちなみに実行ファイルの場所（フォルダ）にコピーしてもエラーが起きてコンパイルできませんでした

エラーに出てるけどビルドに必要なのはVCOMPD.libであってvcomp90.dllじゃないんで

>>355
VS2010 (=verison 10.0) なのに、なんで vcomp90 (=version 9.0 : VS2008用) を
指定してたりするの?

あと、Debug用ライブラリ (vcompd.lib = Visual C++ OpneMP, debug) 使うなら、
VS2010 Pro (=有料版) が必要。

解決方法を4つ考えてみた:
(1) VS2010 Professional を買う
(2) VS2008 Express + Windows SDK 7.0 を使う
(3) Cygwin や MinGW をインストールして、付属のgcc/g++ を使う
(4) Linux や *BSD を使う (VMware/VirtualBoxでも併用すればよろし)

VC++のOpenMPはデバッグビルドだと_DEBUGをundefしてからomp.hをincludeしないといけないってのが昔あったが

VS2010 Pro 評価版を Virtual PC とかの捨て環境にインストールすれば vcompd.lib も入ってるけど、これコピーして使ったら逮捕されるかもしれないからやめたほうがいいね。

>>361-364
多数のレス本当にありがとうございます。
とりあえずVS2010Expressでは、OpenMPが使用できないということですね
>>362さんの（２）の方法で試してみます。あと>>364さんの提案だとできそうですが・・・やめたほうがいいですね

久しぶりの書き込みです
言われた通りVS2008＋SDK7.0でopenmpをコンパイラ実行することができました

できればサポ３．０以上を無償ソフトで使えればよかった・・・

メモリのローカリティって何?

なるべく近いアドレスのデータだけを

本屋にOpenMPの新しげな本が置いてあったんだけど
あれって買った方がいいと思う？

好きにすれば。

元IBMのゴルゴ13こと
青山(名前あってるかな？)先生の本がいいからなぁ。
どこかでpdf版もあったと思うけど。

初心者なら青山さんの冊子でしばらく事足りるとおもうし、
だいぶ経験積んでいるのなら、買っても言うのではないかと。

あと、外人さんが書いたものの日本語訳なら
いっそのとこ原書買う方がいいかも。
アマゾンか丸善に

ひょっとして並列できるところ全部並列化したら
かえって遅くなる？

そういうこともある。

TBBのスレってないんだね

http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html

std::for_eachがOpenMP使えるみたいだけど
どんな使い方すればいいんんだろ

>>376
OpenMPがfor文を並列化することが多いものだから普通すぎる使い方だろ

イテレータの実装はスレッドセーフになってんのかね？

先週出た Visual Studio Express 2012 for Desktop で、
OpenMP が使えるかどうか試してみた。

WIN32 Release/Debug, x64 Release/Debug のすべてで、
omp_get_num_procs(), omp_get_num_threads() を使ったプログラムを
ビルドして実行できたよ。

VS 2010 ExpressはSDK入れても出来なかったのにな
2008はできていたのに

>>373
アムダールの法則

OpenMP有効で、Core i 3 530(2.93GHz)の環境で
23.66Gflops出た。理論値は23.44Gflopsだが・・
OpenMP簡単でスゲーな

結果が壊れてないか確認する必要はあるけどね

spec.org だっけ・・・わすれたｗけど
にSMP マシンのテストで
どういうコンパイルオプションを使ったか書いてあるので
それと同じでやってみるとなおいいかも。

ものにもよるけど、経験上は20CPU(コアか・・)くらいまでなら
コア数に比例して上がっていくよね。
大規模流体計算とかだとMPI とかになるだろうけど、
それでも、OpenMP はデュアルコアが一般になった今日では簡単でとても便利だ。

>>384
OpenMPがいいかMPIがいいかの違いは、
共有メモリがいいか分散メモリがいいかの違いだけ。
大規模問題は往々にしてメモリ帯域が足りなくなったり、ロックの問題が出てくるから、MPIが使われる。
それ以外はOpenMPのほうが有利。

あと、メモリに依存しないオンキャッシュで収まる問題なら、
MPI、OpenMPに限らずほぼコア数にスケールする。
しかし、OpenMPで20コアまでスケールするような問題は見たことがないな。

Opteron 24コアだと8コアくらいまでがリニアに速くなって
それ以上は足せば速くなるけど少しの違いだったな
メモリの帯域が問題だと思ってたけど

>>386
Opteronで6コア以上だったらNUMAだからメモリバインドをしっかりしないとスピードは上がらんよ。
Linuxならnumactlが必要。Windowsは残念ながらOS任せなので、スケールは難しい。

MPIだと一部だけパージ可能だからその点は楽

openmp を使って並列化したプログラムを intel fortran コンパイラでコンパイル（最適化は -O0）して４コア（Xeon 5150）のマシンで実行したところ、-openmpオプションの有無によってかかる時間が
有：実時間3m39s、ユーザーcpu時間14m22s
無：実時間2m53s、ユーザーcpu時間2m53s
のようになりました。
つまり openmp で４コアを使っているのに実時間は減っておらず、cpu 時間がコア数の数にだいたい比例して増えています。

まったく同じプログラムを別のマシン Core i5-3470S で同じバージョンの ifort で -openmp オプション付きでコンパイル・実行したところ、かかった実時間は （-optionmp 無しでの実時間）/コア数より少し大きい程度だったので、このマシンでは問題が無さそうです。

どういった原因が考えられますか？

>>389
memory-boundなプログラムなのでは？
Nehalem前後で並列性能が大きく変わるはず。

>>389
ロックのしかたがクソとか
プログラム依存の話なのか環境の話なのか切り分けるために
配列要素を合計するような単純なforループで試してみたらいいんじゃないのかな
CPU時間が増えているということは複数コアが使われているのは確かだと思うけど
普通はコア数に比例してCPU時間が増えてコア数に反比例して実時間が減るよね

処理を分割せずに同じ処理をマルチコアで実行してしまっている気がする

みなさんありがとうございます。
FGSL のプログラムを使って多数回のモンテカルロ積分をしていて上記のような問題が起きたのですが、private, shared などの指定がまずかったようです。
積分値が異常ではなかったので、答えは間違いないが Xeon では時間短縮できていないと誤解してしまいました。しかし積分値の分散は openmp ありのほうが小さいので、どうも何らかの異常があったようです。

モンテカルロ積分に関係する量をすべて private にし、乱数の種をスレッドごとに異なる値にすることによって、積分値の異常も計算時間の異常も解決したようです。
ありがとうございました。

critical (name)
のnameってグローバル？
あるライブラリで
#pragma omp critical(hoge)
があった場合、別のライブラリの
#pragma omp critical(hoge)
と衝突する？

>>394
Cの場合、グローバル変数とローカル変数の名前が被っている時はローカル変数の方が優先されるので、衝突は起こりません

何これ言語？

あ

い

を