最適化問題に対する超高速&安定計算

クラスタ計算機やスーパーコンピュータ上での大規模最適化問題やグラフ探索などの研究のお話が中心

1ノードでの SDPA と SDPARA

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

○ 計算サーバ1 (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 (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

○ 計算サーバ1:
■ 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
○ 計算サーバ2:
■ 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
コメント (2)
この記事をはてなブックマークに追加

PowerEdge C410x

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

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

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

新クラスタ計画 2010年8月

2010年08月29日 04時38分31秒 | Weblog
いろいろな事情で調達が遅れているが、以下の仕様で10月には稼働させる予定になっている(次の方針を採用する)。SDPARA の実行が主要目的だが、他の最適化ソフトウェアの実行にも適した仕様になっている。

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

○ 電源:単相200V30A; 3口
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
コメント
この記事をはてなブックマークに追加

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

2010年08月28日 02時26分21秒 | Weblog
執筆と校正が終了したので、数学セミナーの10月号に以下の内容が無事に掲載される予定になった。以下の 4 節はこちらの内容をまとめたものになっている。

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

1: はじめに
2: 最適化問題に関する最新の傾向について
3: 半正定値計画問題と使用方法
4: 大規模 SDP のスパコンによる高速計算
5: おわりに
コメント
この記事をはてなブックマークに追加

KSMAP琵琶湖合宿

2010年08月27日 02時25分16秒 | Weblog
以下のように10月9日から11日まで琵琶湖で KSMAP の合宿が開催されます。5 ~ 6 月は関東、10 月は関西で最適化系の合宿が恒常的に開催されるようになっておりますので、今後とも両者への積極的な参加をお願い致します。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
日本オペレーションズ・リサーチ学会
研究部会『OR横断若手の会』
「若手研究交流会(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温度と最適化ソフトウェア その2

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

○ SDPA 7.3.2 + GotoBLAS2 1.13

○ 問題1 : 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)

○ 問題2 : 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温度と最適化ソフトウェア

2010年08月25日 02時01分15秒 | Weblog
以下の 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 ライブラリ その2

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

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

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

○問題2: FH2+.1A1.STO6G.pqgt1t2p.dat-s
SDPA 7.3.2 64bit + GotoBLAS2 1.13
CPU 最高温度: 60.0℃; 実行時間 3m12s
コメント
この記事をはてなブックマークに追加

CPU温度と BLAS ライブラリ

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

○問題 mcp2000-1.dat-s

○マシン1
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

○マシン2
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
コメント
この記事をはてなブックマークに追加

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

2010年08月22日 11時09分16秒 | Weblog
大規模動的ネットワークに対する最短路高速計算システム

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

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

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

④想定される用途
大規模ネットワークにおける最短経路の高速計算及びクラウドによる並列分散コンピューティング
コメント
この記事をはてなブックマークに追加

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

2010年08月21日 02時21分53秒 | Weblog
数学セミナー10月号の原稿の作成が終った。題名や構成については以下の通りになる。

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

Dell Powerconnect

2010年08月20日 01時38分22秒 | Weblog
クラスタ計算機用のネットワークスイッチである Dell PowerConnect 2724 が暑さが原因で故障が発生した(大変焦げ臭い臭いがした)。幸い研究室には Dell PowerConnect 2824 が予備として1台あったので、スイッチの交換と全ノードを再起動した。現時点では特にトラブルは発生しておらず SDPARA の数値実験も再開した。
コメント
この記事をはてなブックマークに追加

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

2010年08月19日 03時33分45秒 | Weblog
数学セミナーの9月号に予告が出ているそうだが(まだ現物を見ていないので)、今度は10月号に以下の解説記事を書く予定になっている(実際にはもう書き終った)。

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

コメント
この記事をはてなブックマークに追加

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

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

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


特集1
数学を発展させるコンピュータソフト
コメント
この記事をはてなブックマークに追加

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

2010年08月17日 02時12分27秒 | Weblog
量子化学に対する SDPARA の数値実験だが、残り6問になったが解きにくい問題が残っていることもあって、最近はほとんど最適に解けていない。何はともあれもう少しで終るというのは気持ちが良いものだ。

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
コメント
この記事をはてなブックマークに追加