MUMPS 4.9 登場

MUMPS ライブラリ のバージョン 4.9 が公開された。SDPA と SDPARA では外部ライブラリとして MUMPS も利用している。細かい 4.8.4 から 4.9 への変更点はホームページを参考にしていただくが、速度的には以下のようにほとんど変化は見られない。

問題 1 : d2s6Kn0r01a4.dat-s

SDPA 7.3.1 + MUMPS 4.8.4 : 53.921s
SDPA 7.3.1 + MUMPS 4.9 : 54.301s

問題 2 : s5000n0r05g2FD_R.dat-s

SDPA 7.3.1 + MUMPS 4.8.4 : 3m49.649s
SDPA 7.3.1 + MUMPS 4.9 : 3m49.596s

旧 SDPA サーバ修理中

旧 SDPA サーバ修理中だが、まだ修理は完了していない。

1: RAID コントローラ(RAID 5)が異常の可能性
2: RAID コントローラを交換する
3: 別のエラーで起動しない
4: マザーボードを交換する
5: ところがこの新マザーボードが初期不良の可能性
6: 別の新しいマザーボードを用意する
7: この新しいマザーボードと交換した新 RAID コントローラの組合せで起動しない
8: 元の RAID コントローラに戻すと一応起動する

というわけで結構ややこしい。交換用のマザーボードや RAID コントローラと言っても元の物と微妙に仕様が異なっているので、新旧の組合せの動作確認も必要になる。

New technologies in SDPA project 3

前回までは速く安定して計算するための技術紹介だったが、今回は計算基盤に関する内容になる。これまでは Linux を中心に開発を行っているが、Windows で動作させるのが面倒なことや、クラスタ計算機などが無いので並列計算出来ませんという要望に答えるために最適化 Online Solver というものを用意してきた。

1: SDPA Online Solver
http://sdpa.indsys.chuo-u.ac.jp/portal/ (従来版)
http://laqus.indsys.chuo-u.ac.jp/portal/ (新版)

2: 最短路 Online Solver
http://opt.indsys.chuo-u.ac.jp/portal/

これらは、最適化それに Web 系の技術、クラスタ、グリッド、クラウドなどの技術の融合になっている。今後は説明の図にもあるように、需要によって動的に計算資源が増減するあるいは適切な計算資源を選択、起動するシステムの構築を行う予定になる。クラウドコンピューティングというのはグリッドとは異なり企業ベースで始められたので、認知や普及の速度が速い。クラウドも普及して一段落したらその先の展開は読みにくいが、我々は最適化ソフトウェアのサービスが行いたいのであって、計算基盤の構築、管理がしたい訳ではないので、将来的には最適化 Online Solver のようなサービスの形態も変わっていくだろう。

オープンソースの開発とコミュニティの維持

先日、以下の内容で講演をしていただいた。世界的に見てもオープンソースの開発については資金が潤沢にあるわけでもなく、組織的にも問題が多いのだが、日本の現状はローカライズ(日本語化)がメインであって、開発そのものに参加することは少なくとも日本にいては難しいのが現状である。OpenOffice だけではないが、日本ではオープンソースと言うと、無料そしてコスト削減ということが前面に出てしまい、単なるユーザ（ダウンロードするだけ）ということに特に引け目も感じていないように見えてしまう。単に公的な資金の投入ということだけではなく、企業や個人などからの寄付、参加などオープンソース文化に対する理解が日本は遅れていて、国力に見合うような貢献が出来る見込みも無さそうだ。
ただし、日本の情報系、ソフトウェア系に対する研究資金というのは決して少ないわけではないが、大規模な公的プロジェクトは成功例が少ないという事実がある。特に大きな財政支援が無いプロジェクトの方がむしろ細々としながらも継続して動いているという事実からも学ぶ点は多い。


オープンソースコミュニティでのソフトウェア開発とコミュニティマネジメントについて
OpenOffice.org/FreeBSD.orgへの参加を通して

現在のあらゆるコンピュータ環境に、もはやフリーソフトウェア(オープンソースソフトウェア)は必須である。フリーソフトウェア(オープンソースソフトウェア)は大抵無料で入手できるため、開発者などに開発費が支払われることはほとんどない。OpenOffice.orgおよびFreeBSD.orgでの開発およびコミュニティマネジメントを通して、どうしたら参加できるか、我々は何を求めているか、どうしたら存続、維持できるかなどについて話をする。

New technologies in SDPA project 2

今回の新技術は安定して高精度で計算するために必要となる。SDPA などの数値計算の世界では倍精度では仮数部の bit 数が足りないのだが、CG やゲームの世界では単精度でも十分であり、最適化でも組合せ最適化の世界では一般には単精度で十分であろう。というわけでさらに高精度(4倍精度)計算がハードウェアでサポートされることは需要や市場の大きさを考慮すると当分無いと思われる。
SDPA では最適解に接近するに連れて変数行列の条件数が発散して数値的にも不安定になる傾向がある。そこで全部あるいは一部の計算を多倍長で行う必要がある。SDPA ではおそらく多くの問題で 4 倍精度計算で十分であると予想される。そこで一部の計算を 4 倍精度で行い、しかもこの 4 倍精度の計算部分をマルチスレッド化して高速化する予定もある。

New technologies in SDPA project 1

今日から４回シリーズで SDPA プロジェクトで用いられている幾つかの新技術について紹介する。１回目は速く計算するための方法についてになる。内点法のアルゴリズム的にも様々な工夫があるが、これらは特に”新技術”というほどでも無いので今回は割愛する。

１：並列計算(MPI と pthread のハイブリッド並列計算)
SDPARA で用いられている並列計算。計算する行列の範囲を MPI レベルで分割して、各ノード上でさらに pthread で並列に計算する

２：CPU のマルチコア化
Schur complement 行列の計算、Cholesky 分解、探索方向の計算などで CPU のマルチスレッドを利用した並列計算を行う

３：メモリ階層構造の考慮と活用
上記の１と２については、メモリの階層構造を可能な範囲で考慮して、資源共有等によるボトルネックの発生を防ぐ

４：GPGPU (今後)
密な計算（行列積）や疎な計算（疎行列のアクセスと計算）で今後 GPGPU を活用する可能もある

SDPA 7.3.1 + GotoBLAS or Intel MKL

Intel のコンパイラと MKL ライブラリを最新のものにバージョンアップしたので、GotoBLAS との比較を行ってみた。

○実行マシン：Intel Xeon 5460 (3.16GHz) x 2 : メモリ 48GB : CentOS 5.3 for x86_64
Intel C++ & Fortran コンパイラ 11.1.046, Intel MKL ライブラリ 10.2.1.017

問題 1 : theta6.dat-s
SDPA 7.3.1 + GotoBLAS 1.38 : 14.91s
SDPA 7.3.1 + Intel MKL 10.2.1.017 : 16.04s

問題 2 : LiH.1Sigma+.STO6G.pqgt1t2p.dat-s
SDPA 7.3.1 + GotoBLAS 1.38 : 22.9s
SDPA 7.3.1 + Intel MKL 10.2.1.017 : 23.7s

もしも SDPA の一部の演算を 4 倍精度で行ったら

SDPA の計算において数値精度を悪化させる原因は様々だが、SDPA-GMP などを使用した場合では非常に高い数値精度が得られることも多い。そこで、SDPA の一部の演算を高精度で行うことによって、数値的に安定な解が得られる可能性もあるだろう。以前から変数行列の逆行列を求める箇所があやしいと睨んでいるので、この部分の計算だけを４倍精度(正確には double-double なので疑似 4 倍精度)で行うと仮定する。これで現在のデータから 4 倍精度演算による結果を推定してみよう。

1: 行列 Y の逆行列 Y^{-1} を求める部分のみを 4 倍精度化する
2: 4 倍精度演算は現在の最適化された倍精度演算の約 1/100 の速度とする

問題１: Be.1S.SV.pqgt1t2p
現在(SDPA 7.3.1) : 2232.9s
一部 4 倍精度 : 2969.9s(推定)

問題２: s5000n0r05g2FD_R
現在(SDPA 7.3.1) : 276.4s
一部 4 倍精度 : 406.5s(推定)

問題３: thetaG51
現在(SDPA 7.3.1) : 86.0s
一部 4 倍精度 : 217.3s(推定)

当初の目標10ペタFLOPS

http://www.riken.go.jp/r-world/info/release/press/2009/090717/ スカラー型計算機のみに絞って、当初計画どおり、性能目標10ペタFLOPS達成と2012年完成を目指すということになっている。採用する CPU は現時点で世界最高速と書いてあるけれども、全体性能で世界最高速というのは無くなっているので、こちらの方は諦めてしまったのではないだろうか。世界最高速でなくても安定して稼働すれば超高速スパコンには違いないので、密でも疎でも性能を引き出せるようなアプリケーションの開発とノウハウの取得をお願いしたい。

SDPA Online Solver 変更

SDPA Online Solver (http://sdpa.indsys.chuo-u.ac.jp/portal/) を以下のように変更を行った。ソフトウェアは公開前も含めて最新の物を使用している。

A: SDPA 7.3.1 + GotoBLAS 1.34 + MUMPS 4.8.4
実行マシンは AMD Opteron 2384 (2.7GHz) x 2 CPU ; 32GB memory
スレッド数は 1, 2, 4, 8 から選択

B: SDPARA 7.3.1 + GotoBLAS 1.38 + MUMPS 4.8.4
実行クラスタは Intel Xeon 5345 2.33GHz x 2 CPU x 4 node ; 16GB memory/node
並列計算のノード数等は以下から選択
1: 1 node x 1 core
2: 2 node x 1 core
4: 4 node x 1 core
8: 4 node x 2 core
16: 4 node x 4 core
32: 4 node x 8 core

C: SDPARA 1.0.1 + GotoBLAS 1.38 + ATLAS 3.9.11
上記の SDPARA と同じ

SDPA サーバ壊れた＆復旧

SDPA サーバ (sdpa.indsys.chuo-u.ac.jp) が突然 Disk の読み書きが出来なくなって、reboot 等も不可能になった。明らかに RAID コントローラか Disk に異常が発生している。手動で reboot したら、やはり RAID コントローラに異常発生しているようなので、緊急措置として他のマシンで再インストールや再設定等を行って、SDPA サーバとして使うことを考えてみた。
しかし、良く考えてみると同種類の Dell PowerEdge 2970 があと２台あるので、試しに RAID 5 の Disk を全部取り替えてみると無事に起動した(やはり Disk ではなく RAID コントローラの故障か？)。SDPA Online Solver の再設定には 1 時間ぐらいかかったが、それでもマシンが１台減っただけで、無事に SDPA サーバが復旧した。購入後まだ９ヶ月ぐらいなのに壊れるのは少し早い。

SCOPE つくば合宿 受賞者名簿

様々な事情で SCOPE つくば合宿の受賞者の公式発表が遅れました。今年度の受賞者は以下の通りです。全体的に研究のレベルが高いので、採点を行い受賞者を決めるのは結構苦労しました。もちろん来年も開催予定です。

○最優秀論文賞
小林佑輔　　東京大学大学院 情報理工学系研究科 数理情報学専攻
今道貴司　　京都大学大学院 情報学研究科 数理工学専攻

○優秀論文賞
越川 満　　筑波大学大学院 システム情報工学研究科 コンピュータサイエンス専攻
神山 直之　　中央大学理工学部情報工学科
安井 雄一郎　　中央大学 理工学研究科 経営システム工学専攻
山中翔太　　京都大学情報学研究科
松川恭明　　筑波大学大学院 システム情報工学研究科 社会システム工学専攻
山口大輔　　中央大学大学院・理工学研究科・情報工学専攻

レイアウトとテンプレート変更

暑いので期間限定で涼しげなテンプレートに変更してみました。いろいろなテンプレートが選べるのですが、どうもブログの内容と一致しそうなものが見当たりません。以前のレイアウトは意外と見やすかったので、また元に戻すかもしれません。

Parallel Cholesky Factorization とブロックサイズ その２

前回と同じで SDPARA 7.3.1 のブロック数を変化させて全体の実行時間を違いを測定してみた。この場合では 192 が良さそうだ。

非負かつ半正定値(DNN : doubly non‐negative)制約
1: nug16ak.dat-s (QAP : 二次割当問題)

SDPARA 7.3.1 (サイズ 48) : 1145.1s (29反復)
Cholesky bMat = 905.9s, 79.1%

SDPARA 7.3.1 (サイズ 160) : 907.7s (30反復)
Cholesky bMat = 709.9s, 78.2%

SDPARA 7.3.1 (サイズ 168) : 1001.6s (31反復)
Cholesky bMat = 760.9s, 77.1%

SDPARA 7.3.1 (サイズ 192) : 887.1s (30反復)
Cholesky bMat = 699.4s, 80.4%

SDPARA 7.3.1 (サイズ 216) : 971.3s (31反復)
Cholesky bMat = 745.6s, 78.1%

SDPARA 7.3.1 (サイズ 232) : 947.5s (30反復)
Cholesky bMat = 736.6s, 79.1%

SDPARA 7.3.1 (サイズ 256) : 887.1s (30反復)
Cholesky bMat = 720.2s, 79.9%

マルチスレッドによる計算とそのバランシング

SDPA 7.3.1 では添付の図のように Schur complement 行列を行単位(実際は列単位だが実質同じ)でマルチスレッド計算を行っている。しかしスレッド間のロードバランシングが問題によっては悪いので少し調査を行った。今回は回数のみに着目しているが、将来的には予めスレッドごとに計算する範囲を決めてキューを作成した方が良い。

○SDPA 7.3.1 + GotoBLAS 1.34 + MUMPS 4.8.4 : CPU Intel Xeon 5550 2.67GHz ; メモリ 72GB
全て 8 スレッド(OMP_NUM_THREADS=8)で動作させた。

問題１: mcp500-1.dat-s
これは行数が少なく、大変疎な問題なのでほとんど 1st スレッドしか利用されない。

スレッド番号 実行回数
1 7750
2 250
3 0
4 0
5 0
6 0
7 0
8 0

問題２: mcp2000-10.dat-s
同じく疎な問題だが、行数が増えるので多少バランシングされる。

スレッド番号 実行回数
1 16712
2 7573
3 1964
4 2077
5 1280
6 656
7 1329
8 409

問題３ : theta6.dat-s
やはり疎でも行数が多い(4375)と、それなりにバランシングされる。

スレッド番号 実行回数
1 13035
2 12449
3 9202
4 8991
5 9547
6 8300
7 8776
8 8450

問題４: D512.dat
密な問題の場合では以下のようにかなり良い。

スレッド番号 実行回数
1 1099
2 1101
3 1065
4 1063
5 1103
6 1073
7 1134
8 1066