1ノードでの SDPA と SDPARA

以下の二つの計算サーバを用いて、1 ノード上での SDPA と SDPARA の性能を比較した。SDPARA の方は MPI と Pthread による二段階並列になっているので、これも様々な組合せを調べてみた。やはり1ノードであれば余計なオーバーヘッドが無い分だけ SDPA の方が速い。また、SDPARA では CPU数 = MPI, 1CPU あたりのコア数 = Pthread とするのが、一番性能が良さそうだが以下の結果を見るとそれほど単純では無さそうだ。

○ 計算サーバ１ (4 CPU x 6 コア = 24 コア)
CPU : AMD Opteron 8439 (2.80GHz / 6MB L3) x 4 (24コア)
Memory : 128GB (32 x 4GB / 800MHz)
OS : Fedora 13 for x86_64

○ 計算サーバ２ (2 CPU x 4 コア = 8 コア)
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2 (8コア)
Memory : 72GB (18 x 4GB / 800MHz)
OS : Fedora 13 for x86_64

○ 問題 : NH3+.2A2\".STO6G.pqgt1t2p.dat-s

○ 計算サーバ１：
■ SDPA 7.3.2 (24コア) : 4m15s
■ SDPARA 7.3.2 (1 MPI x 24 Pthread) : 4m58s
■ SDPARA 7.3.2 (2 MPI x 12 Pthread) : 4m19s
■ SDPARA 7.3.2 (4 MPI x 6 Pthread) : 4m31s
■ SDPARA 7.3.2 (6 MPI x 4 Pthread) : 4m35s
■ SDPARA 7.3.2 (12 MPI x 2 Pthread) : 4m59s
■ SDPARA 7.3.2 (24 MPI x 1 Pthread) : 5m52s
○ 計算サーバ２：
■ SDPA 7.3.2 (8コア) : 8m4s
■ SDPARA 7.3.2 (1 MPI x 8 Pthread) : 8m17s
■ SDPARA 7.3.2 (2 MPI x 4 Pthread) : 8m20s
■ SDPARA 7.3.2 (4 MPI x 2 Pthread) : 8m43s
■ SDPARA 7.3.2 (8 MPI x 1 Pthread) : 9m18s

PowerEdge C410x

PowerEdge C410x は以下のように GPU カードの搭載を目的としたラックマウント型の拡張シャーシになっている。特にブレードサーバ等ではスペースの関係上、GPU カードの内蔵は難しい場合もあって、外部接続を行う必要がある。高負荷の計算時には GPU 自体も熱くなって、GPU の熱によってサーバ本体も暴走する危険性もあるので、このように両者を切り離してしまう方が安定性から考えても好ましいのかもしれない。GPU カードは ATI 製でも内蔵可能となっている。

最大16.48テラFLOPSの計算処理能力をデータセンターに追加可能。

PowerEdge C410xは、3Uの16スロット外部PCIe拡張シャーシです。最大で16枚のGPUカードへの8つのホスト接続をサポートします。 これにより、膨大な並列計算処理をサーバから切り離すことが可能となり、システムパフォーマンスと柔軟性が大幅に向上します。

新クラスタ計画 2010年8月

いろいろな事情で調達が遅れているが、以下の仕様で１０月には稼働させる予定になっている（次の方針を採用する）。SDPARA の実行が主要目的だが、他の最適化ソフトウェアの実行にも適した仕様になっている。

１： Linpack 性能は考慮に入れない。つまり、ノード数、CPU 数、コア数を増やすことは重視しない
２： これまでの SDPARA の実行特性を考慮して CPU は Intel Xeon 56xx 系を採用する
３： 大規模問題の実行を考慮して、１ノードあたりのメモリ量を増やす。

○ 電源：単相２００Ｖ３０Ａ; ３口
○ 10U モジュール型ブレードエンクロージャ PowerEdge M1000e
○ 2ソケットハーフハイトサーバ Dell PowerEdge M710HD

CPU : インテル(R) Xeon(R) プロセッサー X5670(2.93GHz) x 2 個
メモリ : 128GB (16X8GB/2R/1333MHz/DDR3 RDIMM/CPUx2) or 144GB (18X8GB/2R/1333MHz/DDR3 RDIMM/CPUx2)
ネットワーク : GbE x 1 & Infiniband (QDR) x 1

大規模最適化問題に対する高速計算 -- 理論からスパコンまで -- その３

執筆と校正が終了したので、数学セミナーの１０月号に以下の内容が無事に掲載される予定になった。以下の 4 節はこちらの内容をまとめたものになっている。

題名：大規模最適化問題に対する高速計算 理論からスパコンまで

1: はじめに
2: 最適化問題に関する最新の傾向について
3: 半正定値計画問題と使用方法
4: 大規模 SDP のスパコンによる高速計算
5: おわりに

KSMAP琵琶湖合宿

以下のように１０月９日から１１日まで琵琶湖で KSMAP の合宿が開催されます。5 ～ 6 月は関東、10 月は関西で最適化系の合宿が恒常的に開催されるようになっておりますので、今後とも両者への積極的な参加をお願い致します。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
日本オペレーションズ・リサーチ学会
研究部会『ＯＲ横断若手の会』
「若手研究交流会(KSMAP琵琶湖合宿)」のご案内
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

本研究部会では，昨年に引き続いて今年も，異なる大学・企業に所属する
様々な研究領域の若手研究者が活発に交流することを目的としたセミナーを
企画しました．

今回は，遠方からご参加の方の利便性を考慮して，琵琶湖湖畔の琵琶湖
コンファレンスセンターに開催地を移しました．
本セミナーを通じて，大学・企業や研究領域の枠を超えた新たな出会いが
生まれることを期待しています．

日程：2010年10月9日（土）～ 10月11日（月）
場所：琵琶湖コンファレンスセンター（滋賀県彦根市）
発表申込み締切： 2010年9月10日（金）
参加申込み締切： 2010年9月24日（金）

本研究交流会の詳細，ならびに参加申し込み等については
http://www.kurims.kyoto-u.ac.jp/~tanigawa/ksmap-camp/
をご覧ください．

※宿泊施設の収容人数に限りがあるため，申込人数に上限を設けさせて
頂きます．先着順となりますので，早めにご検討頂ければ幸いです．

※本研究交流会に関するお問い合わせの際は下記のメールアドレスを
ご利用ください．
実行委員会メールアドレス：ksmap-camp2010@amp.i.kyoto-u.ac.jp

主査：林 俊介 (京都大学)
幹事：福永 拓郎 (京都大学)
実行委員：梅谷 俊治 (大阪大学，実行委員長)，来嶋 秀治 (九州大学)，
高澤 兼二郎 (京都大学)，谷川 眞一 (京都大学)，檀 寛成 (関西大学)，
蓮池 隆（大阪大学)，増山 博之 (京都大学)

CPU温度と最適化ソフトウェア その２

こちらのブログでも何回か報告しているように SDPA クラスタ上で ソフトウェア SDPARA を用いて４ヶ月以上連続で大規模な量子化学 SDP を解く実験を行っている。残りが３問ということで、あと数日で終了すると推測するが、これは全てのコアを計算に用いた全力計算状態なのでハードウェアにかかる負担も大きい。しかしこの４ヶ月間で二つのノードのメモリを交換したのみで他には特にトラブルは発生しなかった。
この SDPA クラスタ上で数値実験に用いているのは以下の問題１のタイプなので、発熱量は問題２と比較すると少し低めになっている。ただし問題１の方が全体の発熱量（消費電力）が低い半面、メモリにより負荷がかかっているとも言える。

○ SDPA 7.3.2 + GotoBLAS2 1.13

○ 問題１ : NH3+.2A2\".STO6G.pqgt1t2p.dat-s
2964 = mDIM
22 = nBLOCK
8 8 8 8 28 28 64 28 28 64 128 64 64 56 224 224 56 744 744 224 224 -154 = bLOCKsTRUCT
Schur complement 行列を作るのに大変な時間を要する。非常に疎なデータなので演算よりもアドレス計算あるいはキャッシュやメモリアクセスの比重が大きくなる。

Core 0: +58.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +55.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +57.0°C (high = +84.0°C, crit = +100.0°C)
Core 4: +57.0°C (high = +84.0°C, crit = +100.0°C)
Core 5: +55.0°C (high = +84.0°C, crit = +100.0°C)
Core 6: +53.0°C (high = +84.0°C, crit = +100.0°C)
Core 7: +57.0°C (high = +84.0°C, crit = +100.0°C)

○ 問題２ : mcp7000-10.dat-s
7000 = mDIM
1 = nBLOCK
7000 = bLOCKsTRUCT
Schur complement 行列を作る部分は非常に高速。その半面、行列積の計算が大きな比重を占める

Core 0: +68.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +65.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +65.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +65.0°C (high = +84.0°C, crit = +100.0°C)
Core 4: +66.0°C (high = +84.0°C, crit = +100.0°C)
Core 5: +64.0°C (high = +84.0°C, crit = +100.0°C)
Core 6: +62.0°C (high = +84.0°C, crit = +100.0°C)
Core 7: +65.0°C (high = +84.0°C, crit = +100.0°C)

CPU温度と最適化ソフトウェア

以下の 8 コアの計算サーバを用いて、最適化ソフトウェア実行中の各 CPU コアの温度を測定してみた。SDPA + BLAS の組合せでは CPU 内のリソースが効率良く使われていないようで、発熱量も他と比較すると極めて低い。整数計画問題に対するソルバー (Gurobi, CPLEX) や最短路問題に対するソルバー(msp) などでは CPU 内の演算処理部分はフルに使用されていない。前回と同様に SDPA + GotoBLAS2 の発熱量は非常に大きい。

○計算サーバ
CPU : Intel Xeon 5550 (2.66GHz / 8MB L3) x 2 (8コア)
Memory : 72GB (18 x 4GB / 800MHz)
OS : Fedora 13 for x86_64

○ Gurobi 3.0.1
Core 0: +57.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +54.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 4: +57.0°C (high = +84.0°C, crit = +100.0°C)
Core 5: +55.0°C (high = +84.0°C, crit = +100.0°C)
Core 6: +53.0°C (high = +84.0°C, crit = +100.0°C)
Core 7: +57.0°C (high = +84.0°C, crit = +100.0°C)

○ CPLEX 12.2
Core 0: +57.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +55.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 4: +58.0°C (high = +84.0°C, crit = +100.0°C)
Core 5: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 6: +53.0°C (high = +84.0°C, crit = +100.0°C)
Core 7: +57.0°C (high = +84.0°C, crit = +100.0°C)
Core 0: +57.0°C (high = +84.0°C, crit = +100.0°C)

○ msp 0.21(最短路ソルバー)
Core 1: +55.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 4: +58.0°C (high = +84.0°C, crit = +100.0°C)
Core 5: +56.0°C (high = +84.0°C, crit = +100.0°C)
Core 6: +53.0°C (high = +84.0°C, crit = +100.0°C)
Core 7: +57.0°C (high = +84.0°C, crit = +100.0°C)

○ SDPA 7.3.2 + リファレンス BLAS 3.2.1
Core 0: +49.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +42.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +52.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +44.0°C (high = +84.0°C, crit = +100.0°C)
Core 4: +50.0°C (high = +84.0°C, crit = +100.0°C)
Core 5: +45.0°C (high = +84.0°C, crit = +100.0°C)
Core 6: +45.0°C (high = +84.0°C, crit = +100.0°C)
Core 7: +45.0°C (high = +84.0°C, crit = +100.0°C)

○ SDPA 7.3.2 + GotoBLAS2 1.13
Core 0: +68.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +65.0°C (high = +84.0°C, crit = +100.0°C)
Core 2: +65.0°C (high = +84.0°C, crit = +100.0°C)
Core 3: +65.0°C (high = +84.0°C, crit = +100.0°C)
Core 4: +66.0°C (high = +84.0°C, crit = +100.0°C)
Core 5: +64.0°C (high = +84.0°C, crit = +100.0°C)
Core 6: +62.0°C (high = +84.0°C, crit = +100.0°C)
Core 7: +65.0°C (high = +84.0°C, crit = +100.0°C)

CPU温度と BLAS ライブラリ その２

結論から見ると予想通りというか、同じ計算マシンで同じソフトの組合せを用いても以下のように発熱量は随分異なっている。問題１の方は行列積の占める時間が大きいので、GotoBLAS2 が行列積を行っている時間も長くなり CPU 内の演算量も増えて発熱が大きくなる。一方、問題２の方は疎行列に対する処理が占める時間が大きく、メモリやキャッシュに対する処理が中心となり発熱量を抑えることができるようだ（その代わりにメモリが熱くなっているだろう）。量子化学に対する SDP は後者の問題２のパターンになるので、現在 SDPA クラスタで行っている長期実験においても CPU に対する負荷は少しだけ抑えられていると推測される。

○計算マシン
CPU : Intel Core i7 940 2.93GHz (4コア)
Memory : 8GB
OS : Fedora 13 for x86_64

○問題１： mcp2000-10.dat-s
SDPA 7.3.2 64bit + GotoBLAS2 1.13
CPU 最高温度: 65.5℃; 実行時間 1m2s

○問題２： FH2+.1A1.STO6G.pqgt1t2p.dat-s
SDPA 7.3.2 64bit + GotoBLAS2 1.13
CPU 最高温度: 60.0℃; 実行時間 3m12s

CPU温度と BLAS ライブラリ

以前も調査したのだが、SDPA + 最適化 BLAS の組合せは SDPA + リファレンスBLAS と比較すると発熱が大きい。ただし以下のように一般的には前者の組合せの方が高速である。以下を見ると GotoBLAS = 最強発熱の伝説は本当らしい。クラスタ計算機でもスパコンでも全力計算時には大変な発熱量になるので、熱に関する設計は余裕を持たせた方が良いだろう。

○問題 mcp2000-1.dat-s

○マシン１
CPU : AMD Phenom(tm) II X4 955 3.2GHz(4コア)
Memory : 8GB
OS : Fedora 13 for x86_64

1: SDPA 7.3.2 64bit + BLAS 3.2.2
CPU 最高温度: 44℃; 実行時間 12m39s
2: SDPA 7.3.2 64bit + AMD ACML 4.4.0
CPU 最高温度: 52℃; 実行時間 1m19s
3: SDPA 7.3.2 64bit + Intel MKL 11.1.072
CPU 最高温度: 52℃; 実行時間 1m20s
4: SDPA 7.3.2 64bit + GotoBLAS2 1.13
CPU 最高温度: 53℃; 実行時間 1m8s

○マシン２
CPU : Intel Core i7 940 2.93GHz (4コア)
Memory : 8GB
OS : Fedora 13 for x86_64

1: SDPA 7.3.2 64bit + BLAS 3.2.2
CPU 最高温度: 53.5℃; 実行時間 8m20s
2: SDPA 7.3.2 64bit + AMD ACML 4.4.0
CPU 最高温度: 63.5℃; 実行時間 1m6s
3: SDPA 7.3.2 64bit + Intel MKL 11.1.072
CPU 最高温度: 63.5℃; 実行時間 1m2s
4: SDPA 7.3.2 64bit + GotoBLAS2 1.13
CPU 最高温度: 65.5℃; 実行時間 1m2s

大規模動的ネットワークに対する最短路高速計算システム

大規模動的ネットワークに対する最短路高速計算システム

①技術の概要
大規模なネットワーク上で二点間の最短路を求める最短路問題は非常に幅広い応用が存在する
1: 世界最高レベルの性能を持った最短路計算エンジン
2: 拡張性の高いアルゴリズムとデータ構造により様々な条件を追加することが可能
3: クラウドコンピューティングの技術によるオンライン・ソルバーの構築解法にはダイクストラ法というアルゴリズムが用いられるが、データ構造やメモリ階層構造を考慮した実装上の工夫により世界最高速レベルの速度、安定性、低メモリ消費などの特性を備えたソフトウェアの作成に成功した。また道路データだけでなく、鉄道などの時空間ネットワークなど大規模なネットワーク上での最短路検索への対応を行った。

②産業界へのアピールポイント
現在よりも高性能かつ高機能なナビゲーションシステムの開発、また渋滞状況に応じた交通管制や大規模災害時における避難シミュレーションなどの新規分野の開拓が期待できる

③技術の特徴
1: 世界最高レベルの性能を持った最短路計算エンジン
2: 拡張性の高いアルゴリズムとデータ構造により様々な条件を追加することが可能
3: クラウドコンピューティングの技術によるオンライン・ソルバーの構築

④想定される用途
大規模ネットワークにおける最短経路の高速計算及びクラウドによる並列分散コンピューティング

大規模最適化問題に対する高速計算 -- 理論からスパコンまで -- その２

数学セミナー10月号の原稿の作成が終った。題名や構成については以下の通りになる。

題名：大規模最適化問題に対する高速計算 -- 理論からスパコンまで --
1: はじめに
2: 最適化問題に関する最新の傾向について
3: 半正定値計画問題と使用方法
4: スパコンによる大規模 SDP の高速計算
5: おわりに

Dell Powerconnect

クラスタ計算機用のネットワークスイッチである Dell PowerConnect 2724 が暑さが原因で故障が発生した（大変焦げ臭い臭いがした）。幸い研究室には Dell PowerConnect 2824　が予備として１台あったので、スイッチの交換と全ノードを再起動した。現時点では特にトラブルは発生しておらず SDPARA の数値実験も再開した。

大規模最適化問題に対する高速計算 -- 理論からスパコンまで --

数学セミナーの９月号に予告が出ているそうだが（まだ現物を見ていないので）、今度は１０月号に以下の解説記事を書く予定になっている（実際にはもう書き終った）。

大規模最適化問題に対する高速計算
-- 理論からスパコンまで --

高速化・最適化のためのBLAS入門

私よりも BLAS に詳しい人はたくさんいると思うのだが、
”高速化・最適化のためのBLAS入門”
という題名で作成した解説記事が数学セミナーに掲載された。BLAS に関する日本語の情報はインターネットにたくさんあるのだが、意外と BLAS に関する日本語の解説記事は見当たらない（特に最新の内容で）。数学セミナーということでプログラミングのテクニックといった内容はあまり含まれていない。

2010年9月号　 　通巻 588号
数学セミナー 2010年9月号 588号

特集1
数学を発展させるコンピュータソフト

量子化学に対する SDPARA その２

量子化学に対する SDPARA の数値実験だが、残り６問になったが解きにくい問題が残っていることもあって、最近はほとんど最適に解けていない。何はともあれもう少しで終るというのは気持ちが良いものだ。

15 1.6e-05 5.2e-10 2.1e-09 +4.49e-02 -2.98e-01 4.1e-01 1.3e-01 1.00e-01
16 1.3e-05 3.1e-10 2.0e-09 +2.92e-02 -2.63e-01 6.1e-01 1.4e-01 1.00e-01
17 1.1e-05 1.2e-10 2.7e-09 +1.50e-02 -2.29e-01 6.1e-01 1.4e-01 1.00e-01

phase.value = noINFO
Iteration = 17
mu = +1.0638203723749080e-05
relative gap = +2.4408425190005970e-01
gap = +2.4408425190005970e-01
digits = -3.0102999566398120e-01
objValPrimal = +1.4965833391326535e-02
objValDual = -2.2911841850873316e-01
p.feas.error = +2.6606948205182314e-08
d.feas.error = +2.6806944333657157e-05
total time = 137272.054816