やはり、問題が大きくなると解くのに時間がかかる。ただ、BryodenBand の場合、ほぼ入力サイズに比例して時間がかかっているので、計算時間がどのくらいかかるのかを予測できるのは、かなり便利。
論文本体は、Multithread の部分を書き足したので、これから Figure や Table の整理。
これが終わると、本格的な数値実験のための問題選択に入ることになる。
今日のBGM: 聖剣伝説4-OST[1-2], DewPrism-OST[1-2]
今日のランチ:つのぶえ ミックスカツ
2009年9月30日水曜日
2009年9月29日火曜日
BroydenBand を全力で解く
今日は、SDPARA で BroydenBand を全力で解いている最中。
(もちろん、解いているのはクラスタで、人間が全力疾走しているわけではない。)
BroydenBand は SDPARA の最新機能の性能がストレートに出るので、これのログを取ると同時にどこまで大きなところまで解けるかを確認する。
ちなみに、single processor で解く際には、BroydenBand300ですでに 10GB を突破する。まぁ、Schur complemet の要素数だけで 10 億に迫るので、しかたないとも言える。
論文は、new parallel schemes のところのラフスケッチを書いたところ。(1日でA4で1.5枚ぐらいしか進んだ。やはり 10pt で両端まで使うと、かなり1ページに書ける。)
次は、multi threading についての内容の予定。
今日のBGM:El Cazad OST[1-2], Xenosaga III OST[1-2], Madlax OST [1-2]
今日のランチ:つかさ しめさば
(もちろん、解いているのはクラスタで、人間が全力疾走しているわけではない。)
BroydenBand は SDPARA の最新機能の性能がストレートに出るので、これのログを取ると同時にどこまで大きなところまで解けるかを確認する。
ちなみに、single processor で解く際には、BroydenBand300ですでに 10GB を突破する。まぁ、Schur complemet の要素数だけで 10 億に迫るので、しかたないとも言える。
論文は、new parallel schemes のところのラフスケッチを書いたところ。(1日でA4で1.5枚ぐらいしか進んだ。やはり 10pt で両端まで使うと、かなり1ページに書ける。)
次は、multi threading についての内容の予定。
今日のBGM:El Cazad OST[1-2], Xenosaga III OST[1-2], Madlax OST [1-2]
今日のランチ:つかさ しめさば
2009年9月28日月曜日
Mittelman の問題を分類
Mittelman の問題を一通り解き終わったので、分類を開始。
まず、single processor で 500 秒で解けるような小規模問題を除外しておいた。
これに基づいて、問題をいくつかに分類して、実際に解く(デバッグ情報無しで解く)グループをピックアップした。
また、これとは別に多項式計画問題も解いてみて、どういった傾向が出るのかを確認中。最新の実装だと、当然ながら、これまでよりも時間が短縮されることがある(一部、例外あり)。
また、MUMPS の ScaLAPACK サイズ変更だが、どうやら ICNTL(19)=2 の情報が有効らしい。ただし、これだけを変更してもメモリ違反が出てしまう。 マニュアルの4.10 でもう少し詳しく調べて見る必要がある。ただ、ここでの Schur complement はこちらのほしい情報とは異なる可能性もある。その場合は、ソースを直接変更することもありうる。
今日は書類作成などで論文本体が進んでないので、明日はできるだけ英語を頑張る。
今日のBGM: FF12-OST[1-4]
今日のランチ:鳥こまち 鶏から揚げ
まず、single processor で 500 秒で解けるような小規模問題を除外しておいた。
これに基づいて、問題をいくつかに分類して、実際に解く(デバッグ情報無しで解く)グループをピックアップした。
また、これとは別に多項式計画問題も解いてみて、どういった傾向が出るのかを確認中。最新の実装だと、当然ながら、これまでよりも時間が短縮されることがある(一部、例外あり)。
また、MUMPS の ScaLAPACK サイズ変更だが、どうやら ICNTL(19)=2 の情報が有効らしい。ただし、これだけを変更してもメモリ違反が出てしまう。 マニュアルの4.10 でもう少し詳しく調べて見る必要がある。ただ、ここでの Schur complement はこちらのほしい情報とは異なる可能性もある。その場合は、ソースを直接変更することもありうる。
今日は書類作成などで論文本体が進んでないので、明日はできるだけ英語を頑張る。
今日のBGM: FF12-OST[1-4]
今日のランチ:鳥こまち 鶏から揚げ
[自分メモ]Mittelman の問題を分類
Mittelman の問題を一通り解き終わったところで、SDPARA で本格的に解く (デバッグ情報をはずして)問題を取捨選択。
基本的な基準としては、
基本的な基準としては、
- single processor で 500 秒以内で解ける問題は外す(並列計算がもったいないので)
- 同じ種類の問題は、一番大きな問題だけにする
とする。ただし、1の基準で見ると、Mittelman の問題は Schur が DENSE なものしか残らない。
以下選んでいく。
- [G59mc] MPI効果はあるけど、Thread 効果はない
- [butcher] MPI & Thread 両方で効果ありで全体もOK
- [checker1.5] MPI & Thread 両方で効果あるけど、全体の割合低い
- [chipl12] MPI & Thread 両方で効果ありで全体もOK
- [diamond_patch] MPI & Thread 両方で効果あるけど、全体の割合低い
- [ice_2.0] MPI & Thread 両方で効果あるけど、全体の割合低い
- [neu3] MPI & Thread 両方で効果ありで全体もOK
- [neu3g] MPI & Thread 両方で効果ありで全体もOK
- [p_auss2_3.0] MPI効果はあるけど、Thread 効果はない 全体の割合も低い
- [reimer5] MPI & Thread 両方で効果ありで全体もOK
- [shmup5] MPI効果はあるけど、Thread 効果はない 全体の割合も低い
- [taha1b] MPI & Thread 両方で効果ありで全体もOK
やはり、Max-cut に似た傾向のある問題では、主双対内点法の弱さがストレートに出る。
次に、sparsePOP で生成した問題も確認。
- [BroydenBand 系列] ELEMENTS の効果はOK。ただ、CHOLESKY は16台になると逆効果。
- [BorydenTri 系列] 問題構造が簡単するぎるためか、案外割合低い
- [ChanedSingular 系列] solve に手間取っているみたい(MUMPS の ScaLAPACK のブロックサイズを変更して確認する)。あと、Thread 間に競合が起こる場合あり。
- 他の問題は、生成時間に対して、あっという間に解けてしまうので、あまり良くない。
あと、sfsdp の問題は、なかなか好調。ただし、これも生成の関係であまり大きくできない。
インパクトがあるのは、やはり大きな問題なので、BryodenBand, sfsdp でどこまで大きい問題を解けるかを調べてみる。
2009年9月27日日曜日
Mittleman の問題を一通り解き終わった
Node数 1,4,16 Thread 数 1,8 に変更しての最初のデータ取り終了。
だいたい182029秒なので、丸2日といったところ。
これから本格的な数値実験を行う問題を選択する。(いまのデータはデバッグ情報も表示しているため)
基準としては、
特に3は重要で、こういったものを取り込んでおかないと、自分に都合のいいデータだけを集めてしまうことになる。
また、本格的な数値実験に入る前に、MUMPS のブロック数を変更できるのかどうかを確認しなおす。たしか、MUMPS では ScaLAPACK のルーチンに関するブロック数は OS の種類などによって自動的に決まっているはずで、それを dmumps_() の呼出で変更できるのかどうか、調べる。
追記(時刻 19:28)
Mittelman の問題は、ほとんどが Schur complement が dense だった。いくつかは sparse だけど、それらは、single processor でも高速に解けてしまって、並列計算のうまみがなかった。まぁ、dense のほうは、マルチスレッドの効果が出るものもあるので、それは取っておこう。
だいたい182029秒なので、丸2日といったところ。
これから本格的な数値実験を行う問題を選択する。(いまのデータはデバッグ情報も表示しているため)
基準としては、
- 並列計算なので、それなりの規模の問題
- SDPARA での並列化の効果が出ている問題
- 逆に並列化の効果が出ていない問題
特に3は重要で、こういったものを取り込んでおかないと、自分に都合のいいデータだけを集めてしまうことになる。
また、本格的な数値実験に入る前に、MUMPS のブロック数を変更できるのかどうかを確認しなおす。たしか、MUMPS では ScaLAPACK のルーチンに関するブロック数は OS の種類などによって自動的に決まっているはずで、それを dmumps_() の呼出で変更できるのかどうか、調べる。
追記(時刻 19:28)
Mittelman の問題は、ほとんどが Schur complement が dense だった。いくつかは sparse だけど、それらは、single processor でも高速に解けてしまって、並列計算のうまみがなかった。まぁ、dense のほうは、マルチスレッドの効果が出るものもあるので、それは取っておこう。
2009年9月26日土曜日
SDPARA 数値実験途中メモ
Mittelman のところの問題で、どの程度性能が出るのか実験中。
http://plato.asu.edu/ftp/sdp/
既存 SDPARA 同様に m=n のケースでは性能が出ないが、Mittelman の問題では max-cut などがあるため、これに当てはまるケースが少なくない。
また、1反復のELEMENTS が 1 秒を下回る場合、Multi Thread の生成に時間がかかって逆効果になる。
http://plato.asu.edu/ftp/sdp/
既存 SDPARA 同様に m=n のケースでは性能が出ないが、Mittelman の問題では max-cut などがあるため、これに当てはまるケースが少なくない。
また、1反復のELEMENTS が 1 秒を下回る場合、Multi Thread の生成に時間がかかって逆効果になる。
登録:
投稿 (Atom)