投稿
GotoBLAS については、
../kernel/x86_64/gemm_ncopy_4.S:175: Error: undefined symbol `RPREFETCHSIZE' in operation
というメッセージが出ていたが、これについては getarch.c の
#define FORCE_NEHALEM
を有効にすることで回避できた。今回のCPUは Westmere-EP のモデルのようであるが、getarch.c にWestmere-EP に相当する部分はなかったので、
http://ja.wikipedia.org/wiki/Xeon
を参考にして一番近そうな Nehalem を選択しておいた。
コンパイルには、
make BINARY=64 CC=icc FC=ifort USE_THREAD=1 USE_OPENMP=1 NUM_THREADS=24
としてある。
これで SDPARA のコンパイルに一歩前進である。
ただ、たったいま気がついたが、intel compiler といっしょに MKL が入っていた。
これを使うのもひとつの手である。
あと、昨日出したメールについて昨日の夜のうちに返信があり、飛行機の乗り継ぎの関係で今夜だけ日本に一泊するとのことで、スケジュールを変更して今日の夜に打ち合わせをすることになった。
今日の作業内容：GotoBLAS コンパイル + 打ち合わせ準備
今日のランチ：味庵 ピリ辛炒めの揚げ豆腐
明日の予測作業時間：4h
2010年11月11日木曜日
2010年11月10日水曜日
GotoBLAS2 がエラーでコンパイルできていない
SuSE11 の計算機で SDPARA をコンパイルできるかどうか試してみているが、GotoBLAS2 でコンパイルエラーになっている。
メモとして書いておくと、
../kernel/x86_64/gemm_ncopy_4.S:175: Error: undefined symbol `RPREFETCHSIZE' in operation
のようなメッセージが出る。どうやら、CPU の自動認識に失敗しているようで、RPREFETCHSIZE の #define が取り込まれていない様子である。
CPU 自体は、
$ cat /proc/cpuinfo | grep Xeon | head -1
model name : Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
となっている。
これについては、明日また調べることにする。
あと、最短路の論文をチェック。
論文では数値実験をしているが、どうやらグラフの密度でだいぶ性能が左右されるようだ。
とりあえず数値実験に用いたプログラムを入手できるかどうかを著者にメールしてみた。
入手できないのであれば、自分で組むことになる。
今日の作業内容：
6:30-7:00 [ng] 文字のプログラム改良
7:00-8:00 [ok] 改良の続き
11:00-12:00 [ng] MPSP 論文チェックp1-p6
15:00-15:30 [ok] 計算機設定整理
16:45-17:30 MPSP論文チェックp5-p8
今日のBGM: FF7 OST [1,2]
今日のランチ：シッダルータ ポテトとグリーンピースのカレー
明日の予測作業時間：2h
メモとして書いておくと、
../kernel/x86_64/gemm_ncopy_4.S:175: Error: undefined symbol `RPREFETCHSIZE' in operation
のようなメッセージが出る。どうやら、CPU の自動認識に失敗しているようで、RPREFETCHSIZE の #define が取り込まれていない様子である。
CPU 自体は、
$ cat /proc/cpuinfo | grep Xeon | head -1
model name : Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
となっている。
これについては、明日また調べることにする。
あと、最短路の論文をチェック。
論文では数値実験をしているが、どうやらグラフの密度でだいぶ性能が左右されるようだ。
とりあえず数値実験に用いたプログラムを入手できるかどうかを著者にメールしてみた。
入手できないのであれば、自分で組むことになる。
今日の作業内容：
6:30-7:00 [ng] 文字のプログラム改良
7:00-8:00 [ok] 改良の続き
11:00-12:00 [ng] MPSP 論文チェックp1-p6
15:00-15:30 [ok] 計算機設定整理
16:45-17:30 MPSP論文チェックp5-p8
今日のBGM: FF7 OST [1,2]
今日のランチ：シッダルータ ポテトとグリーンピースのカレー
明日の予測作業時間：2h
2010年11月9日火曜日
並列計算の数値実験の論文へのまとめ方
昨日に続いて、数値実験の論文へのまとめ方についての論文を読む。今回は並列計算に関するものである。
Reporting Computational Experiments with Parallel Algorithms: Issues, Measures, and Expert's Opinions
ORSA Journal on Computing
１９９５年のものなので、コンピュータ名などは古い印象がある。
並列計算の指標などについてまとめられており、抜粋すると、
Speedup(p) = (特定の計算機上で最も高速なシリアル計算での計算時間)/(p台使用時の計算時間)
RelativeSpeedup(p) = (並列ソフトを1台で実行したときの計算時間)/(p台使用時の計算時間)
AbsoluteSpeedup(p) = (いろんな計算機で実行したシリアル計算の最短時間)/(p台での並列計算の計算時間)
efficiency(p) = S(p) / p
[ただし、S(p) は Speedup(p),RelativeSpeedup(p),AbsoluteSpeedup(p)]
incremental efficiency = ((p-1)*(p-1台での計算時間))/(p*p台での計算時間)
といったところである。
ただし、これらの計算も実は状況によって様々に異なることが指摘されており、どれがいいかについては疑問が残る。
この論文では、どのような指標がよいか23人の研究者からアンケートを取っているが、これがバラバラである。
要するに研究者の中でも並列計算を評価する指標はコンセンサスが取れていない。
今日の作業内容：
6:30-7:00 [ok] 数値実験の仕方の論文 並列計算について [その１]
7:00-7:30 [ok] p10-p20
8:00-8:30 [ok] p28-p34
8:15-8:45 [ok] 最短路アルゴリズム確認
10:00-11:00 [ok] アルゴリズム調査
11:00-11:30 [ok] Floyd-Warshall のアルゴリズム確認
11:30-12:00 [ok] Folyd-Warshall 関連の論文を調査
13:30-14:30 [ng] SNL サンプル作成
今日のBGM: FF12 OST [1,2]
今日のランチ：角笛 さばの竜田揚げ
明日の予測作業時間：5h
Reporting Computational Experiments with Parallel Algorithms: Issues, Measures, and Expert's Opinions
ORSA Journal on Computing
１９９５年のものなので、コンピュータ名などは古い印象がある。
並列計算の指標などについてまとめられており、抜粋すると、
Speedup(p) = (特定の計算機上で最も高速なシリアル計算での計算時間)/(p台使用時の計算時間)
RelativeSpeedup(p) = (並列ソフトを1台で実行したときの計算時間)/(p台使用時の計算時間)
AbsoluteSpeedup(p) = (いろんな計算機で実行したシリアル計算の最短時間)/(p台での並列計算の計算時間)
efficiency(p) = S(p) / p
[ただし、S(p) は Speedup(p),RelativeSpeedup(p),AbsoluteSpeedup(p)]
incremental efficiency = ((p-1)*(p-1台での計算時間))/(p*p台での計算時間)
といったところである。
ただし、これらの計算も実は状況によって様々に異なることが指摘されており、どれがいいかについては疑問が残る。
この論文では、どのような指標がよいか23人の研究者からアンケートを取っているが、これがバラバラである。
要するに研究者の中でも並列計算を評価する指標はコンセンサスが取れていない。
今日の作業内容：
6:30-7:00 [ok] 数値実験の仕方の論文 並列計算について [その１]
7:00-7:30 [ok] p10-p20
8:00-8:30 [ok] p28-p34
8:15-8:45 [ok] 最短路アルゴリズム確認
10:00-11:00 [ok] アルゴリズム調査
11:00-11:30 [ok] Floyd-Warshall のアルゴリズム確認
11:30-12:00 [ok] Folyd-Warshall 関連の論文を調査
13:30-14:30 [ng] SNL サンプル作成
今日のBGM: FF12 OST [1,2]
今日のランチ：角笛 さばの竜田揚げ
明日の予測作業時間：5h
2010年11月8日月曜日
最短路問題
今日は、SDPAの論文について、レフリーから教えてもらった、数値実験の方法に関する論文に目を通した。
Designing and Reporting on Computational Experiments with Heuristic Methods
Journal of Heuristics, 1:9-32, 1995
特に重要なのはP11(論文内では3ページめ)にある Table 1 である。これがこの論文の要点である。
抜粋しておくと、
1. Define the goals of the experiment.
2. Choose measures of performance and factors to explore.
3. Design and execute the experiment.
4. Analyze the data and draw conclusions.
5. Report the experiment's results.
あと、Table 2 も有益である。
1. Reproducibility is essential.
2. Specify all influential factors in details.
3. Be precise about timing.
4. Show how algorithm parameters are set.
5. Use statistical experimental design techniques.
6. Compare the heuristic with other methods.
7. Reduce variability of results.
8. Produce a comprehensie report of the results.
これらは、今後の改訂に活かしていこう。
あと、SNL のプログラムの一部で最短路問題がボトルネックになっているので、それを解消するための改良をスタート。
Matlab のプログラムをいろいろと書き直したところ、だいたい10倍程度の高速化になった。
これを C++ で書けば、さらに2倍から5倍程度は高速化できそうな手応えはあるが、問題はそれでもボトルネックに成りかねないところである。
多点スタート多点ゴールの最短路問題で、しかも他にも条件分岐が入っているので、おそらくダイクストラ法はあまり高速化できなそうな気がする。
最短路問題のアルゴリズムはバラエティに富んでいるので、どのアルゴリズムなら効率的かを考えるところから始めたほうがよさそうである。
今日の作業内容：
6:45-7:15 [ok] SNL 論文復習
13:20-14:00 [ng] 事務処理いろいろ
14:00-14:20 [ok] 事務処理続き
14:20-14:50 [ok] データ整理
17:00-18:00 [ok] Matlab プログラム改良
18:00-18:30 [ok] 改良つづき
今日のランチ：つかさ 生サーモン照り焼き
明日の予測作業時間：4h
Designing and Reporting on Computational Experiments with Heuristic Methods
Journal of Heuristics, 1:9-32, 1995
特に重要なのはP11(論文内では3ページめ)にある Table 1 である。これがこの論文の要点である。
抜粋しておくと、
1. Define the goals of the experiment.
2. Choose measures of performance and factors to explore.
3. Design and execute the experiment.
4. Analyze the data and draw conclusions.
5. Report the experiment's results.
あと、Table 2 も有益である。
1. Reproducibility is essential.
2. Specify all influential factors in details.
3. Be precise about timing.
4. Show how algorithm parameters are set.
5. Use statistical experimental design techniques.
6. Compare the heuristic with other methods.
7. Reduce variability of results.
8. Produce a comprehensie report of the results.
これらは、今後の改訂に活かしていこう。
あと、SNL のプログラムの一部で最短路問題がボトルネックになっているので、それを解消するための改良をスタート。
Matlab のプログラムをいろいろと書き直したところ、だいたい10倍程度の高速化になった。
これを C++ で書けば、さらに2倍から5倍程度は高速化できそうな手応えはあるが、問題はそれでもボトルネックに成りかねないところである。
多点スタート多点ゴールの最短路問題で、しかも他にも条件分岐が入っているので、おそらくダイクストラ法はあまり高速化できなそうな気がする。
最短路問題のアルゴリズムはバラエティに富んでいるので、どのアルゴリズムなら効率的かを考えるところから始めたほうがよさそうである。
今日の作業内容：
6:45-7:15 [ok] SNL 論文復習
13:20-14:00 [ng] 事務処理いろいろ
14:00-14:20 [ok] 事務処理続き
14:20-14:50 [ok] データ整理
17:00-18:00 [ok] Matlab プログラム改良
18:00-18:30 [ok] 改良つづき
今日のランチ：つかさ 生サーモン照り焼き
明日の予測作業時間：4h
2010年11月5日金曜日
Wake On LAN の設定
Debian や Ubuntu は普段あまり使わないので、Vista の上の VMWare で動かしているが、Vista 自体もあまり動かしていないので、必要なときだけネットワーク経由で電源を入れられるように変更。
こういった機能は Wake On LAN と言って、オンボードの LAN 経由で起動できることが多い。
Windows Vista で Wake On LAN に対応させるときには、
http://tomorrow.meyon.gonna.jp/?eid=621382
がとても参考になる。
今回は、BIOS 画面で、[On Board LAN BOOT ROM] を [Enabled]にして再起動した。
(BIOSの項目はBIOSごとに異なるので、必ずしも同じ名前ではない)
そのあとは、[デバイスマネージャ]->[ネットワークアダプタ]->[LANにつながっているもの]->[プロパティ]->[電源の管理] と選んで[このデバイスで、コンピュータのスタンバイ状態を元に戻すことができるようにする]をチェックする。
また、このときにコマンドプロンプトから
ipconfig /all
としておいて、実際に使っている LAN カードの MAC アドレスを取得する。
具体的には、Physical Address と書いてあるところで、00-AA-BB-CC-11-22-33 と16進数で書かれている。
ここで、Windows Vista を終了する。
この Vista を今回は別サーバの RedHat からネットワーク経由で起動する。
RedHat では
# yum install wol
で wol コマンドをインストールする。
ここで
$ wol 00:AA:BB:CC:11:22:33
とすると、Vista PC が起動する。
（MAC アドレスが Windows 上だとハイフンだけど Linux 上だとコロンなところに注意）
なお、Windows Vista に外側からアクセスするには、VNC や cygwin による SSH などが必要である。VNC は UltraVNC などでできるようにあるが、dsm プラグインを設定したり、アクセスを変更したりなどが必要である。
また、cygwin の場合は、SSH をインストールしておく必要がある。これも他のサイトにいろいろと情報がある。なお、SSH でログインした場合、終了するときのコマンドは
$ shutdown.exe -s now
である。Linux なら -h であるが、-s である点に注意が必要である。
また、shutdown.exe は cygwin のコマンドであり、デフォルトでは入らないようなので、自分で入れる必要がある。shutdown.exe を実行すると、cygwin だけでなく Windows Vista 自体が終了するので、また必要なら wol で起動しなおす。
今日の作業内容：
8:30-9:00 [ok] SFSDP での実験
10:00-10:30 [ok] 事務処理関係チェック
13:00-13:30 [ok] Wake On LAN 設定
13:30-14:00 [ok] SFSDP での実験、大きめ
14:10-14:40 [ok] 発表原稿チェック
14:40-15:30 [ng] SeDuMi 中身チェック
15:50-16:30 [ok] SDPA 論文校正内容検討その１
16:30-17:00 [ng] SDPA論文校正内容検討その１まとめ
17:30-18:00 [ok] SDPA論文校正内容検討その１まとめ続き
今日のBGM: Romasing SAGA 3 OST [1-3]
今日のランチ： らく 山芋定食
明日の予測作業時間： 5h
こういった機能は Wake On LAN と言って、オンボードの LAN 経由で起動できることが多い。
Windows Vista で Wake On LAN に対応させるときには、
http://tomorrow.meyon.gonna.jp/?eid=621382
がとても参考になる。
今回は、BIOS 画面で、[On Board LAN BOOT ROM] を [Enabled]にして再起動した。
(BIOSの項目はBIOSごとに異なるので、必ずしも同じ名前ではない)
そのあとは、[デバイスマネージャ]->[ネットワークアダプタ]->[LANにつながっているもの]->[プロパティ]->[電源の管理] と選んで[このデバイスで、コンピュータのスタンバイ状態を元に戻すことができるようにする]をチェックする。
また、このときにコマンドプロンプトから
ipconfig /all
としておいて、実際に使っている LAN カードの MAC アドレスを取得する。
具体的には、Physical Address と書いてあるところで、00-AA-BB-CC-11-22-33 と16進数で書かれている。
ここで、Windows Vista を終了する。
この Vista を今回は別サーバの RedHat からネットワーク経由で起動する。
RedHat では
# yum install wol
で wol コマンドをインストールする。
ここで
$ wol 00:AA:BB:CC:11:22:33
とすると、Vista PC が起動する。
（MAC アドレスが Windows 上だとハイフンだけど Linux 上だとコロンなところに注意）
なお、Windows Vista に外側からアクセスするには、VNC や cygwin による SSH などが必要である。VNC は UltraVNC などでできるようにあるが、dsm プラグインを設定したり、アクセスを変更したりなどが必要である。
また、cygwin の場合は、SSH をインストールしておく必要がある。これも他のサイトにいろいろと情報がある。なお、SSH でログインした場合、終了するときのコマンドは
$ shutdown.exe -s now
である。Linux なら -h であるが、-s である点に注意が必要である。
また、shutdown.exe は cygwin のコマンドであり、デフォルトでは入らないようなので、自分で入れる必要がある。shutdown.exe を実行すると、cygwin だけでなく Windows Vista 自体が終了するので、また必要なら wol で起動しなおす。
今日の作業内容：
8:30-9:00 [ok] SFSDP での実験
10:00-10:30 [ok] 事務処理関係チェック
13:00-13:30 [ok] Wake On LAN 設定
13:30-14:00 [ok] SFSDP での実験、大きめ
14:10-14:40 [ok] 発表原稿チェック
14:40-15:30 [ng] SeDuMi 中身チェック
15:50-16:30 [ok] SDPA 論文校正内容検討その１
16:30-17:00 [ng] SDPA論文校正内容検討その１まとめ
17:30-18:00 [ok] SDPA論文校正内容検討その１まとめ続き
今日のBGM: Romasing SAGA 3 OST [1-3]
今日のランチ： らく 山芋定食
明日の予測作業時間： 5h
2010年11月4日木曜日
SDPA の論文の校正スタート
１月最後に投稿していたSDPAの論文がようやくレフリーから返却されてきた。
かなり大幅な校正が必要、という判断であったが、reject されなかっただけ良かったと考えて、早速校正をするべきかと思う。
なにはともあれ、レフリーレポートを良く読んで、どのように校正すべきかを検討するところからスタートである。
あと、semidefinite embedding のは、読んだ論文の数値結果はどうやら SFSDP のよりもかなり高速である。ただ、データが特殊なので、論文で提案している手法が効果的なのか、あるいはデータの特質で高速に解けるのかを切り分ける必要がある。とりあえず、データを生成するプログラムは昨日作成したので、これを SFSDP にかけることになる。
今日の作業内容：SDPA 校正スタート、データ生成
今日のランチ：らく チキンカツ
明日の予測作業時間：5h
かなり大幅な校正が必要、という判断であったが、reject されなかっただけ良かったと考えて、早速校正をするべきかと思う。
なにはともあれ、レフリーレポートを良く読んで、どのように校正すべきかを検討するところからスタートである。
あと、semidefinite embedding のは、読んだ論文の数値結果はどうやら SFSDP のよりもかなり高速である。ただ、データが特殊なので、論文で提案している手法が効果的なのか、あるいはデータの特質で高速に解けるのかを切り分ける必要がある。とりあえず、データを生成するプログラムは昨日作成したので、これを SFSDP にかけることになる。
今日の作業内容：SDPA 校正スタート、データ生成
今日のランチ：らく チキンカツ
明日の予測作業時間：5h
登録:
投稿 (Atom)