PowerEdge Cシリーズサーバ＆PowerEdge M910

Dell のサーバシリーズに PowerEdge Cシリーズが加わった。例えば PowerEdge C6100 の場合では、2U に２ソケットサーバを４ノードまで収容可能とのことなので、例えば 10U では、CPU が 5 x 2 x 4 = 40 個搭載できる。一方、ブレードサーバだと、PowerEdge M1000e は 10U 中に 8 ブレード x 2 CPU なので、合計で CPU 16 個となって、前者の方が搭載できる CPU 数は多い。
いよいよ Nehalem-EX 搭載の PowerEdge M910 が登場したが、やはり当初の噂通りに 6 コアの Intel Xeon (Westmere-EP)と比較するとクロック周波数が低い。しかし 1ブレードに 4CPU 搭載可能になっているので、10U では CPU 32個を搭載することができる。

某スパコンと SDPARA その７

二週間に及ぶスパコンでの実行が終了した。未解決問題の幾つかを解決することが出来たので成功ではあるが、同時に今後の課題も判明した。今回解くことが出来た巨大な SDP のデータ特性は以下の通り。この問題は大き過ぎて、こちらのクラスタ計算機では解くことができない。

記号定義
mDIM : SDP の主問題における制約式の数
nBLOCK : ブロック数
bLOCKsTRUCT : 各ブロックの大きさ

116910 (mDIM)
14 (nBLOCK)
20 20 20 20 190 190 400 190 190 400 800 400 400 -850 (bLOCKsTRUCT)

情報システムで役立つ最適化問題 再掲載

3月27日に SCOPE 研究会を行ったが、そこで議論になって点を踏まえて以下の記事を再掲載しておく。このような最適化問題に興味を持っている方は多いと思うが、これらに取り組むためには情報システム等の知識が多数必要で、その辺がネックとなっているのではないだろうか。

１：(混合)整数計画問題と制約プログラミング
ファイルなどの配置関係やマシンや経路等の割当、選択等で用いられる基本的な最適化問題

２：グラフ分割問題と最大クリーク問題
ネットワークや計算機資源（ディスク、CPU）の分割や選択に用いる

３：長方形及び多角形詰め込み問題
計算機資源の有効利用、ジョブマネージャー等でのスループット向上

４：最短路問題や最小費用フロー問題
ネットワーク経路の探索、ファイル転送等

日本数学会 ２０１０年度年会・市民講演会 再掲載

いよいよ本日となりましたので再掲載します。とは言っても私自身はすでに別の用事が入っておりますので、以下の講演会には参加しません。対象は中学生から大人までという内容だそうです。

日本数学会 ２０１０年度年会・市民講演会

日時：
２０１０年３月２８日（日）１４：００～１６：３０
場所：
慶應義塾大学 日吉キャンパス第4校舎B棟J19教室
（日吉キャンパスへのアクセス、キャンパスマップ）
講演者，タイトル：
森吉 仁志（名古屋大学大学院多元数理科学研究科 教授）
調和級数から指数定理へ
小島 政和（東京工業大学大学院情報理工学研究科 教授）
数理最適化への招待

統数研と富士通スパコン

統計数理研究所（統数研）は昨年秋に広尾から立川へ移転しているが、建物の地下に以下の富士通製スパコンが設置されている。非常に高性能なスパコンとは言え、性能的には特筆するほどのものではないのかもしれないが、注目は Intel Xeon X5570（2.93GHz）を搭載していることである。また、以下の記事にもあるように SPARC Enterprise M9000 の方はメモリ領域が最大で 2TB あるそうだが、IBM POWER7 系のサーバではメモリ 3TB という仕様もある（尋常ではなく高そうだが）。スパコンも良いが、やはりメモリが多いマシンも魅力的。

富士通、統数研の新スパコンを受注

某スパコンと SDPARA その６

まだ某スパコンの使用期間は終わっていないので実験を継続中だが、当初の大きな目標の中の一つは達成することができた。それと同時にやり方と工夫によっては、かなり大きな問題も SDPA クラスタで解くことができることが判明した。論文等の問題があるので、最適解の値自体をここに掲載することは無いが、その他結果等についてはまた報告する予定。

１：密や疎データに分けた後で MPI + OpenMP(Pthread) に二段階並列に対応させているが、これも有効に動作している
２：やはり Intel Xeon系の CPU の方が実行性能が良さそう（特に今回のような超大規模疎データの場合）
３：量子化学系はまだ double で扱える範囲になっているが、DNN(半正定値 + 非負制約)の問題等ではかなり厳しい

○ SDPA クラスタ
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.4 for x86_64

○ 某スパコン
128 Nodes, 512 CPUs, 2048 CPU cores; (今回使用した分のみ)
CPU : AMD Opteron 8356 2.3GHz (quad cores) x 4 / node
Memory 32GB / node
NIC : GbE x 2 and Infiniband x 4 / node
OS : RHEL 4.x for x86_64

某スパコンと SDPARA その５

以前の SDPARA の論文(計算機環境は今日と大きく異なるが)や近日中に発表する SDPARA の論文では、
１：Schur complement 行列の計算(F1, F2, F3 式)は scale up しやすい
２：Parallel Cholesky 分解(ScaLAPACK による)は、１と比べると scale up　しない。
という性質がある。これらの結果等から考察すると某スパコンでは F3 式の計算時間がもう少し速くなってもいいはずである。このシステムでは AMD Opteron(Barcelona) の 4-way なので、合計で 16 コアあるのだが、メモリや L3 キャッシュの性能を考えると、同時に使用するコア数はもう少し減らした方が良いかもしれない。しかし、Intel Xeon 系はコア数を最大まで使っても SDPA(SDPARA)では性能が上がることが多い。というわけで、やはり Intel 系の方がお薦めである(金額は高めだが)。

○ソフトウェア : SDPARA 7.3.2
○実験結果

SDPA クラスタ
16プロセス x 8スレッド : 4004.9s(24反復 : pdOPT)
F3 式計算時間 = 2625.7s, 65.6%
Cholesky 分解計算時間 = 1601.2s, 40.0%

某スパコン
128プロセス x 16スレッド : 1770.8s(24反復 : pdOPT)
F3 式計算時間 = 957.7s, 54.3%
Cholesky 分解計算時間 = 509.9s, 28.9%


○ SDPA クラスタ
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.4 for x86_64

○ 某スパコン
128 Nodes, 512 CPUs, 2048 CPU cores; (今回使用した分のみ)
CPU : AMD Opteron 8356 2.3GHz (quad cores) x 4 / node
Memory 32GB / node
NIC : GbE x 2 and Infiniband x 4 / node
OS : RHEL 4.x for x86_64

新クラスタ計算機

大学のセンターに大規模なスパコンが本当に必要かは議論が要るところで、プロジェクト別、目的別に必要な規模の計算機を揃えた方が効率的で省電力ということも考えられるだろう。個人的には計算需要が多いので増設したいところだが、新しいクラスタ計算機を構築すると古い計算機は止めてしまうので、電力消費量（発生する熱の総量）を増やすことなく実質的に計算機資源を増やすことができる。
来年度も新規構築と旧クラスタ停止の計画があるが、全体の性能強化と計算機資源の統合が効率的に行っていく予定である。
これから出荷されるサーバ用 CPU においては、
Intel Xeon 6 コア(Westmere-EP) クロック周波数は高め (3GHz 超)
Intel Xeon 8 コア(Nehalem-EX) クロック周波数は含め (2GHz 台後半)
というのがある(AMD は除く)。開発中の最適化ソフトウェアの性能等を考慮すると後者の方が良さそうだ。

Eucalyptus とオンライン・ソルバー

以前から考えているオンライン・ソルバーに関する構想で、
1: 実マシン内で計算機資源をなるべく競合しないように、複数の最適化ソフトウェアを実行する（いままでいろいろと試してきた通り）。
2: 多少性能が落ちても、最適化ソフトウェアの実行毎に仮想マシンを作成、起動する。
というのがある。実際には最適化ソフトウェアによって、実行する計算機を分けるということを行っている（例えば SDPA クラスタは SDPARA 専用のクラスタ)。
2 のためには Eucalyptus という便利なツールがあるので試してみようと思っている。

某スパコンと SDPARA その４

別の問題で両計算機の性能を比較してみたが、やはり速度差は２倍程度になる。それはともかく、スパコンで実行と言っても通常の計算サーバのように使っているユーザが多いようだ。つまり並列化されていない（せいぜいスレッド並列ぐらい）ソフトウェアを大量にジョブマネージャーのキューに投入している（これならばスパコンでなくてクラウドで十分ではないだろうか）。自前で MPI 並列化されたソフトウェアを作成して実行しているユーザは本当に少ないようだ。

○ソフトウェア : SDPARA 7.3.2
○実験結果

SDPA クラスタ
16プロセス x 8スレッド : 4004.9s(24反復 : pdOPT)

某スパコン
128プロセス x 16スレッド : 1770.8s(24反復 : pdOPT)

○ SDPA クラスタ
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.4 for x86_64

○ 某スパコン
128 Nodes, 512 CPUs, 2048 CPU cores; (今回使用した分のみ)
CPU : AMD Opteron 8356 2.3GHz (quad cores) x 4 / node
Memory 32GB / node
NIC : GbE x 2 and Infiniband x 4 / node
OS : RHEL 4.x for x86_64

某スパコンと SDPARA その３

某スパコンと同時に研究室のクラスタ計算機もフル稼働状態になっている。先日も報告したように意外とスパコンとクラスタ計算機の速度差が無いのだが、スパコン側ではノード数が多いので、ノード数 x メモリ量の値が大きくなり非常に大きな問題を解くことができる。
しかし、結局以下の問題を解決しなければ、このまま計算の規模だけ大きくしていっても意味がない。
1: 数値精度の問題 : 大きな規模でdouble の10数桁の精度では完全に不足。ただし、４倍精度にすると大幅に速度が落ちる。
2: int 64bit 化の問題 : 本体だけならば対応は難しくないが、周辺のライブラリも合わせる必要があるので大変。

平成２２年度 第１回 SCOPE 研究会 再掲載

開催が１週間後になりましたので再掲載します。今後は参加者のために託児所も必要かもしれません。本当にいろいろとありましたが、2009 年度ももうすぐ終わります。しかし、日本OR学会では３月から新年度なので以下は 2010 年度の行事になります。以下のご講演は今まで最適化、OR系の場所ではほとんど触れられてこなかった内容だと思いますので、多くの方のご参加をお待ちしております。

2010年度 第１回研究会
日　時 ： 2010年03月27日（土）14:00～
会　場 ： 中央大学 後楽園キャンパス 6号館4階 6410号室

講演者：佐藤仁 (東京工業大学 学術国際情報センター)
講演題目： 大規模データ処理と最適化
講演概要：近年、科学技術計算において大量のデータに対する解析処理が広く行われている。多くの場合、このような処理は、スーパーコンピュータやクラウドのような大規模並列計算環境で行われるが、効率的に計算資源を利用するためには、最適化技術が不可欠である。この講演では、大規模並列計算環境でのデータ処理における最適化技術の応用事例として、複製配置を0-1整数計画問題としてモデル化したファイル複製配置最適化システム、及び、仮想マシンの移動を最短経路問題としてモデル化した大規模データアクセスの高速化技術、について紹介する。

講演者：竹房あつ子 (産業技術総合研究所 情報技術研究部門)
講演題目： 性能を保証する分散実行環境のためのコアロケーション手法
講演概要：グリッドとネットワーク資源管理技術により，複数の組織にある計算機やストレージなどの資源と広帯域ネットワークを必要に応じて組み合わせ，性能が保証された仮想的な利用環境を構築することが可能になった．この際，利用者の要求する計算機性能や通信帯域を保証しつつ，利用価格や資源の有効利用など，利用者や資源管理者の方針を考慮して，適切に資源を割り当てる（コアロケーション）必要がある．さらに，利用者の資源要求に対して即座に処理するためには，コアロケーションに要する時間も課題となる．
本研究では，資源が事前予約で複数の組織から提供されることを前提とし，利用者や資源管理者の方針が反映可能なコアロケーション手法を提案する．提案手法では，分散する計算機群とその間のネットワークのコアロケーションを最適化問題にモデル化し，複数の予約プランを作成して適切な資源群を確保する．評価では，コアロケーションの求解時間を制約条件とソルバの違いにより比較し，実用化に向けて議論する．

某スパコンと SDPARA その２

某スパコンと言っても下記の仕様を見れば、わかる人にはどこのスパコンなのかわかるだろうが、一つだけ実験結果を載せておく。CPU のクロック周波数等が異なるが、使用しているコア数が 2048/128 = 16倍になって、実行時間がたかだか２倍程度にしか速くならないのはやはり意外である。本当はプロセス数やコア数を同じにしたり適宜変更して実行してみれば、いろいろとわかるのだろうが、スパコンを借りられる期間が短いのと他にも解きたい問題があるので、その辺の実験は省略する。

○問題名 : H2O.1A1.DZ.pqgt1t2p.dat-s
○ソフトウェア : SDPARA 7.3.2
○実験結果

SDPA クラスタ
16プロセス x 8スレッド : 49037.9s(37反復 : pdOPT) : 約13時間37分

某スパコン
128プロセス x 16スレッド : 24850.4s(38反復 : pdOPT) : 約6時間54分

○ SDPA クラスタ
16 Nodes, 32 CPUs, 128 CPU cores;
CPU : Intel Xeon 5460 3.16GHz (quad cores) x 2 / node
Memory : 48GB / node
NIC : GbE x 2 and Myrinet-10G x 1 / node
OS : CentOS 5.4 for x86_64

○ 某スパコン
128 Nodes, 512 CPUs, 2048 CPU cores; (今回使用した分のみ)
CPU : AMD Opteron 8356 2.3GHz (quad cores) x 4 / node
Memory 32GB / node
NIC : GbE x 2 and Infiniband x 4 / node
OS : RHEL 4.x for x86_64

SCOPE@つくば -未来を担う若手研究者の集い2010-

SCOPE@つくば -未来を担う若手研究者の集い2010- の日時と場所が確定致しました。少し蒸し暑くなってくる頃ですが、会場は広い場所を確保致しましたので、狭苦しさや暑苦しさは無いと思います。一般講演や表彰については昨年とほぼ同じですが、特別企画については現在検討中です。

開催日 : 2010年6月26日(土), 27日(日)
会　場 : 筑波大学 春日キャンパス 講堂（予定）
参加費 : 無料（ただし, 宿泊, 懇親会への参加は有料）
事前登録 : 不要（ただし, 筑波大学の宿泊施設利用希望の場合は必要）

某スパコンと SDPARA

先方のご厚意により、某スパコンをしばらく大規模に使用できることになったので、現在いろいろと試している。スパコンの使用には慣れているつもりだったが、やはりご当地によって環境等が異なるので、使えるようになるまでは少し時間がかかった。いろいろと調べたので、もう反対にコンサルティング出来るぐらいまで来たのではないかと思う。
メーカー製のコンパイラと MPI での使用は諦めて、OpenMPI + Intel Compiler で SDPARA 本体, MUMPS, BLAS, LAPACK, BLACS, ScaLAPACK ライブラリを全てコンパイルし直した。現在の一番の問題はノード数が多いとやはり安定して動作しないことと、実験に再現性が無いことであろう。ノード数が多いと全てのノードが長時間安定して動かない。これは世界中のスパコンに共通した悩みになる。