2010年03月22日

言語goで並列プログラミングを書いてみた

定番のフィボナッチの計算をしてみた

シリアルとパラレルの比較の結果は次の通り


Serial
fib = 102334155
time = 12156 m sec
Parallel
fib = 102334155
time = 4668 m sec


コアは2でハイパースレッドをONで、コアの設定は4とした。

tbbと同様の傾向を示している。

ライブラリか、それとも言語かの判断基準は?


テストコード
posted by zengaichi at 13:18| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

2010年03月16日

言語goはコンカレントプログラミング言語?

クエッションを付けている、なぜ

 進化中ということだろうか

   チュートリアルを読んでいると

     これからだ

   と、表現しているように見える

 マルチCPUコアはマニュアルで設定する

  でも、他のライブラリもそうだし

と言いつつ、さてどう比較したものだろうか
posted by zengaichi at 22:23| Comment(1) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

2009年12月31日

並列処理もハイブリッドの時代?

並列処理にもメニーコアが得意なものとGPUが得意なものがある。

アプリケーションが必要とする特性によって選ぶことになるのだろう。

並列処理の特性を見極めて開発するということなのだろうか。

posted by zengaichi at 12:31| Comment(2) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

OpenCLとリモートディスクトップ環境

ATIもNIVIDAもリモートディスクトップ環境での動作は厳しいようだ。


posted by zengaichi at 12:21| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

OpenCLへの期待?

ベンダ別の拡張APIを覚えなくてよいというのはあるだろう。

アプリケーションの実装の違いは?

高層の部分は統一できそうだが低層の部分は?


posted by zengaichi at 09:22| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

OpnCLのインストール:NVIDIA編

SDKをインストールするとき
32ビット版ではパスに英字以外のものを含むとエラーとなる。
Windows Vista以降ではtmp、tempはユーザ毎に設定するので、アカウントは英字にする必要がある。

事前にCudaのSDKをインストールしておく必要があるようだ。

最新のドライバをインストールするとOpenCLが動かなくなる。
posted by zengaichi at 09:17| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

2009年12月30日

OpenCLのインストール:ATI編

3日ほどトライヤルするが上手くいかなかった

原因は分かればたいしたことはないが

 Windows 7で更に困難を極めた


パスに英字以外の文字が含まれると動かないという

 よくある話で、インストール先の問題には違いないが

Windows 7(正確にはVista以降)ではセキュリティの都合、

 ユーザ毎にtempとtmpが異なるようにしているため、

アカウント名(ユーザ名)を英数字にする必要があった。

追記:
clBuildProgramでエラー(-11)が返ってくる

posted by zengaichi at 23:35| 並列プログラミング | 更新情報をチェックする

2009年10月10日

コアの数とtbbの効果らしきもの

計測結果を見ると(たった1つのプログラムからでは余り参考にはならないだろうが)

  CPUの数に比例するというよりは
  コアの数に比例しているということなのだろう。

i7での興味深いところは通常のアプリケーションではコアだけしか動いていないように見える(4つのパフォーマンスメータが動くが残りの4つはゼロパーセントのまま)がtbbでは8つのパフォーマンスメータが100パーセントになっている。

HTのコンセプトから考えると、CPUの空いたリソースを有効活用しようとするものなので、tbbはそれも活用していることになるが、HTが故に1コアの性能理論値を超えることができないと言ったところだろうか。

(0.8(コア)+0.2(HT) = 1.0で2.0になることはない)

そう考えると並列の効果はCPU数よりもコア数に依存することになるのだろう。

仮想的に2となっても、物理的限界の1を超えることはできないと言ったところになるのだろうか。
posted by zengaichi at 16:24| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

駄目押しでPen4でtbbの計測を

速くなるどころか逆に遅くなる。
tbbで遊ぶなら多いCPUに限るということなのでしょう。

CPU数(8:コア4HT4)i7

count = 44
parallel time = 1.08989
serial time = 5.68009

CPU数(4:コア2HT2) Atom

count = 44
parallel time = 11.3102
serial time = 25.8457

CPU数(2:コア2)Core 2

count = 44
parallel time = 10.5555
serial time = 19.9362

CPU数(1)Pen4

count = 44
parallel time = 22.59
serial time = 22.1493

計測データ
posted by zengaichi at 15:35| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

さらにtbbの時間計測を

Core2でも計測してみた。すると2倍弱だった。HTの効果は気休め程度なのだろうか。

CPU数(8:コア4HT4)i7

count = 44
parallel time = 1.08989
serial time = 5.68009

CPU数(4:コア2HT2) Atom

count = 44
parallel time = 11.3102
serial time = 25.8457

CPU数(2:コア2)Core 2

count = 44
parallel time = 10.5555
serial time = 19.9362


Core2の計測結果
posted by zengaichi at 14:52| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

tbbとCPU数の効果らしきもの

i7とAtomの代表値で見るとシリアル処理では5倍の開きとなっているので、単純にスケーリングするとAtomでのパラレルが11秒なので2秒だが、i7では1秒で終わっている。
倍のCPU数を持つi7なので1/2に短縮と言うことだろう。

CPU数(8:コア4HT4)i7

count = 44
parallel time = 1.08989
serial time = 5.68009

CPU数(4:コア2HT2) Atom

count = 44
parallel time = 11.3102
serial time = 25.8457


posted by zengaichi at 14:19| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

久々にtbbを試す(その6)

i7 Coreで試すと5倍強の開きとなった。
コア数に依存していることになる。


count = 17
parallel time = 0.00181417
serial time = 3.35619e-005
parallel sum = 1597
serial sum = 1597
count = 18
parallel time = 3.93988e-005
serial time = 5.43557e-005
parallel sum = 2584
serial sum = 2584
count = 19
parallel time = 5.50853e-005
serial time = 8.1716e-005
parallel sum = 4181
serial sum = 4181
count = 20

省略

count = 44
parallel time = 1.08989
serial time = 5.68009
parallel sum = 701408733
serial sum = 701408733
count = 45
parallel time = 1.74323
serial time = 9.04117
parallel sum = 1134903170
serial sum = 1134903170
count = 46
parallel time = 2.81998
serial time = 14.9807
parallel sum = 1836311903
serial sum = 1836311903



posted by zengaichi at 14:00| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

久々にtbbを試す(その5)

またまた試してみた

フィボナッチ関数で比較すると2倍強のままで維持している。これはリソースによるものらしい(並列のときは全てのコアが100%)。
(time:秒)

count = 17
parallel time = 0.000919
serial time = 6.2e-05
parallel sum = 1597
serial sum = 1597
count = 18
parallel time = 7.7e-05
serial time = 0.000132
parallel sum = 2584
serial sum = 2584
count = 19
parallel time = 0.000106
serial time = 0.000201
parallel sum = 4181
serial sum = 4181
count = 20

省略

count = 44
parallel time = 11.3102
serial time = 25.8457
parallel sum = 701408733
serial sum = 701408733
count = 45
parallel time = 18.0784
serial time = 41.1529
parallel sum = 1134903170
serial sum = 1134903170
count = 46
parallel time = 29.9365
serial time = 66.4455
parallel sum = 1836311903
serial sum = 1836311903

コード
posted by zengaichi at 12:46| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

2009年09月27日

pallel_reduceの評価らしきもの

マルチコアで行うとどうなるかの興味半分で行ってみました。
 データ数に対して並列の処理効果があるようです。


1000個
time :0.000224
index = 566
2000個
time :0.000401
index = 1130
3000個
time :0.000509
index = 653

  :
  :

9000個
time :0.000527
index = 8315


posted by zengaichi at 00:47| Comment(1) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

久々にtbbを試す(その4)

追いかけて見てサンプルコードの間違いを見つけました。

parallel_reduceの動作は

  1. スレッドが生成される

  2. クラス用スケジューラを呼ぶ

  3. 空の子供のスケジュールを作る(ここでは複写しない)

  4. スプリット用のコンストラクタを呼ぶ

  5. オペレータを処理する

  6. すべての子供の終りでジョインする

  7. すべてのスレッドが終わったら結果を返す


というような動きです。
で、スプリットのコンストラクタにバグがあることに気がついたとうことです。



修正後のコード
posted by zengaichi at 00:35| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

2009年09月26日

tbbを試す(その3)

追跡してみた。


values[ 0] (0x33f11000)
values[1000] (0x33f11fa0)
index = 0 (0x33f11000)
index = 1000 (0xfa0)
index = 1 (0x33f11004)
Segmentation fault (core dumped)


値がおかしいのではなく、スレッド生成時のポインタの上位の値がカットされてしまっている。

posted by zengaichi at 10:49| Comment(2) | TrackBack(1) | 並列プログラミング | 更新情報をチェックする

2009年09月22日

久々にtbbを試す(その2)

次にparallel_reduceを試すと

FreeBSD 7.2ではバギーなのだろうか?
(Windowsで試す根性はなかったのでというべきか)

 ある条件下では Core Dump を産み落としてくれる。


  • 複数のパテーションでスレッドが生成されるとき

  • 指定のパテーション内ではスレッドが生成されないので問題はない

  • 分割されたときのbeginの値がおかしい



マルチスレッドの恩恵を受けれそうにないので、FreeBSDでは、また、しばらく見送り

コード
posted by zengaichi at 16:49| Comment(0) | TrackBack(1) | 並列プログラミング | 更新情報をチェックする

久々にtbbを試す(その1)

tbb/parallel_forのサンプルを作ってみた。
FreeBSD 7.2で。

まあ、それなりに。
が、その2へ続く

サンプルコード
posted by zengaichi at 16:39| Comment(0) | TrackBack(1) | 並列プログラミング | 更新情報をチェックする

2009年02月12日

CUDAのGPU品定めメモ


GPUの型番以外にGPUが計算のできる仕様「Compute Capability」が1.0から1.3まである。
(「Cuda Programming Guid ver 2.1」の付録Aに記載されている。)

倍精度で計算したいのなら1.3が必要なのだ。

計算目的で買うのであればパフォーマンスもさることながら有効桁数も重要なので気をつける必要がある。

今のところ1.3をサポートして安そうな型番はGTX 260であるが、おっと、電源容量が足らないかもしれない、ケースに収まらないかもしれないという心配がある。


posted by zengaichi at 23:05| Comment(1) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする

CUDA ver 2.1 インストールメモ

ドライバ、ツール、SDKをダウンロードしインストール後のメモ

VS2008でコンパイルする準備として

 ソリューションエクスプローラで
  プロジェクトを右クリックで
   カスタムビルド規則を選んで

$(ProgramData)\NVIDIA Corpration\NVIDIA CUDA SDK\common\Cuda.rulesを「新しい規則...」でインポートする。

・XPとVistaではフルパスが異なるので注意
・Cuda.rulesのVer2.0用と内容が異なるので注意

ハイライトについては

$(ProgramData)\NVIDIA Corpration\NVIDIA CUDA SDK\doc\sytax_highlight\visual_studio8にあるファイルusertype.defを使う。方法はそこにReadMeに記載してある。

よくあるサンプルのためのINCLUDEとLIBは$(ProgramData)\NVIDIA Corpration\NVIDIA CUDA SDK\commonにある。コンパイル時にはそのパスを含める必要がる。

・デバックや実行時は、ツール(コンパイラ)のライブラリは見に行くが、SDKのlibにあるDLLには見に行かないので注意する必要がある。
SDKにあるDLLに対してはコピーするかパスを通すかなどの処置が必要。


posted by zengaichi at 22:44| Comment(0) | TrackBack(0) | 並列プログラミング | 更新情報をチェックする