森田/日誌/2009-05-29
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
|
ログイン
]
開始行:
日誌って感じじゃなくなってきたので、そのうちページ作って移すかも。~
-並列プログラミング実装
--一応、一番お手軽な方法で実装。時間計測で、既存の逐次的プログラムとどれだけ計算時間が違うか調べる。
--解像度:500x500(25000dot) ループ最大回数:2048
--使用マシン:hdw3dc2 並列時はhdw3dc3-10をスレーブプロセスとして使用 プロセス数16
--測定は一度のみなのでひょっとしたらぶれてるかも。でも大体の傾向はつかめるので複数回実験は省略。
--計測はマンデルブロ集合判定部のみ。初期化部やBMPへの書き出しの部分は測定範囲には入れず。
--計算時間の単位は秒
|No.|実数範囲|虚数範囲|計算時間(逐次的)|計算時間(並列)|備考|
|1|-2〜2|-2〜2|3.100|10.116|計算量少なめ|
|2|-2〜0.5|-1.25〜1.25|7.810|10.377|計算量やや少なめ|
|3|-1.4〜-1.36|-0.02〜0.02|18.130|10.619|計算量多め|
|4|0.2〜0.4|-0.65〜-0.45|9.750|10.484|計算量やや多め|
~
まぁ見てわかるように、明らかに並列は通信のオーバーヘッドが影響してそう。~
No1では逐次的が約7秒早いのに大して、No3では並列が約7.5秒早い。~
また、逐次的が1と3で15秒近く計算時間が違うのにたいして、並列は0.5秒ほどしか違わない。~
つまり、並列は実質の計算時間はそこまでかかっていないが、通信にかける時間が殆どを占めると予想される。~
~
ちなみに現在の並列のほうは、座標データを一個マスターが送信し、スレーブはそれを受け取り計算し、結果をマスターに送信し、再度マスターから座標データを受け取るというやり方で実現している。~
このやり方では、今回の解像度では25000個の座標データがあり、マスターは25000回データを各スレーブに受信し、25000回データを受け取っていることになる。~
ブロッキング方式で実現している(ノンブロッキングにしようがない)ので、各スレーブは、他のスレーブがマスターとデータ通信を行っていることにより、データ送信待ちの時間が増えているのではないかと推測される。~
~
一度の座標データの送信で、複数の座標データを送れば少しは早くなるんじゃないかなぁ。~
---------------------------------------------
追記:mpiccでコンパイルすると標準でレベル3の最適化がされてるみたい 同等の最適化をgccでかけたらめっちゃ早くなったんですけど。~
ちょっとプログラムに訂正加えつつ、再検討……
---------------------------------------------
色つけるときに参考にしたサイト:http://lecture.ecc.u-tokyo.ac.jp/~cichiji/cp-05/cp-05-11-3.html~
マンデルブロ集合プログラムをちょっと改変とか。~
とりあえず、繰り返し回数をユーザーに決定させるようにしたことと、出力した画像から、部分指定して拡大ってのをやりやすくするために、既存の画像のpixelを指定して、座標データに変換し、ファイルに書き出すプログラムを作成。~
ファイルからロードして、マンデルブロ集合プログラムにデータとしてそのまま渡せるように。~
自分で使う上で、だいぶ不便はなくなったので、明日から転送のボトルネックを解決するできるように頑張る。~
終了行:
日誌って感じじゃなくなってきたので、そのうちページ作って移すかも。~
-並列プログラミング実装
--一応、一番お手軽な方法で実装。時間計測で、既存の逐次的プログラムとどれだけ計算時間が違うか調べる。
--解像度:500x500(25000dot) ループ最大回数:2048
--使用マシン:hdw3dc2 並列時はhdw3dc3-10をスレーブプロセスとして使用 プロセス数16
--測定は一度のみなのでひょっとしたらぶれてるかも。でも大体の傾向はつかめるので複数回実験は省略。
--計測はマンデルブロ集合判定部のみ。初期化部やBMPへの書き出しの部分は測定範囲には入れず。
--計算時間の単位は秒
|No.|実数範囲|虚数範囲|計算時間(逐次的)|計算時間(並列)|備考|
|1|-2〜2|-2〜2|3.100|10.116|計算量少なめ|
|2|-2〜0.5|-1.25〜1.25|7.810|10.377|計算量やや少なめ|
|3|-1.4〜-1.36|-0.02〜0.02|18.130|10.619|計算量多め|
|4|0.2〜0.4|-0.65〜-0.45|9.750|10.484|計算量やや多め|
~
まぁ見てわかるように、明らかに並列は通信のオーバーヘッドが影響してそう。~
No1では逐次的が約7秒早いのに大して、No3では並列が約7.5秒早い。~
また、逐次的が1と3で15秒近く計算時間が違うのにたいして、並列は0.5秒ほどしか違わない。~
つまり、並列は実質の計算時間はそこまでかかっていないが、通信にかける時間が殆どを占めると予想される。~
~
ちなみに現在の並列のほうは、座標データを一個マスターが送信し、スレーブはそれを受け取り計算し、結果をマスターに送信し、再度マスターから座標データを受け取るというやり方で実現している。~
このやり方では、今回の解像度では25000個の座標データがあり、マスターは25000回データを各スレーブに受信し、25000回データを受け取っていることになる。~
ブロッキング方式で実現している(ノンブロッキングにしようがない)ので、各スレーブは、他のスレーブがマスターとデータ通信を行っていることにより、データ送信待ちの時間が増えているのではないかと推測される。~
~
一度の座標データの送信で、複数の座標データを送れば少しは早くなるんじゃないかなぁ。~
---------------------------------------------
追記:mpiccでコンパイルすると標準でレベル3の最適化がされてるみたい 同等の最適化をgccでかけたらめっちゃ早くなったんですけど。~
ちょっとプログラムに訂正加えつつ、再検討……
---------------------------------------------
色つけるときに参考にしたサイト:http://lecture.ecc.u-tokyo.ac.jp/~cichiji/cp-05/cp-05-11-3.html~
マンデルブロ集合プログラムをちょっと改変とか。~
とりあえず、繰り返し回数をユーザーに決定させるようにしたことと、出力した画像から、部分指定して拡大ってのをやりやすくするために、既存の画像のpixelを指定して、座標データに変換し、ファイルに書き出すプログラムを作成。~
ファイルからロードして、マンデルブロ集合プログラムにデータとしてそのまま渡せるように。~
自分で使う上で、だいぶ不便はなくなったので、明日から転送のボトルネックを解決するできるように頑張る。~
ページ名: